BGP and Multi-Cloud Routing

That model no longer reflects how many organizations actually operate.
Today, workloads often live across AWS, Azure, and Google Cloud at the same time. Sometimes this is intentional. Sometimes it is the result of acquisitions, separate engineering teams, SaaS dependencies, regional requirements, or SaaS platforms that depend on a specific cloud provider. Either way, the network has to make these environments behave like one reliable system.
That is where the hard part begins.

Cloud-native routing tools are useful inside each provider, but they do not automatically solve routing between providers, between clouds and colocation hubs, or between multiple cloud environments and an enterprise WAN. Once routing needs to become dynamic, policy-driven, and resilient across administrative boundaries, BGP becomes the common language.

BGP is not new, and it is not always simple. But in multi-cloud networking, it remains one of the few mechanisms that AWS, Azure, Google Cloud, carriers, colocation providers, SD-WAN platforms, and enterprise routers can all understand.

What inter-cloud routing actually means

The term “inter-cloud routing” is often used loosely, so it is worth defining the main scenarios.

Cloud-to-cloud routing refers to direct or indirect traffic flows between different cloud providers. For example, an application tier in AWS might need to communicate with a database, analytics platform, or identity service hosted in Azure or Google Cloud. This is often the most complex design because no single provider has native visibility or authority over the whole path.

Hybrid cloud routing describes connectivity between on-premises environments and one or more cloud providers. This is where many enterprises first introduced BGP into their cloud network designs, especially through services such as AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, and IPsec VPN.

Multi-region routing inside one cloud provider is a different problem. AWS Transit Gateway, Azure Virtual WAN, Google Cloud Router, and Google Cloud Network Connectivity Center all provide tools for managing routing within their own ecosystems. BGP may still be involved, but the operational model is usually simpler because the environment sits inside one provider’s control plane.

BGP becomes most important at the boundaries: between providers, between cloud and on-premises, or between a cloud environment and a colocation or transit fabric. These are the places where there is no single routing authority and where routing policy needs to be expressed in a protocol that all sides can support.

Why BGP, and why static routing is not enough

Static routes can work in a small lab or a simple single-cloud deployment. They become fragile once the environment grows.

Every new VPC, VNet, subnet, VPN, interconnect, or regional deployment adds another place where someone may need to update a route table manually. Over time, that becomes less of a routing design and more of an operational risk.

BGP solves a different problem. It allows networks to exchange reachability information dynamically and apply policy to those routes. Operators can prefer one path over another, withdraw routes when a link fails, and use attributes such as local preference, AS path, and MED where the platform supports them.

In multi-cloud environments, this matters because there is no single control plane. AWS does not control Azure routing. Azure does not control Google Cloud routing. Your colocation routers, cloud routers, SD-WAN fabric, and provider interconnects all need a consistent way to exchange routing information.

BGP is not perfect, but it is still the most widely supported mechanism for doing that at scale.

A common multi-cloud BGP architecture

A typical enterprise architecture uses a colocation facility, cloud exchange, or network hub as the routing midpoint between cloud providers and on-premises networks.

In this design, the enterprise router or virtual network appliance establishes BGP sessions with each provider:

The cloud providers do not directly control each other’s routing decisions. The enterprise hub becomes the policy point where routes are accepted, filtered, preferred, suppressed, or re-advertised.

That policy point is critical. Without it, a multi-cloud design can easily become an accidental transit network where one cloud learns routes from another cloud in ways the operator did not intend.

Architecture pattern 1: AWS and Azure through dedicated connectivity

One common enterprise pattern is to connect AWS and Azure through dedicated connectivity that terminates at the same colocation facility.

On the AWS side, this may involve AWS Direct Connect. On the Azure side, it may involve Azure ExpressRoute. A physical or virtual router in the colocation facility establishes BGP sessions with both providers and applies routing policy between them.

A simplified Cisco IOS-style configuration might look like this:

! ===========================================================
! Colo Router — eBGP to AWS and Azure
! ===========================================================

