Setting Up a VPC on AWS: Cloud Networking Fundamentals

By Khimananda Oli | Last reviewed: August 2026

Misconfigured networking is the most common cause of production outages and security breaches I see during cloud audits. Setting up a VPC on AWS: Cloud Networking Fundamentals requires understanding isolation boundaries, not just clicking through the console wizard. This guide walks you through building a resilient, secure network foundation that supports scaling applications and compliance requirements from day one.

How do you plan IP addressing when setting up a VPC on AWS?

IP planning is irreversible once peering or transit gateway connections are established. When setting up a VPC on AWS, choose a CIDR block that accommodates future growth without overlapping your on-premises networks or other cloud environments. A /16 block (65,536 addresses) provides ample room for most application VPCs, while a /20 is often sufficient for microservice-specific networks.

Subnet Sizing Strategy

Avoid the common mistake of creating oversized public subnets. Public subnets should only host load balancers, bastions, and NAT gateways. Allocate smaller CIDRs (/24 or /26) for public tiers and larger blocks (/22 or /23) for private application and database subnets where your actual workloads reside.

• Public Subnets: /24 per AZ (251 usable IPs) — sufficient for ELBs and jump hosts.
• Application Subnets: /22 per AZ (1,019 usable IPs) — allows horizontal auto-scaling.
• Data Subnets: /24 per AZ — databases rarely require massive IP density but need isolation.
• Reserved: Always leave unallocated space within your VPC CIDR for future subnet creation.

If you are migrating existing infrastructure, review our guide on migrating a website from shared hosting to the cloud to understand how legacy IP schemes map to modern VPC designs.

What is the correct subnet and gateway configuration for AWS VPC?

The distinction between public and private subnets in AWS is purely determined by routing, not by any inherent subnet property. A subnet becomes "public" only when its route table contains a default route (0.0.0.0/0) pointing to an Internet Gateway (IGW). Without this explicit route, even a subnet with public IP-enabled instances remains effectively private.

Configuring Gateways via Terraform

Infrastructure as Code prevents drift and documents intent. When setting up a VPC on AWS using Terraform, define your gateways explicitly rather than relying on module defaults that may change. See our practical guide to Infrastructure as Code with Terraform for foundational patterns.

<!-- Terraform: Internet and NAT Gateway Configuration -->
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "${var.project}-igw" }
}

resource "aws_eip" "nat" {
  domain = "vpc"
  tags   = { Name = "${var.project}-nat-eip" }
}

resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public_a.id
  tags          = { Name = "${var.project}-nat-gw" }
  
  # Ensure IGW exists before NAT GW creation
  depends_on = [aws_internet_gateway.main]
}

A critical operational detail: NAT Gateways must reside in public subnets but serve private subnets. For high availability, deploy one NAT Gateway per Availability Zone. While a single NAT GW reduces cost, it creates a single point of failure; if that AZ goes down, all private subnet egress traffic stops regardless of your multi-AZ application deployment.

How do you secure traffic when setting up a VPC on AWS?

Security in AWS networking operates at two distinct layers: Security Groups (stateful firewalls at the ENI level) and Network ACLs (stateless filters at the subnet boundary). In practice, Security Groups handle 95% of access control logic because they support connection tracking and reference-based rules.

Principle of Least Privilege in Practice

Never use 0.0.0.0/0 in Security Group ingress rules except for public-facing load balancers on ports 80/443. For backend communication, reference Security Group IDs as sources instead of CIDR blocks. This allows dynamic IP assignment while maintaining strict access control.

1. Create tier-specific Security Groups: Separate SGs for web, app, and data layers.
2. Reference SG IDs, not IPs: Use source_security_group_id to allow inter-tier traffic.
3. Restrict SSH/RDP: Limit management port access to bastion or SSM Session Manager only.
4. Audit quarterly: Remove unused rules; stale permissions accumulate silently.

For teams managing sensitive data, align your VPC security model with compliance frameworks. My experience with SOC 2 and ISO 27001 audits shows that documented, automated security group management satisfies auditors far better than manual console changes. If you're deploying applications that require hardened baselines, start with our secure Ubuntu server setup guide to complement network-layer controls.

When should you use NAT Gateway versus VPC Endpoints?

NAT Gateways enable outbound internet access for private subnets but incur hourly charges plus data processing fees. VPC Endpoints (Gateway and Interface types) provide private connectivity to AWS services without traversing the public internet, often at lower cost and higher security.

In production environments, I recommend Gateway Endpoints for S3/DynamoDB (they're free and reduce NAT costs significantly) and Interface Endpoints for services like Secrets Manager, ECR, and CloudWatch Logs. Reserve NAT Gateways strictly for legitimate external dependencies: package repositories, third-party APIs, or license servers. This approach typically reduces monthly networking spend by 30–40% for data-intensive workloads.

How do you validate VPC connectivity and troubleshoot routing issues?

After setting up a VPC on AWS, validation prevents silent failures. Never assume connectivity works because configuration looks correct. Use VPC Reachability Analyzer to verify paths between ENIs before deploying applications. This tool evaluates route tables, security groups, NACLs, and gateway configurations to confirm whether traffic can actually flow.

Essential Validation Checklist

• Route Table Association: Confirm each subnet is associated with the intended route table (not the main table).
• NAT Gateway Health: Check CloudWatch metrics for packets dropped; unhealthy NAT GWs fail silently.
• DNS Resolution: Test nslookup against VPC DNS (169.254.169.253) to verify private hosted zones.
• Flow Logs: Enable VPC Flow Logs early; retroactive debugging without them is nearly impossible.

A frequent issue in Nepal-based deployments connecting to global AWS regions is MTU mismatch when traversing VPN or Direct Connect. Standard VPC MTU is 9001 bytes for intra-VPC traffic but drops to 1500 for internet-bound or peered traffic. If you experience intermittent connection failures or slow transfers, verify MTU settings on both ends and adjust TCP MSS accordingly.

Building Production-Ready AWS Networks

Setting up a VPC on AWS: Cloud Networking Fundamentals extends beyond initial provisioning. Sustainable cloud networking requires codified infrastructure, continuous validation, and cost-aware architecture decisions. Start with proper IP planning, enforce least-privilege security groups, optimize egress with VPC Endpoints, and validate every path before going live. These practices form the foundation for compliant, scalable systems that survive audits and traffic spikes alike.

If your team needs hands-on guidance designing or auditing AWS networking for production workloads, reach out to discuss your specific requirements. Whether you're preparing for SOC 2 certification, optimizing multi-region connectivity, or troubleshooting persistent networking issues, experienced architectural review prevents costly rework downstream.