Phase 5: Advanced & Multi-Cloud

Centralized networking, shared services & transit gateways

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

Imagine you're building a huge LEGO city, much bigger than just a few houses. You have all sorts of different buildings: a police station, a hospital, a huge grocery store, and lots of houses where your LEGO people live. Each of these important buildings is like a VPC (a Virtual Private Cloud), which is a special, private area in the cloud where your computer programs and data live. If every single one of your LEGO buildings needed its own direct road or pipe connecting it to every other building, your city would quickly become an impossible tangle of spaghetti roads, impossible to manage or keep safe.

Instead, what if you built a big, well-organized central transportation hub – like a main train station or a major downtown square? All your important buildings (your VPCs) would connect only to this central hub. When a LEGO person or a package (data) needs to go from the hospital to the grocery store, it first goes to the central hub. Then, the hub, acting like a super-smart traffic controller or "transit gateway," directs it safely and efficiently to the grocery store. This keeps your city tidy and easy to manage, because if you want to add a security checkpoint or a special fast lane, you only need to build it once in the central area. This clever way of connecting things is called "centralized networking."

This central hub is also perfect for things that everyone in your city needs. Think about a public library, the main post office, or the city’s power plant. It wouldn't make sense to build a separate library inside every single house or hospital, right? Instead, you’d build these important shared services once, right there in your central downtown area, near your main transportation hub. Any building needing the library simply sends a request to the hub, which routes them to the central library. In the cloud, these shared services are things like a main identity check (to see who is allowed where), a central phone book for all your computer programs, or a big security office that watches for any bad guys trying to get into your systems. So, when building large digital cities in the cloud, architects use centralized networking and shared services to keep everything organized and secure. This means you can create many different sections for your programs, knowing they can all talk safely and efficiently through that smart central hub. It makes managing, growing, and securing your virtual cities much easier, just like having a well-planned road system in a real city.

As you architect multi-account AWS environments through landing zones, managing network connectivity, security, and observability across dozens or even hundreds of VPCs becomes a critical challenge. Ad-hoc VPC peering rapidly devolves into an unmanageable mesh, hindering scalability and consistent policy enforcement. Centralized networking addresses this by establishing a 'hub' – typically a dedicated network or security VPC – where all ingress/egress traffic from 'spoke' application VPCs is routed. This hub-and-spoke model simplifies routing, enables centralized security inspection, and provides a single, controlled point of entry and exit for your entire cloud estate, drastically reducing operational overhead.

This centralized network hub is also fundamental for efficiently delivering shared services across your organization. Imagine common infrastructure like Active Directory (AD) for identity management, DNS resolvers, centralized logging aggregators, security tools (e.g., IDS/IPS), or proxy servers. Instead of deploying these services redundantly in every application account, or managing a complex web of individual peering connections for each service, they are provisioned once in a dedicated 'shared services' VPC. The centralized networking infrastructure then acts as the secure, high-bandwidth conduit, allowing all application VPCs to access these vital services seamlessly and scalably, without direct exposure or complex route management for every spoke.

AWS Transit Gateway (TGW) is the cornerstone service that enables this advanced, scalable centralized networking architecture. Functioning as a regional virtual router, TGW connects thousands of VPCs and on-premises networks (via VPN or Direct Connect) through a single, central gateway. Instead of creating a 'many-to-many' VPC peering spaghetti, you simply attach all your spoke VPCs—application, shared services, security inspection—to the Transit Gateway. This dramatically simplifies routing tables, provides a single aggregation point for network traffic, allows for flexible routing policies between attachments, and offers inherent high availability and scalability, transforming a fragmented network into a cohesive, manageable, and secure cloud backbone for your enterprise landing zone.

Key Takeaways

  • Centralized networking (hub-and-spoke) is crucial for managing network complexity in multi-account cloud environments, preventing VPC peering sprawl.
  • AWS Transit Gateway (TGW) is the core service for building this scalable hub-and-spoke architecture, acting as a regional cloud router.
  • Shared services (e.g., AD, DNS, logging) reside in a dedicated VPC and are accessed by spoke application VPCs through the centralized network hub (TGW).
  • This approach simplifies routing, enables consistent security policy enforcement, and provides a single point for ingress/egress control.
  • TGW offers inherent high availability and scalability, crucial for enterprise-grade cloud networks.

Code Example

terraform
resource "aws_ec2_transit_gateway" "main_tgw" {
  amazon_side_asn = 64512
  description     = "Main Transit Gateway for landing zone"
  tags = {
    Name = "prod-main-tgw"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "app_vpc_attachment" {
  vpc_id                = "vpc-0abc123def4567890" # Example: Application VPC ID
  transit_gateway_id    = aws_ec2_transit_gateway.main_tgw.id
  subnet_ids            = ["subnet-0123456789abcdef0", "subnet-0fedcba9876543210"] # Subnets for TGW ENIs in App VPC
  dns_support           = "enable"
  ipv6_support          = "disable"
  transit_gateway_default_route_table_association = true
  transit_gateway_default_route_table_propagation = true
  tags = {
    Name = "app-vpc-attachment-01"
  }
}

How this code works

This code establishes a centralized network hub, an AWS Transit Gateway, and connects an example application Virtual Private Cloud (VPC) to it. The aws_ec2_transit_gateway resource defines the Transit Gateway itself, giving it a description and an amazon_side_asn for Border Gateway Protocol (BGP) routing, which is a unique identifier within the AWS network. This resource effectively creates the main network "switchboard" for the landing zone, allowing many VPCs and on-premises networks to connect to a single point.

Next, the aws_ec2_transit_gateway_vpc_attachment resource creates the link between a specific vpc_id and the newly created transit_gateway_id. It requires subnet_ids within the attached VPC where the Transit Gateway's network interfaces will reside, enabling traffic flow. A crucial aspect for beginners is transit_gateway_default_route_table_association and transit_gateway_default_route_table_propagation both being set to true. This automatically configures routing by associating the VPC with the Transit Gateway's default route table and propagating its routes. While convenient for initial setup, disabling these for more complex routing requires understanding and managing Transit Gateway route tables manually, which can trip up a beginner expecting continued automatic behavior. Both resources use tags for organizational labeling.

Related Articles

Hand-picked reads to go deeper on landing zones & account strategy.

Back to Cloud Architect Roadmap