Chapter 36: AWS Subnet and Access

AWS Subnets and AWS Access (which almost always means how traffic is allowed or blocked — i.e., Security Groups + Network ACLs + NAT + Internet Gateway + VPC Endpoints).

These two topics together decide:

  • Whether your EC2 instance / ECS task / RDS database is publicly reachable from the internet or completely private
  • Whether your app can reach the internet (for updates, API calls)
  • Whether hackers can reach your database
  • How much you pay for data transfer
  • Whether your app survives when one Availability Zone has a power cut

Let me explain it like we’re sitting together looking at a big map of Hyderabad city — slow, clear, with everyday analogies, real startup examples from Hyderabad, and exactly how to think about subnets and access in 2026.

1. What is an AWS Subnet? (The Most Important Building Block)

A subnet is a logical subdivision of your VPC’s IP address range — a smaller chunk of IP addresses that you place inside one specific Availability Zone.

  • Every subnet lives inside exactly one AZ (you cannot stretch one subnet across multiple AZs)
  • Subnets have a CIDR block (e.g., 10.0.1.0/24 → 256 IP addresses)
  • The two main types:
Type Can reach public internet directly? Typical resources placed here Real Hyderabad analogy
Public Subnet Yes (needs Internet Gateway + route) ALB nodes, NAT Gateway, bastion/jump hosts, public-facing EC2 Main road with direct gate to the highway
Private Subnet No (no direct route to IGW) Application servers (ECS/Fargate), RDS, Redis, internal Lambda Internal lanes inside gated society — safe, no direct highway access

Key rule everyone must memorize:

A subnet is public only if it has a route to an Internet Gateway in its route table. If no route to IGW → it is private (even if you give instances public IPs — they won’t work without the route).

2. How Subnets & Access Control Work Together (The Traffic Police)

Even if a subnet is public, nothing is reachable unless you explicitly allow it.

There are three main layers that control access:

Layer What it controls Stateful or Stateless? Attached to… Example Rule (common in Hyderabad apps)
Security Groups Allow/deny traffic to/from individual resources Stateful (return traffic auto-allowed) EC2, ECS tasks, RDS, Lambda, etc. Allow TCP 443 from 0.0.0.0/0 (HTTPS)
Network ACLs (NACLs) Allow/deny traffic at subnet level Stateless (must allow both directions) Subnet Allow inbound 80/443, outbound ephemeral ports
Route Tables Decide where traffic goes (internet, other subnets, VPC peering) Subnet 0.0.0.0/0 → Internet Gateway (public subnet only)

Golden rule in 2026 (memorize this):

Security Groups = allow what you want NACLs = deny what you don’t want (rarely needed if Security Groups are tight) Route Tables = decide if subnet can reach internet at all

3. Real Hyderabad Example – Food Delivery App Networking

Your startup’s Swiggy-like app in Gachibowli:

VPC design (very common production pattern):

text

Access & connectivity rules:

  • ALB lives in public subnets (a, b, c) → receives user traffic on 443 (HTTPS)
  • ECS Fargate tasks (orders-service, payment-service) live in private subnets → Security Group allows inbound only from ALB (port 3000)
  • RDS PostgreSQL in private subnets → Multi-AZ, Security Group allows inbound only from ECS Security Group (port 5432)
  • NAT Gateway in public subnet a → private subnets use it to reach internet (yum update, call external APIs)
  • VPC Endpoint for S3 & DynamoDB → private subnets reach S3/DynamoDB without NAT/internet → zero data transfer cost, more secure
  • No public IP on any private resource → impossible to SSH or attack directly

What happens during traffic:

User in Uppal → hits https://app.com → Route 53 → CloudFront (Hyderabad Edge) → ALB (public subnets) → ALB → ECS tasks (private subnets) → ECS → RDS (private) or DynamoDB (via VPC endpoint) → ECS → external payment gateway (via NAT Gateway)

If AZ-a fails (power cut in that data center): → ALB stops sending traffic to AZ-a → RDS fails over to standby in AZ-b → App stays up (users don’t notice)

4. Quick Hands-On – See Subnets & Access in Console

  1. VPC console → Your VPCs → pick your VPC
  2. Subnets → see which are public (route table has 0.0.0.0/0 → igw-xxxx) vs private
  3. Route Tables → click one → see routes (public = igw, private = nat or local only)
  4. Security Groups → see inbound rules (HTTP/HTTPS allowed?)
  5. Launch EC2 in private subnet → try curl google.com → fails (no NAT/internet route)

Summary Table – AWS Subnets & Access Cheat Sheet (2026)

Question Answer (Beginner-Friendly)
What is a subnet? Smaller IP range inside one AZ of your VPC
Public vs Private subnet? Public = has route to Internet Gateway; Private = no direct internet
How to allow internet from private? NAT Gateway / NAT Instance in public subnet
How to allow S3/DynamoDB privately? VPC Endpoint (Gateway or Interface type)
Main access control tools? Security Groups (resource level), NACLs (subnet level)
Best practice for production? Multi-AZ VPC + public subnets (ALB/NAT) + private subnets (app/DB) + VPC Endpoints

Teacher’s final note: Subnets decide “where” your resources live inside the VPC. Access rules decide “who can talk to them”. Put databases and workers in private subnets + tight Security Groups + VPC Endpoints = secure, low-cost, highly available app. Put everything in one public subnet with wide-open Security Groups = hacker paradise + surprise bills.

Got it? This is the “make sure your app is safe and fast” lesson.

Next?

  • Step-by-step: Build secure multi-AZ VPC with public/private subnets + NAT + endpoints?
  • Deep dive on Security Groups vs NACLs (when to use both)?
  • Or how to calculate data transfer costs in different designs?

Tell me — next whiteboard ready! 🚀🔒

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *