Cloud Networking Basics: VPCs, Subnets, NAT, and Security Groups

Quickstart

Use this when a workload “should” connect but doesn’t. The goal is to eliminate whole classes of issues quickly, before you deep-dive into cloud console pages.

Overview

Cloud networking basics are the foundation for reliable deployments: private application tiers, secure databases, stable outbound access, and predictable traffic flow. The vocabulary can feel intimidating (VPCs, subnets, NAT, security groups), but the core ideas are simple: define address space, split it into zones, control routes, and enforce allowlists.

Core concepts

VPC (or VNet): your private address space

A VPC is a logically isolated network where you choose a CIDR range (like 10.0.0.0/16). Everything inside gets private IPs from that range. Think of it as “your data center network,” but with programmable routing and firewalls.

CIDR and subnets: how you carve up the space

CIDR notation defines how big an IP block is. A /16 is large; a /24 is much smaller. You split a VPC into subnets (often per Availability Zone) so you can control routing and isolation boundaries.

Public vs private subnets

A subnet becomes “public” when it has a route to an Internet Gateway and instances can receive public IPs. A “private” subnet has no direct route to the internet. Private subnets are where you put databases, internal services, and most app workloads.

Internet Gateway vs NAT

• Internet Gateway (IGW): enables inbound/outbound internet for public subnets (when routes allow it).
• NAT (gateway/instance): enables outbound-only internet from private subnets. NAT is for updates, package installs, external APIs — not for inbound traffic.

Security groups vs network ACLs

The two most common “it should work” blockers are security groups and NACLs. The key difference is how they behave.

A simple mental model: the packet’s journey

When you’re stuck, walk the packet:

1. Name: resolve hostname to IP (DNS).
2. Source policy: does the source allow egress to that destination/port?
3. Route: does the source subnet know where to send it (local, peering, NAT, IGW)?
4. Destination policy: does the destination allow ingress from that source/port?
5. App: is something listening and healthy behind the destination?

Step-by-step

Let’s build a “classic” layout: public entry + private app tier + private database tier. This pattern translates across providers (AWS VPC / Azure VNet / GCP VPC), even if the names differ.

Step 1: Plan CIDRs and tiers

Step 2: Route tables, IGW, and NAT (make traffic intentional)

Routing decides where packets can go. The simplest stable setup uses two route tables: a public route table (with a default route to an internet gateway) and a private route table (with a default route to NAT).

Step 3: Security groups (least privilege that still works)

Security groups are where you encode “who can talk to whom.” A practical approach is to model your application layers: load balancer → app → database. Each layer gets its own security group.

Step 4: A minimal VPC layout as code (example)

The snippet below shows a compact AWS-style layout: VPC, one public subnet, one private subnet, IGW, NAT, and security groups. Use it as a mental model even if you’re on another cloud — the pieces are the same. (Keep production setups multi-AZ; this is minimal on purpose.)

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" {
  region = var.region
}

variable "region" { type = string, default = "eu-central-1" }
variable "vpc_cidr" { type = string, default = "10.20.0.0/16" }

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = { Name = "unilab-net" }
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
  tags = { Name = "unilab-igw" }
}

resource "aws_subnet" "public_a" {
  vpc_id                  = aws_vpc.main.id
  cidr_block               = "10.20.10.0/24"
  availability_zone        = "${var.region}a"
  map_public_ip_on_launch  = true
  tags = { Name = "public-a" }
}

resource "aws_subnet" "private_a" {
  vpc_id           = aws_vpc.main.id
  cidr_block        = "10.20.20.0/24"
  availability_zone = "${var.region}a"
  tags = { Name = "private-a" }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
  tags = { Name = "rt-public" }
}

resource "aws_route_table_association" "public_a" {
  subnet_id      = aws_subnet.public_a.id
  route_table_id = aws_route_table.public.id
}

resource "aws_eip" "nat" {
  domain = "vpc"
  tags = { Name = "eip-nat" }
}

resource "aws_nat_gateway" "nat" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public_a.id
  tags = { Name = "nat-a" }
  depends_on = [aws_internet_gateway.igw]
}

resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat.id
  }
  tags = { Name = "rt-private" }
}

resource "aws_route_table_association" "private_a" {
  subnet_id      = aws_subnet.private_a.id
  route_table_id = aws_route_table.private.id
}

