mkl

log: 3

Scaling Network Connectivity from Point-to-Point Connections to a Hub-and-Spoke Network Architecture

7/31/2023

AWS Transit GatewayAmazon EC2Amazon VPCNetworking

In this log, we’ll review a valuable solution to provision and manage network connectivity between VPCs from existing point-to-point connections to a hub-and-spoke network architecture with AWS Transit Gateway.

Let’s dive in.


Customer Needs

The customer has established private connectivity to their VPCs through VPC peering connections on AWS. (They currently have three instances running.) Managing their point-to-point connections will be harder to scale as the customer adds more VPCs to their workload.

The customer needs a solution to provision and manage reliable network connectivity between their current VPCs and also plan for additional instances.


Current Architecture

VPC peering with EC2 Diagram

The current architecture VPC peering connections established from Instances A and B and Instances A and C.


Objectives


Note:

If you decide to recreate this solution for demo purposes, make sure to review the Region selector to ensure that the Region is set to your corresponding workload location settings. In my case, it’s set to N. Virginia (us-east-1).


Remove VPC peering connections

The customer mentioned that VPC A has peering connections to VPC B and C, respectively. Let’s look at the VPC Dashboard in the AWS Management Console and open up EC2 to check the peering connections.

The current VPC peering connections:

AWS VPC Dashboard - peering Connections

VPC A has two peering connections to VPC B and C, respectively.

Navigate to EC2 from the search bar and click “Instances.” Notice the 4 instances currently running.

AWS EC2 Dashboard - Instances

I’ll connect to “Spacecraft B Instance” via Session Manager.

Once a session starts, I’ll ping to test the connectivity between Spacecraft B Instance and Spacecraft A Instance. All packets were transmitted and received between both instances.

ping 10.0.0.10

Next, I test the connectivity between Spacecraft B Instance and Spacecraft C Instance. None of the packets were transmitted and received between both instances.

ping 10.2.0.10
EC2 Session Manager

Now that we’ve understood what is working and connected, we can remove the peering connections and route table entries back in the VPC Dashboard.

AWS VPC Dashboard - Peering connections

Create / Configure a Transit Gateway using AWS Transit Gateway, and add a 4th VPC to the Transit Gateway

There are a few parts to replacing the peering connections with AWS Transit Gateway.

I’ll create a Transit Gateway in the VPC dashboard to replace the peering connections.

AWS VPC Dashboard - Transit Gateway

I added an optional tag, “Spacecraft-TGW” a default Amazon side Autonomous System Number (ASN), “64512”

Next, I will create separate subnets for each transit gateway VPC attachment.

AWS VPC Dashboard - Subnets AWS VPC Dashboard - Subnets AWS VPC Dashboard - Subnets
  • VPC A - AZ1 TGW (10.0.2.0/28)
  • VPC A - AZ2 TGW (10.0.3.0/28)
  • VPC B - AZ1 TGW (10.1.2.0/28)
  • VPC B - AZ2 TGW (10.1.3.0/28)
  • VPC C - AZ1 TGW (10.2.2.0/28)
  • VPC C - AZ2 TGW (10.2.3.0/28)
  • VPC D - AZ1 TGW (10.3.2.0/28)
  • VPC D - AZ2 TGW (10.3.3.0/28)

Using a separate subnet allows you to configure the following:

  • Keep inbound and outbound network ACLs, associated with the transit gateway subnets, open.
  • You can apply network ACLs to your workload subnets depending on your traffic flow.

Next, I’ll need to create a Transit Gateway attachment for each VPC from the VPC Dashboard.

AWS VPC Dashboard - Transit gateway attachments AWS VPC Dashboard - Transit gateway attachments
  • Name tag - VPC A Attachment
  • Transit gateway ID - Spacecraft-TGW
  • VPC ID - Spacecraft-A VPC
  • Subnet IDs - VPC A - AZ1 TGW, VPC A - AZ2 TGW

When you connect resources to a transit gateway in a specific Availability Zone, you must ensure that a subnet is enabled in that AZ. For the traffic to be correctly sent to the transit gateway, the transit gateway must have an attachment in the subnet of that same Availability Zone, and the subnet’s route table must include a route that points to the transit gateway. This way, resources in the specified zone can communicate with the transit gateway effectively.

AWS VPC Dashboard - Transit gateway attachments

AWS Transit Gateway attachment serves as both a source and destination of packets. When one or more VPCs are attached, AWS Transit Gateway deploys an elastic network interface within VPC subnets to route traffic. You must have at least one subnet per Availability Zone to enable traffic flow across all subnets within the zone.


Update the VPC route tables to point to the transit gateway

To ensure that my three routes for each VPC attachment is displayed, I’ll need to check the Transit gateway route tables tab in the VPC Dashboard.

AWS VPC Dashboard - Transit gateway route tables

Great, let’s check the Route table tab to add routes to the subnet route table.

AWS VPC Dashboard - Route tables - Edit Routes

I used “10.0.0.0/8” for the Destination to keep the configuration simple since the local route is more specific and 10.0.0.0/16 will traverse the more specific local route to the VPC. Any other traffic for 10.0.0.0/8 will traverse the less specific route (10.0.0.0/8) to the transit gateway.

For the Target: I typed “tgw-” to find the VPC A attachment.

AWS VPC Dashboard - Route tables - VPC D

Once I’ve saved my route changes, the Route table should show a new route under the corresponding VPC.

When you attach a VPC to a transit gateway, you must add a route to your subnet route table for traffic to route through the transit gateway.


Verify connectivity between VPCs using AWS Transit Gateway

It’s now time to check if the VPCs are using AWS Transit Gateway and can communicate with each other.

I’ll go back to the EC2 Dashboard, Spacecraft B Instance, and use Session Manager to ping another Instance to verify the connection.

EC2 Session Manager

Ping Spacecraft B Instance (ping 10.0.0.10) from Spacecraft A Instance to verify connectivity.

Ping Spacecraft B Instance (ping 10.2.0.10) from Spacecraft C Instance to verify connectivity.

Ping Spacecraft B Instance (10.3.0.10) from Spacecraft D Instance to verify connectivity.

Awesome! Now Spacecraft B Instance can communicate with Spacecraft C Instance without being directly peered. In addition, our new Spacecraft D Instance also doesn’t need to be directly peered, making this solution a more scalable approach compared to a VPC peer connection.


Solution Architecture

VPC peering with EC2 Diagram

A fourth VPC is created and added to the current workload. An Internet Gateway is attached to all VPCs and removes the VPC peering connections, and an AWS Transit Gateway is utilized as a centralized hub allowing transitive routing between VPCs.


Conclusion

VPC peering is ideal for scenarios where you want to establish direct and simple communication between specific VPCs. It is easy to set up and is well-suited for scenarios where you have limited VPCs that need to exchange traffic.

AWS Transit Gateway is designed for more complex networking architectures and scenarios where you need to connect multiple VPCs together and have full mesh connectivity for hub-and-spoke network architectures, where you need to connect multiple VPCs and enable transitive routing for better scalability and manageability.

It supports transitive routing, allowing VPCs attached to the Transit Gateway to communicate with each other, even if they are not directly peered. AWS Transit Gateway also supports VPN and Direct Connect connections, allowing you to extend your on-premises network into the cloud.


I’ve had such a blast diving into AWS Transit Gateway and learning more about it, and I hope you had just as much fun on this journey!

I’m genuinely passionate about sharing my discoveries and curiosities with others, and I truly hope you found this as enjoyable as I did.