Cloud Networking Fundamentals: VPCs, Subnets, and Gateways

Introduction

Picture this: You've just joined a team building a multi-tier web application in the cloud. The backend services need to communicate securely with databases, the frontend needs public internet access, and everything must be isolated from other workloads. Where do you even start with cloud networking?

If you've ever felt overwhelmed by cloud networking concepts, you're not alone. Virtual Private Clouds (VPCs), subnets, and gateways form the backbone of every cloud application, yet they're often glossed over in favor of flashier topics like containers and serverless functions. The reality is that understanding cloud networking is crucial for building secure, scalable, and maintainable systems.

Without proper network design, your applications become security risks, performance bottlenecks, or maintenance nightmares. But with solid fundamentals, networking becomes an enabler that gives you precise control over traffic flow, security boundaries, and system architecture.

Core Concepts

Virtual Private Clouds (VPCs)

Think of a VPC as your own private data center in the cloud. It's an isolated network environment where you define the IP address ranges, routing rules, and security policies. Unlike physical networks, VPCs give you complete control over network configuration without managing hardware.

A VPC is defined by its CIDR block, which determines the range of IP addresses available. For example, a VPC with CIDR block 10.0.0.0/16 provides roughly 65,000 IP addresses. This becomes your network boundary where you'll place all your cloud resources.

The key insight here is that VPCs provide both isolation and control. Your resources can't accidentally communicate with other customers' resources, and you decide exactly how traffic flows within your network.

Subnets: Dividing Your Network

Subnets are subdivisions within your VPC that organize resources by function, security requirements, or availability zones. Each subnet exists in a single availability zone and has its own subset of your VPC's IP range.

The most common pattern involves public and private subnets:

• Public subnets contain resources that need direct internet access, like load balancers or bastion hosts
• Private subnets house backend services, databases, and internal systems that shouldn't be directly accessible from the internet

This separation creates natural security boundaries. Your web servers might sit in public subnets to serve traffic, while your databases live in private subnets, accessible only through your application layer.

Internet and NAT Gateways

Gateways control how traffic enters and exits your VPC. An Internet Gateway enables bidirectional communication between your VPC and the public internet. Resources in public subnets use it to both receive inbound traffic and initiate outbound connections.

NAT Gateways solve a common problem: how do resources in private subnets access the internet for updates or external API calls without exposing themselves to inbound traffic? NAT Gateways allow outbound internet access while blocking unsolicited inbound connections.

You can visualize these gateway relationships and traffic flows using tools like InfraSketch, which helps clarify how your network components connect before you start building.

Security Groups vs Network ACLs

Security controls in cloud networking operate at two levels. Security Groups act as virtual firewalls for individual resources, controlling traffic at the instance level. They're stateful, meaning if you allow inbound traffic on port 80, the response traffic is automatically allowed back out.

Network Access Control Lists (NACLs) operate at the subnet level, providing an additional layer of filtering. Unlike Security Groups, NACLs are stateless, so you must explicitly define both inbound and outbound rules. They serve as a subnet-wide safety net, catching traffic that shouldn't flow between network segments.

The defense-in-depth approach uses both layers. NACLs provide broad network-level controls, while Security Groups offer granular, application-specific rules.

How It Works

Traffic Flow Architecture

Understanding how packets flow through your cloud network is essential for troubleshooting and optimization. When a user makes a request to your application, the traffic follows a predictable path through your network components.

External traffic first hits your Internet Gateway, which routes it to the appropriate subnet based on your routing tables. The subnet's NACL evaluates the traffic against its rules. If allowed, the packet reaches your instance, where Security Group rules make the final access decision.

For outbound traffic from private subnets, the flow reverses through NAT Gateways. Your database server can reach external APIs by routing through the NAT Gateway, which translates the private IP to a public IP, makes the request, and routes the response back to the original instance.

Routing Tables and Traffic Direction

Routing tables are the traffic directors of your VPC. Each subnet associates with a routing table that defines where traffic should go based on destination IP addresses. The most common routes include local routes for VPC traffic and default routes (0.0.0.0/0) for internet traffic.

Public subnets typically route internet traffic through Internet Gateways, while private subnets route through NAT Gateways. Custom routes become important when connecting multiple VPCs or integrating with on-premises networks.