router bgp 65000
 bgp router-id 203.0.113.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast

 ! AWS Direct Connect Amazon-side ASN depends on the design.
 ! Public VIFs commonly use Amazon ASN 7224.
 ! Direct Connect Gateway uses a private Amazon-side ASN,
 ! defaulting to 64512 unless customized.
 neighbor 169.254.10.2 remote-as 
 neighbor 169.254.10.2 description AWS-DX-Primary
 neighbor 169.254.10.2 password 7 
 neighbor 169.254.10.2 timers 10 30

 ! Azure ExpressRoute private peering uses Microsoft ASN 12076.
 neighbor 192.168.100.2 remote-as 12076
 neighbor 192.168.100.2 description Azure-ER-Primary
 neighbor 192.168.100.2 password 7 
 neighbor 192.168.100.2 timers 10 30

 address-family ipv4
  neighbor 169.254.10.2 activate
  neighbor 169.254.10.2 route-map RM-FROM-AWS in
  neighbor 169.254.10.2 route-map RM-TO-AWS out
  neighbor 169.254.10.2 prefix-list PL-AWS-IN in

  neighbor 192.168.100.2 activate
  neighbor 192.168.100.2 route-map RM-FROM-AZURE in
  neighbor 192.168.100.2 route-map RM-TO-AZURE out
  neighbor 192.168.100.2 prefix-list PL-AZURE-IN in
 exit-address-family

There are two important details here.

First, the AWS-side ASN should not be hardcoded blindly. AWS documentation distinguishes between public virtual interfaces, where Amazon ASN 7224 is commonly used, and Direct Connect Gateway designs, where the Amazon-side ASN defaults to 64512 unless customized.

Second, Azure ExpressRoute private peering uses Microsoft ASN 12076. Microsoft documents AS 12076 for Azure public, private, and Microsoft peering.

This architecture offers strong operational control, predictable bandwidth, and private connectivity. The tradeoff is cost and complexity: colocation presence, cross-connects, port fees, router capacity, redundancy planning, and cloud-provider-specific behavior all need to be managed carefully.

Architecture Pattern 2: transit gateway Hub-and-Spoke

For AWS-centered environments, AWS Transit Gateway is often used as the routing hub for multiple VPCs, VPNs, and Direct Connect-based attachments.

In this model, AWS Transit Gateway handles the internal AWS hub-and-spoke design, while BGP sessions extend outward through VPN attachments, Direct Connect Gateway, or a colocation router.

A Terraform-style example for a BGP-enabled VPN attachment might look like this:

resource "aws_ec2_transit_gateway" "main" {
  description                     = "Multi-cloud hub"
  amazon_side_asn                 = 64512
  auto_accept_shared_attachments  = "disable"
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"

  tags = {
    Name = "tgw-multicloud-hub"
  }
}

resource "aws_customer_gateway" "colo" {
  bgp_asn    = 65000
  ip_address = "203.0.113.1"
  type       = "ipsec.1"

  tags = {
    Name = "cgw-colo-primary"
  }
}

resource "aws_vpn_connection" "colo_to_tgw" {
  transit_gateway_id  = aws_ec2_transit_gateway.main.id
  customer_gateway_id = aws_customer_gateway.colo.id
  type                = "ipsec.1"
  static_routes_only  = false

  tunnel1_inside_cidr = "169.254.10.0/30"
  tunnel2_inside_cidr = "169.254.11.0/30"

  tags = {
    Name = "vpn-colo-bgp"
  }
}

This model works well when AWS is the primary aggregation point. However, operators should be careful with assumptions around ECMP and path selection. AWS Transit Gateway supports ECMP in specific cases, but the behavior depends on attachment type and route characteristics. In particular, ECMP should not be assumed across fundamentally different attachment types or different AS paths without validating the exact design.

Traffic engineering with BGP attributes

In practice, one of the most common requirements is simple path preference.

For example:

• Prefer the dedicated circuit for production traffic.
• Use IPsec VPN as backup.
• Avoid sending one cloud provider’s routes into another cloud unless explicitly allowed.
• Make failover automatic, but not unpredictable.

