Cloud networking fundamentals

The sections below are the object model per provider. Hub placement and NAT bills sit on the hub-and-spoke guide.

The objects that actually exist

An Amazon VPC is a logically isolated virtual network in one AWS Region. Subnets are zonal. Route tables, internet gateways, NAT gateways, and VPC peering or Transit Gateway attachments are how packets leave. Security groups are stateful instance-level filters. Network ACLs are stateless subnet-level filters. AWS documents both.

An Azure virtual network is an isolated network in one Azure region, with address space you assign. Subnets are regional slices of that space (not AZ-scoped the way AWS subnets are). Network security groups filter at subnet or NIC. VNet peering and a hub VNet or Virtual WAN are the usual ways to share egress. CAF landing-zone diagrams put connectivity in a dedicated subscription for that reason.

A Google Cloud VPC is global. Subnets are regional and can span zones in that region. Implied firewall rules deny ingress and allow egress; you add rules on top. Shared VPC puts the network in a host project. VPC Network Peering connects VPCs without exchanging IAM. Google documents that last point explicitly: admins of one VPC do not become admins of the peer.

An Alibaba Cloud VPC is a private network in a region. vSwitches are zone-scoped. Route tables and security groups (or network ACLs, depending on product) control traffic. CEN or peering is how you connect VPCs. Do not assume AWS Transit Gateway behaviors apply.

Engineering recommendation: pick one CIDR plan per provider first. Overlapping RFC1918 blocks across an AWS VPC and an Azure VNet will break later VPN or interconnect work. That is a planning constraint, not a documented automatic conflict until you connect them.

Read a live network

AWS, Singapore:

aws ec2 describe-vpcs --region ap-southeast-1 \
  --query 'Vpcs[].{Id:VpcId,Cidr:CidrBlock,IsDefault:IsDefault}' \
  --output table
aws ec2 describe-nat-gateways --region ap-southeast-1 \
  --query 'NatGateways[].{Id:NatGatewayId,Vpc:VpcId,State:State,Subnet:SubnetId}' \
  --output table

IsDefault=True is the account-default VPC. Engineering recommendation: do not run production there. A NAT gateway State=available in one subnet is a zonal egress dependency and a common bill line. Interpret a missing NAT as either private-only (good if intended) or instances with public IPs (usually not).

Azure:

az network vnet list \
  --query "[].{name:name,rg:resourceGroup,location:location,cidrs:addressSpace.addressPrefixes}" \
  -o table

location is the VNet’s region. Two rows with overlapping cidrs in different regions are fine until you peer them.

Google Cloud:

gcloud compute networks list
gcloud compute networks subnets list --network=NETWORK

SUBNET_MODE AUTO means Google created subnets in many regions. That is convenient and a wide address-plan surprise. CUSTOM means you own the regional subnet list.

Alibaba Cloud console: VPC > VPCs, or DescribeVpcs in the region you care about. Confirm vSwitch zones match the ECS zones you launch.

Risks and limitations

Hub-and-spoke concentrates egress. That is a security and inspection choice. It also concentrates NAT and firewall cost. Provider price lists charge for NAT, data processing, and inter-AZ or inter-region bytes. I am not quoting rates; they change.

Peering is not transitive on the usual AWS and Azure constructs unless you add a hub. Google Cloud’s Network Connectivity Center is a different product with its own spoke model. Read the page for the product you enabled.

Private endpoints shift traffic off the internet and onto the provider backbone. They do not remove IAM. A private endpoint to an open bucket is still an open bucket.

Default-allow egress is common. Shared responsibility puts those rules on your side of the model.

For the usual production pattern, continue with Hub-and-spoke cloud networking.