# Security groups (LB -> App -> DB pattern)
resource "aws_security_group" "app" {
  name   = "sg-app"
  vpc_id = aws_vpc.main.id

  ingress {
    description = "App port from LB"
    from_port   = 8080
    to_port     = 8080
    protocol    = "tcp"
    cidr_blocks = ["10.20.10.0/24"] # or reference an LB security group in real setups
  }

  egress {
    description = "Allow outbound (tighten per your needs)"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = { Name = "sg-app" }
}

resource "aws_security_group" "db" {
  name   = "sg-db"
  vpc_id = aws_vpc.main.id

  ingress {
    description     = "DB from app"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
  }

  tags = { Name = "sg-db" }
}

Step 5: Troubleshoot with repeatable probes

When connectivity fails, use probes that tell you which layer is failing: DNS, TCP reachability, TLS, and HTTP. The commands below are safe and fast, and work from most Linux containers/VMs.

#!/usr/bin/env bash
set -euo pipefail

# Usage:
#   ./netcheck.sh example.internal 5432
#   ./netcheck.sh api.example.com 443
#
# These checks help you identify: DNS issue vs route/firewall drop vs app not listening.

HOST="${1:?host required}"
PORT="${2:-443}"

echo "== DNS resolution =="
( command -v dig >/dev/null && dig +short "$HOST" ) || ( getent hosts "$HOST" || true )

echo
echo "== TCP reachability (timeout means drop; refused means app not listening) =="
if command -v nc >/dev/null; then
  nc -vz -w 3 "$HOST" "$PORT" || true
else
  # Bash TCP check fallback
  timeout 3 bash -c "cat </dev/null >/dev/tcp/$HOST/$PORT" && echo "TCP: OK" || echo "TCP: FAIL"
fi

echo
echo "== TLS/HTTP probe (if applicable) =="
if [[ "$PORT" == "443" || "$PORT" == "8443" ]]; then
  curl -sS -m 5 -I "https://$HOST:$PORT" || true
else
  curl -sS -m 5 -I "http://$HOST:$PORT" || true
fi

echo
echo "== Trace route hint (may be blocked by firewalls) =="
( command -v traceroute >/dev/null && traceroute -n -w 1 -q 1 "$HOST" | head -n 8 ) || true

echo
echo "Next steps if it fails:"
echo "  - DNS fails: check private DNS/hosted zone/resolver rules"
echo "  - TCP timeout: check route table + SG/NACL (drops look like timeouts)"
echo "  - Refused: app/service not listening or wrong target port"

Step 6: Going beyond basics (when your network grows)

Once you have the basics stable, you’ll encounter “real-world” requirements: private access to managed services, hybrid connectivity, and multi-network topologies. Here are the most common next steps and when to use them:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-db
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: ingress
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: db
      ports:
        - protocol: TCP
          port: 5432

Common mistakes

These are the issues that show up again and again in incident reviews. If you recognize your setup in one of these, you’ve found a great place to fix first.

FAQ

What’s the difference between a VPC and a subnet?

A VPC is the full private network and address space (CIDR range). A subnet is a slice of that space, usually tied to an AZ, where you attach routing and apply subnet-level controls. You place workloads into subnets to control exposure and traffic flow.

How do I know if a subnet is “public” or “private”?

A subnet is effectively public if its route table has a default route (0.0.0.0/0) to an Internet Gateway and instances can have public IPs. A subnet is private if it does not route directly to the IGW. Private subnets often route outbound through NAT instead.

What does NAT actually do?

NAT enables outbound internet access for private subnets by translating private source IPs to a public IP on the way out. NAT does not enable inbound internet access to private instances. For inbound access, use a load balancer, public service, or a private admin path (VPN/bastion/SSM).

Are security groups stateful, and why do I care?

In many clouds, security groups are stateful: if you allow inbound to a port, return traffic is allowed automatically. This makes them easier to reason about than stateless controls (like many NACLs), which require explicit rules in both directions.

Why do I get timeouts instead of explicit errors?

Firewalls and routing drops usually produce timeouts because packets are silently discarded. That’s why the troubleshooting flow starts with DNS, then probes TCP reachability, then checks route tables and security rules.

What’s a safe default security group strategy?

Use layered security groups aligned to your architecture: an inbound-facing layer (LB), an app layer, and a data layer. Allow only the required ports between layers, and avoid broad CIDR allowlists when you can reference security groups directly.

When should I use VPC endpoints / PrivateLink?

Use them when you want private access to managed services (object storage, secrets, APIs) without routing through the public internet. They reduce exposure and can simplify egress control — but still require careful DNS and policy configuration.

Cheatsheet

Keep this nearby for incident response. It’s designed to help you identify the failing layer fast and apply the right fix without guesswork.

Wrap-up

Cloud networking basics aren’t about memorizing provider-specific names — they’re about understanding the path. Once you internalize DNS → routing → security groups/NACLs → listener, most connectivity issues become quick, mechanical fixes. Keep your network simple, private by default, and consistent across environments, and troubleshooting becomes a checklist instead of a mystery.

Want to connect networking to the rest of your platform? The related posts cover Terraform structure, cost drivers like NAT/egress, and Kubernetes fundamentals that show up in real environments.

Related posts

• Terraform Mistakes: State, Modules, and the ‘One Big Plan’ Trap
• Cloud Cost Optimization: 15 Leaks You Can Fix This Month
• Serverless Done Right: When Functions Beat Containers
• Docker for Developers: Images, Layers, and Caching Explained
• Kubernetes Without Tears: Pods, Services, Ingress in One Story
• CI/CD That Stays Green: Pipeline Patterns That Scale