Cloud Networking Fundamentals: VPCs, Subnets, and Security Groups Explained

Every cloud deployment starts with networking — and getting it right from the beginning saves enormous pain later. A poorly designed network creates security vulnerabilities, performance bottlenecks, and scaling limitations that are difficult and expensive to fix once production workloads are running.

This guide explains the fundamental building blocks of cloud networking — VPCs, subnets, route tables, security groups, and NAT gateways — with practical guidance on designing a network that is secure, scalable, and cost-effective.

Virtual Private Clouds: Your Isolated Network

A VPC (Virtual Private Cloud) is your own isolated network within the cloud provider's infrastructure. Think of it as your own data center network, but without the physical hardware. Everything you deploy — servers, databases, load balancers, containers — lives inside a VPC. You define the IP address range, create subnets, configure routing, and control what traffic is allowed in and out.

Choose your VPC's CIDR block carefully — it determines how many IP addresses are available and cannot be changed later without creating a new VPC. A /16 network (65,536 addresses) provides ample room for growth. Avoid overlapping with other networks you might need to connect to via VPN or peering — if your VPC uses 10.0.0.0/16 and your office network uses the same range, you cannot connect them directly.

Subnets: Segmenting Your Network

Subnets divide your VPC into smaller network segments, each in a specific availability zone. The most important distinction is between public and private subnets. Public subnets have a route to an internet gateway, allowing resources in them to receive traffic directly from the internet. Private subnets do not have direct internet access — resources in them can only be reached through a load balancer, NAT gateway, or VPN.

A standard design uses three tiers. The public tier contains load balancers, bastion hosts, and NAT gateways. The application tier (private) contains your application servers and containers. The data tier (private) contains databases, caches, and other data stores. Each tier has subnets in multiple availability zones for redundancy. This multi-tier architecture follows the principle of least privilege at the network level — databases are never directly accessible from the internet.

Route Tables: Directing Traffic

Route tables determine where network traffic is directed. Each subnet is associated with a route table that contains rules mapping destination IP ranges to targets (internet gateway, NAT gateway, VPC peering connection, VPN gateway). The most specific matching rule wins.

Public subnets have a route to the internet gateway for traffic destined for the internet. Private subnets route internet-bound traffic to a NAT gateway (which translates private IP addresses to the NAT gateway's public IP) so instances can download updates and access external APIs without being directly reachable from the internet.

Security Groups: Instance-Level Firewalls

Security groups are stateful firewalls attached to individual instances. They control which traffic is allowed to reach each resource. "Stateful" means that if you allow inbound traffic on a port, the response traffic is automatically allowed outbound — you do not need to create separate rules for responses.

Design security groups around the principle of least privilege. A web server security group allows inbound traffic on ports 80 and 443 from anywhere, and nothing else. A database security group allows inbound traffic on port 5432 only from the application server security group — not from any IP address, but from a specific security group. This means only instances that belong to the application security group can reach the database. Reference security groups in rules instead of IP addresses whenever possible — this makes your rules dynamic and self-updating as instances are added or removed.

Network ACLs: Subnet-Level Firewalls

Network ACLs provide an additional layer of network filtering at the subnet level. Unlike security groups, they are stateless — you must create explicit rules for both inbound and outbound traffic. Use NACLs for broad rules (blocking entire IP ranges, allowing specific ports at the subnet level) and security groups for fine-grained, instance-specific rules.

NAT Gateways: Internet Access for Private Resources

Resources in private subnets need internet access for software updates, external API calls, and downloading dependencies. A NAT gateway, placed in a public subnet, provides outbound internet access while keeping the resources unreachable from the internet. This is a key security pattern — your application servers can reach the internet, but the internet cannot reach them directly.

NAT gateways are not free. They incur hourly charges plus data processing costs. For cost optimization, consider using a single NAT gateway instead of one per availability zone (with the tradeoff of reduced redundancy). For development environments, a NAT instance (a small EC2 instance configured for NAT) can be cheaper than a managed NAT gateway.

VPC Peering and Transit Gateways

VPC peering connects two VPCs so resources in each can communicate using private IP addresses. This is useful for connecting production and management VPCs, connecting VPCs across regions, or connecting to partner VPCs. For organizations with many VPCs, a Transit Gateway provides a hub-and-spoke model that simplifies connectivity management.

Designing for High Availability

Deploy resources across multiple availability zones. Each tier should have subnets in at least two AZs — if one AZ has an outage, your application continues running in the other. Load balancers automatically distribute traffic across healthy instances in multiple AZs. Databases should use multi-AZ deployments for automatic failover.

ZeonEdge designs and implements secure, scalable cloud network architectures for businesses of all sizes. Learn more about our cloud networking services.