A common approach is to use local preference inside the enterprise AS and AS path prepending toward external peers.

! ===========================================================
! Inbound policy: prefer dedicated connectivity over VPN backup
! LOCAL_PREF 200 = preferred
! LOCAL_PREF 100 = backup
! ===========================================================

ip prefix-list PL-AWS-IN seq 10 permit 10.1.0.0/16 le 24
ip prefix-list PL-AWS-IN seq 20 permit 10.2.0.0/16 le 24
ip prefix-list PL-AWS-IN seq 100 deny 0.0.0.0/0 le 32

ip prefix-list PL-AZURE-IN seq 10 permit 10.10.0.0/16 le 24
ip prefix-list PL-AZURE-IN seq 20 permit 10.11.0.0/16 le 24
ip prefix-list PL-AZURE-IN seq 100 deny 0.0.0.0/0 le 32

route-map RM-FROM-AWS permit 10
 match ip address prefix-list PL-AWS-IN
 set local-preference 200
 set community 65000:200 additive

route-map RM-FROM-AWS-BACKUP permit 10
 match ip address prefix-list PL-AWS-IN
 set local-preference 100
 set community 65000:100 additive

route-map RM-TO-AZURE permit 10
 match ip address prefix-list PL-ONPREM-PREFIXES
 set metric 100

route-map RM-TO-AZURE-BACKUP permit 10
 match ip address prefix-list PL-ONPREM-PREFIXES
 set as-path prepend 65000 65000 65000

Local preference is usually the cleanest way to influence outbound path selection inside your own AS. AS path prepending is commonly used to influence how external networks choose paths back toward you.

MED can be useful, but it is provider- and topology-dependent. Google Cloud Router uses advertised priority as MED, and Google documents how advertised MED is calculated for same-region and cross-region routes.

With Azure ExpressRoute, operators should avoid assuming that MED behaves like it would in a simple router-to-router lab. Microsoft documents ExpressRoute routing behavior, private peering limits, and path considerations, and also notes that forward and return paths can differ. Validate the exact circuit behavior before relying on MED as the primary traffic-engineering mechanism.

GCP cloud router and BGP

Google Cloud Router dynamically exchanges routes between a VPC network and a peer network using BGP. It is commonly used with Cloud VPN, Dedicated Interconnect, and Partner Interconnect.

A simplified gcloud example might look like this:

gcloud compute routers create multicloud-router \
  --network=prod-vpc \
  --region=us-east1 \
  --asn=64514 \
  --advertisement-mode=CUSTOM \
  --set-advertisement-ranges=10.20.0.0/16,10.21.0.0/16

gcloud compute routers add-bgp-peer multicloud-router \
  --peer-name=colo-peer-tunnel1 \
  --interface=vpn-tunnel1-if \
  --peer-ip-address=169.254.20.1 \
  --peer-asn=65000 \
  --region=us-east1

gcloud compute routers get-status multicloud-router \
  --region=us-east1 \
  --format="json(result.bgpPeerStatus)"

Google’s Cloud Router limits are quota-based and can vary by project, region, VPC, and route type. Google’s documentation distinguishes between quotas, which may be adjustable, and system limits, which are fixed. For a production design, operators should check the current Cloud Router quotas instead of relying on a static number in an article.

BGP path selection in a multi-cloud context

The standard BGP decision process still matters, but cloud platforms do not expose every knob equally.

A simplified decision model looks like this:

1. WEIGHT
Cisco-local, highest value wins, not propagated.

2. LOCAL_PREF
Highest value wins inside the local AS.
Useful for choosing preferred outbound paths.

3. AS_PATH length
Shorter path usually wins.
AS path prepending can make backup paths less attractive.

4. ORIGIN code
IGP is preferred over EGP, which is preferred over incomplete.

5. MED
Lower value is preferred, but behavior can be provider- and topology-dependent.

6. eBGP over iBGP
External BGP routes are usually preferred over internal BGP routes.

7. Tie-breakers
Router ID, neighbor IP, and platform-specific logic may apply.

