AWS transform documentation change
Summary
Removed detailed sections about IP migration strategies, VPC configuration generation, network resource tagging, and security group association processes. Simplified document to focus only on network topologies.
Security assessment
The removed content included security-related guidance about securing mapping files and security group associations, but the deletion itself doesn't indicate resolution of a specific vulnerability. The change appears to be a documentation simplification rather than a security fix. No evidence of addressing an active security issue is present in the diff.
Diff
diff --git a/transform/latest/userguide/transform-vmware-migrate-network.md b/transform/latest/userguide/transform-vmware-migrate-network.md index c8d79e87a..d31dfc3ac 100644 --- a//transform/latest/userguide/transform-vmware-migrate-network.md +++ b//transform/latest/userguide/transform-vmware-migrate-network.md @@ -5 +5 @@ -Network topologiesIP migration approachesGenerate VPC configurationTag network resourcesSecurity group association +Network topologies @@ -47,99 +46,0 @@ For both topologies AWS Transform doesn’t open the communication to the intern -## 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:** Assign new fixed IP addresses from your VPC CIDR block. You can modify VPC CIDR ranges during migration, and AWS Transform automatically propagates changes to subnets, route tables, and security groups. 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. - - - - -IP strategy is set at the wave level, with the option to override specific instances through inventory file customization. - -### DNS and network considerations - -Your DNS strategy should align with your IP addressing choice: - - * **Static IP DNS:** DNS entries point directly to fixed IPs, simplifying resolution for legacy systems but requiring manual updates when IPs change. - - * **Dynamic IP DNS:** Services accessed via DNS names that resolve to current IPs, supporting auto-scaling and failover through Route 53 or Cloud Map service discovery. - - * **Hybrid DNS Architecture:** Enterprise pattern using on-premises DNS initially, implementing conditional forwarders between on-premises and Route 53 during migration, then gradually transitioning to Route 53 post-migration. - - - - -For NSX environments, AWS Transform automatically converts security policies and gateway policies to Security Groups, associating them with network interfaces based on VM external IDs and IP addresses. However, for DHCP assignments in NSX environments, automatic Security Group generation is currently limited because IP addresses aren't known until instance launch. - -## 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 modify your VPC CIDRs. - - 1. In the **Generated VPCs** list provide your CIDRs - - 2. Choose the **Regenerate network** button and review the results. - - 8. Ensure that the target account has the required quotas. - - - - -AWS Transform then analyzes your source network data and translates your source network to the following 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. Review the generated network configuration, and then either deploy it on your own or ask AWS Transform to deploy it for you. However, 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 will also use tools such as Reachability Analyzer to run an analysis in order 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 tag: - -Key: `CreatedFor` Value: `AWSTransform` - -## 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. -