# Advanced VPC Routing and Transit Gateway

> Chapter 2 of the Courseiva AWS-NETWORKING-SPECIALTY curriculum — https://courseiva.com/learn/aws-networking-specialty/advanced-vpc-routing-and-transit-gateway

**Official objective:** 1.2 — Design advanced routing solutions using transit gateway, VPC peering, and route tables.

## Introduction

How do you connect dozens of separate virtual networks (VPCs) in the cloud without creating a messy, unmanageable spiderweb of connections?  That is the core problem that Advanced VPC Routing and Transit Gateway solves. For the ANS-C01 exam, understanding this central hub-and-spoke architecture is critical because the exam tests your ability to design scalable, secure, and cost-effective network topologies that replace old-fashioned VPC peering.

## The High-Speed Train Network Analogy

Have you ever wondered how a city with multiple train stations manages to send a passenger from any station to any other station without them all colliding or getting lost?  Imagine you are the transport planner for a major city. Before, every train station (VPC) had its own direct track to every other station it needed to reach. That worked when you had just three or four stations, but now you have dozens. Building tracks between every pair is a nightmare of cost and complexity — that is the old VPC peering way. 

 So you design a central Grand Central hub — a Transit Gateway. Every station simply connects to this one hub with a single track. The hub itself contains a giant whiteboard (the route table) that lists every station and the exact platform to send trains to get there. When a train from the northern station wants to reach the eastern station, the conductor checks the whiteboard and is told: take platform 7, which leads to the hub, and from there, platform 12 leads directly to the eastern station. 

 But here is the clever part: you can also decide that trains from the northern station are not allowed to reach the southern station — maybe it carries freight, not passengers. You write a rule on the whiteboard saying no. That is a route table entry blocking or allowing traffic. And if the eastern station is actually a special logistics depot (a VPN or Direct Connect), the whiteboard still shows the path, but the train will hand off to a different kind of vehicle. The whole system scales elegantly: add a new station, connect it to the hub, update the whiteboard, done. It is centralised, manageable, and secure. This is exactly what Transit Gateway does for your VPCs in the cloud.

## Core explanation

Let us start with the basics. A VPC, or Virtual Private Cloud, is your own private, isolated section of the cloud where you launch resources like servers (EC2 instances) and databases. Think of each VPC as a separate, walled-off office building. Initially, if you had two VPCs and wanted them to talk to each other, you used a direct connection called VPC peering. This worked like building a single bridge between two buildings. 

 The problem emerges when you have many VPCs — say, ten or twenty. Using VPC peering, you would need to create a peering connection between every pair that needs to communicate. That is a lot of bridges, and each one has to be manually set up, with route tables updated on both sides. This does not scale. It is also difficult to manage security centrally because each peering connection has its own rules. 

 This is where AWS Transit Gateway enters the picture. Transit Gateway is a network transit hub that you connect all your VPCs and on-premises networks to. Instead of a spiderweb of peering connections, you have a star topology with Transit Gateway at the centre. Each VPC connects to the Transit Gateway via a single attachment. That is it. 

 Now, how does data actually move? Inside the Transit Gateway, you create route tables. These are not complicated — they are just sets of rules that say: if a packet is destined for this IP address range (CIDR block), send it to this attachment. For example, you have a shared services VPC (which might host Active Directory or shared security tools) and multiple workload VPCs. You can create a route table for the shared services VPC that allows it to send traffic to all workload VPCs. But you can create a different route table for the workload VPCs that only allows them to send traffic back to the shared services VPC, and not to each other. This is called segmentation and is one of Transit Gateway's superpowers. 

 Transit Gateway also supports different attachment types, not just VPCs. You can attach a VPN (Virtual Private Network) connection from your on-premises data centre, or a Direct Connect connection (a dedicated physical line), or even another Transit Gateway in a different region (called peering attachment). This makes Transit Gateway the single control point for all your hybrid and multi-VPC networking. 

 Why does this exist? Because as companies grow and adopt microservices, multiple accounts, or DevOps environments, they end up with many VPCs. Managing them all with VPC peering is a full-time job. Transit Gateway centralises routing, simplifies security (you can use AWS Network Firewall or a firewall appliance on the path), and reduces the number of connections you need to manage. It is fundamentally a scalability tool. 

 What it replaces is the old hub-and-spoke that used a specially configured VPC as a router (the so-called 'transit VPC' pattern) which required you to run your own virtual routers and was complex to maintain. Transit Gateway is a managed service — AWS handles the hardware and availability. 

 Now, some important terms you will see on the exam: 

 - Transit Gateway Attachment: The connection point between a VPC (or VPN, etc.) and the Transit Gateway. Each attachment has a unique ID. 
 - Transit Gateway Route Table: A collection of routes that determine where traffic goes. You can have multiple route tables for different attachments. 
 - Route Propagation: A feature where the routes from a VPN attachment (like on-premises network segments) are automatically added to a route table. For VPC attachments, you must manually add routes or use resource access manager (RAM) features. 
 - Association: Which route table a particular attachment is associated with. One attachment can be associated with exactly one route table. 
 - Peering Attachment: Connects two Transit Gateways together, allowing VPCs in different regions to talk to each other through Transit Gateways. 

 In summary, Transit Gateway is the central nervous system of a multi-VPC architecture. It is designed to make complex networking simple, scalable, and auditable. For the exam, you need to know when to choose Transit Gateway over VPC peering, how to design route tables for isolation and sharing, and how to connect on-premises to the cloud using Transit Gateway.