The important point is not just the order of the decision process. The important point is knowing which attributes you control, which attributes the cloud provider honors, and which attributes are only meaningful in a specific context.

For example, AWS Direct Connect supports BGP communities in specific routing contexts, especially around public virtual interfaces and route propagation scope.

Azure supports BGP community values for ExpressRoute-related routing visibility and policy use cases, including custom BGP community values on virtual networks. However, Microsoft’s documented behavior should be followed carefully, and operators should not assume that every community sent to Microsoft will be honored as a routing instruction.

Google Cloud Router uses BGP route advertisements and advertised priorities, but final path behavior can still depend on the peer router and other BGP attributes.

Key challenges enterprises face

The architecture diagram is usually the easy part. The operational edge cases are where multi-cloud BGP becomes difficult.

Route Asymmetry

Traffic from AWS to Azure may take one path, while return traffic from Azure to AWS takes another. This can happen because each provider, router, firewall, and transit fabric applies its own routing logic.

Asymmetry is not always bad, but it becomes a problem when stateful firewalls, load balancers, inspection devices, or compliance tools expect both directions of a flow to pass through the same point.

Limited Visibility

Each provider exposes only part of the routing picture. AWS, Azure, and Google Cloud all have their own route tables, APIs, logs, and diagnostic tools.

Troubleshooting a multi-cloud routing issue often means correlating data from several places:

• Cloud route tables
• BGP session status
• Provider logs
• Router RIB and FIB output
• Firewall session tables
• Flow logs
• Synthetic probes
• Application telemetry

Without centralized observability, engineers end up reconstructing incidents manually.

Policy Inconsistency

A policy that sounds simple in a design meeting can become messy in implementation.

“All production traffic should prefer the dedicated path” may translate into different configurations across AWS, Azure, Google Cloud, the colocation router, the SD-WAN edge, and the firewall cluster.

The more providers are added, the more important it becomes to define intent clearly and automate the resulting policy.

Provider-Specific Limits

Every cloud provider has limits, and those limits change over time.
For example, AWS Direct Connect documents specific BGP quotas, including route limits for private and transit virtual interfaces and BFD constraints.

Azure ExpressRoute documents private peering limits, including 4,000 IPv4 prefixes and 100 IPv6 prefixes for private peering, with higher IPv4 limits available in some ExpressRoute Premium scenarios.

Google Cloud Router documents quotas and limits separately, with quota behavior depending on region, VPC, and learned-route scenarios.

A good design should cite current provider limits and treat them as design inputs, not permanent facts.

Failover and Redundancy

Redundancy is not just about having two links. It is about knowing exactly what happens when the primary path fails.

A common design is to keep both the primary circuit and the backup VPN path active, while making the dedicated circuit more attractive through routing policy. If the primary route disappears, BGP can select the backup path without waiting for an engineer to intervene.

BFD can improve this further by detecting forwarding-path failure faster than standard BGP timers. On AWS Direct Connect, AWS documents a minimum BFD interval of 300 ms and a minimum multiplier of 3. That means failure detection can happen in roughly 900 ms before the rest of the routing convergence process begins.

A simplified Cisco-style example:

interface GigabitEthernet0/0/0
 description AWS-Direct-Connect-Primary
 ip address 169.254.10.1 255.255.255.252
 bfd interval 300 min_rx 300 multiplier 3

router bgp 65000
 neighbor 169.254.10.2 fall-over bfd

 neighbor 169.254.30.2 remote-as 
 neighbor 169.254.30.2 description AWS-VPN-Backup
 neighbor 169.254.30.2 route-map RM-FROM-AWS-BACKUP in

The important distinction is between failure detection and full service recovery.

BFD may detect a failure quickly, but the total recovery time also depends on the router platform, routing policy, forwarding table updates, firewall behavior, application retry logic, and whether the backup path has sufficient capacity.

Security considerations

Multi-cloud BGP security is mostly about discipline. The protocol will advertise what you tell it to advertise, even when that is not what you meant.

The safest default is a whitelist-only export policy. Advertise only the prefixes that are explicitly approved for that peer, and deny everything else.

! Whitelist-only outbound policy

