Cloud Networking and VPCs

Migrating to the cloud doesn't mean surrendering control of your network; it means gaining the ability to define and program it with unprecedented flexibility. The Virtual Private Cloud (VPC) is the cornerstone of this control, providing a logically isolated section of a public cloud where you can launch resources in a virtual network you define. Mastering VPCs—their components, connectivity, and security—is essential for building scalable, secure, and cost-effective cloud architectures that meet the demands of modern applications and DevOps practices.

VPC Fundamentals and Address Space

A Virtual Private Cloud (VPC) is your private data center within the cloud provider's global infrastructure. It is a software-defined network that provides complete logical isolation from other customers' networks. When you create a VPC, the first and most critical decision is its IP address range, defined in Classless Inter-Domain Routing (CIDR) notation (e.g., 10.0.0.0/16). This CIDR block is a pool of private IP addresses from which you can allocate segments to subdivisions of your network.

The size of the CIDR block determines the number of available IP addresses. A /16 block (like 10.0.0.0/16) provides 65,536 addresses, while a /28 block provides only 16. It's crucial to plan for growth and potential future connections, like VPC peering, to avoid overlapping IP ranges, which would prevent networks from being joined. All resources you launch, such as virtual machines (EC2 instances) or databases, will be assigned an IP address from this VPC's pool, allowing them to communicate with each other securely over the cloud provider's backbone.

Organizing with Subnets: Public, Private, and Routing

A VPC's IP address space is divided into subnets, which are segments of the VPC tied to a specific Availability Zone (e.g., us-east-1a). Subnets allow you to group resources based on function and security requirements. The key distinction is between public subnets and private subnets. A public subnet has a route to an Internet Gateway (IGW), a managed service that facilitates two-way communication between resources in your VPC and the public internet. This makes it suitable for front-end web servers or load balancers.

Conversely, a private subnet does not have a direct route to the internet. It is designed to host backend services like application servers, databases, or internal caches that should not be directly accessible from the open web. To enable resources in a private subnet to download software updates or access external APIs, you use a NAT Gateway. A NAT Gateway, placed in a public subnet, allows instances in a private subnet to initiate outbound connections to the internet, but it prevents any unsolicited inbound traffic from reaching them. This creates a secure, outbound-only internet access pattern.

Controlling Traffic Flow: Route Tables and Gateways

Network traffic within a VPC is governed by route tables. Each subnet is explicitly associated with one route table, which contains a set of rules (routes) that determine where network traffic is directed. A route specifies a destination CIDR and a target (e.g., local for traffic within the VPC, igw-xxx for the Internet Gateway, or nat-xxx for a NAT Gateway).

Every VPC has a default main route table. If you don't explicitly associate a custom route table with a subnet, it uses the main one. For example, the route table for a public subnet would have a route sending 0.0.0.0/0 (all non-local traffic) to the Internet Gateway. A private subnet's route table would send 0.0.0.0/0 to a NAT Gateway for outbound traffic, while having no route to an IGW. This declarative model is powerful: you don't configure individual servers; you define the network's behavior at the subnet level, and all resources within it inherit those rules.

Enforcing Security: Network ACLs and Security Groups

Security in a VPC operates at two distinct layers: the subnet level and the instance level. A Network Access Control List (NACL) is a stateless firewall that operates at the subnet boundary. It contains numbered rules (e.g., Rule 100, Rule 200) that explicitly allow or deny traffic based on protocol, port, and source/destination IP. NACLs are evaluated in order before traffic enters or leaves a subnet. They are useful for creating coarse-grained, subnet-wide deny rules (e.g., blocking a known malicious IP range).

The primary defense, however, is the security group. This is a stateful firewall that operates at the level of an individual cloud resource, like a virtual machine. Unlike NACLs, security groups only contain allow rules; all other traffic is implicitly denied. Their stateful nature means that if you allow an inbound connection on port 80, the corresponding outbound response traffic is automatically permitted, regardless of outbound rules. Security groups are attached directly to resources, making them ideal for defining application-specific access policies, such as "only the web server security group can talk to the database on port 5432."

Advanced Connectivity: VPC Peering and Transit Gateways

As your cloud footprint grows, you often need to connect multiple VPCs, whether within the same account or across different accounts and regions. VPC peering creates a direct, one-to-one network connection between two VPCs using the cloud provider's private network. Once peered, instances in either VPC can communicate with each other using private IP addresses as if they were on the same network. Critical constraints include non-overlapping IP ranges and the fact that peering connections are not transitive (if VPC A is peered to B, and B to C, A cannot talk to C).

For more complex, hub-and-spoke architectures, you use a Transit Gateway. This acts as a regional cloud router, enabling you to connect multiple VPCs, on-premises data centers (via VPN or Direct Connect), and even other transit gateways through a central hub. It provides transitive routing, simplifying management for large-scale networks. When designing with a transit gateway, you manage route propagation and associations, giving you fine-grained control over which network segments can communicate.

Common Pitfalls

1. Overlapping IP Address Ranges: Creating VPCs or subnets with overlapping CIDR blocks (e.g., one VPC with 10.0.0.0/16 and another with 10.0.1.0/24) will prevent you from ever connecting them via VPC Peering or Transit Gateway. Always plan your IP addressing scheme hierarchically from the start, accounting for future expansion and interconnection.
2. Misconfigured Security Group Rules: The most common cause of connectivity issues is overly restrictive security groups. Remember that security groups are stateful and default-deny. A classic mistake is allowing HTTP traffic (port 80) into a web server but forgetting that the server itself needs outbound ephemeral port access (e.g., 1024-65535) to send responses back to clients.
3. Confusing NACLs with Security Groups: Using a Network ACL to perform the function of a security group leads to brittle, hard-to-manage rules. NACLs are stateless, so you must create explicit inbound and outbound rules for every allowed connection. They are best used for simple, subnet-wide block/allow lists, not for complex application-layer security.
4. Neglecting the NAT Gateway's Public Subnet Placement: A NAT Gateway must be deployed in a public subnet because it needs a route to an Internet Gateway to function. Placing it in a private subnet will break outbound internet access for your resources. Furthermore, you must ensure the private subnet's route table points 0.0.0.0/0 traffic to the NAT Gateway, not the IGW.

Summary

• A Virtual Private Cloud (VPC) is your configurable, isolated virtual network in the cloud, defined by a private IP address range (CIDR block).
• Subnets partition a VPC across Availability Zones; public subnets have routes to an Internet Gateway for bidirectional internet access, while private subnets use NAT Gateways for secure, outbound-only access.
• Traffic flow is controlled by route tables associated with subnets, which direct traffic to appropriate targets like local VPC, IGW, or NAT Gateway.
• Security is enforced at two layers: Network ACLs provide stateless, subnet-level filtering, while security groups offer stateful, resource-level firewall rules (allow-only).
• To connect multiple VPCs, use VPC peering for simple one-to-one links or a Transit Gateway for scalable, transitive hub-and-spoke architectures, ensuring IP ranges never overlap.