paulpas VPC (Virtual Private Cloud)
Design and configure isolated cloud networks with subnets, route tables, security groups, and advanced networking features for secure, scalable infrastructure.
TL;DR Checklist
- Use multiple availability zones for high availability
- Separate public and private subnets by function
- Use NAT gateways for private subnet egress (not NAT instances)
- Configure security groups as stateful firewalls
- Use network ACLs for stateless, subnet-level filtering
- Enable VPC Flow Logs for network traffic analysis
- Configure route tables with specific routes (no overly broad routes)
- Use VPC endpoints for private AWS service access
- Enable DNS hostnames and DNS resolution
- Plan IP address space with non-overlapping CIDRs
When to Use
Use VPC when:
- Isolating resources within a custom network
- Building production infrastructure requiring network control
- Implementing network segmentation and security boundaries
- Creating hybrid architectures with on-premises networks
- Building multi-tier applications with different security zones
When NOT to Use
Avoid VPC complexity when:
- Building simple proof-of-concepts
- Requiring no network customization (default VPC acceptable)
- Running fully serverless architectures (less relevant for Lambda)
Purpose and Use Cases
Primary Purpose: Provide isolated, customizable network environments with granular control over IP addressing, routing, and access control.
Common Use Cases:
- Production Application Tiers — Web, app, database layers in separate subnets
- Hybrid Cloud — VPN/Direct Connect to on-premises networks
- Multi-Tenancy — Isolated VPCs per tenant with VPC peering
- Disaster Recovery — Secondary VPC in different region with failover
- Development/Testing — Separate non-production VPCs with minimal cost
Architecture Design Patterns
Pattern 1: Three-Tier Production VPC with High Availability
AWSTemplateFormatVersion: '2010-09-09'
Resources:
# VPC
ProductionVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsHostnames: true
EnableDnsSupport: true
Tags:
- Key: Name
Value: production-vpc
# Internet Gateway
InternetGateway:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: prod-igw
AttachGateway:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref ProductionVPC
InternetGatewayId: !Ref InternetGateway
# Public Subnets (for ALB and NAT)
PublicSubnetAZ1:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref ProductionVPC
CidrBlock: 10.0.1.0/24
AvailabilityZone: us-east-1a
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: public-subnet-az1
PublicSubnetAZ2:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref ProductionVPC
CidrBlock: 10.0.2.0/24
AvailabilityZone: us-east-1b
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: public-subnet-az2
PublicSubnetAZ3:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref ProductionVPC
CidrBlock: 10.0.3.0/24
AvailabilityZone: us-east-1c
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: public-subnet-az3
# Private Subnets (for application servers)
PrivateSubnetAZ1:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref ProductionVPC
CidrBlock: 10.0.11.0/24
AvailabilityZone: us-east-1a
Tags:
- Key: Name
Value: private-subnet-az1
- Key: Type
Value: Application
PrivateSubnetAZ2:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref ProductionVPC
CidrBlock: 10.0.12.0/24
AvailabilityZone: us-east-1b
Tags:
- Key: Name
Value: private-subnet-az2
- Key: Type
Value: Application
PrivateSubnetAZ3:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref ProductionVPC
CidrBlock: 10.0.13.0/24
AvailabilityZone: us-east-1c
Tags:
- Key: Name
Value: private-subnet-az3
- Key: Type
Value: Application
# Database Subnets (for RDS)
DBSubnetAZ1:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref ProductionVPC
CidrBlock: 10.0.21.0/24
AvailabilityZone: us-east-1a
Tags:
- Key: Name
Value: db-subnet-az1
- Key: Type
Value: Database
DBSubnetAZ2:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref ProductionVPC
CidrBlock: 10.0.22.0/24
AvailabilityZone: us-east-1b
Tags:
- Key: Name
Value: db-subnet-az2
- Key: Type
Value: Database
# NAT Gateway (High Availability - one per AZ)
NATGatewayEIP1:
Type: AWS::EC2::EIP
DependsOn: AttachGateway
Properties:
Domain: vpc
Tags:
- Key: Name
Value: nat-eip-az1
NATGateway1:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt NATGatewayEIP1.AllocationId
SubnetId: !Ref PublicSubnetAZ1
Tags:
- Key: Name
Value: nat-gateway-az1
NATGatewayEIP2:
Type: AWS::EC2::EIP
DependsOn: AttachGateway
Properties:
Domain: vpc
Tags:
- Key: Name
Value: nat-eip-az2
NATGateway2:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt NATGatewayEIP2.AllocationId
SubnetId: !Ref PublicSubnetAZ2
Tags:
- Key: Name
Value: nat-gateway-az2
NATGatewayEIP3:
Type: AWS::EC2::EIP
DependsOn: AttachGateway
Properties:
Domain: vpc
Tags:
- Key: Name
Value: nat-eip-az3
NATGateway3:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt NATGatewayEIP3.AllocationId
SubnetId: !Ref PublicSubnetAZ3
Tags:
- Key: Name
Value: nat-gateway-az3
# Route Tables
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref ProductionVPC
Tags:
- Key: Name
Value: public-rt
PublicRoute:
Type: AWS::EC2::Route
DependsOn: AttachGateway
Properties:
RouteTableId: !Ref PublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref InternetGateway
# Associate public subnets with public route table
AssocPublicSubnetAZ1:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnetAZ1
RouteTableId: !Ref PublicRouteTable
AssocPublicSubnetAZ2:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnetAZ2
RouteTableId: !Ref PublicRouteTable
AssocPublicSubnetAZ3:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnetAZ3
RouteTableId: !Ref PublicRouteTable
# Private Route Tables (one per AZ for NAT)
PrivateRouteTableAZ1:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref ProductionVPC
Tags:
- Key: Name
Value: private-rt-az1
PrivateRouteAZ1:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref PrivateRouteTableAZ1
DestinationCidrBlock: 0.0.0.0/0
NatGatewayId: !Ref NATGateway1
AssocPrivateSubnetAZ1:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PrivateSubnetAZ1
RouteTableId: !Ref PrivateRouteTableAZ1
# Similar for AZ2 and AZ3...
# VPC Flow Logs
VPCFlowLogRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: vpc-flow-logs.amazonaws.com
Action: sts:AssumeRole
Policies:
- PolicyName: CloudWatchLogPolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- logs:CreateLogGroup
- logs:CreateLogStream
- logs:PutLogEvents
- logs:DescribeLogGroups
- logs:DescribeLogStreams
Resource: '*'
VPCFlowLogGroup:
Type: AWS::Logs::LogGroup
Properties:
LogGroupName: /aws/vpc/flowlogs
RetentionInDays: 30
VPCFlowLog:
Type: AWS::EC2::FlowLog
Properties:
ResourceType: VPC
ResourceId: !Ref ProductionVPC
TrafficType: ALL
LogDestinationType: cloud-watch-logs
LogGroupName: !Ref VPCFlowLogGroup
DeliverLogsPermissionIAM: !GetAtt VPCFlowLogRole.Arn
Tags:
- Key: Name
Value: prod-vpc-flowlog
Key Elements:
- Multi-AZ subnets for high availability
- Public subnets for ALB and NAT gateways
- Private subnets for application servers
- Database subnets for RDS
- NAT gateway per AZ for egress (not single point of failure)
- Public/private route tables with appropriate routes
- VPC Flow Logs for network traffic analysis
Pattern 2: Security Groups and Network ACLs
Resources:
# Security Group for ALB
ALBSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: alb-sg
GroupDescription: Security group for Application Load Balancer
VpcId: !Ref ProductionVPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
Description: HTTP from internet
- IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0
Description: HTTPS from internet
SecurityGroupEgress:
- IpProtocol: -1
CidrIp: 0.0.0.0/0
Description: Allow all outbound
Tags:
- Key: Name
Value: alb-sg
# Security Group for Application Tier
AppSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: app-sg
GroupDescription: Security group for application servers
VpcId: !Ref ProductionVPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 8080
ToPort: 8080
SourceSecurityGroupId: !Ref ALBSecurityGroup
Description: App traffic from ALB
- IpProtocol: tcp
FromPort: 22
ToPort: 22
SourceSecurityGroupId: !Ref BastionSecurityGroup
Description: SSH from bastion
SecurityGroupEgress:
- IpProtocol: -1
CidrIp: 0.0.0.0/0
Description: Allow all outbound
Tags:
- Key: Name
Value: app-sg
# Security Group for Database
DBSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: db-sg
GroupDescription: Security group for database servers
VpcId: !Ref ProductionVPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 5432
ToPort: 5432
SourceSecurityGroupId: !Ref AppSecurityGroup
Description: PostgreSQL from app tier
SecurityGroupEgress:
- IpProtocol: -1
CidrIp: 0.0.0.0/0
Description: Allow all outbound
Tags:
- Key: Name
Value: db-sg
# Network ACL for Database Subnets
DBNetworkAcl:
Type: AWS::EC2::NetworkAcl
Properties:
VpcId: !Ref ProductionVPC
Tags:
- Key: Name
Value: db-nacl
# Inbound Rule: PostgreSQL from App Tier
DBIngressPostgreSQL:
Type: AWS::EC2::NetworkAclEntry
Properties:
NetworkAclId: !Ref DBNetworkAcl
RuleNumber: 100
Protocol: 6 # TCP
RuleAction: allow
CidrBlock: 10.0.11.0/24 # App subnet AZ1
PortRange:
FromPort: 5432
ToPort: 5432
# Inbound Rule: Ephemeral ports for return traffic
DBIngressEphemeral:
Type: AWS::EC2::NetworkAclEntry
Properties:
NetworkAclId: !Ref DBNetworkAcl
RuleNumber: 120
Protocol: 6 # TCP
RuleAction: allow
CidrBlock: 0.0.0.0/0
PortRange:
FromPort: 1024
ToPort: 65535
# Outbound Rule: Allow all
DBEgress:
Type: AWS::EC2::NetworkAclEntry
Properties:
NetworkAclId: !Ref DBNetworkAcl
RuleNumber: 100
Protocol: -1 # All
Egress: true
RuleAction: allow
CidrBlock: 0.0.0.0/0
Key Elements:
- Security groups as stateful firewalls
- Reference-based ingress rules (security group ID, not CIDR)
- Network ACLs for stateless filtering
- Principle of least privilege for all rules
- Clear descriptions for auditing
Pattern 3: VPC Endpoints for Private AWS Service Access
Resources:
# S3 Gateway Endpoint (free)
S3Endpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref ProductionVPC
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3'
RouteTableIds:
- !Ref PrivateRouteTableAZ1
- !Ref PrivateRouteTableAZ2
- !Ref PrivateRouteTableAZ3
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal: '*'
Action:
- s3:GetObject
- s3:PutObject
Resource: arn:aws:s3:::app-bucket/*
# DynamoDB Gateway Endpoint
DynamoDBEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref ProductionVPC
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.dynamodb'
RouteTableIds:
- !Ref PrivateRouteTableAZ1
- !Ref PrivateRouteTableAZ2
- !Ref PrivateRouteTableAZ3
# Secrets Manager Interface Endpoint
SecretsManagerEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref ProductionVPC
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.secretsmanager'
VpcEndpointType: Interface
SubnetIds:
- !Ref PrivateSubnetAZ1
- !Ref PrivateSubnetAZ2
- !Ref PrivateSubnetAZ3
SecurityGroupIds:
- !Ref EndpointSecurityGroup
PrivateDnsEnabled: true
# Security Group for Interface Endpoints
EndpointSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Security group for VPC endpoints
VpcId: !Ref ProductionVPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 10.0.0.0/16 # VPC CIDR
Description: HTTPS from VPC
Key Elements:
- S3/DynamoDB gateway endpoints (no charges)
- Interface endpoints for other services
- Private DNS enabled for seamless access
- Subnet and security group configuration
Integration Approaches
1. Integration with Route 53
VPC + Route 53 provides:
- Private hosted zones for internal DNS
- DNS resolution for VPC resources
- Health checks for failover
2. Integration with Direct Connect
VPC + Direct Connect enables:
- Dedicated network connection to on-premises
- Low-latency, high-bandwidth hybrid connectivity
- Consistent network performance
3. Integration with VPN
VPC + VPN provides:
- Encrypted site-to-site connectivity
- Remote access VPN for employees
- Cost-effective alternative to Direct Connect
4. Integration with VPC Peering
Multi-VPC connectivity:
- Non-transitive peering between VPCs
- Cross-account and cross-region peering
- Private connectivity between VPCs
Common Pitfalls
❌ Pitfall 1: Overlapping CIDR Blocks
Problem: Overlapping subnets prevent routing between VPCs or on-premises networks.
Solution:
- Plan IP address space upfront
- Use tools like ipcalc to prevent overlap
- Document CIDR allocation per VPC
- Use VPC CIDR 10.x.0.0/8 range for planning space
❌ Pitfall 2: Single NAT Gateway
Problem: NAT gateway in single AZ becomes bottleneck; AZ failure affects all private subnets.
Solution:
- Deploy NAT gateway per AZ
- Route each private subnet to local AZ NAT
- Distributes bandwidth; no single point of failure
❌ Pitfall 3: Overly Permissive Security Groups
Problem: Allow all traffic violates least-privilege; increases blast radius.
Solution:
- Restrict ingress to required ports/sources
- Use security group references instead of CIDR blocks
- Regularly audit rules
- Deny by default
❌ Pitfall 4: No VPC Flow Logs
Problem: Network issues hard to troubleshoot; no traffic visibility.
Solution:
- Enable VPC Flow Logs to CloudWatch
- Analyze traffic patterns and anomalies
- Integrate with CloudWatch Insights for queries
- Monitor rejected connections
❌ Pitfall 5: Bastion Host Too Permissive
Problem: SSH to EC2 instances allowed from anywhere.
Solution:
- Require bastion host for SSH access
- Restrict bastion ingress to known IPs
- Use Systems Manager Session Manager (no SSH needed)
- Log all bastion access
❌ Pitfall 6: Not Using VPC Endpoints
Problem: Private subnets route all traffic through NAT gateway; adds cost and latency.
Solution:
- Use S3/DynamoDB gateway endpoints (no charge)
- Interface endpoints for Secrets Manager, KMS, etc.
- Reduces NAT gateway traffic and costs
Best Practices Summary
| Category | Best Practice |
|---|---|
| Architecture | Multi-AZ subnets; separate public/private/database layers |
| NAT | One NAT gateway per AZ; no single point of failure |
| Security | Least-privilege security groups; use reference-based rules |
| Monitoring | Enable VPC Flow Logs; analyze traffic patterns |
| Endpoints | Use gateway endpoints for S3/DynamoDB; interface for others |
| DNS | Use private hosted zones for internal DNS |
Related Skills
| Skill | Purpose |
|---|---|
cncf-aws-ec2 |
Deploy instances within VPC subnets |
cncf-aws-rds |
Database subnets and security groups |
cncf-aws-elb |
Load balancers integrated with VPC |
cncf-aws-iam |
Network-level access controls |
cncf-aws-cloudformation |
Infrastructure as code for VPC |
Core Workflow
Assess Requirements — Understand the use case, scale, integration needs, and existing infrastructure. Checkpoint: Document requirements, constraints, and success criteria.
Design Architecture — Plan component interactions, data flow, and deployment strategy using cloud-native best practices. Checkpoint: Verify the architecture addresses all requirements and follows CNCF conventions.
Implement & Configure — Create manifests, configurations, and deployment scripts. Include resource limits, health checks, and observability hooks. Checkpoint: Validate all YAML against schema and test in a staging environment.
Deploy & Monitor — Apply manifests to the cluster, verify component health, and confirm observability is working. Checkpoint: Confirm all pods/services are running, probes passing, and metrics/alerts configured.
Constraints
MUST DO
- Include at least one complete working YAML manifest example
- Note when content is auto-generated vs. manually verified
- Reference relevant CNCF project documentation
MUST NOT DO
- Deploy manifests without testing in a staging environment first
- Use deprecated API versions (e.g., apps/v1beta1)
- Omit resource limits and requests in Kubernetes manifests
Live References
Authoritative documentation links for this skill's domain. The model follows markdown links at load time to resolve external references and inline content.