VPC and the Isolation Model

When you launch a VM in the cloud, it automatically lands inside some network. That network is the VPC. AWS, GCP, and Alibaba all call it VPC; only Azure uses a different name — VNet. The abstraction they refer to is the same — an isolated virtual network with a private IP space sitting on top of public cloud infrastructure.

Because the same abstraction wears different names, jumping between vendor docs makes it easy to lose your bearings. Routing, connectivity, and security come in later posts.

Why VPC Exists

Cloud is fundamentally a multi-tenant environment. Workloads from many customers run side by side on the same physical infrastructure. Without isolation, one customer’s traffic could be visible to another, and IP addresses would collide.

VPC solves this with SDN-based virtual networks. Each VPC has its own IP space and its own route table, and is isolated from other VPCs by default. From the user’s perspective, it’s like spinning up your own data center on top of the cloud.

This isolation comes from three elements combined — IP space, Subnet, and Tenancy.

IP Space (CIDR)

The first thing you decide when creating a VPC is the CIDR block. Specify a private IP range like 10.0.0.0/16 and the addresses inside that range will be allocated to resources within the VPC.

The recommendation is to stay inside the private ranges defined by RFC 1918 — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. These ranges are not routable on the public internet, so they don’t collide with external addresses, and other VPCs are free to use the same ranges.

The catch comes when you want to connect VPCs later. Two VPCs both on 10.0.0.0/16 will produce ambiguous routes when wired together via Peering or Transit Gateway. Carving up the private space at the organization level from day one is the safer move.

The prefix length is also hard to change after the fact, so picking a generous space with future growth in mind pays off.

What IP space contributes to isolation is straightforward: only resources inside the same VPC interpret the same IP space meaningfully, while other VPCs are separated at the IP level from the start.

Subnet

Once the VPC has its IP space, you split that space into smaller blocks. Those blocks are Subnets.

Subnets are typically created per Availability Zone (AZ). Resources in the same AZ go into one Subnet; resources in a different AZ go into a different Subnet. Since AZs are physically separate data center clusters, splitting by AZ is the foundation of availability — if one AZ fails, Subnets in other AZs are unaffected.

flowchart LR
    subgraph VPC ["VPC (10.0.0.0/16)"]
        subgraph AZ_a ["AZ-a"]
            S_a1["Public Subnet
10.0.1.0/24"]
            S_a2["Private Subnet
10.0.2.0/24"]
        end
        subgraph AZ_b ["AZ-b"]
            S_b1["Public Subnet
10.0.3.0/24"]
            S_b2["Private Subnet
10.0.4.0/24"]
        end
    end

From the isolation perspective, Subnets act less as a separation boundary themselves and more as the smallest unit at which policies apply. Routing rules and security rules attach at the Subnet level, and the Public Subnet vs. Private Subnet distinction emerges from those routing rules.

Tenancy

Even within the same VPC, whether a resource shares physical hardware with other customers is decided by the Tenancy option. Tenancy can be set as a VPC default or specified per instance.

The default is shared tenancy. Multiple customers’ VMs run together on the same physical host, which keeps cost low and is sufficient for typical workloads.

Choosing dedicated tenancy means resources in that VPC do not share physical hardware with anyone else. It’s typically used when compliance demands are strong — financial regulation, medical data, government workloads. Cost goes up and the available instance types are more limited.

Vendors name the option differently. AWS splits it into dedicated and host; GCP exposes a separate concept called sole-tenant nodes. The pattern is the same regardless of naming — pushing isolation further costs more.

Tenancy adds physical-hardware-level isolation on top of IP-level isolation, raising the strength of isolation by another step.

Vendor Naming Map

The core terms covered so far, mapped across vendors:

The names that stand out the most are Azure’s VNet and Alibaba’s VSwitch. The rest stay close to the same vocabulary. Build the mental model in one vendor and at least half of any other vendor’s docs will already feel familiar.

Compared to Pre-Cloud Isolation

The idea of an isolated private network predates the cloud. On-prem data centers split traffic with VLANs and used RFC 1918 private ranges; this pattern is decades old.

VPC reimplements that pattern on top of SDN. The dependency on physical-layer concepts like VLAN tags is gone, and abstractions like IP space / Subnet / Tenancy are now operable through APIs and code. Spinning up a new Subnet takes one API call rather than cable work. The substance of isolation is unchanged, but operational flexibility is on a different level.

Wrap-up

VPC isolation is the combination of three elements:

• IP space (CIDR): the private IP address space scoped to a VPC. Stay inside RFC 1918 ranges and pick a generous size with future connectivity in mind.
• Subnet: the block that splits the VPC per Availability Zone. AZ-level separation is the basis of availability, and the unit at which routing and security policies apply.
• Tenancy: whether physical hardware is shared. Shared is the default; dedicated is for stronger compliance demands.

Vendor names differ, but the abstraction is the same — VPC, VNet, and VSwitch are different labels on the same concept.

Isolation does not come from any single element alone. IP space handles address collisions, Subnet handles availability and policy attachment, Tenancy handles physical hardware. How far to push isolation is decided by what the workload demands.

The next article covers traffic flow inside a VPC — the routing structure that Route Tables, Internet Gateways, and NAT Gateways build together.