BGP in Cloud Networking: AWS, Azure and Google Cloud Hybrid Routing Explained

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
        |
   Application

BGP 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:

• Which routes are advertised?
• Which routes are learned?
• Where are those routes installed?
• How are multiple paths selected?
• What happens during link failure?
• How do AWS, Azure, and Google Cloud handle route propagation?
• How can BGP create asymmetric routing?
• What happens when cloud and on-premises CIDR ranges overlap?

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.

What Is BGP?

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 C

routers can dynamically exchange information about the networks they know.

A simplified BGP relationship looks like:

Router A
ASN 65001
   |
   | BGP
   |
Router B
ASN 65002

Router A can advertise:

10.10.0.0/16
10.20.0.0/16

while Router B advertises:

172.16.0.0/16

Each 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.

Why BGP Matters in Cloud Networking

Imagine a company with an on-premises network:

10.10.0.0/16

and cloud workloads:

10.50.0.0/16

With static routing, administrators might manually configure:

On-Prem:
10.50.0.0/16 → VPN

Cloud:
10.10.0.0/16 → VPN

That is manageable with two networks.

Now imagine:

30 VPCs
12 Azure VNets
8 Google Cloud VPCs
4 data centers
60 branch offices

Manually maintaining every route becomes much harder.

BGP changes the model to:

Network
   |
Advertise Prefixes
   |
   BGP
   |
Learn Remote Prefixes
   |
Routing Table

When properly designed, new routes can propagate through the architecture without manually adding every destination to every router.

BGP Is Not the Data Plane

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 A

The 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:

• firewall rules
• missing return routes
• security groups
• network ACLs
• NAT
• MTU problems
• asymmetric routing
• incorrect route preference

Never treat an established BGP session as proof that end-to-end connectivity works.

ASN: Autonomous System Numbers

BGP identifies routing domains using Autonomous System Numbers, or ASNs.

A simplified hybrid architecture might be:

Enterprise Router
ASN 65010
      |
      | BGP
      |
Cloud Router
ASN 64520

Private 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 65020

The AS path helps describe which autonomous systems a route has traversed.

In traditional BGP, this information contributes to loop prevention and path selection.

AWS BGP Architecture

AWS uses BGP in several hybrid connectivity scenarios, particularly with:

• AWS Site-to-Site VPN
• AWS Direct Connect
• Transit Gateway connectivity
• Direct Connect Gateway
• Transit Gateway Connect

A typical architecture might look like:

Corporate Network
      |
Customer Router
      |
      | BGP
      |
AWS Connectivity
      |
Transit Gateway
      |
      VPC

When 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 Router

This 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

AWS Transit Gateway Route Propagation

Suppose the enterprise advertises:

10.100.0.0/16

toward AWS.

Conceptually:

On-Prem Router
10.100.0.0/16
       |
      BGP
       |
VPN / Direct Connect
       |
Transit Gateway

The 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 Attachment

while a development routing domain could intentionally omit that route.

This provides much better control than blindly distributing every enterprise route everywhere.

AWS Transit Gateway: Association vs Propagation

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 A

while:

VPN Attachment
      |
 Propagates Routes
      |
Route Table A

AWS 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.

Azure BGP Architecture

Microsoft Azure uses BGP extensively in hybrid connectivity.

Common examples include:

• Azure VPN Gateway
• ExpressRoute
• Azure Virtual WAN
• Network Virtual Appliances
• Virtual WAN BGP connections

A simplified architecture is:

On-Premises Router
       |
      BGP
       |
ExpressRoute / VPN
       |
Azure Virtual Hub
       |
      VNet

With 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

Azure Virtual WAN Route Tables

Each Virtual WAN hub has routing tables.

A basic model is:

Spoke VNet
    |
Virtual Hub
    |
Route Table
    |
Destination

Azure 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 Services

does not necessarily imply:

Development → Production

Routing policy should reflect security and segmentation requirements.

Static Routes vs Dynamically Learned Routes in Azure

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/16

being 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 Network

But it also means engineers must understand both dynamic and static routing when troubleshooting unexpected paths.

