This article explores the differences in how the three major cloud providers design and operate network units, focusing on the configurations of subnets, VPCs, regions, and availability zones.

The Differences

Based on the information from this page, we can summarize the key differences as follows:

https://blog.ipspace.net/2021/02/vpc-subnets-aws-azure-gcp.html

AWS appears to be the strictest in its network design, which may be due to it being the earliest major cloud player.

Subsequent providers like Azure and GCP may have attempted to offer more flexibility based on AWS's design experience.

Two key points for further discussion:

1. How GCP implements VPCs that span regions

2. How Azure and GCP implement subnets that span Availability Zones (AZs)

Click the image links. due to own’s referrer-policy, go check the origin website to show the images.

https://blog.ipspace.net/2021/02/vpc-subnets-aws-azure-gcp.html

The Illusion of Boundary-less Networks

Have you ever wondered how an internal network can seemingly transcend physical limitations?

But here's the kicker: it's all an illusion, albeit a very clever one. While users might perceive VPCs as seamlessly spanning multiple regions, the underlying infrastructure still relies on physical network transmission and Software-Defined Networking (SDN) control. It's not actually transcending physical boundaries; it's just making you think it is.

It sounds convoluted, but is it just because you're not used to it?

Let's look at some examples you're more familiar with:

1. containerization: you think you've abstracted away the entire computing environment, free from the shackles of the host system. In reality, containers still depend on the underlying OS and hardware. It's just hidden from view.

2. serverless architectures: "No servers? Magic!" Not quite. The servers exist, but the cloud provider has simply whisked away the management tasks, leaving you with the illusion of server-less-ness.

GCP's Global VPC: Appearing to Ignore Physical Limitations

GCP is unique in allowing VPCs to span regions. This is achieved through several layers of abstraction and implementation:

Software-Defined Networking (SDN)

It's a tech that turns hardcoded network hardware into flexible software.

In the past, everything was hardcoded - functions, configs, you name it. Think routers, switches - all that stuff was set in stone.

SDN's job? Stop the hardcoding madness. It's all about abstracting away those physical dependencies wherever possible.

Andromeda

Andromeda is GCP's SDN layer. It implements SDN principles and exposes interfaces for use by the Global VPC. Key features include:

• Intelligent Routing: Beyond simple distance-based routing, it considers current load, network health, and performance metrics for routing decisions.

• Network Function Virtualization (NFV): Transforms traditional hardware network devices (like firewalls, NAT) into virtualized services.

Global VPC

Global VPC is the friendly face of this whole operation. It's what users interact with, handling things like subnets, routing tables, and security rules.

• Subnets

• Routing tables

• Network ACLs and Security Groups

How It All Fits Together

You can think of Global VPC as a shell or console, translating user commands into specific operations for Andromeda (the kernel). Global VPC acts as an intermediary, managing input and output.

Think about Dependency Inversion.

This layered approach follows the Dependency Inversion Principle (DIP) in software design.

Each layer can be both an abstraction for the layer above and a concrete implementation for the layer below.

Users → Global VPC → Andromeda → Physical Network

Andromeda serves as the abstraction provider for Global VPC and implements SDN concretely.

Global VPC acts as the abstraction provider for users and indirectly implements high-level SDN logic, relying on Andromeda for specific operations.

Let’s Pretend We Are a Request

User Request
→ Internet
→ GCP Edge Location (Point of Presence)
→ Google's Global Network
     |
     |-- Andromeda SDN Layer
     |      (Traffic management, routing decisions)

→ Target GCP Region
→ Specific Service/Resource
  (e.g., Load Balancer, VM, Cloud Run, etc.)

Curious how your data actually travels through this maze? Here's the quick tour:

• You hit 'Enter' on your keyboard. Your request goes through the internet.

• It reaches Google's front door (an edge location or Points of Presence).

• Now it's on Google's private superhighway.
  • Andromeda plays air traffic controller, guiding your data.
  • Your request arrives at its destination, maybe halfway around the world!

That's how GCP makes it look like your network is one big, happy family, even when it's spread across the globe!

To Simplify

1. Global VPC sets the traffic rules,

2. but Andromeda is the clever delivery guy who knows all the shortcuts.

Back to the Question

This is why in GCP's Global VPC, an IP address range can span multiple regions. For example, a single, globally unique IP might belong to a load balancer. Once traffic reaches the load balancer, it can be distributed to different regions based on proximity or other factors.

Subnets Spanning Availability Zones

Both Azure and GCP allow subnets to span Availability Zones within a region.

This is simpler to implement than cross-region VPCs situations because the physical infrastructure is closer together within a single region.

• Azure uses Azure Virtual Network technology, which employs SDN-like methods to manage cross-AZ networks.

• GCP's Andromeda platform handles not only cross-region communication but also manages network virtualization within regions (including across AZs).

By allowing subnets to span AZs, these providers offer more flexibility in resource allocation and failover scenarios, while still maintaining the performance and isolation benefits of separate AZs.

References

https://digitalcloud.training/a-brief-history-of-aws-and-how-computing-has-changed/

https://www.pluralsight.com/resources/blog/cloud/history-google-cloud-platform

https://techcommunity.microsoft.com/t5/educator-developer-blog/the-history-of-microsoft-azure/ba-p/3574204

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq#can-a-virtual-network-span-regions

https://cloud.google.com/about/locations#network

https://research.google/pubs/andromeda-performance-isolation-and-velocity-at-scale-in-cloud-network-virtualization/

https://cloud.google.com/blog/products/networking/google-cloud-networking-in-depth-how-andromeda-2-2-enables-high-throughput-vms