AWS Transit Gateway

AWS Transit Gateway is a regional network transit hub that you use to interconnect your virtual private clouds (VPCs) and on-premises networks. As your cloud infrastructure grows, you may have dozens or hundreds of VPCs. Traditionally, to connect VPCs together, you would use VPC peering. However, VPC peering has several limitations: it's a one-to-one connection, does not support transitive routing (if VPC A is peered with VPC B and VPC B is peered with VPC C, traffic cannot flow from A to C through B), and managing hundreds of peering connections becomes operationally complex. Transit Gateway solves this by providing a central hub that all VPCs and on-premises networks attach to. It uses a hub-and-spoke model, where the Transit Gateway acts as the hub, and each VPC or VPN connection is a spoke. This allows transitive routing between all attached networks without the need for individual peering connections.

Transit Gateway is a fully managed service. When you create a Transit Gateway, AWS provisions a highly available, scalable router in the region. You then create attachments to connect your VPCs, VPN connections (from on-premises or other clouds), AWS Direct Connect gateways, and even other Transit Gateways (via peering). Each attachment is associated with a route table. Transit Gateway uses route tables to determine where to send traffic. You can create multiple route tables to isolate networks (e.g., production vs. development) or to control routing policies. For example, you can have a route table that only allows traffic between specific VPCs, while another route table allows all traffic.

Behind the scenes, Transit Gateway uses the AWS global network infrastructure to route traffic efficiently. It supports multicast and can handle up to 50 Gbps per attachment (default limit, can be increased). Transit Gateway also integrates with AWS Network Manager to provide a centralized view of your global network.

Transit Gateway has two main pricing components: an hourly charge for each Transit Gateway you create (currently $0.05 per hour in most regions) and a per-GB data transfer charge for data processed by the Transit Gateway (e.g., $0.02 per GB for intra-region transfers). There is also a charge for each attachment (e.g., VPC attachment costs $0.05 per hour). Note that data transfer between VPCs via Transit Gateway is charged at the standard inter-AZ or inter-region data transfer rates, which can add up.

There is no tiered pricing for Transit Gateway itself—it's a flat hourly rate plus usage charges. However, you can use Transit Gateway with AWS Organizations to manage multiple accounts centrally.

Before Transit Gateway, the primary AWS solution for connecting multiple VPCs was VPC peering. VPC peering is a one-to-one connection that does not support transitive routing. So if you have 10 VPCs, you would need up to 45 peering connections (n*(n-1)/2) to fully mesh them. Transit Gateway reduces this to 10 attachments (one per VPC). Additionally, VPC peering does not support overlapping CIDR blocks, while Transit Gateway can handle overlapping CIDRs with careful route table design (though it's not recommended). For hybrid connectivity, you can use AWS VPN or Direct Connect to connect your on-premises network to Transit Gateway, enabling connectivity to all attached VPCs. Without Transit Gateway, you would need a separate VPN connection for each VPC.

Another alternative is the Third-party virtual firewall or router in a VPC (e.g., Cisco CSR), but that requires manual management and scaling. Transit Gateway is fully managed and scales automatically.

Use Transit Gateway when you need to connect multiple VPCs (more than three or four) and need transitive routing. Also use it when you need to connect on-premises networks to multiple VPCs via VPN or Direct Connect. For a simple connection between two VPCs, VPC peering is simpler and cheaper. For connecting a single VPC to an on-premises network, a direct VPN or Direct Connect connection may be sufficient. Use Transit Gateway when you anticipate growth or need centralized network management. On the CLF-C02 exam, look for scenarios with "many VPCs" or "hybrid connectivity" that require "transitive routing"—Transit Gateway is the answer.

To create a Transit Gateway and attach a VPC using the AWS CLI:

# Create a Transit Gateway
aws ec2 create-transit-gateway --description "MyTGW" --region us-east-1

# Create a VPC attachment
aws ec2 create-transit-gateway-vpc-attachment \
    --transit-gateway-id tgw-0abcdef1234567890 \
    --vpc-id vpc-1a2b3c4d \
    --subnet-ids subnet-11111111 subnet-22222222

Note that you must specify at least one subnet per Availability Zone to ensure high availability.

Transit Gateway route tables are similar to VPC route tables. Each attachment is associated with a route table. You can propagate routes from attachments to route tables. For example, you can create a route table that has a static route to an inspection VPC for traffic filtering.

Transit Gateway integrates with AWS CloudWatch for metrics (e.g., BytesIn, BytesOut) and AWS CloudTrail for API logging. You can also use VPC Flow Logs on the attachments to monitor traffic. Security groups and network ACLs are applied at the VPC/subnet level, not at the Transit Gateway level. For centralized security, you can route traffic through a security appliance VPC (inspection VPC) using Transit Gateway route tables.

A financial services company has 50 VPCs across multiple AWS accounts, each serving different business units (e.g., trading, risk, compliance). They also have an on-premises data center with legacy systems. Without Transit Gateway, they would need 1,225 VPC peering connections (50*49/2) and separate VPN connections to each VPC from the data center. By using Transit Gateway, they attach all VPCs and a VPN connection to a single Transit Gateway. They use separate route tables to isolate trading VPCs from other VPCs for security. The cost includes the Transit Gateway hourly fee, attachment fees, and data transfer charges. They save significantly on operational overhead and reduce complexity. A common mistake is forgetting to update route tables in each VPC, causing connectivity failures.

A global e-commerce company operates in three AWS regions: us-east-1, eu-west-1, and ap-southeast-1. They need to connect VPCs in each region to a central shared services VPC in us-east-1. They create a Transit Gateway in each region and peer them together using Transit Gateway peering (inter-region peering). This allows VPCs in different regions to communicate through the hub. They use AWS Network Manager to visualize the entire network. Cost considerations include inter-region data transfer fees, which are higher than intra-region. A pitfall is not planning for bandwidth limits; each Transit Gateway attachment supports up to 50 Gbps, but peering across regions may have lower limits.

A company acquires another company that already has an AWS environment with its own VPCs. To integrate networks quickly, they use Transit Gateway to connect the two sets of VPCs without requiring IP address renumbering. They create a Transit Gateway and attach both companies' VPCs. They use route tables to control which VPCs can communicate. This allows a phased integration. A common misconfiguration is overlapping CIDR blocks; Transit Gateway does not natively handle overlapping IPs, so they must use network address translation (NAT) or careful route design. AWS recommends using non-overlapping CIDRs.