AWS Glossary
Amazon VPC
Amazon Virtual Private Cloud — logically isolated network within AWS where you control IP addressing, subnets, routing, and access controls.
AI & assistant-friendly summary
This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.
Summary
Amazon Virtual Private Cloud — logically isolated network within AWS where you control IP addressing, subnets, routing, and access controls.
Key Facts
- • Amazon Virtual Private Cloud — logically isolated network within AWS where you control IP addressing, subnets, routing, and access controls
- • Definition Amazon Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where you launch AWS resources in a virtual network that you define
- • Every AWS account gets a default VPC; production workloads should use custom VPCs with intentional network design
- • 0
- • 0/8`, `172
Entity Definitions
- Lambda
- Lambda is an AWS service relevant to amazon vpc.
- EC2
- EC2 is an AWS service relevant to amazon vpc.
- S3
- S3 is an AWS service relevant to amazon vpc.
- RDS
- RDS is an AWS service relevant to amazon vpc.
- DynamoDB
- DynamoDB is an AWS service relevant to amazon vpc.
- VPC
- VPC is an AWS service relevant to amazon vpc.
- ECS
- ECS is an AWS service relevant to amazon vpc.
- ElastiCache
- ElastiCache is an AWS service relevant to amazon vpc.
- compliance
- compliance is a cloud computing concept relevant to amazon vpc.
- HIPAA
- HIPAA is a cloud computing concept relevant to amazon vpc.
- PCI DSS
- PCI DSS is a cloud computing concept relevant to amazon vpc.
Related Content
- AWS ARCHITECTURE REVIEW — Related service
- AWS CLOUD SECURITY — Related service
Definition
Amazon Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where you launch AWS resources in a virtual network that you define. You have complete control over your network environment — IP address ranges, subnets, route tables, and network gateways. Every AWS account gets a default VPC; production workloads should use custom VPCs with intentional network design.
Core VPC Components
Subnets
- Subdivisions of your VPC’s IP address range, tied to a single Availability Zone
- Public subnets: Have a route to an Internet Gateway; resources can have public IPs
- Private subnets: No direct internet route; resources reach internet via NAT Gateway
- Best practice: place application servers and databases in private subnets; only load balancers in public subnets
Internet Gateway (IGW)
- Enables communication between VPC resources and the internet
- Attach one IGW per VPC; update route tables to route
0.0.0.0/0traffic to it
NAT Gateway
- Allows resources in private subnets to initiate outbound internet connections (software updates, API calls) without being reachable from the internet
- Managed service; deploy one per Availability Zone for high availability
- Charged per hour + per GB of data processed
Route Tables
- Control traffic routing within the VPC and to external destinations
- Each subnet must be associated with a route table
- Local route (
10.0.0.0/16 → local) always takes precedence
Security Groups
- Stateful firewall at the instance/ENI level
- Allow rules only (no explicit deny)
- Evaluate all rules before allowing/blocking traffic
- Changes take effect immediately
Network ACLs (NACLs)
- Stateless firewall at the subnet level
- Both allow and deny rules; rules evaluated in number order
- Require explicit rules for both inbound AND outbound (stateless)
- Use for broad subnet-level security boundaries
VPC Design Patterns
Standard 3-Tier Architecture:
Internet → Internet Gateway
→ Public Subnet (ALB, NAT Gateway)
→ Private Subnet - App Tier (EC2, ECS, Lambda)
→ Private Subnet - Data Tier (RDS, ElastiCache)Multi-AZ for High Availability:
- Deploy public and private subnets in each Availability Zone (minimum 2, preferably 3)
- Place NAT Gateways in each AZ — single NAT Gateway is a single point of failure
CIDR Planning:
- VPC CIDR cannot be changed after creation — plan for growth
- Use
/16for VPCs (65,536 IPs) to allow future subnet expansion - Use RFC 1918 private ranges:
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 - Reserve non-overlapping CIDRs across VPCs if you plan to peer them
VPC Endpoints
VPC Endpoints enable private connectivity to AWS services without internet traversal:
- Gateway Endpoints: S3 and DynamoDB (free, route table based)
- Interface Endpoints (PrivateLink): 100+ AWS services (hourly charge + per-GB)
Use VPC Endpoints to keep traffic between your VPC and AWS services on the AWS private network — required for some compliance frameworks (PCI DSS, HIPAA) that prohibit unencrypted internet transit.
Common Mistakes
Mistake 1: Using overlapping CIDR ranges across VPCs. If you later need to peer two VPCs, overlapping CIDRs make peering impossible. Plan CIDRs across accounts and regions upfront.
Mistake 2: Deploying NAT Gateway in only one AZ. A single NAT Gateway is a single point of failure. Deploy one per AZ for production-grade availability.
Mistake 3: Over-relying on security groups instead of network segmentation. Security groups control instance-level access, but subnet segmentation (placing databases in data-tier subnets with no internet route) provides defense in depth.
Related AWS Services
- AWS Transit Gateway: Hub-and-spoke connectivity between multiple VPCs and on-premises networks
- VPC Peering: Direct 1:1 connection between two VPCs (see VPC Peering vs Transit Gateway)
- AWS Direct Connect: Dedicated private network connection from on-premises to AWS
- AWS Network Firewall: Stateful, managed network firewall for VPC traffic inspection
Related FactualMinds Content
Need Help with This Topic?
Our AWS experts can help you implement and optimize these concepts for your organization.