Google Cloud BGP Architecture

Google Cloud uses Cloud Router as a major component of dynamic hybrid routing.

Cloud Router works with technologies such as:

• Cloud VPN
• Cloud Interconnect
• Network Connectivity Center
• Router appliance

A simplified architecture looks like:

On-Premises Router
       |
      BGP
       |
Cloud Interconnect / VPN
       |
Cloud Router
       |
Google Cloud VPC

Cloud 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 path

They work together but perform different functions.

Google Network Connectivity Center and BGP

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 Networks

Google’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

Google Cloud Router and Router Appliances

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 VPC

Google 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.

Regional vs Global Dynamic Routing in Google Cloud

Google Cloud introduces an important design decision:

regional dynamic routing vs global dynamic routing.

Consider VPC resources in:

Europe
United States
Asia

If 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.

AWS vs Azure vs Google Cloud BGP Architecture

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.

BGP and Hybrid Cloud Routing

Now consider a practical hybrid architecture.

             AWS
              |
         Transit Gateway
              |
              |
Corporate ----+---- Azure
Network       |    Virtual WAN
              |
              |
          Google Cloud
              NCC

The corporate network might advertise:

10.0.0.0/8

while the clouds advertise:

AWS
10.50.0.0/16

Azure
10.60.0.0/16

Google Cloud
10.70.0.0/16

The 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.

Route Leaking Between Clouds

Imagine:

AWS → On-Prem → Azure

AWS advertises:

10.50.0.0/16

to 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
  ↓
AWS

This can be useful.

It can also be completely unintended.

Therefore, cloud BGP architectures need explicit route advertisement policies.

Do not simply redistribute everything everywhere.

Route Filtering

A good BGP architecture controls which prefixes are exchanged.

Suppose the enterprise owns:

10.0.0.0/8

but only wants AWS to reach:

10.20.0.0/16
10.30.0.0/16

Advertising 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/8

unless 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.

BGP Does Not Replace Firewalls

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 Connection

The route only provides reachability.

Security still depends on controls such as:

Cloud Firewall
Security Group
Network ACL
NVA
Host Firewall
Application Policy

A 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.

BGP and Asymmetric Routing

One of the most important cloud networking problems is asymmetric routing.

Consider two cloud connections:

         Link A
        /
Router
        \
         Link B

Traffic leaves through Link A:

Client
  ↓
Link A
  ↓
Cloud

but returns through Link B:

Cloud
  ↓
Link B
  ↓
Client

Pure 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.

BGP and Multiple Default Routes

Cloud-connected Linux routers may also have multiple upstream paths.

For example:

Linux Router
   |
   +---- ISP
   |
   +---- Cloud VPN
   |
   +---- MPLS

A 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.

BGP Failover in Hybrid Cloud

One major advantage of dynamic routing is automated failure response.

Consider two connections:

             Connection A
            /
Data Center
            \
             Connection B

The 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 B

This 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.

Active/Active vs Active/Passive Cloud Connectivity

Hybrid architectures commonly use either active/active or active/passive connectivity.

Active/Passive

Primary Connection
      |
   ACTIVE

Backup Connection
      |
   STANDBY

The backup path is used mainly after failure.

Active/Active

Connection A
     +
Connection B
     |
Both Carry Traffic

Active/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.

BGP Route Preference

Suppose two paths advertise:

10.50.0.0/16

The routing system must choose between them.

BGP can use several attributes and provider-specific routing rules to influence that decision.

Traditional BGP concepts include:

• AS_PATH
• LOCAL_PREF
• MED
• communities
• prefix specificity

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.

Longest Prefix Match Still Matters

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 B

Traffic to:

10.50.10.20

matches both routes.

But:

10.50.0.0/16

is more specific.

Therefore Path B is used.

This principle becomes extremely important when cloud environments advertise aggregate routes alongside more specific prefixes.

Overlapping CIDR Blocks: A Major Hybrid Cloud Problem

One of the hardest problems in multicloud networking is overlapping address space.

Imagine:

AWS:
10.20.0.0/16

Azure:
10.20.0.0/16

Now an enterprise router receives traffic for:

10.20.5.10

Which cloud contains the destination?

The IP address alone cannot answer the question.

Possible solutions include:

• renumbering
• NAT
• proxy architectures
• isolated routing domains
• VRFs
• network appliances

But every workaround increases complexity.

A good multicloud strategy should therefore establish an IP addressing plan before large numbers of networks are deployed.

BGP Route Advertisement Design

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 paths

For example:

AWS

Advertise:
10.50.0.0/16

Accept:
10.10.0.0/16
10.20.0.0/16

Reject:
Everything else

Azure:

Advertise:
10.60.0.0/16

Accept:
10.10.0.0/16
10.20.0.0/16

Google Cloud:

Advertise:
10.70.0.0/16

Accept:
10.10.0.0/16
10.20.0.0/16

This makes route behavior much easier to audit.

BGP Security Considerations

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:

• explicit prefix policies
• ASN planning
• route limits
• segmentation
• logging
• configuration change control
• monitoring BGP state
• redundant connectivity
• firewall enforcement

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.

Monitoring Cloud BGP

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 withdrawals

For example, a BGP session dropping from:

ESTABLISHED

to:

IDLE

may 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.

Troubleshooting Hybrid Cloud BGP

When connectivity fails, troubleshoot in layers.

Do not immediately modify the firewall.

Start with the BGP session.

Step 1: Is the BGP session established?

Router A
   |
 BGP?
   |
Router B

If not, check:

• peer IP
• ASN
• underlying tunnel/connectivity
• TCP connectivity
• configuration
• authentication if applicable

Step 2: Is the prefix being advertised?

For example:

10.50.0.0/16

Step 3: Is the remote side receiving it?

Advertising a prefix does not prove that the peer accepted it.

Step 4: Is it installed in the effective routing table?

A learned route can lose to another route.

Step 5: What is the next hop?

Follow the actual path.

Step 6: Is the return route present?

This is one of the most commonly overlooked checks.

Step 7: Are security controls allowing the traffic?

Only after validating routing should you focus on:

firewalls
security groups
ACLs
host firewalls

The workflow is:

BGP SESSION
     ↓
ADVERTISEMENT
     ↓
RECEIVED ROUTE
     ↓
ROUTE SELECTION
     ↓
FORWARD PATH
     ↓
SECURITY POLICY
     ↓
DESTINATION
     ↓
RETURN ROUTE

AWS, Azure and Google Cloud: The Common BGP Pattern

Despite differences between providers, the general hybrid cloud architecture is surprisingly consistent.

Enterprise Network
       |
Enterprise Router
       |
      BGP
       |
Hybrid Connectivity
       |
Cloud Routing Layer
       |
Transit Layer
       |
Cloud Workloads

AWS 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.

How BGP Fits Into Multicloud Networking

Now combine the three providers:

              Enterprise Core
             /       |       \
           AWS     Azure     GCP
            |         |       |
           BGP       BGP     BGP

The 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 ↔ AWS

transit.

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:

• latency
• bandwidth
• security
• resilience
• cost
• regulatory requirements
• operational complexity

BGP and Cloud Backbone Networks

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 Region

BGP 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.

BGP Design Checklist for Hybrid Cloud

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 routing

If these questions cannot be answered before production deployment, the network design is not finished.

Frequently Asked Questions

Does AWS use BGP?

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.

Does Azure use BGP?

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.

Does Google Cloud use BGP?

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.

Is BGP required for cloud networking?

No. Many simple cloud networks operate without customers configuring BGP directly. It becomes particularly important in hybrid, multicloud, dynamic-routing, and enterprise WAN architectures.

Does BGP replace static routes?

Not completely. Cloud architectures frequently combine dynamic and static routes. AWS Transit Gateway route tables, for example, support both propagated and static routes.

Can BGP cause asymmetric routing?

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.

Final Thoughts

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 B

But production environments add multiple layers:

BGP
 ↓
Route Propagation
 ↓
Transit Routing
 ↓
Route Selection
 ↓
Security Inspection
 ↓
Application Traffic
 ↓
Return Routing

AWS 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.