Overview
An Amazon Virtual Private Cloud (VPC) is an isolated virtual network that enables you to launch AWS resources in a logically isolated environment. A properly designed VPC architecture follows security best practices by segregating resources into public and private subnets, controlling traffic flow, and providing secure internet connectivity.
VPC Components
A well-architected VPC consists of the following key components:
1. Subnets
Subnets are subdivisions of your VPC’s IP address range. There are two types:
- Public Subnets – Have a route to an Internet Gateway, allowing resources to communicate directly with the internet. Typically used for internet-facing load balancers, NAT Gateways, and bastion hosts. (Web/app servers are commonly placed in private subnets behind a public load balancer.)
- Private Subnets – Do not have direct internet access. Used for web/application servers, databases, and other backend resources that should not be directly accessible from the internet.
2. Route Tables
Route tables control traffic routing within your VPC. Each subnet must be associated with a route table, which determines where network traffic is directed. Public subnets route internet traffic (0.0.0.0/0) to an Internet Gateway, while private subnets route internet traffic to a NAT Gateway.
3. Internet Gateway (IGW)
An Internet Gateway is a horizontally scaled, redundant, and highly available VPC component that provides two-way communication between resources in your VPC and the internet. Resources in public subnets with public IP addresses can communicate directly with the internet through the IGW. For IPv4, instances must also have a public IP address or Elastic IP (EIP) and permissive Security Group and Network ACL rules to reach the internet.
4. NAT Gateway
A Network Address Translation (NAT) Gateway enables resources in private subnets to access the internet for outbound connections (such as software updates) while preventing inbound internet-initiated connections. Important: The NAT Gateway itself must be deployed in a public subnet and is assigned an Elastic IP address.
5. VPC Endpoints
VPC Endpoints enable private connectivity to AWS services without requiring an Internet Gateway or NAT Gateway. There are two types:
- Gateway Endpoints – Available only for Amazon S3 and DynamoDB. These are added as targets in your route table.
- Interface Endpoints (AWS PrivateLink) – Available for most other AWS services. These create elastic network interfaces (ENIs) in your subnet and require Security Group configuration.
VPC Endpoints keep AWS service traffic within the AWS network and improve security. Note that endpoints only provide connectivity to AWS services—you still need a NAT Gateway (or other egress solution) for accessing general internet destinations like third-party APIs or software repositories.
Best Practices Architecture
The following architecture demonstrates AWS VPC best practices with proper network segmentation and secure internet connectivity:
Architecture Diagram
VPC Configuration:
- CIDR Block: 10.0.0.0/16
- Public Subnet: 10.0.1.0/24
- Private Subnet: 10.0.2.0/24
| Component | Location | Resources |
|---|---|---|
| Public Subnet | 10.0.1.0/24 |
• Internet-facing Load Balancers (ALB/NLB) • NAT Gateway • Bastion Hosts (or SSM Session Manager) |
| Private Subnet | 10.0.2.0/24 |
• Web/Application Servers • Databases • Backend APIs |
| Internet Gateway | VPC-level | Enables public subnet resources to access the internet |
| NAT Gateway | Public Subnet | Provides outbound internet access for private subnet resources |
Route Table Configuration
Proper route table configuration is critical for controlling traffic flow:
Public Subnet Route Table
| Destination | Target | Description |
|---|---|---|
10.0.0.0/16 |
local |
Internal VPC traffic |
0.0.0.0/0 |
igw-xxxxxxxxx |
Internet traffic via IGW |
Private Subnet Route Table
| Destination | Target | Description |
|---|---|---|
10.0.0.0/16 |
local |
Internal VPC traffic |
0.0.0.0/0 |
nat-xxxxxxxxx |
Outbound internet via NAT Gateway |
Security Best Practices
- Network Segmentation – Always separate public-facing resources from internal resources using different subnets.
- Security Groups – Configure security groups to allow only necessary traffic. Use the principle of least privilege.
- Network ACLs – Implement Network Access Control Lists as an additional layer of security at the subnet level.
- NAT Gateway Placement – Deploy NAT Gateways in public subnets. For high availability, deploy one NAT Gateway per Availability Zone.
- VPC Flow Logs – Enable VPC Flow Logs to capture information about IP traffic for security analysis and troubleshooting.
- Bastion Hosts – If using bastion hosts for SSH/RDP access, consider AWS Systems Manager Session Manager instead, which doesn’t require opening inbound ports or managing bastion infrastructure.
- VPC Endpoints – Use VPC endpoints to access AWS services privately without traversing the internet.
Resource Placement Guidelines
Public Subnet Resources
- Internet-facing Application Load Balancers (ALB) or Network Load Balancers (NLB)
- NAT Gateways (for private subnet outbound access)
- Bastion hosts or jump boxes (if required; consider AWS Systems Manager Session Manager instead)
Private Subnet Resources
- Web servers and application servers (typically behind a load balancer in the public subnet)
- Backend APIs and microservices
- Databases (RDS, ElastiCache, etc.)
- Internal Load Balancers (for multi-tier architectures)
- Any resource that should not be directly accessible from the internet
High Availability Considerations
For production environments, implement the following high availability measures:
- Multi-AZ Deployment – Deploy resources across multiple Availability Zones (AZs) with subnets in each AZ.
- Multiple NAT Gateways – Deploy one NAT Gateway per AZ. If a NAT Gateway or its AZ fails, resources in other AZs can continue operating.
- Load Balancing – Use Application Load Balancers or Network Load Balancers across multiple AZs for redundancy.
- Database Replication – Configure database multi-AZ deployments or read replicas for resilience.
Common Architecture Mistakes to Avoid
- Incorrect NAT Gateway Placement – NAT Gateways must be placed in public subnets, not private subnets or at the VPC level.
- Missing Route Table Associations – Every subnet is always associated with exactly one route table. If you don’t explicitly associate a subnet with a custom route table, it will automatically use the VPC’s main route table. Always verify which route table each subnet is using.
- Overly Permissive Security Groups – Avoid using 0.0.0.0/0 for inbound rules unless absolutely necessary (e.g., for public load balancers).
- Single Point of Failure – Deploying a single NAT Gateway creates a single point of failure. Use one per AZ for production.
- Exposing Databases to the Internet – Databases should always be in private subnets with no direct internet access.
- Not Using VPC Endpoints – Traffic to AWS services can incur NAT Gateway charges. Use VPC endpoints for cost savings and security.
Conclusion
A well-designed VPC architecture is fundamental to building secure and scalable applications on AWS. By properly segregating resources into public and private subnets, correctly configuring route tables, and deploying NAT Gateways in the appropriate locations, you create a robust network foundation that follows AWS best practices and enhances the security posture of your infrastructure.