Solution 3: Sharing VPC interface endpoints - AWS Prescriptive Guidance
Use caseChallengesSolutionArchitectureImplementation stepsLimitationsDesign considerations

Solution 3: Sharing VPC interface endpoints

Use case

Your applications are mapped to different business units, and you want to migrate them to different AWS target accounts in the same Region for billing and isolation purposes.

Challenges

Multiple workload accounts increase both the administrative overhead and the cost of individual VPC interface endpoints in each account. Therefore, you might want to have fewer staging VPCs for Application Migration Service and centrally manage routing for the staging VPCs to reduce costs and administrative overhead.

Solution

Share VPC endpoints by using a shared staging area subnet, AWS Organizations, and AWS RAM. For more information about VPC sharing, see the Amazon VPC documentation.

Architecture

The following diagram illustrates the architecture for this solution.

Traffic flow for rehosting multiple accounts by sharing VPC endpoints.

The diagram illustrates the following traffic flow:

1. The Application Migration Service replication server queries the VPC+2 DNS to resolve the API endpoint for Application Migration Service, Amazon EC2, or Amazon S3.

2. The VPC+2 DNS resolves the private IP of the endpoint with the help of AWS managed private hosted zones and responds to the Application Migration Service replication server.

3-6. The replication server uses that IP to connect to the AWS service API through the interface endpoint for the service.

Implementation steps

  1. In the central networking account, create the staging VPC and subnet for Application Migration Service.

  2. Create endpoints for Application Migration Service, Amazon EC2, or Amazon S3 with private DNS names enabled. This creates an AWS managed private hosted zone and associates it with the staging VPC.

  3. Share the staging subnet with target application accounts in the same AWS organization and AWS Region.

  4. For hybrid connectivity between AWS and your on-premises data center (not shown in the previous diagram) use Transit Gateway, AWS Direct Connect or AWS Site-to-Site VPN with Route 53 Resolver endpoints, as shown in solution 1 and solution 2.

Limitations

  • The AWS accounts for the participant VPCs and the owner VPC have to be part of the same organization in AWS Organizations.

  • For a list of shareable resources, see the Amazon VPC documentation.

  • For VPC sharing limitations, see the Amazon VPC documentation.

Design considerations

  • To reduce your operational overhead, create a resource once, and then use AWS RAM to share that resource with other accounts. This eliminates the need to provision duplicate resources in every account and reduces operational overhead.

  • Simplify security management for your shared resources by using a single set of policies and permissions. If you create duplicate resources in your separate accounts, you have to implement identical policies and permissions and keep them synchronized across all accounts. Instead, you can manage all users who share an AWS RAM resource through a single set of policies and permissions. AWS RAM offers a consistent experience for sharing different types of AWS resources.

  • Provide visibility and auditability. View the usage details for your shared resources by integrating AWS RAM with Amazon CloudWatch and AWS CloudTrail. For more information, see Monitoring AWS RAM using EventBridge and Logging AWS RAM API calls with AWS CloudTrail in the AWS RAM documentation.