Multi-Region Networking on AWS

Multi-Region Networking on AWS

Master Multi-Region AWS Connectivity by diving into setting up Transit Gateway peering!

Published Mar 31, 2024

Building a Multi-Region AWS Network for a Real Estate Startup

In this guide, we dive into constructing a secure, scalable, and resilient network infrastructure on AWS for a real estate startup focusing on transforming abandoned commercial spaces into residential apartments. With operations centered in New York City and San Francisco, the startup requires an AWS setup that supports high availability and seamless inter-region connectivity.


Before starting, ensure you have an AWS account as well as some familiarity with AWS services including VPC, EC2, Transit Gateway, and Route 53.

Create Regional Virtual Private Clouds (VPCs)

Start with setting up two VPCs, representing New York City and San Francisco.

New York City VPC (us-east)

  1. Navigate to the VPC Dashboard in the AWS Management Console.
  2. Create a new VPC named nyc-vpc with a CIDR block

San Francisco VPC (us-west)

  1. Switch your region to us-west in the AWS Console.
  2. Repeat the VPC creation process, this time naming the VPC sf-vpc with a CIDR block

Subnets and Internet Gateway Attachment

For each VPC, create a public subnet and attach an internet gateway to enable external access.
  • Public Subnets: Create in nyc-vpc and in sf-vpc.
  • Internet Gateways: Attach a new internet gateway to each VPC for internet access.

AWS Transit Gateway for Inter-Region Connectivity

AWS Transit Gateway simplifies networking across multiple VPCs and regions by acting as a network transit hub.
  1. Create a Transit Gateway named US-Coastal-TGW-1 with default route table association and propagation enabled, in the us-east-1 region, the another one US-Coastal-TGW-2 in the us-west-1 region.
  2. Create Transit Gateway Attachments for both VPCs, connecting them to the respective Transit Gateways.
  3. Create Transit Gateway Peering Attachment between the two Transit Gateways to enable inter-region communication.
  4. Update Route Tables in each VPC to route traffic through the Transit Gateway through the private subnets.
Attaching your Virtual Private Clouds (VPCs) to an AWS Transit Gateway (TGW) establishes a centralized hub to manage network traffic across your VPCs, enabling the east and west coast networks to communicate with each other. Here’s a simplified step-by-step guide on how to attach both VPCs to the Transit Gateway:

Step 1: Navigate to the Transit Gateway Dashboard

  1. Open the AWS Management Console and go to the VPC Dashboard.
  2. In the navigation pane, under Transit Gateway, select Transit Gateways.

Step 2: Create a Transit Gateway

If you haven't already created a Transit Gateway:
  1. Click Create Transit Gateway.
  2. Provide a Name tag and Description for your Transit Gateway, such as US-Coastal-TGW-1.
  3. Ensure Default route table association and default route table propagation are enabled to simplify routing.
  4. Click Create Transit Gateway.
  5. Repeat this process to create a Transit Gateway for the West Coast, e.g., US-Coastal-TGW-2.

Step 3: Attach Your VPCs to the Transit Gateway

For each VPC (NYC-VPC and SF-VPC):
  1. In the left navigation pane, under “Transit Gateway,” click on “Transit Gateway Attachments.”
  2. Click on the “Create Transit Gateway Attachment” button.
  3. In the attachment configuration:
    • Attachment name tag: Give your attachment a meaningful name, like NYC-VPC-Attachment.
    • VPC ID: Select the VPC you are attaching, starting with the NYC VPC.
    • Subnet IDs: Choose one or more subnets within your VPC where the Transit Gateway will route traffic. It's best to select subnets across different Availability Zones for redundancy. Usually, this is done for private subnets.
    • Repeat this process for the SF VPC, ensuring both are attached to the TGW.
  4. Repeat this process for the West Coast VPC, attaching it to the US-Coastal-TGW-2.

Step 4: Create a Transit Gateway Peering Attachment

To enable inter-region communication between the Transit Gateways, you need to make a peering attachment:
  1. In the Transit Gateway Attachment dashboard, click on Create transit gateway attachment.
  2. Select Transit Gateway peering attachment.
  3. Choose the other Transit Gateway as the Acceptor and enter the ID of the transit gateway to peer with.
  4. Create the attachment.
  5. Switch to the other region to accept the peering attachment in the other Transit Gateway.

Step 5: Update Transit Gateway Route Tables

After adding the peering connection, you need to add a static route on your transit gateway route table to route traffic to the other region:
  1. Navigate to the Transit Gateway Route Tables associated with your Transit Gateway.
  2. Select the route table, then click on Routes > Create static route.
  3. Add route:
    • CIDR: For the SF Transit Gateway, enter the CIDR block of the NYC VPC, and vice versa.
    • Attachment: Select the Transit Gateway Peering Attachment.
  4. Save changes.
  5. Repeat this process for the other Transit Gateway. You should now have two routes on each transit gateway route table.

Step 4: Update VPC Route Tables

After finishing setting up the transit gateway and attachments, you need to update the route tables in each VPC to ensure traffic destined for the other VPC is routed through the Transit Gateway. We will be adding routs for our private subnets, we will use the tables that are associated with the private subnets.
  1. Navigate to the Route Tables associated with your VPCs.
  2. Select the route table, then click on Routes > Edit routes.
  3. Add route:
    • Destination: For the SF VPC, enter the CIDR block of the SF VPC, and vice versa.
    • Target: Select the Transit Gateway VPC attachment.
  4. Save changes.

Step 5: Testing Connectivity

To validate the setup, we will launch some EC2 instances in each VPC and test connectivity (e.g., ping or SSH) between the two instances across the Transit Gateway. You will notice the public instances cannot communicate with each other, but the private instances can.
Following these steps will establish a network bridge between your east and west coast networks, enhancing your startup's infrastructure with seamless inter-region connectivity on AWS.

Launch EC2 Instances in Each Region

Deploy an EC2 instance in each VPC to simulate application servers.
  1. Launch a Public EC2 instance in the nyc-vpc, within the public subnet, configuring it as a web server.
  2. Launch a Private EC instance in the nyc-vpc, within the private subnet, for internal services.
  3. Repeat for the sf-vpc, ensuring both instances are in public and private subnets and can access one another.
  • EC2 Instances: launch a public server in each instance and launch a private server in each instance. You can install Apache on the public servers.

Validate EC2 Instances Communication

To ensure the network is correctly configured, verify that the instances can communicate across regions.
  1. SSH into the NYC instance using its public IP.
  2. Ping the San Francisco instance from the New York instance using the SF instance's private IP.

Configure Amazon Route 53 for DNS Management

Amazon Route 53 ensures your domain's traffic is efficiently managed and directed using geolocation.
  1. Register a domain for your real estate startup, e.g., realestatestartup.com.
  2. Create a hosted zone for your domain in Route 53.
  3. Create two record sets:
    • nyc.realestatestartup.com pointing to the NYC VPC resources.
    • sf.realestatestartup.com pointing to the SF VPC resources.
  4. Set up DNS records for nyc.realestatestartup.com and sf.realestatestartup.com pointing to resources in the respective VPCs.
  5. Test the DNS resolution by pinging the domain names from your local machine.

Final Thoughts

By completing these steps, the real estate startup has established a robust AWS network spanning New York City and San Francisco. This network foundation supports high availability and efficient inter-region connectivity, crucial for delivering a seamless user experience across the startup's digital platform.