Add an On-Premises Subnet to an AWS VPN: VGW vs Transit Gateway

An existing Site-to-Site VPN carries 10.60.0.0/16, a new service network appears behind the same on-premises gateway as 10.70.0.0/16, and someone asks whether a proxy is required. Usually it is not: a routed path can carry the prefix, but only if three things line up, and which three depends on the AWS architecture you already run. A virtual private gateway has one route-table boundary; a transit gateway adds a second. Getting the advertisement right and the table wrong produces a session that looks healthy and delivers nothing.

Publish a prefix the gateway can actually deliver

The on-premises gateway needs an onward route to the new network before any advertisement is meaningful. Advertising 10.70.0.0/16 through BGP tells AWS where to send packets for that range; it does not create the local forwarding path that makes the range reachable at the other end. Confirm that the gateway has a route for the prefix pointing at the device that holds it, and that the device is configured to answer for those addresses. Export policy and accepted prefix limits are the next constraint, because a prefix that the session filters out never reaches AWS at all.

Keep aggregates and more-specifics deliberate. Overlapping paths that arrive from two directions are a design decision, not a detail to discover later.

Path one: the virtual private gateway boundary

With a virtual private gateway, the AWS VPN routing documentation describes two distribution modes, static routes and BGP advertisements, and both depend on the subnet route table that the application actually uses. Propagation is convenient when you control the whole range, and an explicit route is easier to reason about when you want the destination listed next to the target. Either way, the check is the same: does the specific application subnet table contain a working path to the VPN target for the new prefix, and does it win against anything more specific?

A healthy BGP session proves the channel exists. It says nothing about whether a given subnet table consumed the route.

Path two: the transit gateway adds a table

A transit gateway splits that one question into two. The VPC subnet has to send the destination to the transit gateway attachment, and then the transit gateway route table has to select the VPN attachment for that same prefix. Association and propagation choices decide which attached networks receive the route, so a prefix can be advertised correctly by the VPN and still never reach the VPC whose table was never associated with the right route table.

The common failure is a route that exists in one table and not the other, with each team convinced its side is correct. When you compare the two architectures, this extra boundary is the whole difference: more places to look, and more precise control over who gets the route.

Route propagation does not grant every attachment the prefix either. It distributes it to the tables configured to receive it.

The return path is its own policy decision

Traffic that arrives is only half the exchange. The new on-premises network needs a route back to the AWS source prefixes through the correct gateway, and the security policy on both ends has to permit that source and destination pair. If the tunnel negotiates a protection scope with traffic selectors, the new prefix has to be inside it, or the packet is dropped before any route table is consulted.

Address overlap is the other trap. Disjoint, explicitly owned ranges keep this simple; overlapping ranges mean translation or a redesign, and neither is an interchangeable variant of the same recipe.

Test with a source in the new network and a destination in the application subnet, then repeat in the other direction. A one-directional test proves one direction.

When the proxy is genuinely the better boundary

A proxy earns its place when the requirement is a narrow service interface, when the application already expects that architecture, or when the network path cannot be made to carry the prefix without translation you do not want. It is not the fallback for a route table entry nobody checked.

Decide in this order: local forwarding, advertisement, table boundary, return policy. Fix the first one that fails, and only then ask whether the routed path is the right answer at all.