Subnets

Learn AWS subnets as AZ-scoped network segments for public, private, and isolated workload placement.

Last reviewed: June 2026

·AWS CloudAWS CLI v2AWS SDKsAWS Well-Architected Framework
✅
Quick Understanding: Subnets helps teams design, build, secure, operate, and troubleshoot AWS workloads. In enterprise projects, the important questions are ownership, blast radius, automation, observability, compliance, and cost.

🔍 What Is It?

A subnet is a range of IP addresses inside a VPC. Each subnet exists in exactly one Availability Zone.

Subnets are usually categorized by routing behavior: public, private, or isolated.

🎯 Why Do We Need It?

Subnets let architects place resources based on exposure and failure domain.

Load balancers may live in public subnets, applications in private subnets, and databases in isolated private subnets.

Common developer mistakes:

  • →Choosing defaults without checking security, cost, or failure behavior
  • →Treating AWS services as isolated tools instead of part of an architecture
  • →Skipping tags, alarms, IAM review, backups, and runbooks until production incidents happen
  • →Building manually in the console and then struggling to reproduce environments

🏗️ What Happens in Real Projects?

A production VPC might create the same subnet tiers in three AZs:

  • →public-a, public-b, public-c
  • →app-a, app-b, app-c
  • →data-a, data-b, data-c

This allows multi-AZ application and database deployments with consistent routing.

⚙️ How It Works

A subnet inherits the VPC CIDR boundary but has its own CIDR slice. Its route table determines whether it is public or private.

A public subnet has a route to an internet gateway and resources can use public IPs. A private subnet usually routes outbound internet through NAT. An isolated subnet has no internet route.

💻 Example

Subnet tiering model — A practical subnet plan for a three-tier app.

text
public-a  10.20.0.0/24  -> internet gateway
public-b  10.20.1.0/24  -> internet gateway
app-a     10.20.10.0/24 -> NAT gateway
app-b     10.20.11.0/24 -> NAT gateway
data-a    10.20.20.0/24 -> no internet route
data-b    10.20.21.0/24 -> no internet route

🤔 Common Confusions

❓ What makes a subnet public?

Its route table has a route to an internet gateway and resources have public IP behavior.

❓ Can one subnet span multiple AZs?

No. A subnet belongs to one AZ only.

❓ Should databases be in public subnets?

Almost never. Databases should usually be in private or isolated data subnets.

🚨 Common Production Issues

**Subnets too small** block Auto Scaling and managed service placement.

**Database in public subnet** creates unnecessary exposure.

**Only one AZ subnet tier** prevents high availability.

**Inconsistent route tables** make one AZ behave differently from another.

✅ Best Practices

Create matching subnet tiers across multiple AZs

Leave enough IP capacity for scaling and managed service overhead

Use public subnets only for resources that must receive public traffic

Place app and data tiers in private subnets

Name subnets clearly by tier and AZ

Review subnet routes before deploying sensitive resources

🏛️ Architect's Note

Senior Architect's Perspective

Subnets are placement decisions. They express which systems can be reached, how they fail by AZ, and how much future scale the network can support.

💬 Frequently Asked Questions

Interview: How would you explain Subnets in a real AWS project?

Subnets should be explained through the business workload it supports, the AWS responsibility boundary, the failure modes, the security controls, and how it is monitored and automated.

Interview: What production mistake do developers commonly make with Subnets?

The common mistake is using the service successfully in a lab but not designing for least privilege, multi-AZ resilience, alarms, cost visibility, and repeatable infrastructure.

Can a subnet route table be changed later?

Yes, but changing routes can immediately affect traffic. Production changes should be planned and tested.

How large should subnets be?

Large enough for peak scale, deployment surge, managed service reservations, and future growth. Avoid tiny production subnets.

🎯 Key Takeaways

1Subnets are AZ-scoped
2Route tables decide public/private behavior
3Subnet tiers support clean architecture boundaries
4IP capacity planning prevents scaling failures

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these AWS references to verify the concept in official docs and continue into the most relevant SplashRide pages.