Border Gateway Best Practices

Plan your address space before peering

The single most common Border Gateway problem isn't a BGP session that won't come up — it's a session that comes up perfectly while carrying overlapping prefixes. If your VPC and the peer both use 10.10.0.0/16, BGP will advertise both sides and traffic will end up in the wrong place. Before you configure a peering, map the address space on both ends and confirm there is no overlap. Renumbering later is painful.

Start with an explicit prefix list, not "advertise all subnets"

"All subnets" is convenient and dangerous. A subnet you add for an unrelated internal service becomes visible to your BGP peer the moment it exists. Start with a manual advertised prefix list covering exactly the subnets the peer needs to reach. Revisit the list when you actually want to expose new subnets — that review is the feature, not overhead.

Prefer regional mode unless you have a reason for global

Regional mode keeps the blast radius of a misconfiguration inside one region. Global mode propagates learned routes — and mistakes — to every region the VPC reaches. Use regional until you have a clear reason to flip to global (single peering that must serve every region, centralized on-prem connectivity, etc.). Going regional → global later is a single toggle; going the other way is much more work.

Use distinct ASNs on each side

Using the same ASN on both sides of a BGP session requires extra configuration (allowas-in or similar) and makes it easier to create loops when you add a third party. Even when the platform allows it, pick different ASNs — one of them can still be a private-range ASN. The default is quieter.

Check the VPC route table after any session change

When a BGP session comes up, drops, or has its advertised prefix set changed, the VPC route table updates. Always verify the table looks the way you expect before routing production traffic over the session. Navigate to VPC → Route Tables, select the table, and look for Dynamic Routes from the gateway.

Size your advertised set carefully on global-mode gateways

Every prefix learned by a global-mode gateway propagates to every region's route table. Large numbers of prefixes learned from a hub-style peering multiply the state carried on the backbone and in every VPC route table. Keep the peer's advertised set as small as practical, and avoid using global mode for broad route tables that only one region needs.

Treat BGP as a reachability signal, not an access-control signal

BGP tells your VPC where to send traffic for a prefix. It does not tell the target instance whether to accept it. Border Gateway itself does not have security groups — access control has to live on the workload side: OS-level firewalls, application-level auth, or an in-path appliance. Don't assume the presence of a Dynamic Route implies authorized access.

Schedule mode and policy changes for quiet windows

A routing-mode change or a significant shift in advertised prefixes triggers a reconvergence. Route tables are rebuilt in every region affected, and existing connections may see a brief loss during the churn. Outside of emergencies, make these changes when traffic is low.

Document your BGP configuration with your peer

BGP troubleshooting is much faster when both sides have a written agreement on ASNs, advertised prefixes, VLANs, passwords, and expected route scope. When something breaks, the documented expectation is what you compare against.

---

Troubleshooting

BGP session won't come up. Check the basics first: can the two sides reach each other on the peering IP at all (ping or tcpdump on port 179)? Confirm the peer's ASN matches what you configured. If the transport is a private line or interconnect, confirm it is up and not flapping. Most "BGP won't come up" issues are actually transport issues.

Session comes up but no prefixes are learned. Confirm the peer is actually advertising prefixes by checking the peer's routing output. Also confirm the Border Gateway is in the routing mode you expect.

Prefixes are learned but traffic isn't flowing. Check the VPC route table — the Dynamic Routes should be installed with the Border Gateway as next hop. If they are, look at what happens to the packet once it lands on the workload instance: OS firewalls, application-layer rules, or a more specific policy route that's capturing the traffic before it reaches the learned route.

Traffic works in one direction but not the other. Asymmetric advertising. Your side advertises what the peer needs, but the peer isn't advertising what your side needs (or vice versa). Verify the advertised prefix list on both ends.

Route flapping. Usually caused by transport instability — BGP follows the session liveness. Stabilize the underlying connection and the flapping usually stops. If the transport is solid and the session still flaps, check the peer ASN, password, and link settings on both sides.

Global-mode routes not visible in another region. Confirm the gateway's mode is actually global (not regional) and that the VPC has a subnet in the region you're checking. Global mode propagates to regions the VPC has subnets in — if the VPC doesn't exist in a region, there's no route table for it there.

Deleting a Border Gateway is rejected. Resources still reference it — BGP neighbors, advertised route sets, or policy routes that name it as next hop. Remove those references, then retry the delete.