Border Gateway Protocol is usually associated with internet service providers and large autonomous systems, but BGP has also become a fundamental part of modern cloud networking.
The moment an organization connects a data center, branch network, SD-WAN platform, or another cloud to AWS, Microsoft Azure, or Google Cloud, dynamic routing becomes an important architectural consideration.
A typical hybrid environment might look like this:
On-Premises Network
|
Router
|
BGP
|
VPN / Dedicated Connection
|
Cloud Transit Network
|
VPC
|
ApplicationBGP allows networks on both sides of that connection to exchange routes dynamically instead of requiring administrators to maintain large collections of static routes manually.
But cloud BGP introduces additional questions:
This guide explains those questions from a practical cloud-networking perspective.
For the broader architecture first, read Cloud Network Architecture: AWS vs Azure vs Google Cloud. If you specifically need centralized cloud transit, continue with AWS Transit Gateway vs Azure Virtual WAN vs Google Network Connectivity Center.
Border Gateway Protocol (BGP) is a routing protocol used to exchange reachability information between routing domains.
Instead of manually configuring:
10.20.0.0/16 → Gateway A
10.30.0.0/16 → Gateway B
10.40.0.0/16 → Gateway Crouters can dynamically exchange information about the networks they know.
A simplified BGP relationship looks like:
Router A
ASN 65001
|
| BGP
|
Router B
ASN 65002Router A can advertise:
10.10.0.0/16
10.20.0.0/16while Router B advertises:
172.16.0.0/16Each side then learns how to reach networks behind the other router.
This is extremely useful in hybrid cloud environments because routes can change automatically when connectivity changes.
Imagine a company with an on-premises network:
10.10.0.0/16and cloud workloads:
10.50.0.0/16With static routing, administrators might manually configure:
On-Prem:
10.50.0.0/16 → VPN
Cloud:
10.10.0.0/16 → VPNThat is manageable with two networks.
Now imagine:
30 VPCs
12 Azure VNets
8 Google Cloud VPCs
4 data centers
60 branch officesManually maintaining every route becomes much harder.
BGP changes the model to:
Network
|
Advertise Prefixes
|
BGP
|
Learn Remote Prefixes
|
Routing TableWhen properly designed, new routes can propagate through the architecture without manually adding every destination to every router.
One distinction is particularly important.
BGP exchanges routing information.
It does not carry application packets itself.
Conceptually:
BGP
|
| learns
↓
10.50.0.0/16 → Connection AThe routing table then uses that information when forwarding actual packets.
Therefore:
BGP = control plane
while:
packet forwarding = data plane
This distinction becomes important during troubleshooting.
A BGP session can be established successfully while application traffic still fails because of:
Never treat an established BGP session as proof that end-to-end connectivity works.
BGP identifies routing domains using Autonomous System Numbers, or ASNs.
A simplified hybrid architecture might be:
Enterprise Router
ASN 65010
|
| BGP
|
Cloud Router
ASN 64520Private ASNs are commonly used in private enterprise and cloud routing designs.
The ASN becomes part of BGP’s routing logic, particularly through the AS_PATH attribute.
For example:
Prefix: 10.100.0.0/16
AS_PATH: 65010 65020The AS path helps describe which autonomous systems a route has traversed.
In traditional BGP, this information contributes to loop prevention and path selection.
AWS uses BGP in several hybrid connectivity scenarios, particularly with:
A typical architecture might look like:
Corporate Network
|
Customer Router
|
| BGP
|
AWS Connectivity
|
Transit Gateway
|
VPCWhen Transit Gateway is involved, routing has multiple layers.
Traffic may pass through:
Workload
↓
VPC Route Table
↓
Transit Gateway Attachment
↓
Transit Gateway Route Table
↓
VPN / Direct Connect Path
↓
On-Premises RouterThis distinction is critical.
The VPC route table and Transit Gateway route table are not the same routing table.
AWS documents that Transit Gateway route tables control routing between supported attachments, and attachments can propagate routes into Transit Gateway route tables.
Official reference: AWS Transit Gateway route tables
Suppose the enterprise advertises:
10.100.0.0/16toward AWS.
Conceptually:
On-Prem Router
10.100.0.0/16
|
BGP
|
VPN / Direct Connect
|
Transit GatewayThe route can then become available to the appropriate Transit Gateway routing domain depending on the attachment and propagation configuration.
The important point is that learning a route and making that route available to every attached VPC are separate decisions.
This enables segmentation.
For example:
Production TGW Route Table
10.100.0.0/16 → Hybrid Attachmentwhile a development routing domain could intentionally omit that route.
This provides much better control than blindly distributing every enterprise route everywhere.
Two concepts often confuse engineers working with Transit Gateway:
association and propagation.
An attachment is associated with a Transit Gateway route table that determines how traffic entering through that attachment is routed.
Propagation controls whether routes associated with an attachment are automatically inserted into another Transit Gateway route table.
Conceptually:
VPC-A Attachment
|
Associated with
|
Route Table Awhile:
VPN Attachment
|
Propagates Routes
|
Route Table AAWS currently supports both propagated and static routes in Transit Gateway route tables.
This distinction is essential when designing separate production, development, and shared-services routing domains.
Microsoft Azure uses BGP extensively in hybrid connectivity.
Common examples include:
A simplified architecture is:
On-Premises Router
|
BGP
|
ExpressRoute / VPN
|
Azure Virtual Hub
|
VNetWith Azure Virtual WAN, routes from VPN, ExpressRoute, and other connections can propagate into Virtual Hub route tables.
Microsoft documents that connections can dynamically propagate routes to one or multiple Virtual Hub route tables, while BGP can be used to exchange routes with external routers.
Official reference: Azure Virtual Hub routing documentation
Each Virtual WAN hub has routing tables.
A basic model is:
Spoke VNet
|
Virtual Hub
|
Route Table
|
DestinationAzure provides a Default route table and supports additional routing behavior through associations and propagation.
The same architectural principle we saw with AWS appears here:
Connecting something to a transit hub does not necessarily mean every route should be distributed everywhere.
For example:
Production
|
+------ Shared Services
Development
|
+------ Shared Servicesdoes not necessarily imply:
Development → ProductionRouting policy should reflect security and segmentation requirements.
Virtual WAN can contain both static and dynamically learned routes.
This matters because route preference can change the path traffic takes.
Microsoft documents that static routes added to a Virtual Hub route table take precedence over dynamically learned routes for the same prefixes.
Consider:
10.50.0.0/16being learned dynamically through one connection while a static route for the same prefix points toward a security appliance.
Traffic may follow the static route instead.
This is often intentional in architectures that require centralized inspection:
Spoke
|
Virtual Hub
|
Firewall
|
Hybrid NetworkBut it also means engineers must understand both dynamic and static routing when troubleshooting unexpected paths.
Google Cloud uses Cloud Router as a major component of dynamic hybrid routing.
Cloud Router works with technologies such as:
A simplified architecture looks like:
On-Premises Router
|
BGP
|
Cloud Interconnect / VPN
|
Cloud Router
|
Google Cloud VPCCloud Router exchanges routing information through BGP while the underlying connectivity service transports the actual traffic.
This distinction is important:
Cloud Router
=
Dynamic route exchange
Cloud VPN / Interconnect
=
Connectivity pathThey work together but perform different functions.
Network Connectivity Center extends this architecture into centralized connectivity.
Google documents NCC as a hub-and-spoke framework capable of connecting VPC networks and hybrid networks.
A hybrid architecture could look like:
Branch
|
Cloud VPN
|
Cloud Router
|
NCC Hybrid Spoke
|
NCC Hub
|
VPC NetworksGoogle’s current documentation states that hybrid spokes can use resources such as HA VPN tunnels, Cloud Interconnect VLAN attachments, and Router appliance VMs.
Official reference: Google Network Connectivity Center overview
Network Connectivity Center can also integrate third-party virtual routers.
A router appliance VM establishes BGP peering with Cloud Router.
Conceptually:
External Network
|
Third-Party Router
|
Router Appliance VM
|
BGP
|
Cloud Router
|
Google Cloud VPCGoogle explicitly documents BGP as the mechanism used between Router appliance instances and Cloud Router to dynamically exchange routes.
This allows products such as SD-WAN or virtual routing appliances to participate in cloud routing architecture without requiring every route to be manually configured.
Google Cloud introduces an important design decision:
regional dynamic routing vs global dynamic routing.
Consider VPC resources in:
Europe
United States
AsiaIf dynamic routes need to influence resources across multiple regions, the VPC’s dynamic routing mode becomes important.
Google documents that global dynamic routing is required in certain NCC cross-region route-exchange scenarios.
This is an excellent example of why a working BGP session does not automatically mean every region sees the routes in the way an engineer expects.
The routing scope must also be understood.
The providers use different products, but the high-level architecture can be summarized as follows:
| Area | AWS | Azure | Google Cloud |
|---|---|---|---|
| Dynamic routing protocol | BGP | BGP | BGP |
| Dedicated hybrid service | Direct Connect | ExpressRoute | Cloud Interconnect |
| VPN connectivity | Site-to-Site VPN | VPN Gateway | Cloud VPN |
| Transit architecture | Transit Gateway | Virtual WAN | NCC |
| Cloud routing component | TGW/VGW/DX architecture | Virtual Hub/Gateway | Cloud Router |
| Third-party routing integration | Transit Gateway Connect and appliances | NVAs/BGP connections | Router appliance |
| Route segmentation | TGW route tables | Virtual Hub route tables | NCC topology/route controls |
The underlying lesson is more important than product names:
All three providers require engineers to think about route advertisement, propagation, preference, segmentation, and return paths.
Now consider a practical hybrid architecture.
AWS
|
Transit Gateway
|
|
Corporate ----+---- Azure
Network | Virtual WAN
|
|
Google Cloud
NCCThe corporate network might advertise:
10.0.0.0/8while the clouds advertise:
AWS
10.50.0.0/16
Azure
10.60.0.0/16
Google Cloud
10.70.0.0/16The enterprise router then learns how to reach each cloud dynamically.
But this introduces an important design question:
Should every cloud learn routes to every other cloud through the corporate network?
Maybe.
Maybe not.
That decision should be intentional.
Imagine:
AWS → On-Prem → AzureAWS advertises:
10.50.0.0/16to the enterprise router.
The enterprise router then advertises that prefix toward Azure.
Azure now has a route to AWS through the data center.
The resulting traffic path could become:
Azure
↓
ExpressRoute
↓
Data Center
↓
Direct Connect
↓
AWSThis can be useful.
It can also be completely unintended.
Therefore, cloud BGP architectures need explicit route advertisement policies.
Do not simply redistribute everything everywhere.
A good BGP architecture controls which prefixes are exchanged.
Suppose the enterprise owns:
10.0.0.0/8but only wants AWS to reach:
10.20.0.0/16
10.30.0.0/16Advertising the entire /8 may provide far broader reachability than necessary.
A better approach is often:
Advertise:
10.20.0.0/16
10.30.0.0/16
Do not advertise:
10.0.0.0/8unless the architecture genuinely requires it.
Routing policy should follow the same least-privilege philosophy used in firewall design.
Our nftables Inter-VLAN Firewall guide applies this principle at the firewall layer; cloud BGP applies a similar discipline to reachability itself.
A route means:
The network knows where to send traffic.
It does not mean:
The traffic is authorized.
Suppose BGP installs:
10.50.0.0/16 → Cloud ConnectionThe route only provides reachability.
Security still depends on controls such as:
Cloud Firewall
Security Group
Network ACL
NVA
Host Firewall
Application PolicyA strong architecture separates:
ROUTING
Where can traffic go?from:
SECURITY
Where is traffic allowed to go?Combining the two concepts mentally is a common source of troubleshooting mistakes.
One of the most important cloud networking problems is asymmetric routing.
Consider two cloud connections:
Link A
/
Router
\
Link BTraffic leaves through Link A:
Client
↓
Link A
↓
Cloudbut returns through Link B:
Cloud
↓
Link B
↓
ClientPure IP forwarding may tolerate this.
Stateful firewalls often do not.
If the firewall sees only one side of a connection, it may drop packets because the expected session state is missing.
This is why BGP path engineering must be coordinated with firewall architecture.
For the Linux-side behavior behind this issue, read Linux rp_filter and Asymmetric Routing.
Cloud-connected Linux routers may also have multiple upstream paths.
For example:
Linux Router
|
+---- ISP
|
+---- Cloud VPN
|
+---- MPLSA normal destination-based routing table may not always produce the desired path.
Linux policy routing can select routing tables based on additional criteria.
CorgiNetwork’s Linux Policy Routing with ip rule and Multiple Routing Tables explains how Linux can maintain multiple routing decisions.
For systems configured through Netplan, also see Netplan Multiple Default Routes and Policy Routing.
These concepts become highly relevant when Linux participates as a cloud router, VPN gateway, firewall, or network appliance.
One major advantage of dynamic routing is automated failure response.
Consider two connections:
Connection A
/
Data Center
\
Connection BThe preferred path is A.
If A fails, BGP can withdraw routes learned through that connection.
The routing system can then use another available path.
Conceptually:
Normal:
10.50.0.0/16 → Connection A
Failure:
Connection A DOWN
↓
BGP route withdrawn
↓
10.50.0.0/16 → Connection BThis is far more scalable than expecting an administrator to manually change routes during every connectivity failure.
However, automatic failover does not guarantee instantaneous application recovery.
Convergence time, firewall state, DNS, application sessions, and routing policy can all affect the final outcome.
Hybrid architectures commonly use either active/active or active/passive connectivity.
Primary Connection
|
ACTIVE
Backup Connection
|
STANDBYThe backup path is used mainly after failure.
Connection A
+
Connection B
|
Both Carry TrafficActive/active designs can improve utilization and resilience but require greater attention to path symmetry.
If traffic can enter through multiple paths, engineers must understand how return traffic chooses its route.
Suppose two paths advertise:
10.50.0.0/16The routing system must choose between them.
BGP can use several attributes and provider-specific routing rules to influence that decision.
Traditional BGP concepts include:
Cloud providers do not necessarily expose every traditional BGP control in the same way.
Therefore, never assume that a technique used on an ISP router behaves identically inside every managed cloud networking service.
Consult the documentation for the specific service being used.
Even when BGP is involved, IP forwarding fundamentally depends on route specificity.
Suppose the routing table contains:
10.0.0.0/8 → Path A
10.50.0.0/16 → Path BTraffic to:
10.50.10.20matches both routes.
But:
10.50.0.0/16is more specific.
Therefore Path B is used.
This principle becomes extremely important when cloud environments advertise aggregate routes alongside more specific prefixes.
One of the hardest problems in multicloud networking is overlapping address space.
Imagine:
AWS:
10.20.0.0/16
Azure:
10.20.0.0/16Now an enterprise router receives traffic for:
10.20.5.10Which cloud contains the destination?
The IP address alone cannot answer the question.
Possible solutions include:
But every workaround increases complexity.
A good multicloud strategy should therefore establish an IP addressing plan before large numbers of networks are deployed.
Instead of thinking only about connectivity, create an advertisement policy.
For every routing domain, document:
Prefixes originated
Prefixes accepted
Prefixes rejected
Default routes
Backup routes
Preferred paths
Failover pathsFor example:
AWS
Advertise:
10.50.0.0/16
Accept:
10.10.0.0/16
10.20.0.0/16
Reject:
Everything elseAzure:
Advertise:
10.60.0.0/16
Accept:
10.10.0.0/16
10.20.0.0/16Google Cloud:
Advertise:
10.70.0.0/16
Accept:
10.10.0.0/16
10.20.0.0/16This makes route behavior much easier to audit.
Dynamic routing can change network reachability automatically.
That makes routing policy security-critical.
An incorrect advertisement could accidentally make a sensitive network reachable from an unintended routing domain.
At minimum, administrators should consider:
Routing and cybersecurity should not be designed independently.
Our Intrusion Detection and Prevention Systems guide explains how network monitoring can complement preventative controls.
For centralized security telemetry, see SIEM Explained.
A production environment should monitor more than whether the tunnel is “up.”
Important signals include:
BGP session state
Prefixes received
Prefixes advertised
Route count changes
Path changes
Tunnel state
Latency
Packet loss
Interface utilization
Route withdrawalsFor example, a BGP session dropping from:
ESTABLISHEDto:
IDLEmay remove many routes at once.
That could affect multiple applications even though the applications themselves remain healthy.
Network monitoring should therefore correlate application failures with routing events.
When connectivity fails, troubleshoot in layers.
Do not immediately modify the firewall.
Start with the BGP session.
Router A
|
BGP?
|
Router BIf not, check:
For example:
10.50.0.0/16Advertising a prefix does not prove that the peer accepted it.
A learned route can lose to another route.
Follow the actual path.
This is one of the most commonly overlooked checks.
Only after validating routing should you focus on:
firewalls
security groups
ACLs
host firewallsThe workflow is:
BGP SESSION
↓
ADVERTISEMENT
↓
RECEIVED ROUTE
↓
ROUTE SELECTION
↓
FORWARD PATH
↓
SECURITY POLICY
↓
DESTINATION
↓
RETURN ROUTEDespite differences between providers, the general hybrid cloud architecture is surprisingly consistent.
Enterprise Network
|
Enterprise Router
|
BGP
|
Hybrid Connectivity
|
Cloud Routing Layer
|
Transit Layer
|
Cloud WorkloadsAWS may implement this through Transit Gateway, Direct Connect, VPN, and associated routing components.
Azure may use ExpressRoute, VPN Gateway, Virtual WAN, and Virtual Hub route tables.
Google Cloud may use Cloud Interconnect, Cloud VPN, Cloud Router, and Network Connectivity Center.
The products differ.
The networking fundamentals do not.
Now combine the three providers:
Enterprise Core
/ | \
AWS Azure GCP
| | |
BGP BGP BGPThe enterprise core effectively becomes a route exchange point between several cloud environments.
At this scale, engineers must decide whether the enterprise network should provide:
AWS ↔ Azure
Azure ↔ Google Cloud
Google Cloud ↔ AWStransit.
Another possibility is direct cloud-to-cloud connectivity.
Another is using a third-party global network or SD-WAN platform.
There is no single topology that fits every organization.
The correct design depends on:
BGP also helps explain the distinction between connectivity to a cloud and the provider’s internal backbone.
Consider:
Enterprise
|
BGP
|
Cloud Edge
|
Provider Backbone
|
Cloud RegionBGP may determine how enterprise routes enter the cloud environment.
Once traffic enters the provider’s infrastructure, internal cloud routing and backbone architecture determine how it reaches its final destination.
This distinction is central to understanding modern cloud networks.
Our Cloud Network Architecture guide examines those global backbone architectures in greater depth.
Before deploying BGP-based hybrid connectivity, document the following:
□ Cloud CIDR ranges
□ On-premises CIDR ranges
□ ASN assignments
□ Prefixes advertised to cloud
□ Prefixes accepted from cloud
□ Route filtering policy
□ Primary connectivity path
□ Backup connectivity path
□ Active/active or active/passive design
□ Default-route behavior
□ Route propagation rules
□ Transit route tables
□ Firewall inspection paths
□ Return-path behavior
□ BGP failure behavior
□ Overlapping CIDRs
□ Monitoring and alerting
□ Disaster recovery routingIf these questions cannot be answered before production deployment, the network design is not finished.
Yes. AWS uses BGP in several hybrid networking services, including Site-to-Site VPN and Direct Connect architectures. Transit Gateway can also receive propagated routes from supported attachments, while Transit Gateway Connect supports dynamic routing scenarios.
Yes. Azure supports BGP in hybrid networking services including VPN Gateway, ExpressRoute, and Virtual WAN architectures. Virtual WAN connections can dynamically propagate routes through hub route tables.
Yes. Google Cloud Router uses BGP for dynamic route exchange with supported hybrid connectivity resources and router appliances. Google documents BGP route exchange between Cloud Router and Router appliance instances.
No. Many simple cloud networks operate without customers configuring BGP directly. It becomes particularly important in hybrid, multicloud, dynamic-routing, and enterprise WAN architectures.
Not completely. Cloud architectures frequently combine dynamic and static routes. AWS Transit Gateway route tables, for example, support both propagated and static routes.
BGP path selection and multiple available connections can contribute to asymmetric paths. Whether this causes a problem depends on the architecture, particularly when stateful firewalls or other stateful devices are involved.
BGP is no longer a protocol relevant only to internet backbone engineers.
It has become a fundamental building block of hybrid cloud, multicloud, SD-WAN, and enterprise cloud networking.
The basic pattern is simple:
NETWORK A
|
Advertise Routes
|
BGP
|
Learn Routes
|
NETWORK BBut production environments add multiple layers:
BGP
↓
Route Propagation
↓
Transit Routing
↓
Route Selection
↓
Security Inspection
↓
Application Traffic
↓
Return RoutingAWS Transit Gateway, Azure Virtual WAN, and Google Network Connectivity Center all expose different implementations of these concepts.
Understanding BGP makes those products much easier to understand because the engineer stops seeing them as isolated cloud services and starts seeing the underlying routing architecture.
That is the key transition from basic cloud administration to professional cloud network engineering.
Continue with AWS Transit Gateway vs Azure Virtual WAN vs Google Network Connectivity Center for centralized transit architecture, Cloud Network Architecture: AWS vs Azure vs Google Cloud for the global architecture, and Linux Policy Routing with ip rule and Multiple Routing Tables for the Linux routing concepts behind many virtual routers and network appliances.
AI Agents as Code: Managing AI Agent Configurations, Prompts and Tools with Git AI agents…
Data Center Power Distribution Architecture: UPS, PDU, Redundancy and Rack Power Explained Data center power…
DNSSEC Troubleshooting: Fix SERVFAIL & DNSKEY Errors DNSSEC Troubleshooting: How to Fix SERVFAIL, DS, DNSKEY…
Terraform State Management Explained: Remote State, Locking, Backends and Best Practices Terraform makes infrastructure reproducible…
RTO vs RPO Explained: Disaster Recovery Objectives, Examples and Planning A disaster recovery plan is…
Network Intrusion Detection Explained: NIDS, Sensors, Signatures and Traffic Analysis A firewall can decide whether…