## Real-world context

Consider a mid-sized company called 'CloudRetail' that runs an e-commerce platform. They have three environments: production, staging, and development. Each environment lives in its own AWS account and has multiple VPCs — one for the front-end web servers, one for the back-end application logic, and one for the database. That is nine VPCs total. 

 Previously, the network team used VPC peering. They had to create 36 separate VPC peering connections just to allow inter-VPC traffic within each environment (and that is not counting connections between environments for data replication). Every time a new VPC was added (say, for a new machine learning service), they had to create more peering links and update dozens of route tables. It was a nightmare. 

 They decided to migrate to AWS Transit Gateway. Here is what the network engineer did step by step: 

 1. Created a Transit Gateway in each environment's AWS account in the US East region. 
 2. Used AWS Resource Access Manager (RAM) to share the Transit Gateway with the other accounts in the same environment. 
 3. Attached each VPC to the Transit Gateway using the console, creating attachments for the front-end, back-end, and database VPCs. 
 4. Created three route tables within the Transit Gateway: a public route table (for front-end VPCs that need internet access via NAT Gateway), an internal route table (for back-end VPCs that talk to databases but not the internet), and a shared services route table (for things like directory servers). 
 5. Associated each VPC attachment with the appropriate route table. For example, the front-end VPC attachment was associated with the public route table. 
 6. Added static routes in each route table. For instance, the public route table had a route for the database CIDR block pointing to the database VPC attachment, and a default route (0.0.0.0/0) pointing to a central egress VPC (via a NAT Gateway) for internet access. 
 7. Set up a VPN attachment from the Transit Gateway to their on-premises data centre, where their legacy inventory system still runs. They propagated the on-premises routes, so all VPCs could reach the inventory system automatically. 
 
 The result: from 36 peering connections to just 3 Transit Gateway attachments per environment. Adding a new VPC now takes minutes — just attach it to the Transit Gateway and update one route table. Security is centralised: they can insert a network firewall appliance in the path by using Transit Gateway to route traffic through a firewall VPC before reaching other VPCs. 

 What does an IT professional actually do with this day to day? They monitor Transit Gateway metrics like packets dropped and bytes in/out using CloudWatch. They audit route tables to ensure no accidental cross-environment connectivity. They troubleshoot connectivity issues by checking that an attachment is associated with the correct route table and that routes are propagated or statically added. They also manage costs — Transit Gateway charges per attachment and per GB of data processed, so they might consolidate workloads to minimise attachments. 

 Common actions: 

 - Creating a new route table for a new business unit VPC. 
 - Removing an old VPC attachment when decommissioning an environment. 
 - Enabling multicast in Transit Gateway (a less common but exam-tested feature) for applications like stock tickers. 
 - Setting up inter-region peering between two Transit Gateways for disaster recovery. 

 The key for the professional is that Transit Gateway reduces the operational overhead of scaling networks. It is the go-to solution for any multi-VPC or hybrid cloud architecture.

