Table of Contents
Understanding Cloud VPCs
A Virtual Private Cloud, usually shortened to VPC, is a logically isolated part of a public cloud where you can build your own private network. The key idea is that you get building blocks similar to an on‑premises network, such as IP ranges, subnets, routers, and firewalls, but they exist inside the provider’s infrastructure and are created through software.
Although each cloud provider has its own name and details, such as Amazon VPC, Azure Virtual Network, or Google VPC, they all follow the same core concept. You define a virtual network boundary, decide how addresses are allocated, and control which traffic is allowed in or out.
VPCs are central to cloud networking because almost every cloud resource that communicates over a network will live inside one.
Core Concepts of a VPC
A VPC is defined primarily by an IP address space and isolation.
You start by choosing an IP range for the VPC, usually with CIDR notation, for example $10.0.0.0/16$ or $192.168.0.0/16$. Inside that range, you create smaller subnets, such as $10.0.1.0/24$ and $10.0.2.0/24$, which group resources and allow you to separate parts of your design.
The isolation of a VPC is logical. Your traffic is kept separate from other customers’ traffic by the provider’s internal mechanisms, even though you all share the same physical infrastructure. From your point of view, your VPC behaves like your own private network.
Within a VPC you typically have these elements.
| Element | Role in the VPC |
|---|---|
| VPC CIDR range | Defines the main private IP space of the VPC |
| Subnets | Smaller segments of the VPC network, often mapped to availability zones |
| Route tables | Control how traffic moves between subnets and to the outside |
| Gateways | Provide access to the internet or to on‑premises networks |
| Security rules | Filter traffic at instance or subnet boundaries |
Although routing, IP addressing, and security are treated elsewhere in the course, here it is important to see that a VPC is the place where these decisions are applied in the cloud.
Public and Private Subnets in a VPC
A very important design pattern in VPCs is the separation between public and private subnets. Both types live inside the same VPC and use the same private address space, but they differ in how they connect to the outside world.
A public subnet is a subnet that has a route to the public internet through a special gateway resource provided by the cloud provider. Instances in a public subnet can usually receive inbound connections from the internet if security rules allow it. They often have public IP addresses associated with them so that external clients can reach them.
A private subnet is a subnet that does not allow direct inbound traffic from the internet. It typically has no direct route to the internet gateway, or only has access through a device that performs network address translation. Instances in a private subnet use private IP addresses only and can be used for application servers, databases, and internal services that should not be publicly reachable.
A typical layout places web servers in a public subnet, behind a public load balancer, and databases in a private subnet. The web servers talk to the databases using private addresses, and only the web servers are visible from the internet.
Route Tables inside a VPC
Routing inside a VPC is controlled by virtual route tables. Every subnet in the VPC is associated with one route table, which lists destinations and the next hop for each destination.
A route table normally includes a local route that allows communication within the VPC’s own CIDR range. This means that by default, subnets inside a VPC can talk to each other using private IP addresses, unless blocked by security controls.
You can then add more routes to the table. For example, you might add:
A route that sends all external traffic, such as destination $0.0.0.0/0$, to an internet gateway, which makes the subnet a public subnet.
A route that sends traffic for an on‑premises network range to a VPN gateway or private connection.
Different subnets can use different route tables, so you can create separate traffic patterns. For instance, private subnets can have a default route pointing to a NAT resource, while public subnets have a default route pointing directly to the internet gateway.
A subnet becomes effectively public if its route table sends external traffic, typically $0.0.0.0/0$, to an internet gateway and security rules permit access.
Internet Gateways and NAT in VPCs
To connect a VPC to the public internet, cloud providers use a special logical device called an internet gateway. It is attached to the VPC and handles the translation between private IP addresses in the VPC and public IP addresses that are visible on the internet.
Instances in a public subnet often get a public IP or can be associated with an external address object such as an Elastic IP in some providers. The route table for the subnet sends outbound traffic with internet destinations to the internet gateway, and return traffic from the internet comes back through the same gateway.
Private subnets usually use a different pattern. They rely on a NAT resource to initiate outbound connections to the internet, for example for software updates, without exposing themselves to inbound connections. The private subnet’s route table will send outbound internet traffic to the NAT device, which then forwards it to the internet gateway.
In many designs, the NAT resource lives in a public subnet so that it can talk both to the private subnet and the internet gateway.
Security Controls in a VPC
VPCs typically provide several layers of security controls that work together. These are software defined and are enforced by the cloud platform itself.
One common control is a per instance or per network interface rule set, often called a security group. Security groups usually act as stateful filters. You specify allowed inbound and outbound traffic based on protocol, port, and source or destination. If an inbound rule allows traffic, return traffic is automatically allowed.
Another control can exist at the subnet boundary, such as network access control lists. These are often stateless, which means that return traffic must be explicitly allowed by matching rules. They can be used to add an extra layer of filtering between subnets.
Because these tools are applied inside the VPC, you can design quite precise trust zones. For example, a public subnet might allow inbound connections only to ports used by a load balancer, while a private database subnet might only allow traffic from specific application subnets.
Connecting VPCs to On‑Premises Networks
In many organizations, a VPC does not stand alone. It must connect to an existing on‑premises network. Cloud providers offer several options for this, typically using VPN connections over the public internet or dedicated private links.
A VPN connection from your data center to your VPC uses encrypted tunnels. At the VPC side, a virtual VPN gateway terminates the tunnel. The VPC route tables then send traffic for on‑premises IP ranges to the VPN gateway, and the on‑premises router does the reverse.
For higher performance and more predictable latency, providers also support private connectivity. These services create a dedicated link from your network to the provider. From the VPC’s perspective, this appears as another gateway that can be used as a next hop for certain prefixes.
In both cases, once routing is set up correctly, clients in your office or data center can reach resources in the VPC using their private IP addresses, and VPC resources can reach back in the same way.
Peering and Multi‑VPC Architectures
As environments grow, it is common to have multiple VPCs instead of a single large one. Reasons include separation by department, environment such as development versus production, or even separation by application.
To allow traffic between these VPCs, providers offer VPC peering. Peering links connect two VPCs and let them exchange traffic using private addresses. Each VPC still keeps its own CIDR block and its own route tables. For peering to work, address ranges must not overlap, and each side must add routes pointing the other VPC’s network to the peering connection.
VPC peering is usually non transitive. This means that if VPC A peers with VPC B, and B peers with C, traffic from A cannot automatically reach C through B. Larger designs often use central hub VPCs, sometimes called transit VPCs or virtual hubs, and connect other VPCs to this central point. The hub VPC contains shared services, such as firewalls, VPN gateways, or inspection devices.
High Availability and Zones in VPCs
Cloud providers distribute their infrastructure across multiple physical locations called availability zones inside a region. VPCs are regional resources, so a single VPC spans all zones in that region. Subnets, however, are usually bound to a specific zone.
You design high availability in a VPC by creating subnets in multiple zones and placing resources in each subnet. For example, you can have a public subnet in zone A and another public subnet in zone B, then run instances or load balancers in both. If one zone has a problem, the resources in the other zone can continue to serve traffic.
Because all these subnets are part of the same VPC, they share the same CIDR space and internal routing. This makes it easier to design redundant architectures that continue to work even if one zone becomes unavailable.
Cost and Operational Considerations
Every networking choice inside a VPC can affect cost and operations. Traffic that crosses certain boundaries such as between zones, between regions, or across VPC peering links can incur data transfer charges. Centralizing shared services, such as logging or inspection, in a hub VPC can simplify management but may increase cross‑VPC traffic.
Automation is also important. VPCs, subnets, route tables, and security rules are all defined using the provider’s APIs. Infrastructure as code tools can describe an entire VPC layout in a template. This makes it easier to reproduce environments, such as development, testing, and production, using the same structure.
VPCs form the foundation for almost all other cloud networking topics. Once you understand how to shape address spaces, subnets, routes, and gateways inside a VPC, it becomes much easier to reason about more advanced cloud architectures that build on top of this model.