Why your BGP session does not show up in the VPC route table

The story that gets repeated is that a routing daemon on an EC2 VPN appliance will teach the VPC its remote prefixes once BGP comes up. Half of that is true. The session comes up, and nothing in the VPC route table changes because of it, which is why the first symptom is usually a subnet quietly black-holing traffic.

Two different things are being confused here: peering with a route server, and installing routes into a table.

The myth: bring up BGP and the VPC learns the prefixes

BGP is a conversation between two speakers, and in this design the speakers are the routing daemon on your appliance and a VPC Route Server endpoint that AWS places in a subnet you own. That conversation carries prefixes. It does not touch the route table of your workload subnets, because those tables learn only through propagation that has to be enabled on each one. Until that happens the VPC fabric knows nothing about what the appliance knows.

The setup steps are separate for a reason: associate, create the endpoint, peer, then enable propagation.

Route Server is a control plane, not a tunnel

Route Server does not encrypt, forward or inspect a single packet. It exists to exchange BGP with the appliance and hand the resulting prefixes to the route tables configured to receive them. The data plane is unchanged: packets still leave through the appliance network interface, travel its VPN, and come back the same way.

That means the source and destination check on the forwarding instance still matters, because the instance is now forwarding traffic addressed to somebody else.

Security groups and subnet controls still apply to the forwarded flow as well. Route Server will not make an appliance that drops traffic forward it, and it will not repair a missing return route on the remote side.

Propagation is per route table, not per VPC

Associating the route server with the VPC and enabling propagation on a route table are two decisions, and only the second one changes what a subnet does. A VPC with six route tables can receive a propagated prefix in one and not the other five, which is exactly right for a hub subnet and exactly what produces the puzzling half-works result. Even where propagation is on, a competing route can win, because VPC route selection prefers the longest prefix and, at equal length, prefers a static route over a propagated one. That preference is applied silently.

Check the effective table for the specific subnet rather than the list of prefixes the appliance advertises. The API answers that question directly: aws ec2 associate-route-server and aws ec2 enable-route-server-propagation --route-table-id <id> are the two steps people forget, and aws ec2 describe-route-tables --route-table-ids <id> shows whether the prefix arrived as a route-server entry at all.

The appliance still carries every packet

Advertising reachability is not the same as having it. A BGP session can stay established while the appliance VPN is down, and a static advertisement that never changes keeps pulling traffic toward a dead path. Route Server supports failure detection such as BFD, but that tests liveness of the peer, not the health of everything behind the peer.

Tie the advertisement to the real remote route: announce the prefix when the tunnel and the remote network are up, and withdraw it when they are not.

Withdraw a prefix and watch what happens

Test in stages, and make the last stage a removal. Confirm the advertisement arrives, the prefix appears in each intended table, the appliance is the next hop, forwarding crosses the active tunnel, and the remote end answers. Then withdraw a test prefix, or shut an approved tunnel, and observe whether traffic moves where the design says it should. Record the before and after tables while the test is still open.

Moving a route to a second appliance does not move the sessions it was carrying, because NAT and firewall state stay with the first device.

For a fixed set of a dozen prefixes, static routes in the VPC tables remain the cheaper answer. Route Server earns its place when the prefix list genuinely changes and the withdrawal policy is something you can explain to the person on call.