## Exam focus

The ANS-C01 exam will test your deep understanding of Transit Gateway route tables, attachments, and how they interact with other services. The exam is famous for asking 'when should you use Transit Gateway versus VPC peering?' and for presenting complex multi-VPC topologies with specific routing requirements. 

 Let us break down exactly what you will see: 
 
 - Route table association vs. propagation: This is the number one confusion trap. The exam will describe a scenario where a VPN attachment is propagated to a route table, but a VPC attachment is only associated. They will ask you why traffic is not reaching the VPC. The answer: propagation only adds routes to the route table from that attachment, but does not allow the attachment to send traffic — the attachment must be associated with a route table to send traffic. 
 - Black hole routes: If you see a destination in a route table with 'blackhole' as the target, it means the attachment is deleted or not functioning. The exam loves to ask why traffic is dropped when the route table still has a route pointing to an attachment that was removed. 
 - Inter-VPC isolation: You need to know how to isolate VPCs from each other while allowing them both to reach a shared services VPC. The pattern is: create a separate route table for each workload VPC (with only a route to the shared services VPC) and a shared route table for the shared services VPC (with routes to all workload VPCs). 
 - TGW peering: They often test that Transit Gateway peering connections do not support transitive routing. What this means: if you peer TGW-A with TGW-B, and TGW-B with TGW-C, traffic from TGW-A cannot reach TGW-C through TGW-B unless you explicitly set up routes in all three. This is a classic exam trick where they say 'all VPCs can communicate' but they set up peering without transitive routing. 
 - Multicast: Transit Gateway supports multicast, but only in specific regions. The exam may ask what additional setup is needed (enable multicast domain, register group members). 
 - Costs: You will not be asked to calculate costs, but they may test best practices like consolidating attachments rather than creating one per subnet. They also test that Transit Gateway is a managed service, so you do not manage the underlying infrastructure. 
 
 Typical question types: 
 
 - 'A company has 20 VPCs and wants to reduce the number of connections needed for inter-VPC communication. Which solution is most cost-effective and scalable?' Answer: Transit Gateway. 
 - 'An architect has VPCs in two regions and wants all VPCs to communicate. What should they do?' Answer: Create a Transit Gateway in each region, peer them. 
 - 'Why is traffic not reaching a VPC that is attached to Transit Gateway?' Options include: the VPC attachment is not associated with a route table; the route table does not have a route for the destination CIDR; the VPC's subnet route tables do not point to the Transit Gateway attachment. All are possible, but the exam makes you pick the most likely cause based on the scenario. 
 
 Key definitions to memorise: 
 
 - Transit Gateway: A regional, managed hub-and-spoke service. 
 - Attachment: The logical connection between a network (VPC, VPN, etc.) and the Transit Gateway. 
 - Association: The binding of an attachment to a specific route table. 
 - Propagation: The automatic injection of routes from a VPN attachment into a route table. 
 - Blackhole: A route target indicating the attachment is deleted or not available. 
 
 The exam also includes scenarios with AWS Direct Connect Gateway and Transit Gateway. You must know that a Direct Connect Gateway can be associated with a Transit Gateway to provide access from on-premises to multiple VPCs. This is a hybrid architecture pattern they test heavily: Direct Connect -> Direct Connect Gateway -> Transit Gateway -> multiple VPCs. 

 Finally, remember that Transit Gateway is a 'managed' service. Do not select answers that involve launching EC2 instances to route traffic when using Transit Gateway. The exam wants you to choose the managed solution over a DIY one.

## Step by step

