Transit Gateway Peering & Multi-Region
Recap: Where We Left Off
Day 8 established Transit Gateway as the regional hub that replaces an unmanageable full mesh of VPC peering, and the mechanism that makes it work is the split between attachment association and route propagation: an attachment associates with exactly one TGW route table, and it propagates its routes into whichever other route tables you allow. That single design decision is what lets you isolate a shared-services VPC from production VPCs while still giving both of them a path to the same hub. The hub-and-spoke model is only as good as the route tables you build around it.
Today we stay inside the same service family but flip the failure mode. Everything that made intra-region TGW pleasant — automatic propagation, a single route table doing the work, predictable MTU — stops being true the moment you peer two Transit Gateways across regions. Peering attachments do not propagate routes at all, so the same hub-and-spoke topology that configured itself yesterday now requires you to hand-build every path. The service is the same; the operational contract is the opposite.
Foundations You'll Need Today
Today's material sits on top of four ideas that the rest of this page will use without stopping to define them. None of them are complicated on their own, but each one is load-bearing: if any of them is fuzzy, the reasoning about peering will not land. Here they are, in the order the day needs them.
IP addresses and CIDR blocks
Every device on a network needs an address so that other devices can find it, and on AWS those addresses are grouped into ranges rather than assigned one at a time. A CIDR block is just a compact way of writing a range of addresses. The notation 10.1.0.0/16 means "start at 10.1.0.0 and include the next 65,536 addresses," while 10.1.0.0/24 means "start at 10.1.0.0 and include the next 256." The number after the slash tells you how big the range is: smaller number, bigger range. When you create a VPC, you pick one of these ranges, and every subnet and instance inside it gets an address from that range.
The reason this matters today is that two networks can only be connected at the routing level if their ranges do not overlap. If Region A uses 10.0.0.0/16 and Region B also uses 10.0.0.0/16, then an address like 10.0.5.7 is ambiguous — it exists in both places, and no router can decide which one a packet is meant for. This is why the day keeps returning to "non-overlapping CIDRs" as a hard constraint: it is not a preference, it is a physical requirement of how routing works.
Route tables and route propagation
A route table is a list of rules that tells a network device where to send a packet based on its destination address. Each rule says, in effect, "if the destination looks like this, send it that way." Every subnet in a VPC has its own route table, and so does a Transit Gateway. When a packet arrives, the device looks up the destination in the table and forwards it to whatever the matching rule points at. If no rule matches, the packet is dropped — and by default, nothing tells the sender why.
There are two ways a rule gets into a route table. You can add it by hand, which is called a static route, or the system can add it automatically when it learns about a network, which is called route propagation. Propagation is convenient because it keeps the table up to date on its own: if you add a subnet to a VPC, the VPC's range is already known and the routes follow automatically. Static routes do not update themselves — if the network changes, someone has to remember to edit the table. Today's entire topic turns on the fact that one specific kind of connection, a peering attachment, supports only the manual kind.
Transit Gateway and attachments
If you have two VPCs that need to talk, you can connect them directly. If you have twenty, connecting every pair to every other pair becomes an unmanageable web of connections. A Transit Gateway solves that by acting as a central hub: every VPC connects to the hub once, and the hub handles forwarding between them. The connection from a VPC to the hub is called an attachment, and it is a real object with its own state — it can be pending, available, or deleted, and it can be associated with a particular route table on the hub.
The hub itself has route tables just like a subnet does, and the rules in those tables decide which attachments can reach which others. That is the mechanism that lets you keep a shared-services VPC reachable from everywhere while isolating two production VPCs from each other, even though all three are attached to the same hub. Today we take two of these hubs, one in each Region, and connect them to each other.
MTU, or how big a packet can be
Data moving across a network is chopped into packets, and every network path has a maximum packet size it will carry, called the MTU. If a packet is larger than the path allows, it either gets split into smaller pieces or dropped. Within a single AWS Region, the path allows fairly large packets, which is efficient. Across Regions, the limit is lower. This sounds like a minor detail until a workload sends something large — a file, a database replication batch — and it silently fails while small requests succeed. Today's material includes that limit because it is one of the specific ways cross-region connections break in practice.
With that grounding, here's why Transit Gateway peering exists and what problem it actually solves.
1. Why This Is on the Exam
SAP-C02 Domain 1 (Design Solutions for Organizational Complexity) and Domain 2 (Design for New Solutions) both lean heavily on multi-region network design, and TGW peering is the connective tissue between them. The exam keeps returning to it because it is the point where a design that looked clean in a single region becomes genuinely hard: you have two independent routing domains, each with its own route tables, its own attachment lifecycle, and no automatic mechanism to keep them in sync. A candidate who understands only intra-region TGW will confidently draw a topology that cannot pass traffic, and the exam is written to catch exactly that.
The second reason is that TGW peering sits at a decision boundary the exam tests constantly: when do you peer Transit Gateways, when do you use a single global Transit Gateway construct, and when do you abandon network-level connectivity entirely in favor of something service-level. Peering is the answer when you need broad, bidirectional, network-layer reachability between two regions and you are willing to own the routing. It is the wrong answer when you only need one service reachable, or when the two sides have overlapping CIDR ranges, or when the traffic volume does not justify the attachment cost. Scenario questions are usually built by taking a requirement that sounds like "connect these regions" and adding a constraint that eliminates peering.
There is also a cost dimension the exam likes to probe. TGW peering is billed on data transfer across the peering attachment, and inter-region data transfer is priced differently from intra-region. A design that routes chatty traffic between regions through a peered TGW when the workload could have been placed in one region is a cost-optimization failure, and Domain 4 questions are often just Domain 1 questions with a bill attached. Knowing the mechanism is what lets you argue about the bill.
Finally, peering is where the MTU constraint bites. Inter-region TGW peering caps the maximum transmission unit at 1500 bytes, which is lower than what you get inside a single region. That number matters for any workload that assumes jumbo frames, and it is the kind of specific, traceable limit the exam uses to separate candidates who have actually built this from candidates who have only read the feature page.
2. How TGW Peering Actually Works
A TGW peering attachment is a connection between two Transit Gateways, and it is created from one side with a request that the other side accepts. The two Transit Gateways can be in different AWS Regions, or in the same Region but different accounts, and the attachment itself is a first-class object that appears in both Transit Gateways' attachment lists once accepted. Traffic between them travels over the AWS global backbone rather than the public internet, which is the property that makes peering attractive for regulated workloads: the packets never leave AWS-controlled network infrastructure, and they are encrypted in transit by the backbone itself.
The critical mechanical difference from a VPC attachment is what happens to routes. When you attach a VPC to a Transit Gateway, the attachment can propagate its CIDR into the TGW route table it is associated with, and that propagation is automatic and continuous — if the VPC's subnets change, the routes follow. A peering attachment does not do this. There is no route propagation for peering, so the CIDR ranges on the far side of the peer are invisible to your route tables until you add them as static routes. This is not a configuration option you can turn on; it is a property of the attachment type.
That means a working cross-region topology requires static routes in both directions and at both layers. On the TGW side, each Transit Gateway's route table needs a static route pointing the remote CIDR at the peering attachment. On the VPC side, each spoke subnet's route table needs a route pointing the remote CIDR at the local Transit Gateway. Miss any one of those four route entries and traffic dies at that hop, usually silently, because a missing route produces a black hole rather than an error.
The packet path is worth walking once, because it makes the failure modes obvious. A packet leaves an instance in us-east-1, hits its subnet route table, and is forwarded to the local TGW because the destination CIDR matches a route pointing at the TGW. The TGW consults the route table associated with the ingress attachment, finds the remote CIDR pointing at the peering attachment, and forwards the packet across the backbone to the peer TGW in us-west-2. That peer TGW consults the route table associated with the peering attachment, finds the destination CIDR pointing at the target VPC attachment, and forwards it. The target VPC's subnet route table then delivers it to the instance. Four lookups, four route entries, and any one of them missing produces a drop.
Security groups and network ACLs still apply at the endpoints, and they are evaluated independently of the TGW routing. This is a common source of confusion during troubleshooting: a perfectly routed packet can still be dropped by a security group on the destination instance, and the symptom looks identical to a routing failure from the outside. The diagnostic discipline is to check routing first, then security, then the application, in that order.
3. The Core Decision Boundary: Peering vs. Alternatives
The fork every scenario question hinges on is whether you need network-level reachability between two regions at all, or whether a narrower mechanism satisfies the requirement. TGW peering gives you broad, bidirectional, any-to-any reachability between the two routing domains, and it costs you the operational burden of maintaining static routes on both sides. If the requirement is narrower — one service, one direction, one consumer — peering is overkill and the exam will usually offer a service-level alternative as the correct answer.
The second fork is whether the two sides can even be connected at the network layer. Peering, like VPC peering, requires non-overlapping CIDR ranges. If both regions were built from the same 10.0.0.0/16 template, no amount of TGW configuration will make them routable to each other, and the correct answer becomes a service-level mechanism that does not merge routing domains. Recognizing an overlapping-CIDR constraint buried in a scenario is one of the fastest ways to eliminate two or three answer choices.
| Requirement | TGW Peering | VPC Peering | PrivateLink | Single-region TGW only |
|---|---|---|---|---|
| Cross-region reachability | Yes, over AWS backbone | Yes, but per-VPC mesh | Yes, service-level only | No |
| Route propagation | Not supported — static routes required | Not supported — static routes required | Not applicable | Supported |
| Overlapping CIDRs tolerated | No | No | Yes | No |
| Scales to many VPCs | Yes, one attachment per region pair | No, N-squared connections | Yes, one endpoint per consumer | Yes, within region |
| Traffic direction | Bidirectional | Bidirectional | Consumer to provider | Bidirectional |
| Typical exam trigger | "Connect all VPCs in two regions" | "Connect exactly two VPCs" | "Expose one service, CIDRs overlap" | "All VPCs are in one region" |
The table's last row is the one to internalize. Exam scenarios rarely say "use TGW peering"; they describe a topology and a constraint, and the correct mechanism falls out of the constraint. Broad multi-VPC connectivity across two regions with no CIDR conflict points at peering. A single service consumed by many accounts points at PrivateLink. Two VPCs that need to talk points at VPC peering, which is cheaper and simpler than standing up two Transit Gateways. The exam is testing whether you can read the constraint, not whether you can name the service.
4. Configuration Modes and Their Tradeoffs
There is no "mode" switch on a peering attachment the way there is on a DMS task, but there are three distinct ways to structure a cross-region topology, and the tradeoff between them is real. The first is a direct TGW-to-TGW peering attachment between the two regional Transit Gateways. This is the simplest topology and the one most scenarios describe: one attachment, static routes on both sides, and traffic flows directly over the backbone. It is also the topology with the fewest moving parts to break, which matters when you are the one on call for it.
The second structure inserts a third Transit Gateway as a transit point, so region A peers with a hub region and the hub region peers with region B. This is sometimes chosen when a central networking account owns the hub and wants to mediate all inter-region traffic, or when the number of regions grows past the point where a full mesh of peering attachments becomes unmanageable. The cost is that every packet now traverses two peering attachments instead of one, which doubles the inter-region data transfer charges and adds a hop of latency. It also doubles the number of static routes you must maintain, because each peering attachment needs its own route entries on both sides.
The third structure is not peering at all but a single Transit Gateway shared across regions through AWS RAM, which works only when the "regions" in the scenario are actually accounts in the same Region. This is worth naming because scenarios sometimes blur the distinction between multi-account and multi-region, and the correct answer changes completely depending on which one is actually being asked. If the requirement is cross-account within one Region, RAM sharing is the answer and peering is unnecessary complexity.
The tradeoff that matters most in practice is the static-route maintenance burden. Every new CIDR added on either side of a peering attachment requires a manual route entry on the far side, and there is no mechanism that will tell you when you have forgotten one. Teams that operate cross-region peering at scale typically manage these routes as code, with the route entries generated from the same source of truth as the VPC CIDR allocations, precisely because the failure mode of a forgotten route is a silent black hole rather than a loud error.
5. Sizing, Limits and Quotas
The numbers that matter for TGW peering are the MTU cap, the attachment and route table quotas, and the bandwidth characteristics of the peering attachment itself. The MTU across inter-region TGW peering is capped at 1500 bytes, which is lower than the jumbo-frame MTU available within a single Region. Any workload that has been tuned for larger frames — storage replication, certain database protocols, or anything that assumes a specific MTU end to end — needs to be re-validated before you route it across a peering attachment. Path MTU discovery usually handles this gracefully, but applications that hard-code a frame size or that set the DF bit aggressively can fail in ways that look like random packet loss.
Transit Gateway route tables have a quota on the number of routes they can hold, and static routes count against it just like propagated routes do. In a large multi-region topology where each region has many VPC CIDRs, the static routes required on the peering attachment's route table can add up quickly, and it is worth checking the current quota against your projected CIDR count before you commit to a design. The quota is adjustable in some cases, but the adjustment is not instantaneous and it is not something you want to discover during a migration window.
Bandwidth across a peering attachment is not a fixed pipe you provision; it is bounded by the aggregate capacity of the Transit Gateways on either end and by the inter-region backbone path. Transit Gateway attachments have their own bandwidth characteristics, and a single peering attachment does not give you a dedicated amount of throughput. For high-volume cross-region replication, the practical guidance is to test the actual throughput your workload achieves rather than assuming a number, because the achievable rate depends on flow count, packet size, and the specific regions involved.
| Characteristic | Value / behavior | Why it matters |
|---|---|---|
| Inter-region peering MTU | 1500 bytes | Lower than intra-region jumbo frames; re-validate MTU-sensitive workloads |
| Route propagation | Not supported on peering attachments | Every remote CIDR needs a manual static route |
| Route table entries | Subject to TGW route table quota | Static routes consume the same quota as propagated routes |
| Bandwidth | Bounded by TGW capacity, not a provisioned pipe | Test real throughput; do not assume a fixed rate |
| Data transfer billing | Charged per GB across the peering attachment | Chatty cross-region traffic is a cost-optimization finding |
Quotas change over time and vary by Region, so the exam-safe position is to know the shape of the constraint — MTU is capped, routes are static, bandwidth is shared — rather than to memorize a specific number that may be stale. When a scenario gives you a specific number, use the number in the scenario rather than a remembered quota.
6. Failure Modes and What They Look Like in Production
The signature failure of TGW peering is the silent black hole. A packet arrives at a Transit Gateway, the route table has no matching entry for the destination, and the packet is dropped with no ICMP unreachable and no log entry by default. From the application's perspective this looks like a timeout, which is indistinguishable from a security group drop, a dead instance, or an application hang. The first diagnostic move is therefore not to look at the application but to verify the route tables on both sides of the peering attachment, in both directions, and to confirm that the remote CIDR is present as a static route pointing at the peering attachment.
The second common failure is a one-way route. Because the two sides of a peering attachment are configured independently, it is entirely possible to have a working forward path and a broken return path. The symptom is a connection that establishes but never completes — a TCP handshake that gets a SYN through but no SYN-ACK back, or an application that hangs on the first response. This is the failure mode that most often gets misdiagnosed as an application bug, because the forward direction demonstrably works. The fix is always to check the return path's route tables with the same rigor as the forward path.
The third failure is MTU-related and presents as intermittent, hard-to-reproduce packet loss. Small requests succeed and large responses fail, or a file transfer stalls partway through. This is the classic signature of a path MTU problem: the handshake and small packets fit within 1500 bytes, but a larger packet that needs fragmentation is dropped because the DF bit is set and no ICMP "fragmentation needed" message is getting back to the sender. The diagnostic move is to test with progressively larger packet sizes and to check whether the application or its load balancer is setting the DF bit.
The fourth failure is a stale route after a CIDR change. Someone adds a new subnet to a VPC on one side, the VPC attachment propagates the new CIDR into the local TGW route table automatically, but nobody adds the corresponding static route on the far side of the peering attachment. The new subnet is reachable within its own region and unreachable from the peer, and the failure appears only for workloads that happen to land in the new subnet. This is the failure mode that argues most strongly for managing cross-region routes as code.
7. The Operational and SRE Angle
Cross-region peering is a shared dependency, and shared dependencies deserve their own SLO. The metric that matters most is not raw throughput but the error rate on cross-region paths, and the practical way to measure it is with synthetic probes that exercise the actual path end to end rather than with infrastructure metrics that only tell you the attachment exists. A canary that makes a request from a workload in region A to a workload in region B on a fixed interval will catch a broken route within one interval, whereas a CloudWatch metric on the attachment will happily report healthy while every packet is being dropped.
For monitoring, the useful signals are the Transit Gateway's own metrics for bytes and packets on the peering attachment, which will drop to zero or near-zero when a route breaks, combined with application-level error rates on the cross-region call path. The combination is what lets you distinguish "the path is broken" from "the path is fine but the destination is unhealthy." Neither signal alone is sufficient, and the exam expects you to know that infrastructure metrics and application metrics answer different questions.
The runbook shape for a cross-region peering incident is short and should be written before you need it. First, confirm the peering attachment state is available on both sides. Second, dump the route tables associated with the peering attachment on both sides and diff them against the expected CIDR list. Third, verify the spoke subnet route tables point at the local Transit Gateway for the remote CIDR. Fourth, check security groups and NACLs at the endpoints. Fifth, test MTU with a large-packet probe. That sequence moves from the most likely cause to the least likely, and it is fast enough to run during an incident.
The SRE implication of the static-route requirement is that your change management process has to cover it. Adding a subnet to a VPC is normally a low-risk change that a team can make independently; in a peered topology it is a cross-team change with a failure mode that only manifests in the other region. The mitigation is to make the route entries a generated artifact of the CIDR allocation process, so that adding a subnet automatically produces the corresponding static route on the far side, and to alert on drift between the two.
8. Edge Cases and Exam Gotchas
The single most-tested gotcha is that peering attachments do not propagate routes. Any answer choice that says "enable route propagation on the peering attachment" is wrong, because the option does not exist. The correct answer always involves manually adding static routes on both sides, and the exam will phrase the question so that the propagation option sounds plausible.
The second gotcha is the MTU cap. Inter-region peering is capped at 1500 bytes, and a scenario that mentions a workload with specific MTU requirements or that describes intermittent large-packet failures is pointing at this limit. Do not confuse it with the intra-region MTU, which is higher.
The third gotcha is the directionality of the configuration. Because both sides are configured independently, a scenario can describe a topology where one side is correctly configured and the other is not, and the symptom will be a one-way failure. The exam expects you to check both directions rather than assuming symmetry.
The fourth gotcha is the distinction between multi-region and multi-account. If the scenario's "regions" are actually accounts in the same Region, the answer is RAM sharing, not peering. Read the scenario carefully for whether the constraint is geographic or organizational.
The fifth gotcha is cost. Peering attachments bill on data transfer, and a scenario that describes high-volume cross-region traffic between workloads that could have been co-located is a cost-optimization question in disguise. The correct answer may be to move the workload rather than to optimize the network.
The sixth gotcha is the interaction with overlapping CIDRs. Peering, like VPC peering, cannot connect overlapping ranges. If the scenario mentions that both regions were built from the same template, the answer is a service-level mechanism such as PrivateLink, not peering.
9. This vs. the Services It Gets Confused With
TGW peering is most often confused with VPC peering, and the distinction is about scale and topology rather than capability. VPC peering connects exactly two VPCs and does not transit; TGW peering connects two routing domains, each of which can contain many VPCs. If a scenario describes connecting two VPCs, VPC peering is cheaper and simpler. If it describes connecting two sets of VPCs, or two regions' worth of network, TGW peering is the answer. The exam will sometimes describe a topology that could be built either way and expect you to pick based on the number of VPCs involved.
The second confusion is with PrivateLink. PrivateLink exposes a specific service to consumers without merging routing domains, which means it works across overlapping CIDRs and does not require static routes. If the requirement is "let these consumers reach this one API," PrivateLink is the answer and peering is overkill. If the requirement is "let everything in region A reach everything in region B," peering is the answer and PrivateLink cannot do it.
The third confusion is with a single Transit Gateway shared across accounts via RAM. That mechanism solves cross-account connectivity within one Region and does nothing for cross-region connectivity. A scenario that mixes the two constraints — multiple accounts and multiple regions — usually requires both mechanisms, and the exam will test whether you can decompose the requirement rather than reaching for one service to solve everything.
| Pick this… | When… |
|---|---|
| TGW peering | You need broad network-level reachability between two regions' worth of VPCs, CIDRs do not overlap, and you can own the static routes |
| VPC peering | Exactly two VPCs need to talk, in the same or different regions, and you do not need transit |
| PrivateLink | One service needs to be reachable by many consumers, especially when CIDRs overlap or you want to avoid merging routing domains |
| RAM-shared Transit Gateway | The "regions" are actually accounts in the same Region and you want centralized network ownership |
| Move the workload | The cross-region traffic is chatty and the latency requirement does not actually demand two regions |
The rule of thumb that survives most scenarios: peering is for topology, PrivateLink is for services, and RAM is for ownership. When a scenario is ambiguous, ask which of those three the requirement is really about, and the answer usually falls out.
Hands-on Lab: Routing Between Two Regions Through Peered Transit Gateways
This lab builds a working cross-region path between two VPCs through peered Transit Gateways, and then deliberately breaks it in the three ways that matter so you can see what each failure looks like. Budget about 45 minutes. You will need permissions to create VPCs, Transit Gateways, and peering attachments in two Regions.
Step 1 — Build the two regional networks. In us-east-1, create a VPC with CIDR 10.1.0.0/16 and one private subnet. In us-west-2, create a VPC with CIDR 10.2.0.0/16 and one private subnet. Launch a t3.micro instance in each subnet with a security group that allows ICMP and SSH from the other VPC's CIDR. Note the instance private IPs; you will use them as the test endpoints.
Step 2 — Create the Transit Gateways. Create one Transit Gateway in each Region. Leave the default route table association and propagation settings in place for now, and attach each VPC to its regional Transit Gateway. Confirm that each attachment shows as available and that the VPC CIDR has propagated into the regional Transit Gateway's default route table.
Step 3 — Create the peering attachment. From the us-east-1 Transit Gateway, create a peering attachment targeting the us-west-2 Transit Gateway. The attachment will sit in a pending-acceptance state until you accept it from the us-west-2 side. Accept it, then confirm that both sides show the attachment as available. At this point, traffic still does not flow, and that is the point of the exercise.
Step 4 — Add the static routes. On the us-east-1 Transit Gateway's route table, add a static route for 10.2.0.0/16 pointing at the peering attachment. On the us-west-2 Transit Gateway's route table, add a static route for 10.1.0.0/16 pointing at the peering attachment. Then update each VPC's subnet route table to point the remote CIDR at the local Transit Gateway. Test with a ping from one instance to the other; it should now succeed.
Step 5 — Break it in the forward direction. Delete the static route for 10.2.0.0/16 from the us-east-1 Transit Gateway route table. Ping again and observe the timeout. Note that there is no error message anywhere in the console and no log entry by default; the packet is simply dropped. This is the silent black hole, and it is the failure you will spend the most time diagnosing in production.
Step 6 — Break it in the return direction. Restore the route you just deleted, then delete the static route for 10.1.0.0/16 from the us-west-2 Transit Gateway route table instead. Ping again. Observe that the behavior is subtly different: depending on your tooling, you may see the request leave but no response return, which is the one-way failure signature. Restore the route.
Step 7 — Probe the MTU. From one instance, run a ping with a payload size that produces a packet larger than 1500 bytes and the DF bit set. Observe the failure. Then run the same test with a payload that fits within 1500 bytes and confirm it succeeds. This is the intermittent large-packet failure you will see when a workload assumes jumbo frames across a peering attachment.
Step 8 — Clean up. Delete the peering attachment, both Transit Gateways, and both VPCs. Transit Gateway attachments and peering attachments bill hourly, so leaving them running is an easy way to accumulate charges.
The takeaway from this lab is that every failure mode of TGW peering is a routing-table problem, and every one of them presents as a timeout rather than an error. The diagnostic skill you are building is the habit of checking route tables on both sides, in both directions, before you look anywhere else.
Scenario Question Drills
Q1. After creating a TGW peering attachment between two regions, spoke VPCs still cannot reach each other. What is most likely missing?
Q2. A workload replicates data between us-east-1 and eu-west-1 through a TGW peering attachment. Small API calls succeed but large file transfers stall partway through. What is the most likely cause?
Q3. A company has two Regions, each with a Transit Gateway and several VPCs. Both Regions were built from the same 10.0.0.0/16 template, so their CIDRs overlap. They need one specific internal API in Region A to be reachable from Region B. What should they use?
Q4. An engineer reports that a cross-region connection establishes but the application hangs waiting for the first response. Route tables on the source side look correct. What should you check first?
Q5. Which statement about TGW peering attachments is accurate?
Q6. A team adds a new subnet to a VPC in Region A. The subnet is reachable from within Region A but not from Region B, even though the peering attachment is healthy. What is the most likely explanation?
Q7. A company wants all inter-region traffic between three Regions to be mediated by a central networking account's Transit Gateway. What is the main tradeoff of this hub-and-spoke peering design compared with a direct mesh?
Q8. Which monitoring approach best detects a broken cross-region path through a TGW peering attachment?
Q9. A scenario describes connecting two VPCs in different Regions that need to exchange traffic directly, with no other VPCs involved. Which is the most cost-effective and simplest choice?
Q10. A packet is dropped at a Transit Gateway because no route matches the destination. What does the sender observe by default?
Q11. A company's cross-region traffic between two Regions is high-volume and chatty, and the latency requirement is actually satisfied by either Region. What should the architect recommend first?
Q12. Which of the following is NOT a valid way to add routes for a TGW peering attachment?
Q13. A team wants to reduce the risk of forgetting a static route when new subnets are added on either side of a peering attachment. What is the most effective mitigation?
Q14. A scenario describes multiple accounts that need centralized network connectivity, and all of them are in the same AWS Region. Which mechanism fits?
Q15. During an incident, a cross-region path through a TGW peering attachment is failing. What is the correct first diagnostic step?
Peek into Tomorrow
Everything in today's topology assumed the traffic crossing the peering attachment was traffic you wanted to allow. The static routes you built are a reachability mechanism, not a security control: once a route exists, any packet matching it is forwarded, and the only thing standing between your regions and the internet is whatever security groups and NACLs happen to be at the endpoints. That is fine for a private cross-region path between two trusted VPCs, but it falls apart the moment the requirement includes inspecting what is actually inside the traffic — blocking a specific domain, detecting a known-bad signature, or enforcing that egress from every spoke VPC passes through one chokepoint before it reaches the internet.
The open question is where that inspection lives. You could put a firewall in every VPC, but that multiplies cost and configuration surface by the number of spokes. You could rely on security groups, but they operate on IP and port, not on payload or domain name. The alternative is a centralized inspection VPC that all egress is routed through, which sounds simple until you try to make the routing work: the spoke route tables have to send 0.0.0.0/0 somewhere, the inspection VPC has to accept it, inspect it, and then hand it back to the same Transit Gateway without creating a routing loop. Tomorrow's topic is the appliance VPC pattern that makes that work, and the Suricata-compatible rule engine that does the actual inspection.