Inter-VPC Communication

As your systems grow, you'll likely need multiple VPCs for different environments, regions, or organizational boundaries. VPC Peering creates direct network connections between VPCs, allowing resources to communicate as if they were on the same network.

Peering connections are not transitive, meaning if VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot automatically reach VPC C. This limitation led to the development of more sophisticated solutions like Transit Gateways.

Design Considerations

Scaling Your Network Architecture

Network design decisions made early in your project have long-term implications. Choose your VPC CIDR blocks carefully, ensuring enough IP addresses for future growth. A common mistake is selecting CIDR blocks that are too small or that conflict with on-premises networks you might later need to connect.

Consider the hub-and-spoke model for complex architectures. Instead of creating peer-to-peer connections between every VPC, designate a central hub that manages connectivity. AWS Transit Gateway exemplifies this pattern, acting as a cloud router that simplifies network topology as you scale.

Security and Compliance Boundaries

Network segmentation supports compliance requirements and reduces blast radius during security incidents. Separate environments (development, staging, production) into different VPCs or subnets. Place sensitive workloads in isolated network segments with strict access controls.

Implement the principle of least privilege in your Security Groups. Start with restrictive rules and open access only as needed. Document your security group rules as they tend to accumulate over time, making it difficult to understand what traffic is actually required.

Multi-Region and High Availability

High availability often requires resources distributed across multiple availability zones. Design your subnets to span multiple zones, allowing load balancers to distribute traffic and providing failover options when zones experience issues.

For multi-region architectures, plan for data replication and failover scenarios. Tools like InfraSketch can help you visualize complex multi-region topologies and ensure you haven't missed critical connections or dependencies.

Cost Optimization Strategies

Network costs can surprise teams new to cloud networking. NAT Gateways charge for both provisioned time and data transfer. In development environments, consider NAT Instances as a cost-effective alternative, though they require more management overhead.

Cross-availability-zone data transfer incurs charges, so optimize your architecture to minimize unnecessary traffic between zones. Place frequently communicating services in the same availability zone when possible, while maintaining adequate redundancy for high availability requirements.

Transit Gateway: Simplifying Complex Topologies

As your network grows beyond a few VPCs, managing individual peering connections becomes unwieldy. Transit Gateway acts as a central hub, simplifying connectivity and routing between VPCs, on-premises networks, and VPN connections.

Transit Gateway supports advanced routing scenarios, including route propagation and association, allowing different parts of your network to have different connectivity policies. This becomes particularly valuable in enterprise environments with complex compliance and security requirements.

Key Takeaways

Cloud networking fundamentals form the invisible foundation that enables everything else in your cloud architecture. VPCs provide isolated environments with complete control over IP addressing and routing. Subnets organize resources by function and security requirements, creating natural boundaries between public-facing and internal components.

Security operates in layers, with NACLs providing subnet-level controls and Security Groups offering instance-level protection. This defense-in-depth approach catches misconfigurations and limits the impact of security incidents.

Gateway components control internet access patterns. Internet Gateways enable bidirectional communication for public resources, while NAT Gateways allow private resources to initiate outbound connections without exposure to inbound traffic.

As systems scale, consider centralized connectivity patterns like Transit Gateway rather than complex mesh topologies. Plan your IP addressing and network segmentation early, as changes become more difficult as your infrastructure grows.

Most importantly, visualize your network architecture before building. Complex networking concepts become much clearer when you can see how components connect and traffic flows between them.

Try It Yourself

Now it's time to apply these concepts to your own projects. Think about a multi-tier application you're building or have worked on recently. How would you design the VPC architecture? What subnets would you create? How would you handle internet access for different tiers?

Head over to InfraSketch and describe your system in plain English. In seconds, you'll have a professional architecture diagram, complete with a design document. No drawing skills required.

Try describing something like: "A three-tier web application with load balancers in public subnets, application servers in private subnets, and databases in isolated subnets, all within a VPC with proper security groups and NAT gateway access."

Experimenting with different network designs will solidify these concepts and help you make better architectural decisions in your real projects. The key is to start simple and add complexity only as your requirements demand it.