1. **Create a Transit Gateway** — Navigate to the AWS Transit Gateway console and create the TGW. Choose the region, set a name, and decide options like default route table association and propagation (typically disable these for security). The TGW is your central hub.
2. **Attach VPCs to the Transit Gateway** — For each VPC you want to connect, create a VPC attachment. This associates a specific VPC with your TGW. You will select which subnets (in each availability zone) to attach — these become the entry/exit points for traffic going through the TGW.
3. **Create and configure Transit Gateway route tables** — Create separate route tables based on your routing policy. For example, a 'shared services' route table that has routes to all workload VPCs, and 'workload' route tables that only have a route back to the shared services VPC. This defines the allowed traffic paths.
4. **Associate VPC attachments with route tables** — For each VPC attachment, associate it with the correct route table. This tells the TGW: 'when this VPC sends traffic, use this set of routes to make decisions'. This is what enables the VPC to send traffic through the TGW.
5. **Update VPC subnet route tables** — In each VPC, go to the route tables for the subnets you attached. Add a route for your destination CIDR blocks (e.g., the other VPCs) with the target being the Transit Gateway attachment ID. This step completes the bidirectional path.
6. **(Optional) Attach on-premises networks** — If you have a VPN or Direct Connect, create a VPN attachment or integrate with Direct Connect Gateway. Propagate the on-premises routes into your Transit Gateway route tables so your VPCs can reach your data centre.

## Comparisons

### Transit Gateway vs VPC Peering

**Transit Gateway:**
- Hub-and-spoke topology, one central hub for many spokes.
- Managed service, no need to manage routing instances.
- Supports transitive routing within a single TGW instance.

**VPC Peering:**
- Point-to-point topology, a distinct link per VPC pair.
- Manual per-connection setup, no centralised management.
- No transitive routing: you must peer each VPC pair directly.

### Transit Gateway Route Table Association vs Transit Gateway Route Propagation

**Transit Gateway Route Table Association:**
- Binds an attachment to a specific route table to allow sending traffic.
- One attachment can be associated with exactly one route table.
- Required for a VPC to be able to send traffic through the TGW.

**Transit Gateway Route Propagation:**
- Automatically adds destination routes from a VPN attachment to a route table.
- Does not allow the attachment to send traffic on its own.
- Typically used for on-premises CIDR ranges via VPN.

### Transit Gateway (TGW) vs Direct Connect Gateway (DXGW)

**Transit Gateway (TGW):**
- Regional service that connects VPCs and on-premises within a region.
- Supports VPC, VPN, and Direct Connect attachments.
- Manages inter-VPC routing through route tables.

**Direct Connect Gateway (DXGW):**
- Global service that connects on-premises to multiple VPCs across regions.
- Used for Direct Connect (dedicated private connection).
- Does not manage routing between VPCs; typically used with Transit Gateway.

## Diagram

_A Transit Gateway acts as a central hub with VPC and on-premises attachments, each associated with a specific route table._

```mermaid
flowchart TD
    A[VPC A - Web] -->|Attachment| TGW[Transit Gateway]
    B[VPC B - App] -->|Attachment| TGW
    C[VPC C - Database] -->|Attachment| TGW
    D[On-prem Data Center] -->|VPN/Direct Connect| TGW
    TGW -->|Route Table A| A
    TGW -->|Route Table B| B
    TGW -->|Route Table C| C
    TGW -->|Propagation| D
```

## Common misconceptions

- **Misconception:** Transit Gateway automatically allows all attached VPCs to communicate with each other. **Reality:** Transit Gateway only routes traffic if you explicitly configure route tables with the necessary routes. By default, no inter-VPC communication is allowed. (Beginners think Transit Gateway is a 'magical hub' that connects everything, but routing is controlled via route tables, similar to how a physical router needs routing entries.)
- **Misconception:** Transit Gateway peering supports transitive routing, so if I peer TGW-A with TGW-B, and TGW-B with TGW-C, traffic from TGW-A can reach TGW-C. **Reality:** Transit Gateway peering does NOT support transitive routing. Traffic from TGW-A cannot reach TGW-C unless you explicitly peer TGW-A with TGW-C. This is a deliberate limitation. (Many people confuse Transit Gateway peering with VPC peering behaviour, or assume it works like a full mesh hub. The exam loves to test this exact misunderstanding.)
- **Misconception:** You can attach a VPC to a Transit Gateway without updating the VPC's route tables. **Reality:** After creating a VPC attachment, you must update the route tables of the subnets in that VPC to point to the Transit Gateway attachment ID for the destination networks you want to reach. (People forget that routing is bidirectional. The Transit Gateway route table is one side, but the VPC's subnet route tables also need to send traffic back to the TGW.)
- **Misconception:** Transit Gateway is required for any multi-VPC setup. **Reality:** For small numbers of VPCs (typically fewer than 6), VPC peering can be simpler and cheaper. Transit Gateway is ideal for many VPCs or complex hybrid architectures. (Beginners see Transit Gateway as the 'newer, shinier' tool and assume it is always better, but the exam tests when to use each solution appropriately.)

