VGW BGP Advertisements vs the VPC Route Table: What Changes What

A missing prefix in a VPC subnet route table and a missing prefix on the customer router are two different faults, and only one of them is repaired inside AWS route tables. The virtual private gateway advertises the CIDR blocks associated with its VPC; the subnet route table decides where a workload sends a reply. Treating the second as a way to change the first is the most common wrong turn in this diagnosis. Run the checks below in order and keep the two directions apart.

Name the attachment before you read any table

A Site-to-Site VPN terminates either on a virtual private gateway or on a transit gateway, and the resource IDs decide which routing model applies. Read them first: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. The answer tells you whether the next table to inspect is a VPC route table or a transit-gateway route table.

If the VPN is attached to a transit gateway, stop treating the VPC route table as the control plane. There the VPC table points at the gateway attachment, and association and propagation happen in the transit-gateway route table. Mixing the two views produces confident conclusions about the wrong object.

The AWS-to-office direction is an advertisement

For a VGW attachment, the gateway advertises the CIDR blocks associated with its VPC to the customer gateway over BGP. Adding an individual subnet route, or pointing a route at a peered VPC or an appliance, does not add another associated CIDR and does not appear in that advertisement. If the office is missing a prefix, compare the received-route list with the VPC associations before editing any route table.

The simple rule has exceptions, so keep it scoped. A VPN CloudHub arrangement can re-advertise site prefixes between customer gateways, and a transit gateway follows its own propagation rules. The statement that a VGW advertises only its own VPC is a useful default, not a law that covers every topology you will meet.

The office-to-AWS direction is propagation plus selection

In the reverse direction the VGW learns the office prefix, but that alone does not move a workload. The subnet route table must either have propagation enabled for the attachment or carry a static route to the same destination. When both exist for one prefix, the static route wins, and the longest prefix match runs before either of them.

Read the origin rather than assuming it: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. An entry with origin EnableVgwRoutePropagation came from BGP; an entry with origin CreateRoute was typed by a human and will keep winning until someone deletes it.

A runbook that keeps the two directions separate

Record four facts on the AWS side before changing anything: the attachment type, the associated VPC CIDRs, the subnet route origin for the prefix in question, and the tunnel and BGP state. The same describe call returns VgwTelemetry with an accepted-route count per tunnel, which tells you whether AWS accepted any routes at all. Then compare that with what the customer device actually installed. A prefix present in BGP but absent from the forwarding table is a local import or best-path problem, not an AWS route-table problem.

If the subnet table lacks the prefix entirely, enable propagation or add a static route, then re-read the same query after the propagation interval rather than assuming the change was immediate. If the prefix exists and traffic still fails, leave the control plane alone and move to the data path.

What not to change while you are in there

Do not toggle propagation on unrelated route tables to fix one missing prefix, and do not add a default route to paper over a single absent CIDR. Both changes widen the blast radius and make the next diagnosis harder. Keep the edit limited to the table that serves the workload subnet in question.

The data path is separate from all of this. Security groups are stateful, network ACLs are not, and a host firewall or an asymmetric return path can drop traffic that routing delivered correctly. An advertised aggregate also does not authorize every service inside it, so restrict access at the policy boundary instead of relying on whether an address happens to appear in a BGP announcement.

Save the before and after of every route-table query in the change record. If the change makes things worse, restore the previous routes and confirm with the same query, because a rollback you cannot verify is only a guess.