Every VMware-to-AWS migration has a security checkpoint that most teams blow past: the moment between generating the target AWS environment and actually deploying it. AWS Transform for VMware creates that checkpoint deliberately when it produces CloudFormation templates for your target network and then waits for you to approve them. This is the time to inspect and harden the templates, before a single resource is provisioned. That design choice can be foundational for your secure migration, but only if you use it.

This post covers the security architecture of AWS Transform for VMware and AWS Application Migration Service (MGN), the controls AWS provides by default, and the controls you need to add for a production-grade migration. I’ll focus on three areas: network and replication security, encryption, and identity and access management.

How AWS Transform and MGN Work Together

AWS Transform for VMware orchestrates the end-to-end migration of VMware workloads to Amazon EC2. It handles discovery, network conversion, wave planning, and migration execution. Within that process, MGN handles the actual block-level server replication and cutover.

The flow moves through four stages: Discovery (ingesting VMware environment data and mapping dependencies), Network Conversion (generating CloudFormation templates that translate VMware network topology into VPCs, subnets, security groups, and gateways), Wave Planning (using dependency analysis to group workloads into migration waves), and Replication/Cutover (block-level replication from on-premises hosts to EC2 via the AWS Replication Agent).

I recommend a multi-account staging architecture: discovery data, planning artifacts, and target workloads are isolated in separate AWS accounts, each with its own IAM boundaries and encryption keys. Transform’s process ends with MGN launching EC2 instances into a Staging account. From there, another tool or process moves workloads into their final Target accounts.

Identity and Access Management

IAM gets far less attention than network and encryption in migration security discussions, even though a misconfigured IAM policy can undermine every other control you’ve put in place.

Replication Agent credentials: When you install the Replication Agent, you provide IAM access keys for initial registration. MGN does not automatically delete these keys after installation. Scope the installation IAM user to minimum permissions, and deactivate or delete those keys immediately after the agent registers successfully. The agent uses its established trust and temporary credentials from that point forward.

MGN service permissions: MGN uses a service-linked role with broad permissions by design. You can’t edit it directly, but you can control who invokes high-impact MGN actions (StartReplication, StartCutover, StartNetwork, FinalizeCutover) by restricting them to specific IAM roles. Use SCPs to prevent MGN actions in non-migration accounts, and enforce separation of duties between replication configuration and cutover execution.

Multi-account IAM boundaries: The multi-account architecture only provides isolation if cross-account roles use explicit Condition blocks (aws:SourceAccount, aws:PrincipalOrgID), trust policies limit assumption to specific accounts, and CloudTrail is enabled everywhere so cross-account role assumptions are logged.

Network and Replication Security

The Replication Agent communicates over two encrypted channels: a control-plane path (TCP 443 to the MGN API) and a data-plane path (TCP 1500 to Replication Servers). All communication uses TLS 1.2 with Perfect Forward Secrecy. Each Replication Server receives a unique TLS certificate validated by its corresponding agent, preventing man-in-the-middle attacks. Data is encrypted on the source before transmission and decrypted only after arrival in the staging subnet.

The risk: MGN creates a security group that opens inbound TCP 1500, and Replication Servers get public IPs by default. If you leave the security group open to 0.0.0.0/0, your Replication Servers accept connections from the entire internet. The data is encrypted in transit, but “encrypted over the internet” and “encrypted over a controlled path” are not equivalent from a risk posture standpoint.

Instead, restrict inbound rules to your actual source server CIDR. For environments with private connectivity, enable “Use private IP” in MGN replication settings to route data over VPN or Direct Connect, disable public IP creation on Replication Servers, and ensure outbound access to AWS services through NAT or VPC endpoints. For fully locked-down environments, AWS Prescriptive Guidance describes a private architecture using VPC endpoints for S3, MGN, and EC2, with Site-to-Site VPN or Direct Connect for the replication data path.

Encryption: Data at Rest and in Transit

MGN’s replication encryption protects the source-to-AWS transfer. EBS encryption protects everything after that: replicated data on AWS storage, snapshots, and data in transit between EC2 instances and attached volumes. These are complementary layers, not redundant ones.

EBS encryption provides AES-256 encryption for data at rest, data in transit between instances and storage, and all snapshots. Encryption is a one-way door: you cannot disable it on an existing encrypted volume or snapshot. Configure encryption in MGN Replication Server settings before starting replication. Changing the key after replication begins forces a full data resync, which can significantly impact migration schedules for large workloads.

If using a multi-account setup, create your KMS key in the Target account and configure cross-account access from the Staging account. This way, when instances are created in the Target account, they’re already encrypted with the appropriate key.

AWS Transform adds its own encryption layer: TLS 1.2+ for all communication, and KMS encryption for all stored data (customer inputs, artifacts, discovery data). The result is encryption at every stage from source environment through transit, at rest on EBS, and within the Transform service itself.

Preventive and Detective Controls

Because Transform produces CloudFormation templates before deploying them, you have a natural integration point for preventive controls. AWS Control Tower supports proactive controls implemented as CloudFormation hooks that evaluate resources before provisioning. Noncompliant security groups, missing encryption, or prohibited networking patterns get caught before any resource is created. This requires configuration, but once set up, every Transform-generated template passes through your governance checks.

After deployment, layer on detective controls: AWS Config conformance packs for compliance checks, Security Hub to aggregate findings from Config, GuardDuty, Inspector, and IAM Access Analyzer, and GuardDuty for threat detection on migrated workloads, especially useful in the first weeks after cutover.

For auditability, both Transform and MGN integrate with CloudTrail. Use CloudTrail Lake for long-term retention and SQL-based queries of migration events. AWS Audit Manager complements this by automatically collecting evidence and supporting manual uploads for migration artifacts that aren’t automatically discoverable: approved exceptions, runbooks, signoffs, and architecture review documents.

Deployment and Post-Cutover Hardening

When Transform generates your target network configuration, the security groups are based on your source VMware firewall rules. Before deploying, review them for overly broad CIDR ranges, unnecessary legacy port exposure, missing egress restrictions (AWS allows all outbound by default), and protocol mismatches from the translation.

After cutover, don’t carry permissive staging rules into production. When using a Staging account, the security groups there may not fully represent what’s needed in the Target account. Treat the staging environment with appropriate security standards regardless: the staging subnet may be exposed to the internet, which means your cutover EC2 instances are exposed as well.

Conclusion

AWS Transform for VMware and MGN provide a well-integrated migration path with security controls at every layer: TLS 1.2 with PFS on the replication stream, EBS encryption at rest, multi-account isolation, and CloudTrail integration for audit. But these controls are a foundation, not a finished product.

The migrations that hold up under scrutiny are the ones where the team added their own controls on top: security groups scoped to real source CIDRs, IAM policies that enforce separation of duties, proactive governance checks on generated infrastructure, and an evidence trail that covers both automated findings and human approvals. The shared responsibility model applies fully here. AWS secures the platform and provides the primitives. You configure them correctly, maintain that posture through cutover, and carry it into production.

References

• Security in AWS Application Migration Service
• Infrastructure security in AWS Application Migration Service
• Network requirements for Application Migration Service
• Security in AWS Transform
• Data encryption in AWS Transform
• Migrate and modernize VMware workloads with AWS Transform for VMware
• Amazon EBS encryption
• Migrating on-premises servers to AWS over private networks
• AWS Control Tower proactive controls
• AWS Audit Manager