ip prefix-list PL-ADVERTISE-TO-AWS seq 10 permit 192.168.0.0/16
ip prefix-list PL-ADVERTISE-TO-AWS seq 20 permit 172.16.0.0/12
ip prefix-list PL-ADVERTISE-TO-AWS seq 100 deny 0.0.0.0/0 le 32

! Prevent Azure prefixes from being re-advertised to AWS.

ip prefix-list PL-NO-AZURE-TO-AWS seq 10 deny 10.10.0.0/16 le 32
ip prefix-list PL-NO-AZURE-TO-AWS seq 20 deny 10.11.0.0/16 le 32
ip prefix-list PL-NO-AZURE-TO-AWS seq 100 permit 0.0.0.0/0 le 32

route-map RM-TO-AWS permit 10
 match ip address prefix-list PL-ADVERTISE-TO-AWS PL-NO-AZURE-TO-AWS

neighbor 169.254.10.2 maximum-prefix 200 80 restart 5

This is especially important at colocation hubs or route-reflector points where AWS, Azure, Google Cloud, and on-premises routes may all be visible to the same routing system.

Avoid treating the hub router as a neutral pass-through device. Without strict per-neighbor import and export policies, it can become an accidental transit point between clouds. That can create route leaks, asymmetric traffic, and troubleshooting problems that are difficult to see until traffic is already flowing the wrong way.

RPKI also deserves context. For public internet-facing BGP sessions, Route Origin Validation can help protect against certain prefix hijacking scenarios. For private RFC 1918 routes exchanged over private cloud interconnects, RPKI does not apply in the same way. In those cases, strict prefix filtering, max-prefix controls, clear route ownership, and change management matter more.

Best practices for multi-cloud BGP

Document the intended policy before implementation

Before configuring BGP, write down what should happen.

Which prefixes should be advertised? Which should never be advertised? Which path is primary? Which path is the backup? What should happen during a cloud-region incident? What traffic is allowed to cross between clouds?

Many failures happen because the intended routing policy exists only in someone’s head.

Use private ASNs consistently

Avoid reusing the same ASN in multiple places unless the design explicitly requires it. ASN conflicts can create subtle routing problems, especially when routes cross cloud, colocation, and on-premises boundaries.

Use whitelist-only route advertisements

Do not rely on implicit defaults. Every BGP neighbor should have an explicit import and export policy.

Apply max-prefix limits

A misconfigured peer advertising too many routes can destabilize the routing plane. Max-prefix limits are a simple protection against accidental full-table leaks or unexpected route floods.

Validate cloud-provider limits before deployment

Do not design from memory. Check current provider documentation for route limits, BGP behavior, ASN requirements, and supported attributes before implementation. AWS, Microsoft, and Google Cloud all update these limits over time.

Centralize routing observability

BGP session changes, route withdrawals, prefix-limit warnings, policy matches, and failover events should be visible in a central monitoring system.

If troubleshooting requires logging into five routers and three cloud consoles during an outage, the observability design is not mature enough.

Test failover during scheduled windows

Backup paths should be tested before they are needed. A route that appears valid in a control-plane table may still fail because of firewall policy, NAT behavior, MTU issues, asymmetric return paths, or insufficient bandwidth.

Multi-cloud networking is not just a connectivity problem. It is a routing-policy problem.

Native cloud tools are improving, and services such as AWS Transit Gateway, Azure Virtual WAN, Google Cloud Router, and Network Connectivity Center reduce a lot of operational burden within each provider. But the moment traffic crosses provider boundaries, the design still needs a common routing language and a clear policy model.

BGP remains the practical choice because it is supported across cloud providers, carriers, colocation fabrics, SD-WAN platforms, and enterprise routers.

The challenge is not simply enabling BGP sessions. The real work is defining what should be advertised, which paths should be preferred, how failover should behave, and how operators will detect when reality no longer matches the intended design.

Enterprises that succeed with multi-cloud routing are not the ones that avoid BGP complexity. They are the ones that document it, automate it, monitor it, and test it before an outage forces them to learn how it behaves.