AWS transform high security documentation change
Summary
Expanded documentation about VMware network migration processes including IP migration strategies, VPC configuration generation steps, network resource tagging requirements, and detailed security group association logic
Security assessment
Added explicit guidance about securing sensitive mapping files containing VM-to-security-group associations ('Follow AWS best practices to secure these files'). Introduced security implications of IP assignment strategies (static IPs for access control) and warnings about modifying security group mapping files. Discusses conversion of NSX security policies to AWS security groups with specific attachment logic.
Diff
diff --git a/transform/latest/userguide/transform-vmware-migrate-network.md b/transform/latest/userguide/transform-vmware-migrate-network.md index 137786c88..1ef5daad2 100644 --- a//transform/latest/userguide/transform-vmware-migrate-network.md +++ b//transform/latest/userguide/transform-vmware-migrate-network.md @@ -5 +5 @@ -Network topologies +Network topologiesIP migration approachesGenerate VPC configurationTag network resourcesSecurity group association @@ -9 +9 @@ Network topologies -AWS Transform can migrate your VMware networks to AWS. You can use [RVTools](https://www.dell.com/en-us/shop/vmware/sl/rvtools), [Export for vCenter](https://github.com/awslabs/export-for-vcenter), or [Import/Export for NSX](https://github.com/awslabs/import-export-for-nsx/) to capture on-premises-network data, and then import that data. The choice of tool depends on the type of on-premises network that you have: +AWS Transform can migrate your VMware networks to AWS. The migration process translates your source environment configuration to an AWS-equivalent network. AWS Transform analyzes your source network data and translates your source network to these AWS networking resources as needed: VPCs, subnets, security groups, network access control lists (NACLs), NAT gateways, transit gateways, internet gateways, elastic IPs, routes, and route tables. AWS Transform then creates AWS CloudFormation templates and AWS Cloud Development Kit (AWS CDK) templates. You'll be able to review the generated network configuration, and then either deploy it on your own or ask AWS Transform to deploy it for you. @@ -11 +11,3 @@ AWS Transform can migrate your VMware networks to AWS. You can use [RVTools](htt - * If you have an NSX-defined network, upload an NSX configuration file imported using the Import/Export for NSX tool. +The translation process requires you to upload a configuration file from your source environment. You can use [RVTools](https://www.dell.com/en-us/shop/vmware/sl/rvtools), [Export for vCenter](https://github.com/awslabs/export-for-vcenter), or [Import/Export for NSX](https://github.com/awslabs/import-export-for-nsx/) to capture on-premises-network data, and then import that file to AWS Transform. The choice of tool depends on the type of source network that you have: + + * If you have an NSX-defined network, upload an NSX configuration file using Import/Export for NSX. @@ -15 +16,0 @@ AWS Transform can migrate your VMware networks to AWS. You can use [RVTools](htt - * If your administrative workstation does not run Windows, RVTools is not approved in your organization, or you want more granular control over the export file's contents, use an [Export for vCenter](https://github.com/awslabs/export-for-vcenter) file. @@ -18,0 +20,3 @@ AWS Transform can migrate your VMware networks to AWS. You can use [RVTools](htt +If your administrative workstation does not run Windows, RVTools is not approved in your organization, or you want more granular control over the export file's contents, use an [Export for vCenter](https://github.com/awslabs/export-for-vcenter) file, which generates a file in the same format as RVTools. + +Ensure that the target account has the required quotas. @@ -24 +28,5 @@ The official RVTools site is [ https://www.dell.com/en-us/shop/vmware/sl/rvtools -For vNetwork, AWS Transform groups VMs by vSwitch and VLAN, with VLAN presented under multiple vSwitches (except for VLAN 0). +AWS Transform analyzes your source network data and translates your source network to these AWS networking resources as needed: VPCs, subnets, security groups, network access control lists (NACLs), NAT gateways, transit gateways, internet gateways, elastic IPs, routes, and route tables. + +If you want the target network to contain different IP ranges than your source network you can modify your VPC CIDR ranges during migration. AWS Transform automatically propagates changes to subnets, route tables, and security groups, and then assigns static IPs based on the CIDR. This is best for applications requiring predictable network behavior, DNS management, or IP-based access control. IP addresses persist across instance restarts using Elastic Network Interfaces (ENIs). + +For NSX environments, you can choose to have AWS Transform automatically convert security policies and gateway policies to Security Groups, associating them with network interfaces based on VM external IDs and IP addresses. In this case you will not have the option to use dynamic IP assignment (DHCP) for your target instances because IP addresses aren't known until instance launch. @@ -26 +34,3 @@ For vNetwork, AWS Transform groups VMs by vSwitch and VLAN, with VLAN presented -For NSX networks, AWS Transform segments the network based on Tier-1 routers: It groups by Tier-1 routers, and collects segments. +AWS Transform then creates AWS CloudFormation templates and AWS Cloud Development Kit (AWS CDK) templates. + +Once the target network is generated, review the generated network configuration. You can either deploy it on your own or ask AWS Transform to deploy it for you. If you choose to let AWS Transform deploy the network for you, it also uses tools such as [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) to run an analysis to check connectivity between subnets across multiple VPCs and under the same VPC. If you choose to make changes to the generated configuration, you must deploy the modified configuration yourself. @@ -45 +55,93 @@ During the migration, you can choose one of two network topologies for the targe -For both topologies AWS Transform doesn’t open the communication to the internet. You must open it manually after taking appropriate security precautions. +By default AWS Transform doesn’t open the communication to the internet for either topology. Once you are ready to use your new network and have configured security precautions according to your company policies, you can manually open the network to the internet + +If you want fine-grained control over the communication between the VPCs, choose the **Isolated VPCs** option and modify the generated network to create the specific communication paths your require. + +## IP migration approaches + +AWS Transform offers three IP addressing strategies for your migration: + + * **IP Address Retention:** Keep original IP addresses during migration. Ideal for lift-and-shift scenarios with legacy applications that have hard-coded IP dependencies or existing firewall rules. + + * **Static IP Assignment:** You can modify VPC CIDR ranges during migration, and AWS Transform automatically propagates changes to subnets, route tables, and security groups, and then assigns static IPs based on the CIDR. This is best for applications requiring predictable network behavior, DNS management, or IP-based access control. IPs persist across instance restarts using Elastic Network Interfaces (ENIs). + + * **Dynamic IP Assignment (AWS DHCP):** Automatically assign IPs from subnet pools at instance launch. Optimal for cloud-native applications, auto-scaling workloads, and container orchestration (ECS, EKS, ASGs). Reduces operational overhead but requires applications to use DNS or service discovery. + + + + +###### Note + +IP strategy is set at the wave level. You can assign different strategies to specific servers by customizing the wave file. For example if you chose a static IP address approach for the wave, but want to assign a dynamic approach to a specific server, you would use `[RESET_VALUE]` as described in [Editing your configuration ](https://docs.aws.amazon.com/mgn/latest/ug/configuration-editing.html) In the _Application Migration Service user guide_. + +## Generate VPC configuration + +###### To import network data + + 1. In the **Job Plan** pane, choose **Migrate network**. + + 2. Expand **Generate VPC configuration**. + + 3. Choose **Import network data**. + + 4. In the **Network source data** section, either select an existing import, or choose **Upload file** to import a new file to add to the list, and then select the file that you uploaded. + + 5. In the **Network topology** section, the topology that you want AWS Transform to generate. + + 6. Choose **Generate VPC configuration**. + + 7. After AWS Transform generates a Amazon VPC configuration, choose **Review generated VPC configuration**. + +In this step you can choose to either **use the current configuation** or **Modify your VPC CIDRs**. You cannot modify the prefix length, which comes after the "/". + +To modify your VPC CIDRs: + + 1. In the **Generated VPCs** list provide your modified CIDRs. + + 2. Choose the **Regenerate network** button. + +Review the results and then choose to continue with network deployment or to repeat the **Modify your VPC CIDRs** and **Regenerate network** steps. + + 8. Review the generated network configuration, and then choose **Deploy using AWS Transform** or **Deploy on my own**. If you make changes to the generated configuration you have to deploy the modified configuration yourself. If you choose to let AWS Transform deploy the network for you, it uses tools such as [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) to run an analysis to check connectivity between subnets across multiple VPCs and under the same VPC. + + + + +## Tag network resources + +For AWS Transform to launch Amazon EC2 instances within your existing AWS network resources which were not created by AWS Transform, the target network resources must be tagged. You can ask AWS Transform to do the tagging for you, in which case it will tag **all** network resources that it finds in the target AWS account and AWS Region. You can also manually tag target network resources that you’ve created on your own with the following tags: + +Key: `CreatedFor` Value: `AWSTransform` + +Key: `ATWorkspace ` Value: `AWS Transform workspace the connector will be used in` + +## Security group association + +When you migrate networks from an NSX source environment, AWS Transform creates security groups based on your source environment configurations. AWS Transform converts the following NSX configurations to security groups: + + * Security policies and security policy rules + + * Gateway policies and gateway policy rules + + + + +The association is based on the `source_groups` for outbound communication, and on the `destination_groups` for inbound communication. During server migration (import inventory), AWS Transform uses the following logic to associate these security groups with the appropriate network interfaces: + + * Rules associated to a VM external ID are attached to all of the elastic network interfaces of the given VM. + + * Rules associated to an IP are attached to the network interface with the specific IP. + + * _Exclude_ rules are ignored. However, you can manually create replacements for them. + + + + +The association maintains the security rules specified in the inventory import. The migration process creates encoded mapping files, one per VPC in your Amazon S3 bucket, that link VM external identifiers and IP addresses to the security groups they should be bound to. Follow AWS best practices to secure these files because they contain sensitive information about mappings. For guidance, see [Data protection in AWS Transform](./data-protection.html). + +###### Important + +Do not modify these mapping files, as they are essential for proper security group association. Modifying these files will cause a failure during the import inventory phase. + +Security groups removed from the VPC after network deployment will not be associated with migrated servers. + +During import, AWS Transform automatically deduplicates security groups based on their ID so as to remove redundant assignments.