Public and Private Subnets in an AWS VPC
This VPC pattern makes exposure decisions explicit. The load balancer and NAT gateway live in the public path, application compute accepts traffic only from the load balancer, and the database has no direct route from the internet.
Published August 18, 2026
Reference architecture
Architecture diagram
Open on the canvasAWS public and private subnet architecture diagram with an internet-facing load balancer, NAT Gateway, private application server, and private RDS database. The image links to a fully editable BuildPlane starter.
Overview
A compact VPC example that makes subnet responsibilities visible. Public subnets contain resources that must reach the internet directly, while application compute and relational data remain private.
Components
- Public Load Balancer: Receives internet traffic and forwards only approved application requests into the private tier.
- NAT Gateway: Lets private compute initiate outbound connections without accepting inbound internet sessions.
- Application Server: Runs application code in a private subnet and receives traffic only from the load balancer.
- RDS Database: Keeps relational data in a separate private subnet with no direct public path.
Network Flow
- Internet users connect to the public load balancer.
- The load balancer routes application traffic to the private application server.
- The application server reads and writes data in the private RDS database.
- When outbound access is needed, the application server routes through the NAT gateway.
Customize First
- Add matching subnets in a second Availability Zone for production availability.
- Replace broad security-group rules with the smallest required source-to-destination rules.
- Add VPC endpoints for AWS services that should not require NAT egress.
Design rationale
Decisions that shape this architecture
Public does not mean every resource is internet-accessible
A public subnet has a route to an internet gateway. Security groups, listener configuration, and public addressing still determine whether a resource can receive traffic.
Use the load balancer as the ingress boundary
The application server remains private and accepts only traffic from the load balancer security group. This removes direct public addressing from the compute tier.
Separate outbound access from inbound access
The NAT gateway lets private compute initiate internet connections without creating an inbound route to the application server.
Before production
Operational checks
Verify route tables independently for each public and private subnet.
Restrict security-group references to the next required tier.
Review NAT data-processing cost and use VPC endpoints where appropriate.
Add equivalent subnets in another Availability Zone for production availability.
Scope and tradeoffs
What this diagram does not solve
The starter shows one-AZ concepts clearly
A production web application should usually duplicate the relevant subnets and zonal compute across at least two Availability Zones.
Subnet placement is only one security layer
IAM, encryption, patching, flow logs, network controls, and application authorization remain necessary even when resources are private.
Common questions
Frequently asked questions
What makes an AWS subnet public?
A subnet is public when its route table has a route to an internet gateway. Individual resources also need suitable addressing and security rules to communicate with the internet.
Why is the database in a separate private subnet?
The separation prevents a direct internet path and lets the database accept connections only from the application tier on the required port.
Can private subnets access AWS services without NAT?
Yes. VPC gateway and interface endpoints can provide private access to supported AWS services and can reduce NAT traffic and exposure.
Keep exploring
Related AWS architectures
Highly Available Three-Tier Web Application on AWS
This starter architecture separates ingress, presentation, application logic, and relational data so each tier can fail and scale independently. It is a practical baseline for teams moving a conventional web application onto AWS without collapsing every responsibility into one server.
Explore the architecture
An AWS Application That Survives an Availability Zone Failure
This architecture focuses on one failure question: what happens when an entire Availability Zone becomes unavailable? Healthy application capacity remains in the other zone, the load balancer removes failed targets, and RDS can promote its synchronous standby.
Explore the architecture
Containerized Web Service with Amazon ECS and Fargate
This architecture runs a production container service without managing an EC2 host fleet. A protected global edge forwards to a Multi-AZ ALB, Fargate tasks stay private, and managed data, image, secret, and observability services support the runtime.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.