One Site-to-Site VPN for Several VPCs on AWS Transit Gateway

Attach the VPN once and each VPC to one transit gateway, then split association from propagation so spokes can reach the office but not each other.

Two VPCs need the office network this quarter, and the second tunnel is where the estimate breaks. AWS Transit Gateway can act as a shared routing hub: the VPN attaches once, and each VPC attaches to the same hub. The on-premises network then reaches every attached VPC through one connection. That changes who owns the routing decision, which is the part most designs get wrong.

The VPN attachment and the VPC attachments are separate objects on the same gateway, which is why the routing relationships have to be built afterwards.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Why peering is not the shortcut people hope for

The tempting alternative is to terminate the VPN on VPC A and peer VPC B to it. Ordinary VPC peering does not provide edge-to-edge transit through A's VPN connection. A peer reaches the addresses the peering itself provides, and a VPN edge is not one of them. Transit is what a hub gives you; peering gives you a pair.

That restriction is a property of peering, not a quota you can raise.

Association and propagation do different work

Inside the transit gateway, association selects the route table used to look up traffic arriving from an attachment. Propagation decides which tables receive an attachment's learned or connected prefixes. A single attachment can associate with one table while propagating into several. Confusing the two is how a design ends up with reachability nobody planned.

A fully connected small hub is the easy case.

Put every attachment in one table and the VPN plus both VPC prefixes resolve cleanly. That also permits VPC-to-VPC reachability the organization may never have intended, because a shared table has no concept of a spoke.

Workload routes live somewhere else

Each workload subnet still needs its own route toward the transit gateway for the intended on-premises prefixes. Those VPC route tables are separate objects from the transit gateway's own tables. Add the prefixes you need and preserve existing routes instead of replacing every destination with a new default. A subnet route also advertises nothing to the customer device.

Choose dynamic or static routing deliberately; peering supplies neither.

Isolate spokes without losing on-premises access

When A and B may each reach the office but must not route to each other, split the tables. The VPN attachment's associated table holds the VPC prefixes. The VPC attachments' associated table holds the on-premises prefixes, with no route joining A to B. Propagation produces that relationship, so you never have to accept every default association.

This is routing isolation, and it is not application authorization.

Security groups, network ACLs, host firewalls and each service's own permissions still decide what traffic is admitted. If inspection is required, design its supported path explicitly rather than assuming the hub performs it.

What the hub does not fix

Address plans must still be non-overlapping, because the hub does not let one prefix identify two workloads. Each VPC attachment needs the Availability Zone coverage its workloads expect. With BGP, the customer device's routes back to every required prefix must match the design and its import policy. A missing advertisement looks exactly like a broken tunnel.

The VPN connection and the transit gateway are now shared infrastructure.

Plan tunnel redundancy, device capacity, monitoring and maintenance around all dependent VPCs instead of treating each one as independently connected.

Migration from an existing virtual private gateway arrangement deserves the same explicit plan. Build the attachments and policies, move one controlled workload path, and confirm the allowed and denied relationships before retiring the old path. Centralisation helps when it gives the network team one place to manage shared connectivity, and hurts when it hides who may reach whom behind a single large table.

Amanqephe ahlobene