Multiple LANs on One AWS VPN Tunnel: What the SA Limit Means
AWS allows one IPsec SA pair per tunnel, and that is not a one-subnet limit. Separate protection scope from routing and access first.
Adding a second branch LAN to an AWS Site-to-Site VPN does not require a second independent IPsec association inside that tunnel. The limit people trip over is real but narrower than it sounds: AWS documents one unique IPsec SA pair per tunnel, one inbound and one outbound, and the two tunnels in a connection each get their own pair. That is a property of the service, not a rule that IPsec protects one subnet at a time. The distinction matters most when a policy-based customer gateway turns each policy entry into its own association.
Start with the connection, not the LAN list
Open the connection in the console and note how it is routed. A static connection carries the remote prefixes you declared. A BGP connection learns them from the customer gateway.
Either way, the tunnel is route-based. What goes inside it is decided by the selectors your device negotiates, not by the number of subnets you can type into a form.
Watch what the customer gateway negotiates
A policy-based device can turn every policy entry into its own SA. Two LANs means two entries, which means two SAs, and that is where the per-tunnel limit starts to matter. The customer gateway requirements warn about exactly this behaviour and suggest consolidated rules on those devices. Check the negotiated selectors rather than the ACL count on the box.
The device has to be configured to present both prefixes under a single policy, or the far end simply cannot hold the result.
Three inventories, kept apart
Mix these three lists and every change becomes guesswork. Keep them as separate columns and fill each one in for your own network.
| Inventory | What belongs there |
|---|---|
| Required networks | 10.20.10.0/24 and 10.20.30.0/24, as presented after any deliberate translation |
| Protection agreement | the selectors the tunnel actually negotiated for those prefixes |
| Delivery and permission | VPC routes, return routes, security groups and any filtering |
Only the middle column is constrained by the SA limit. The first column is a business fact, and the third column is what makes an application work. Read the accepted selectors on the device rather than inferring coverage from the number of ACL lines you wrote.
Consolidate without widening permission
A summary route is the obvious way to get one policy entry, and it is also how a protected set quietly grows. A /20 that covers both /24s also covers addresses neither branch uses, and the tunnel will happily carry them. If you must summarize, pair it with filtering on the receiving side so the extra space is refused rather than merely unadvertised. A refused packet is evidence. An unadvertised address is only an absence of evidence.
Consolidating the protection policy is a change to what may be encrypted. It is not a grant of access, and it should not be treated as one.
Test both LANs, then keep both tunnels
After a coordinated change, inspect the active protection scope and then exercise a real application from each LAN. One subnet working proves nothing about the second one's selector coverage, and even less about its reply path.
Keep both tunnels in the design. Consolidating policy is not permission to discard redundancy, and a single tunnel carrying every branch LAN makes the next maintenance window an outage.
Write the negotiated selectors, the two prefixes and the route owners into the same change record. When a third LAN arrives, that record tells you whether you are adding a selector or starting over.