## Key takeaways

- Transit Gateway is a regional, managed hub that connects multiple VPCs and on-premises networks using a star topology, replacing the complex web of VPC peering connections.
- Transit Gateway route tables are completely independent from VPC route tables; traffic only flows when both sides have matching routes.
- Transit Gateway peering attachments allow inter-region connectivity, but they do not support transitive routing — each pair must be individually peered.
- A Transit Gateway attachment must be associated with exactly one route table to send traffic; propagation only adds routes to a route table but does not enable sending.
- You can achieve VPC isolation by associating each workload VPC with its own route table containing a single default route or a route to only a shared services VPC.
- The Direct Connect Gateway can be integrated with Transit Gateway to give on-premises data centres access to multiple VPCs across an AWS account using a single connection.

## FAQ

**What is the difference between Transit Gateway and VPC peering?**

Transit Gateway uses a hub-and-spoke model where all VPCs connect to a central hub, simplifying management and scaling to many VPCs. VPC peering creates direct point-to-point links, which works for small numbers but does not scale well.

**Can Transit Gateway connect VPCs in different AWS regions?**

Yes, by creating a Transit Gateway peering attachment between two Transit Gateways in different regions. This allows inter-region VPC connectivity.

**Does Transit Gateway support transitive routing?**

Within a single Transit Gateway, yes, if you configure route tables to allow it. But between peered Transit Gateways, no — you cannot route from TGW-A to TGW-C through TGW-B without direct peering between A and C.

**How do I allow only specific VPCs to communicate through Transit Gateway?**

Create separate Transit Gateway route tables for each VPC or group of VPCs. Associate each VPC attachment with the appropriate route table, and only add routes to the VPCs you want to allow.

**What is a blackhole route in Transit Gateway?**

A blackhole route is a route table entry where the target (attachment) has been deleted or is in a failed state. Traffic matching that destination will be dropped.

**Can I use Transit Gateway without a Transit Gateway route table?**

No, every Transit Gateway has at least one route table (the default one). You must associate attachments with a route table for traffic to flow.

## Check your understanding

1. **What service would you use to connect 20 VPCs in the same AWS region while minimising the number of connections?**

   Answer: AWS Transit Gateway, because it uses a hub-and-spoke architecture where each VPC only needs one attachment to the central Transit Gateway.

2. **When you peer two Transit Gateways in different regions, can traffic from a VPC attached to TGW-A reach a VPC attached to TGW-C through TGW-B if TGW-A is only peered with TGW-B?**

   Answer: No, because Transit Gateway peering does not support transitive routing. You must peer TGW-A directly with TGW-C for traffic to flow between them.

3. **A VPC attachment is associated with a Transit Gateway route table that has a route to the destination CIDR, but traffic still fails. What is the most likely missing step?**

   Answer: The VPC's subnet route tables must also have a route pointing to the Transit Gateway attachment ID for the return traffic.

4. **What is the difference between propagating a VPN attachment to a Transit Gateway route table and associating a VPC attachment with that same route table?**

   Answer: Propagation adds the VPN's routes to the route table, but the VPN attachment does not send traffic unless it is also associated. The VPC attachment must be associated to send traffic.

5. **If a Transit Gateway attachment is deleted and the route table still contains a route pointing to it, what appears in the route table?**

   Answer: The route target changes to 'blackhole', indicating the attachment is unavailable.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-networking-specialty/advanced-vpc-routing-and-transit-gateway