The situation
A clinical records platform runs in eu-west-1: 34 VPCs across 19 accounts, every one of them attached to a single transit gateway. The hub has three route tables (production, non-production, shared services). On-premises access comes in over a 10 Gbps dedicated Direct Connect connection and one transit virtual interface into a Direct Connect gateway. That gateway has one association with the transit gateway, with allowed prefixes set to 10.16.0.0/12. The hub has needed no attention for three years. A team attaches a VPC, propagation puts its CIDR in the right route table, and nobody edits a route by hand.
In March the Region was impaired for most of a working day. The review produced a written resilience commitment with a date attached. For the first time there is a second Region in the plan: eu-central-1, four VPCs to start, addressed out of 10.32.0.0/12.
Three kinds of traffic now need a path between the Regions, and they behave nothing alike. The records database tier is PostgreSQL streaming replication on EC2, 40 to 90 Mbps sustained and bursting past 400 Mbps during a reindex. The imaging archive replicates roughly 60 TB a month between one VPC on each side. Everything else is ordinary east-west service traffic between the shared-services VPCs in Ireland and the new application tier in Frankfurt: a few hundred gigabytes a month, spread across dozens of VPC pairs. On top of that, clinicians in the data centre have to reach systems in both Regions, and the commitment date does not leave room for a colocation lead time.
What actually matters
Start with who ends up owning the routing table. Inside eu-west-1 the team relies on propagation: attach, propagate, forget. Any inter-Region option that drops propagation converts a self-maintaining route table into a document that a person has to update. That update is due every time a VPC lands in either Region, across 19 accounts whose teams do not file tickets before attaching. It is a real operational commitment and it should be made deliberately. The alternative is discovering it three months later, when a new VPC in Frankfurt cannot reach Ireland and nobody can say why. The mitigation is to route on summarised supernets rather than per-VPC CIDRs. That turns an unbounded maintenance job into two routes that never change, and it only works if the addressing plan was drawn with summarisation in mind before anything is built.
Then ask what a bad day looks like after the change. The reason the second Region exists is that the first one went dark for seven hours. If the new Region’s reachability depends on a component that lives in the impaired Region, the resilience commitment is partly fiction. Direct Connect gateways are worth understanding here. AWS describes the gateway as a globally available resource, built as a distributed set of BGP route reflectors that operates outside the data traffic path, so it does not put a single Region in the way of the circuit. A peering attachment, by contrast, terminates on a transit gateway at each end. It is only as available as those two Regional routers, which is the correct shape for Region-to-Region traffic and the wrong shape for hybrid reach.
Cost has three different shapes in this decision and they are not comparable at a glance. A transit gateway bills per attachment-hour and per gigabyte processed, quoted in the AWS pricing example at USD$0.05 per attachment-hour and USD$0.02 per GB in US East (Ohio). Inter-Region peering between transit gateways adds outbound inter-Region data transfer on top of the processing charge. AWS charges the processing on the sending transit gateway only: data arriving at the far side over a peering attachment is not processed again. A VPC peering connection has no per-gigabyte processing charge of its own, so inter-Region data transfer is its only charge. A Direct Connect circuit is a port you rent by the hour whether or not it carries a packet, plus cross-connect fees at the colocation. At a few hundred gigabytes a month none of this matters. At 60 TB a month the USD$0.02 per GB processing charge is over a thousand dollars, which is enough to justify a second connectivity mechanism for exactly one VPC pair.
Finally, think about how each option fails and what it looks like when it does. A propagated route withdraws when its attachment goes away, so the route table reflects what is attached. A static route pointed at a peering attachment stays in the table until someone removes it. A misconfigured or stale entry blackholes traffic, and the first symptom is an application timeout rather than a routing alarm. That difference decides what the monitoring has to cover. With static routing between Regions, route-table content itself becomes something to verify continuously rather than something to trust.
What we’ll filter on
- Keeps dynamic route propagation, or names precisely which static routes a human now maintains.
- Carries traffic between every VPC on both sides, not just the pair it directly connects.
- Reaches on-premises in the new Region without new hardware, a new circuit, or a colocation lead time.
- Cost shape that survives 60 TB a month of imaging replication alongside steady database traffic.
- Deliverable inside the commitment window, in weeks rather than months.
The landscape
Inter-Region VPC peering connects exactly two VPCs. Routing is a route-table entry on each side pointing at the peering connection. There is no per-gigabyte processing charge on the connection, and inter-Region peering carries an MTU of 8500 bytes (9001 within a Region). Its limits are the ones that have always applied. There is no transitive routing, so a VPC peered to Ireland cannot use Ireland’s other peerings. There is no edge-to-edge routing, so a peered VPC cannot use the other side’s Direct Connect connection to reach the data centre. Security-group referencing across the peer works only when both VPCs are in the same Region, which they are not here. Each new pair is another connection and another pair of route-table entries: fine for one deliberate pair, unmanageable across 38 VPCs.
A transit gateway peering attachment joins the two hubs directly. It works inter-Region and cross-account, the accepter has to accept it, and inter-Region traffic is encrypted with AES-256 at the virtual network layer as it crosses between Regions. Once it exists, traffic routed to the peer can reach that transit gateway’s VPC and VPN attachments, so one attachment serves every VPC on both sides. The routing behaviour is where it differs from everything else on the hub. Peering attachments do not support route propagation; the only way to send traffic across one is a static route in the transit gateway route table. The same restriction removes ECMP: peering supports neither dynamic routing nor the same static route against two different targets. One peering attachment is permitted between any two transit gateways, with 50 peering attachments per transit gateway by default. Bandwidth runs up to 100 Gbps in each direction per Availability Zone in the Region. MTU is 8500 bytes, matching the VPC attachments, though Path MTU Discovery is not supported on peering attachments the way it is on VPC and Connect attachments.
A second Direct Connect circuit into eu-central-1 is the traditional answer and gives the best routing behaviour of anything here. A transit virtual interface lands on a Direct Connect gateway, which associates with the Frankfurt transit gateway. BGP runs in both directions, routes propagate into the transit gateway route tables, and ECMP is automatic across multiple Direct Connect gateway attachments when prefix, prefix length and AS_PATH match. It also solves none of the Region-to-Region problem, since it terminates on-premises. And it arrives on a schedule set by a Letter of Authorization, a cross-connect and a colocation provider.
The existing Direct Connect gateway already reaches further than most teams realise. A Direct Connect gateway is global: it connects to any Region other than the China Regions. The circuit that lands in Ireland can therefore serve VPCs and transit gateways in Frankfurt with no new hardware at all. Up to 6 transit gateways associate with one Direct Connect gateway, and up to 20 Direct Connect gateways associate with one transit gateway. What sets its role here is that a Direct Connect gateway does not let two associations on the same gateway send traffic to each other. Associating both transit gateways gives on-premises reach into both Regions and gives Ireland no path at all to Frankfurt.
A Site-to-Site VPN between the two transit gateways is the option people reach for when they want dynamic routing between Regions, and it does deliver it: BGP propagation into the route tables, and ECMP across tunnels when the connection uses dynamic routing. Its limits are throughput and packet size. A standard tunnel goes up to 1.25 Gbps and 140,000 packets per second, and a large-bandwidth tunnel up to 5 Gbps. The MTU is 1446 bytes, with no jumbo frames and no Path MTU Discovery. That is a poor fit for 60 TB of imaging a month and a database that bursts to 400 Mbps.
Evaluation
Side by side
| Option | Keeps propagation | Carries VPC to VPC across Regions | On-prem reach, no new circuit | Cost at 60 TB/month | Inside the window |
|---|---|---|---|---|---|
| Inter-Region VPC peering | ✗ | ✗ | ✗ | ✓ | ✓ |
| Transit gateway peering attachment | ✗ | ✓ | ✗ | ✗ | ✓ |
| Second Direct Connect circuit in eu-central-1 | ✓ | ✗ | ✗ | ✗ | ✗ |
| Existing Direct Connect gateway, second association | ✓ | ✗ | ✓ | ✓ | ✓ |
| Site-to-Site VPN between the transit gateways | ✓ | ✓ | ✗ | ✗ | ✓ |
No row is all ticks. The hybrid column and the Region-to-Region columns are satisfied by different rows, because they are different problems that happen to have arrived in the same week. The Direct Connect gateway row cannot carry east-west traffic between the Regions no matter how it is configured. The transit gateway peering row cannot reach the data centre by itself. The two together cover every cell. The VPC peering row covers the single pair where the per-gigabyte processing charge is large enough to notice.
Where each class of traffic lands
The solution
Build the peering attachment first, and decide the addressing before touching the console. Ireland keeps 10.16.0.0/12 and Frankfurt takes 10.32.0.0/12. Every route that has to be written by hand is then written once, against a supernet that will not change as VPCs are added. Create the peering attachment from the Ireland transit gateway and accept it on the Frankfurt side. Then add one static route in each direction: 10.32.0.0/12 pointing at the peering attachment in Ireland’s production route table, and 10.16.0.0/12 pointing at it in Frankfurt’s. Give the two transit gateways distinct Autonomous System Numbers. AWS recommends unique ASNs across peered transit gateways, and re-numbering later is not a small change.
It is worth being precise about where a peering route sits in the transit gateway’s route evaluation order, because the shorthand people repeat is backwards. The transit gateway picks the most specific route first. For identical CIDRs from different attachment types the priority runs static routes, prefix-list-referenced routes, VPC-propagated, Direct Connect gateway-propagated, Transit Gateway Connect-propagated, then the various VPN types. Transit-gateway-peering-propagated routes come last. Propagated peering routes only arise in a Cloud WAN peering, though, and the route written for an ordinary peering attachment is a static route, which sits at the top. Attachment type only breaks ties between identical CIDRs; a more specific prefix wins first whatever it came from. So if the data centre ever advertises 10.32.0.0/12, Ireland’s static route wins the tie and sends that traffic to Frankfurt instead of down the circuit. Keep the on-premises address space clear of both /12s.
For on-premises reach into Frankfurt, associate the existing Direct Connect gateway with the Frankfurt transit gateway. Allowed prefixes behave differently for transit gateway associations than for virtual private gateway associations. For a transit gateway they are not a filter over what the VPCs advertise. They are the exact set of prefixes advertised to on-premises, originated from the Direct Connect gateway’s ASN. Set 10.16.0.0/12 on the Ireland association and 10.32.0.0/12 on the Frankfurt one. Overlapping allowed prefixes across multiple transit gateway associations on one Direct Connect gateway are rejected. That rules out the 0.0.0.0/0 or 10.0.0.0/8 entry a single-Region design often carries, and it is the reason the two /12s had to be drawn before this step rather than after it. On the way back, on-premises prefixes propagate from each Direct Connect gateway attachment into that Region’s transit gateway route table. The hybrid direction stays dynamic even though the Region-to-Region direction is static.
Then the imaging exception. Create one inter-Region VPC peering connection between the two imaging VPCs, with a route in each imaging subnet route table pointing the peer’s /22 at the peering connection. The subnet’s existing 10.0.0.0/8 route to the transit gateway stays where it is. The /22 is the longer match, so imaging replication leaves via the peering connection and every other destination still goes to the hub. That skips the USD$0.02 per GB transit gateway processing charge on roughly 60 TB a month while leaving inter-Region data transfer unchanged, and it needs one connection and two route entries. It gives nothing else: no transitive path to Ireland’s other VPCs, no route to the data centre over Ireland’s circuit, and no cross-Region security-group referencing. The imaging security groups have to allow the peer’s CIDR rather than a group ID.
DNS needs its own pass, because a transit gateway peering attachment does not carry it. Peering does not support resolving public or private DNS host names to private addresses across the peer using a Route 53 Resolver in the other Region. Frankfurt therefore gets its own Resolver inbound and outbound endpoints and its own forwarding rules, shared into the member accounts with AWS RAM. The private hosted zones associate with VPCs in both Regions, so names stay consistent and the resolution path stays Regional. Where the platform publishes a Regional endpoint to clinicians, failover records in the private hosted zone carry the cutover. Route 53 health checkers sit outside the VPC, so they cannot probe a private address. Base the health check on a CloudWatch alarm instead, and the failover record reads that alarm’s data stream.
The last piece is monitoring the routes that no longer withdraw on their own. Static routes do not change when the far side does, so the route tables are now a thing to verify rather than trust. Route Analyzer in Transit Gateway Network Manager traces a path across the peering attachment and reports whether a given source can reach a given destination through the hubs. It reads transit gateway route tables only, not security groups or VPC route tables. Reachability Analyzer covers the VPC side of the same question. Wire it into the pipeline that creates VPC attachments, so a new VPC in Frankfurt proves its path to the hub on the day it is created. Add flow logs on both peering-adjacent attachments and one alarm on blackhole routes appearing in either transit gateway route table.
Worked example
The Ireland production transit gateway route table after the change, trimmed to the routes that matter:
| Destination | Attachment | Route type |
|---|---|---|
| 10.16.0.0/16 | VPC attachment, shared services | propagated |
| 10.17.0.0/16 | VPC attachment, records | propagated |
| 10.20.8.0/22 | VPC attachment, imaging | propagated |
| 172.20.0.0/14 | Direct Connect gateway attachment | propagated |
| 10.32.0.0/12 | Peering attachment to eu-central-1 | static |
Frankfurt’s mirrors it: the four VPC CIDRs propagated, 172.20.0.0/14 propagated from its own Direct Connect gateway association, and a single static 10.16.0.0/12 pointing back at the peering attachment. Two hand-written routes in total, and they do not change when the twelfth VPC lands in Frankfurt.
The imaging VPC in Ireland carries a subnet route table with three entries: 10.20.8.0/22 local, 10.36.8.0/22 to the VPC peering connection, and 10.0.0.0/8 to the transit gateway. A packet to the Frankfurt imaging archive matches the /22 and takes the peering connection. A packet to any other Frankfurt VPC matches the /8, reaches the hub, matches the static /12 there, and crosses the peering attachment. A packet to the data centre matches the /8, reaches the hub, and takes the propagated 172.20.0.0/14 to the Direct Connect gateway. Three destinations, three mechanisms, one route table.
What’s worth remembering
- A transit gateway peering attachment takes static routes only: no propagation, and no ECMP, because one prefix cannot point at two targets.
- A Direct Connect gateway is global and reaches any Region outside China, so a second Region usually needs an association rather than a second circuit; it does not pass traffic from one of its own associations to another.
- For a transit gateway association, allowed prefixes are the exact list advertised to on-premises rather than a filter, and they cannot overlap across two transit gateways on the same Direct Connect gateway.
- Attachment type only breaks ties between identical CIDRs, and a peering attachment’s route is static, so it sits at the top of that order; the peering entry at the bottom of the list is the propagated Cloud WAN case.
- Transit gateway data processing is charged on the sending side only, never on arrival from a peering attachment, so a single very high-volume VPC pair can be worth carving out onto its own inter-Region peering connection.
- Inter-Region VPC peering carries an 8500-byte MTU and no transitive or edge-to-edge routing, and security-group referencing across the peer works only within a Region.