How to Route SaaS Traffic to the Right Customer VPN
Overlapping customer subnets break shared routing. Pick an isolation model, bind each job to a verified tenant, and test cross-tenant paths before launch.
A SaaS platform connects out to a dozen customer networks, and two of those customers both use 10.20.0.10 for their primary database. A worker that receives that address in a job has no way to tell which database the job means, and a shared routing table will happily send it to whichever tunnel the prefix points at. The fix is not more tunnels; it is deciding where tenant identity enters the path and which isolation model the address plan requires. Three conditions settle the choice: whether customer prefixes overlap, how far a mistake may spread, and who operates the connector.
Two customer databases, one destination address
An IP address is a location, not an identity. The request has to carry a tenant that the server verified, and that tenant has to select the network context before the destination is resolved.
When it does not, the failure is quiet. The connection succeeds, the query runs, and the answer comes from the wrong customer's database because the route table had one entry for 10.20.0.10. DNS makes it worse: a cached name that resolved inside tenant A's context can be reused by a job running for tenant B. Nothing in the packet distinguishes the two, so no amount of retry logic repairs it.
Decide on the isolation model first
Write the three conditions down before comparing products. Overlap decides whether one address space can be shared at all; blast radius decides whether a routing mistake is a support ticket or a breach; operational ownership decides whether you can run a connector fleet per tenant.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
If prefixes are distinct and policy allows a controlled hub, one Transit Gateway with per-tenant route tables is workable. Attachment association chooses the route table used for traffic entering from that attachment, and propagation chooses which routes appear in a table. A tenant attachment associated with only its own table, and propagating only its own prefixes, reaches the hub and nothing else. That is a routing decision, and it stays correct only while nobody adds a default route to the shared table.
If prefixes overlap, routing alone cannot separate them. You need either a distinct network context per tenant or a translation plan that gives each customer's space an unambiguous meaning.
What Transit Gateway isolation actually means
Association and propagation are the two knobs that matter, and they are easy to confuse. Association answers which table a packet from this attachment is looked up in; propagation answers which tables learn this attachment's routes. Isolation comes from making both tenant-specific, not from creating more attachments.
A default all-to-all setup is convenient and is not isolation. Separate route tables restrict connectivity, but they do not give one unchanged destination address two meanings inside the same routing context. If the application resolves 10.20.0.10 before it knows the tenant, the routing layer has already lost the information it would need.
AWS added attachment-level 1:1 NAT for Transit Gateway and Cloud WAN on October 23, 2026, which changes the overlap answer for supported attachments. The Transit Gateway NAT documentation describes static, stateless, equal-prefix IPv4 mappings with host bits preserved. Check supported attachment types and regional constraints before you design around it.
Bind the job to a verified tenant
Every job should carry a server-verified tenant identity, and that identity should select an administrator-owned connection record. The record names the approved network context, the service address, the credential reference, and the operations allowed there. An untrusted request must never supply its own VPN identifier, gateway, or private target, because a valid login is not permission to probe every connected customer's address space.
In an isolated-connector design, tenant A's work goes to an A-specific connector that runs in A's VPC and can reach only A's approved resources. Separate containers on one host do not create that separation by themselves; the network namespaces, routes, and egress policy have to implement it. The connector also needs tenant-scoped credentials and queues, since a private route does not scope a shared secret or a shared work item. Pooled application workers are fine as long as the network context and credentials are chosen per tenant, not per host.
Health checks should name the tenant and the stage: tunnel established, route present, and a real service request succeeded are three different signals. An aggregate count of tunnels that are up will hide the one customer whose connector is broken.
Test the paths that must fail
Run three tests before launch. An allowed A operation must succeed, an allowed B operation must succeed, and an A job deliberately aimed at B's connector or translated alias must fail closed. Then break one tunnel and confirm the job fails for that tenant only, without falling back to another customer's same-numbered subnet. Restoration should be tested too, because a stale route or cached credential can outlive the outage.
The architecture can be pooled workers with isolated connectors, or fully separated tenant resources. The invariant is the same: verified tenant context selects the route and the credentials, and no route change ever grants application permission across tenants.