Skip to main content
In this lesson you’ll learn how public and private subnets differ, how to decide which subnet to use, and how to architect a simple web application across both in an AWS VPC. By the end you’ll know when to place resources in public vs private subnets and which controls (routing, NAT, security groups) enforce those boundaries. Decision rule:
  • Ask: should devices on the internet be able to directly reach the resources in this subnet?
    • If yes → make the subnet public.
    • If no → make the subnet private.
Public subnets host resources that must be reachable from the internet (for example, web servers or load balancers). Private subnets host resources that should not be directly reachable (for example, databases, caches, or backend services). Control access using route tables, NAT gateways/instances, security groups, and network ACLs.

​
Example: simple web application (public + private)

Consider a typical web application:
  • The web server serves users on the internet → belongs in a public subnet (has route to an Internet Gateway and usually a public IP or sits behind a public ELB).
  • The database should not be exposed to the internet → belongs in a private subnet (no direct route to the Internet Gateway; only accessible from the web server or other allowed resources).
A cloud network diagram showing a default VPC with an Availability Zone containing a public subnet hosting a web server (connected to the Internet) and a private subnet hosting a database. The graphic illustrates separation of public-facing and private resources.
How traffic flows:
  • Internet → (Internet Gateway) → public subnet → web server.
  • Web server (in public subnet) → private subnet → database (over private IPs).
  • Private subnet typically has no route to the Internet Gateway; outbound internet access (if required for updates, package downloads, etc.) is proxied through a NAT Gateway or NAT instance in a public subnet.
Example security and routing controls (AWS CLI examples):
  • Allow the web server security group to connect to the database port:
  • Create a route for a public subnet to an Internet Gateway:
  • Create a route for a private subnet to a NAT Gateway for controlled outbound access:

​
Extending an on-premises network into AWS

When you extend a private data center into AWS (via VPN or Direct Connect), you commonly place those workload servers in private subnets because they are accessed from your private network rather than the public internet.
A diagram titled "Private Subnet – Use Case" showing a private data center connected via a VPN to a private subnet inside an AWS VPC. The private subnet contains multiple compute instances represented by chip icons.
Typical pattern:
  • On-premises network ↔ VPN/Direct Connect ↔ VPC private subnets
  • No Internet Gateway route in the private subnet’s route table (internet access can still be provided via NAT if needed)
  • Security groups and route tables restrict exposure to only the required internal sources
Do not expose databases, admin panels, or sensitive management interfaces directly in public subnets. Always restrict access via security groups and consider bastion hosts (jump boxes) or VPN access for administrative access.

​
Quick reference: public vs private subnet

​
Best practices & checklist

  • Place internet-facing services in public subnets (or behind public load balancers).
  • Place databases and sensitive services in private subnets.
  • Use security groups to allow only the minimum required traffic (e.g., allow DB port only from the web server SG).
  • Use NAT Gateways in public subnets to provide controlled outbound internet access for private subnets.
  • Use VPN or Direct Connect for private connectivity from on-premises datacenters.
  • Consider VPC endpoints for AWS service access from private subnets without using the internet.
In summary:
  • Public subnets host resources that must be reachable from the internet (they have a route to an Internet Gateway and usually public IP addresses).
  • Private subnets host resources that should not be directly reachable from the internet (they lack a direct route to an Internet Gateway and typically use private IP addresses and NAT for outbound access).

Watch Video

Practice Lab