Amazon VPC

Definition

Amazon Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where you launch resources in a virtual network you define. You control IP ranges (CIDR blocks), subnets per Availability Zone, route tables, internet and NAT gateways, security groups, network ACLs, and VPC endpoints. Every AWS account ships with a default VPC; production workloads should use purpose-built VPCs with explicit tier segmentation — public subnets for load balancers only, private subnets for compute, and isolated data-tier subnets for databases.

When to use it

• Any production AWS workload that needs network isolation, predictable IP addressing, or compliance-driven segmentation (PCI cardholder environments, HIPAA workloads).
• Hybrid connectivity when you will attach VPN, Direct Connect, Transit Gateway, or VPC peering to on-premises or other VPCs.
• Private AWS service access via VPC endpoints (Gateway endpoints for S3/DynamoDB; Interface endpoints for most other services) to keep traffic off the public internet.
• Multi-AZ high availability by spreading subnets across at least two Availability Zones with per-AZ NAT Gateways.

When not to use it

• Default VPC for production — the account default VPC is convenient for experiments but lacks intentional CIDR planning, tier separation, and endpoint strategy.
• Overlapping CIDRs when peering is planned — VPC CIDR blocks cannot overlap with peered VPCs; you cannot change a VPC CIDR after creation without adding secondary CIDRs (with constraints).
• Single NAT Gateway in multi-AZ production — one NAT Gateway creates an AZ single point of failure and cross-AZ data charges for private subnets in other AZs.

Tips

• Plan VPC CIDR as /16 or larger with room for growth; carve subnets with non-overlapping ranges if multi-VPC peering or TGW attachment is on the roadmap.
• Place application tiers in private subnets; only ALBs/NLBs and NAT Gateways belong in public subnets.
• Use security groups (stateful) for instance-level rules and NACLs (stateless) only when you need explicit subnet-level deny rules.
• Enable VPC Flow Logs on production VPCs before an incident — you cannot retroactively capture dropped packets.
• Prefer Gateway endpoints for S3 and DynamoDB (no hourly charge); use Interface endpoints when compliance requires private access to other AWS APIs.

Gotchas

Serious

• Overlapping CIDR blocks across VPCs make peering and some TGW routes impossible until you redesign — the most expensive VPC mistake is planning CIDRs after the fact.
• 0.0.0.0/0 routes to an Internet Gateway on data-tier subnets expose databases and internal services; route tables are the first place to check after a breach.
• Security group references across VPCs require peering/TGW routes and reciprocal SG rules — opening a port in one SG does nothing if return traffic cannot route.

Regular

• Confusing NACL statelessness with security group statefulness — NACL changes require inbound and outbound rules for the same flow; missing outbound rules cause intermittent failures that look like application bugs.
• Forgetting DNS hostnames/resolution when using VPC endpoints or PrivateLink — enable both on the VPC or custom DNS resolution breaks.
• Assuming the default VPC is deleted when you create a custom one — stale default VPC resources linger and confuse auditors.

Official references

• What is Amazon VPC?
• VPC subnets
• Security groups
• VPC endpoints

Related FactualMinds content

• AWS Architecture Review
• AWS Cloud Security Services
• VPC networking best practices for production
• VPC Peering vs Transit Gateway