Phase 2: Core Cloud Services

VPC peering, transit gateways & hub-and-spoke topologies

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine your school is like a giant computer system in the cloud, and each classroom is a separate, private area where different computer programs or "virtual private clouds" (VPCs) live. Just like your math class works on numbers and your art class works on drawings, different VPCs handle different tasks – some for games, some for homework, some for shared school tools. Usually, these classrooms are totally separate, so the computers in one can't talk to the computers in another.

But sometimes, they do need to talk! Maybe your math class needs to send a special report directly to the principal's office (another VPC). The simplest way to do this is like building a secret, private hallway just between the math class and the principal’s office. This is called "VPC peering." It’s super fast and direct, great for when just two classrooms need to chat a lot, like an application needing a shared tool. But here’s the tricky part: if your math class has a secret hallway to the principal’s office, and the principal’s office has another secret hallway to the art class, the math class still can’t use the principal’s hallway to reach the art class. It only goes direct. If you have lots of classrooms, building a bunch of secret hallways between every single pair that needs to talk quickly becomes a giant, tangled mess, like spaghetti hallways everywhere!

To avoid this "spaghetti network" and make things much tidier, grown-ups use something called a "Transit Gateway." Instead of building all those individual secret hallways, imagine if every classroom simply had a door leading to one big, main school hallway. This main hallway is like the Transit Gateway. Now, if the math class needs to talk to the art class, it just sends its message into the main hallway, and the main hallway knows exactly how to get it to the art class.

This clever way of connecting classrooms to a central hallway is called a "hub-and-spoke" design, where the main hallway is the "hub" and all the classrooms are the "spokes." So, when you're designing really big computer systems in the cloud, this means you can easily add new sections or "classrooms" without having to build new messy connections everywhere. You just connect them to the main central hallway, and they can talk to anyone else connected there, keeping everything organized and easy to manage.

When building complex cloud environments, you'll often have multiple Amazon Virtual Private Clouds (VPCs) for different purposes, like development, production, shared services, or various applications. These VPCs are isolated by default. To enable direct communication between two of them, VPC peering is your simplest option. It creates a direct, private network connection between two VPCs using private IP addresses. Think of it as a dedicated cable connecting two specific offices. It's great for scenarios needing high bandwidth and low latency between a couple of VPCs, for instance, connecting an application VPC to a shared services VPC that hosts your Active Directory or a central logging solution. However, peering connections are non-transitive – if VPC A is peered with VPC B, and B is peered with C, A cannot directly communicate with C via B. This limitation means managing a mesh of peering connections becomes cumbersome and complex as your number of VPCs grows, often leading to a "spaghetti" network.

To overcome the scalability and management challenges of VPC peering, especially in larger organizations or multi-account setups, AWS Transit Gateway (TGW) steps in as a game-changer. A TGW acts as a centralized network hub, allowing you to connect thousands of VPCs and on-premises networks to a single gateway. Instead of individual peering connections, each VPC attaches to the TGW, and the TGW handles the routing between them. This fundamentally shifts your network from a complex mesh to a simplified hub-and-spoke model. TGWs provide transitive routing, meaning any VPC attached to the TGW can communicate with any other attached VPC (given correct routing tables and security groups), making network architecture significantly more manageable and scalable. They also support inter-region peering, allowing you to extend your hub-and-spoke network across different AWS regions.

The hub-and-spoke topology is an architectural pattern that strongly emerges from using AWS Transit Gateway. In this model, the Transit Gateway serves as the central "hub," and your individual application VPCs, shared services VPCs, and even on-premises connections act as "spokes." This design simplifies routing significantly: all traffic between spokes must pass through the central hub. This centralization makes it easier to implement network segmentation, apply consistent security policies (e.g., routing all internet-bound traffic through a central egress VPC for inspection), and manage network changes. It reduces operational overhead by consolidating network connectivity and routing decisions, making it the preferred approach for enterprise-scale cloud networks seeking better control, scalability, and security posture.

Key Takeaways

  • VPC Peering provides a direct, private connection between two VPCs; it's simple for limited connections but does not scale transitively.
  • AWS Transit Gateway (TGW) acts as a centralized network hub, enabling transitive routing between many VPCs and on-premises networks.
  • A Hub-and-Spoke topology uses a TGW as the 'hub' and individual VPCs as 'spokes' to simplify routing and network management.
  • TGW significantly improves network scalability, simplifies management, and enables centralized security policy enforcement across your cloud environment.
  • Choose peering for 1:1, low-complexity connections; opt for TGW and a hub-and-spoke model for enterprise-scale, multi-VPC, multi-account, or hybrid cloud networks.

Code Example

terraform
resource "aws_ec2_transit_gateway" "example" {
  description = "Central Transit Gateway for all VPCs"
  tags = {
    Name = "MyCentralTGW"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "app_vpc_attachment" {
  subnet_ids         = ["subnet-0abcdef1234567890", "subnet-0fedcba9876543210"]
  transit_gateway_id = aws_ec2_transit_gateway.example.id
  vpc_id             = "vpc-0applicationvpc"
  tags = {
    Name = "ApplicationVPC-Attachment"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "shared_services_vpc_attachment" {
  subnet_ids         = ["subnet-0123456789abcdef", "subnet-0fedcba987654321"]
  transit_gateway_id = aws_ec2_transit_gateway.example.id
  vpc_id             = "vpc-0sharedservicesvpc"
  tags = {
    Name = "SharedServicesVPC-Attachment"
  }
}

How this code works

This code establishes a central networking hub using an AWS Transit Gateway, then connects two Virtual Private Clouds (VPCs) to it. This creates a "hub-and-spoke" topology, allowing vpc-0applicationvpc and vpc-0sharedservicesvpc to communicate with each other, and potentially other connected networks, through the Transit Gateway. This simplifies network architecture by eliminating the need for individual, direct connections (like VPC peering) between every pair of VPCs as the network grows.

First, the aws_ec2_transit_gateway resource provisions the central hub itself, named MyCentralTGW. Once the Transit Gateway exists, the aws_ec2_transit_gateway_vpc_attachment resources connect specific VPCs to this central hub. One attachment links vpc-0applicationvpc and another connects vpc-0sharedservicesvpc. Each attachment specifies the transit_gateway_id to link to the correct hub and provides subnet_ids from the respective VPCs. A subtle but important detail is that while subnet_ids are required, they are not used for routing traffic; instead, they define which Availability Zones the attachment can use within the VPC, which is crucial for high availability and for deploying the Transit Gateway's network interfaces (ENIs) in those subnets. Route tables within the VPCs and on the Transit Gateway (not shown here) are then updated to direct traffic through these attachments.

Related Articles

Hand-picked reads to go deeper on vpc design & network architecture.

Back to Cloud Architect Roadmap