AWS Subnets Explained: Public vs Private vs Isolated

Simple explanation

Subnets sound technical, but the core idea is straightforward: they are just named chunks of IP address space inside your VPC, each pinned to one Availability Zone. You cannot launch a resource directly into a VPC. You always launch into a subnet.

Whether that subnet is “public” or “private” is not a fixed property. It is entirely determined by the route table attached to it. Change the route table, and the subnet changes type instantly.

How subnets work in AWS

When you create a VPC, you define a CIDR block like 10.0.0.0/16. That is your total IP address pool: 65,536 addresses. You carve that pool into subnets by picking a smaller prefix length, such as 10.0.1.0/24 for 256 addresses.

You pick which Availability Zone the subnet lives in, and it stays there permanently. A subnet cannot span AZs. This is by design: AZ isolation means a hardware failure in one AZ does not affect subnets in others, which is exactly what makes multi-AZ architectures resilient.

Every subnet must be associated with a route table. The route table is the core control: it tells traffic where to go. Every VPC automatically includes a local route (10.0.0.0/16 local) so all subnets can reach each other. Beyond that, you decide what to add. An Internet Gateway route makes a subnet public. A NAT Gateway route gives private subnets outbound access. Nothing extra means the subnet is isolated.

To get multi-AZ redundancy, create one subnet per AZ per tier. A three-AZ, three-tier design has nine subnets total: three public, three private, three isolated.

Public vs private vs isolated subnets

What makes a subnet public?

This is the most misunderstood concept in AWS networking.

The only thing that makes a subnet public is its route table. If the route table associated with a subnet has a route for 0.0.0.0/0 pointing to an Internet Gateway, the subnet is public. There is no other flag, no creation-time setting, no property baked into the subnet itself.

So what does auto-assign public IPs actually do? It ensures that EC2 instances launched in a correctly routed public subnet automatically get a routable address. Without a public IP on the instance, even a properly configured public subnet cannot receive inbound internet traffic for that resource. It is a convenience feature, not a classification feature.

Even in a public subnet with a public IP, a resource is only reachable if its security group or Network ACL allows the traffic. Routing says where traffic can go. Security rules say what traffic is allowed. Both must be correct.

When to use each subnet type

Public subnets: place here

• Application Load Balancers (your internet-facing entry point)
• NAT Gateways: must be in a public subnet to give private subnets outbound access
• Bastion hosts or jump boxes, if you use them instead of AWS Systems Manager
• Network Load Balancers for internet-facing traffic

Private subnets: place here

• EC2 application and API servers
• ECS tasks and EKS worker nodes
• Lambda functions that need VPC access (for example, to reach a private RDS or Redis)
• Internal microservices that should not be directly reachable from the internet

Isolated subnets: place here

• RDS databases
• ElastiCache clusters
• Any workload where outbound internet access is a compliance violation
• Secrets stores, internal certificate authorities, or HSMs

How it works in a real architecture

Here is a standard three-tier web app and the path a user request takes:

User (internet)
    ↓
[Public Subnet]   Application Load Balancer  ← has public IP, IGW route
    ↓
[Private Subnet]  App Server (EC2 / ECS)     ← private IP only, no inbound from internet
    ↓
[Isolated Subnet] RDS Database               ← no internet path in either direction

Inbound path: The user hits the ALB’s public DNS. The ALB sits in a public subnet, has a public IP, and its security group allows inbound HTTPS. It forwards the request to your app tier in a private subnet over the VPC’s internal network.

Outbound patching path: Your app server needs to pull a software update. It sends traffic to the NAT Gateway in the public subnet, which makes the outbound connection using its Elastic IP. Your app server’s private IP is never exposed to the internet.

Database access: The RDS instance in the isolated subnet is not reachable from the internet at any layer. The app server reaches it over the VPC’s local route. If RDS needs to call an AWS service like Secrets Manager, you add a VPC endpoint so that traffic stays on the AWS private backbone and never touches the internet.

This is why the three-tier layout is the default production pattern: it gives you defense in depth without unnecessary complexity. See Default vs Custom VPCs to understand why you should build this yourself rather than rely on the default VPC.

Subnet sizing and CIDR planning

AWS reserves 5 IP addresses in every subnet: the network address, the VPC router, the DNS server, a future-use address, and the broadcast address. A /24 subnet gives you 256 total, so 251 are actually usable. Plan around this from the start.

A typical three-AZ, three-tier design needs nine subnets. With a /16 VPC and /24 subnets, you use 9 of your 256 available blocks, leaving plenty of room to grow.

VPC: 10.0.0.0/16

Public subnets (ALB, NAT GW):
  10.0.1.0/24  →  us-east-1a
  10.0.2.0/24  →  us-east-1b
  10.0.3.0/24  →  us-east-1c

Private subnets (app servers, ECS/EKS):
  10.0.11.0/24  →  us-east-1a
  10.0.12.0/24  →  us-east-1b
  10.0.13.0/24  →  us-east-1c

Isolated subnets (RDS, ElastiCache):
  10.0.21.0/24  →  us-east-1a
  10.0.22.0/24  →  us-east-1b
  10.0.23.0/24  →  us-east-1c

Which subnet type should you use?

When in doubt, default to private. Use isolated when a compliance requirement or risk model says outbound internet must be impossible. Only put a resource in a public subnet if it genuinely needs to accept inbound traffic from the internet.

Creating subnets with the AWS CLI

Notice that all three subnet types are created identically. The difference between public, private, and isolated is made by the route table you associate afterwards, not by anything in the create-subnet call itself.

# Create a public subnet in us-east-1a
aws ec2 create-subnet \
  --vpc-id vpc-0123456789abcdef0 \
  --cidr-block 10.0.1.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-1a},{Key=Type,Value=public}]'

# Enable auto-assign public IP (a resource-level convenience, not what makes it "public")
aws ec2 modify-subnet-attribute \
  --subnet-id subnet-0123456789abcdef0 \
  --map-public-ip-on-launch

# Create a private subnet
aws ec2 create-subnet \
  --vpc-id vpc-0123456789abcdef0 \
  --cidr-block 10.0.11.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=private-1a},{Key=Type,Value=private}]'

# Create an isolated subnet
aws ec2 create-subnet \
  --vpc-id vpc-0123456789abcdef0 \
  --cidr-block 10.0.21.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=isolated-1a},{Key=Type,Value=isolated}]'