Why an AWS VGW subnet route cannot pick one VPN tunnel

Two Site-to-Site VPN connections terminate on one virtual private gateway and advertise the same branch prefix. The subnet route table holds one entry for that prefix, pointing at the gateway, and no field that names a tunnel. Preference between the connections therefore happens somewhere the console does not label as routing. Knowing which layer owns the decision is the difference between a working standby and a change that does nothing.

Two layers are in play: the VPC route that says which gateway, and the gateway's own choice of tunnel. Confusing them produces edits that look correct in the route table and never move a packet.

Two layers that look like one

The subnet route answers a single question: for this destination, which attachment? Its target is the virtual private gateway, and its metric competes only with other routes in the same table. Nothing in that entry distinguishes tunnel one from tunnel two, or connection A from connection B. A more specific prefix is a different destination match, not a finer-grained path choice.

The gateway answers the next question: among the tunnels it holds for that prefix, which one carries traffic now. That decision comes from tunnel health and the BGP attributes received from the customer gateway, and it never appears in the subnet route table.

What the VGW actually compares

Health comes first. A tunnel that is down, or a BGP session that has not come up, loses before any attribute is examined. That is why prepending a path on a connection that is already failing changes nothing.

Among eligible paths for the same prefix, AWS prefers the shorter AS_PATH. When two paths are equal in length it compares MED, subject to the documented condition about the first AS in the path. Read the published order rather than the folklore version, because the folklore usually drops the health step and the static-route exception. One consequence: three prepends on the backup connection make the primary strictly shorter, which is the usual way to state the preference.

Prepending, and when it does nothing

Prepending happens on the customer gateway's outbound advertisements, not inside AWS. You add your own ASN two or three times to the prefix you want AWS to avoid, and AWS then sees a longer path for that connection. The primary connection keeps the unprepended advertisement. If both connections advertise from the same ASN with the same prepend count, you have expressed no preference at all.

Check the received path on the AWS side after the change. A prepend that never left the customer device looks exactly like one AWS ignored.

Static routes ignore the whole argument

If the connection uses static routing there is no AS_PATH to lengthen. AWS documents static VPN routes as taking priority over BGP-learned routes for the same prefix, so a mixed design does not behave like a fully dynamic one. Decide the routing type first, then choose the preference mechanism that exists for it.

With two static connections advertising the same prefix, the useful lever is the prefix: advertise a more specific range on the connection you want used, and accept that you changed which destination matches rather than which path wins.

Why a transit gateway is a different answer

A transit gateway supports equal-cost multipath across VPN attachments, so two connections can share traffic instead of one standing by. That design has a different failure surface: flows spread across tunnels, and one tunnel going down moves only part of the load. Copying a VGW recipe onto a transit gateway, or the reverse, produces expectations neither platform meets.

Pick the model before the mechanism: active and standby with a pinned preference, or active and active with ECMP.

What to verify after you set it

Confirm four things in order. The subnet table still resolves the prefix to the intended gateway. The gateway lists both tunnels as up. The received AS_PATH on the connection you want to avoid is longer than the other one. And a real flow from an instance in that subnet traverses the expected tunnel, observed on both ends rather than inferred from a green status.

Then run the approved failover test and watch the surviving path carry the service. A preference that exists only in a configuration diff is not a preference yet.