Two AWS Accounts, One On-Prem Network: Which Path?
Shared transit gateway, two independent VPNs, or one narrow proxy: pick by ownership and blast radius, not by which route is easiest to add today.
The obvious framing is peering versus VPN, and it is the wrong framing. A peered VPC cannot borrow its neighbour's VPN connection for edge-to-edge routing, so that option was never on the table no matter what a route table suggests. What you actually choose between is a shared network hub, two independent VPN paths, and a narrow application entry. Each one answers a different question about who owns the routing.
Three options and the one that is not an option
Start by deleting the peering idea, then compare what remains on ownership rather than on diagram simplicity. The table below is the decision in compressed form.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
If account A needs reachability to a whole on-premises network, the proxy row is the wrong shape. If account A needs one API, the first two rows are more network than the requirement asked for.
When the shared transit gateway wins
A transit gateway attaches each VPC and the VPN as separate networks, and cross-account sharing lets the VPC owners use the hub without merging accounts. That is the appeal: one place where the on-premises prefixes meet the AWS networks, and one place to reason about which attachment learns which route.
Attaching everything does not mean allowing everything. Association and propagation decide which attachment uses which route table, so two VPC prefixes can each reach an on-premises service while their mutual access stays excluded by the hub's design. The on-premises side still needs return routes for the AWS prefixes, and that is a second team's change ticket.
The cost is organisational as much as financial. The hub owner controls routing relationships that other teams depend on, so a change in one attachment can move traffic for a service the hub owner has never heard of. Attachment hours and data processing add up with every network you attach, which is why hubs tend to grow faster than the team that runs them.
When separate VPNs or a narrow proxy wins
Two independent VPNs fit a small deployment with real operational boundaries: each account changes its own tunnels, and neither can break the other by editing a route table. The limits live on the on-premises side. The peer gateway needs capacity for the additional tunnels, the address plans must not overlap, and two configurations advertising the same prefixes need a deliberate preference rather than hope.
A proxy is the narrowest interface. If account A needs one database or one API in account B, a scoped intermediary gives you a defined entry with its own authentication, logging and availability story. It is also the option most likely to be misused: an intermediary that forwards to every private destination has become an unrestricted relay with extra steps, and it will not behave like transparent VPC-to-on-premises transit for anything else.
The VPC peering restrictions are worth reading before any of this, because they explain why the fourth idea keeps coming back and why it cannot work.
Pick the smallest interface that meets the requirement
Order the questions: does A need a network, a set of networks, or one service? Does the on-premises team want one path or several? Who is allowed to change routing for the other team's traffic? The first answer that produces the smallest interface is the architecture, and everything after it is implementation.
Record the answer with the prefix plan, the route ownership, the tunnel or attachment inventory, and the failure mode each side expects. When someone later asks why account A cannot simply use account B's VPN, that record is the answer, and it saves you from re-litigating the same three options on the next project.