AWS VPC Explained: Complete Guide to Virtual Private Cloud in 2026

Every AWS workload lives inside a network. If you have not explicitly designed that network, you are using AWS's defaults — and the defaults are not designed for production security. Understanding AWS VPC is not optional knowledge for engineers who build on AWS. It is the foundational layer that everything else depends on: your EC2 instances, RDS databases, EKS clusters, Lambda functions, and AI inference endpoints all operate within network boundaries you control through your VPC configuration.

This guide covers everything you need to go from "I vaguely understand what a VPC is" to being able to architect a real production VPC — including the networking decisions that trip up most teams: NAT gateways, security group vs NACL confusion, data transfer costs, and private connectivity for AI/ML services like Bedrock and SageMaker.

What Is a VPC and Why It Exists

An AWS VPC (Virtual Private Cloud) is a logically isolated network you define within AWS — you set the CIDR range, create public and private subnets, configure route tables, and control all inbound and outbound traffic through security groups and NACLs. Every production workload should use a custom VPC; the default VPC puts databases on public-facing subnets by default. Think of it as your own private data center network that runs on AWS infrastructure and is configured entirely through software.

Before cloud computing, if you wanted to run a web server and a database server, you physically connected them with cables in a private rack. The database had no public internet connection. Only the web server was exposed, and only on specific ports. A VPC replicates this isolation model in cloud infrastructure.

When you create a VPC, you define a private IP address range using CIDR notation — for example, 10.0.0.0/16 gives you 65,536 private IP addresses. Every resource you launch in that VPC gets an IP address from this range. Resources in different VPCs cannot communicate with each other unless you explicitly allow it — and by default they cannot reach the public internet unless you configure that too.

VPC Core Components Explained

A VPC is composed of several interconnected resources. Understanding each one and how they interact is essential before you can read or design a real architecture diagram.

Subnets

VPC core components — subnets (IP ranges per AZ), route tables (traffic direction rules), internet gateways (public internet access), and NAT gateways (outbound-only for private subnets) — work together to create the public/private architecture that keeps databases and internal services off the internet. A subnet is a subdivision of your VPC's IP address range, scoped to a single Availability Zone. If your VPC is 10.0.0.0/16, you might create subnets like 10.0.1.0/24 (256 addresses) in us-east-1a and 10.0.2.0/24 in us-east-1b. Resources in the same subnet can communicate freely. Resources in different subnets communicate through the route table.

Route Tables

Every subnet is associated with a route table. A route table is a set of rules (routes) that determine where network traffic is directed. The default route (local) allows resources within the VPC to communicate with each other. Additional routes send traffic to internet gateways, NAT gateways, VPC peering connections, or VPN gateways.

What makes a subnet "public" or "private" is entirely determined by its route table — specifically whether a route to 0.0.0.0/0 (all traffic) points to an Internet Gateway.

Internet Gateway (IGW)

An Internet Gateway is an AWS-managed resource that you attach to a VPC to allow communication between resources in public subnets and the internet. It is horizontally scalable, redundant, and requires no bandwidth constraints or management from you. When a public subnet resource with a public IP sends traffic to the internet, the IGW handles the network address translation (NAT) between the private IP and the public IP.

NAT Gateway

Resources in private subnets have no public IPs and no route to the internet — which is by design. But they often need to reach the internet for legitimate reasons: downloading software updates, calling third-party APIs, pulling container images from Docker Hub. The NAT Gateway lives in a public subnet and allows private subnet resources to initiate outbound internet connections while blocking all inbound connections from the internet.

Elastic Network Interfaces (ENIs)

Every resource in a VPC communicates through an Elastic Network Interface — a virtual network card. EC2 instances, Lambda functions in a VPC, RDS instances, and EKS nodes all have ENIs that give them IP addresses, security group associations, and network connectivity. Understanding ENIs matters when you're troubleshooting connectivity or designing fine-grained security group rules.

Public vs Private Subnets: The Architecture Pattern

The standard production VPC uses three subnet tiers across two or more AZs: public subnets (load balancers, NAT gateways), private app subnets (EC2, EKS nodes), and private data subnets (RDS, ElastiCache, OpenSearch) — where each tier communicates only with adjacent tiers via security group rules and has no direct internet access. Public subnets contain resources that must be directly reachable from the internet; private subnets contain everything that should not be.

In this architecture, the load balancer accepts inbound traffic from the internet. App servers in private subnets receive traffic only from the load balancer's security group. Database servers in data subnets receive traffic only from the app servers' security group. Nothing in the private or data subnets can be reached directly from the internet — even if an attacker somehow got the private IP address.

Private subnet resources reach the internet (for outbound-only traffic) through the NAT Gateway in the public subnet. The route table for private subnets sends all internet-bound traffic (0.0.0.0/0) to the NAT Gateway rather than directly to the Internet Gateway.

Security Groups vs NACLs

Security groups are stateful firewalls attached to individual resources — allow inbound port 443 and return traffic is automatically permitted. NACLs are stateless subnet-level firewalls that require explicit allow rules in both directions, including ephemeral ports 1024–65535 for return traffic. Security groups handle almost all access control; NACLs are for subnet-level IP blocking and compliance defense-in-depth. Confusing the two is one of the most common sources of hard-to-debug connectivity issues in AWS.

Attribute	Security Groups	NACLs
Attached to	Individual resources (EC2, RDS, Lambda, ENI)	Subnets (applies to all resources in the subnet)
Stateful?	Yes — return traffic is automatically allowed	No — inbound and outbound rules evaluated independently
Rule types	Allow rules only (no explicit deny)	Allow and deny rules (evaluated in priority order)
Rule evaluation	All rules evaluated; most permissive wins	Rules evaluated in number order; first match wins
Primary use case	Primary access control for all resources	Subnet-level blocking (e.g., IP blocklists, defense-in-depth)
Default behavior	Deny all inbound; allow all outbound	Allow all inbound and outbound
Applies to	Traffic to/from the specific resource	All traffic entering/leaving the subnet

In practice, security groups do almost all the work in a well-designed VPC. You define security groups for each tier — a web-tier security group, an app-tier security group, a db-tier security group — and configure rules that allow traffic only from the appropriate source security group. NACLs are a secondary layer used for explicit IP blocking (denying a known bad IP range) or as an additional compliance control in regulated environments.

VPC Peering and Transit Gateway

Use VPC peering for direct private connectivity between 2–3 VPCs; use Transit Gateway when you have 4+ VPCs or need hub-and-spoke routing, on-premises VPN connectivity, or transitive routing (which peering cannot do). Transit Gateway costs $0.05/hour per VPC attachment but replaces N² peering connections with a single centralized route table. As AWS environments grow, teams inevitably end up with multiple VPCs that need to communicate.

VPC Peering

VPC peering creates a direct private network connection between two VPCs. Traffic between peered VPCs stays within the AWS network — it never touches the public internet. Peering works within a region, across regions (inter-region peering), and across AWS accounts.

The key limitation: VPC peering is non-transitive. If VPC-A peers with VPC-B, and VPC-B peers with VPC-C, traffic cannot flow from VPC-A to VPC-C through VPC-B. Each pair of VPCs that needs to communicate requires its own peering connection. At two or three VPCs this is manageable. At ten VPCs, you need up to 45 peering connections to achieve full mesh connectivity — which is when Transit Gateway becomes the right answer.

AWS Transit Gateway

Transit Gateway is a regional network hub that acts as a central router for multiple VPCs and on-premises networks. Instead of maintaining dozens of peering connections, each VPC connects to the Transit Gateway once. The Transit Gateway handles routing between them using route tables you configure.

Attribute	VPC Peering	Transit Gateway
Best for	2–3 VPCs with simple connectivity	4+ VPCs, hub-and-spoke, hybrid cloud
Transitive routing	No	Yes
Cross-account	Yes	Yes
Cross-region	Yes (inter-region peering)	Yes (TGW peering)
On-premises connectivity	No	Yes (VPN / Direct Connect)
Cost	$0.01–0.02/GB data transfer only	$0.05/hr/attachment + $0.02/GB
Management overhead	High at scale (N² peering connections)	Low (centralized route tables)

VPC Endpoints for Private AWS Service Access

S3 and DynamoDB Gateway Endpoints are free and route traffic from your VPC to those services over the AWS private network — there is no reason not to enable them in every production VPC. Interface Endpoints for services like Bedrock, SageMaker, and Secrets Manager cost $0.01/hour per AZ but eliminate NAT Gateway data charges and keep sensitive AI inference traffic entirely off the public internet. By default, when your EC2 instance calls the S3 API, that traffic routes over the public internet — even though both are AWS infrastructure — creating both a security concern and an unnecessary data transfer cost.

VPC endpoints solve this by creating a private connection between your VPC and AWS services that uses the AWS private network. Traffic never leaves AWS. There are two types:

Gateway Endpoints

Gateway endpoints are free and available only for S3 and DynamoDB. You add them to a route table, and traffic to those services automatically routes through the private endpoint instead of the internet. There is no reason not to use Gateway endpoints for S3 and DynamoDB in every production VPC.

Interface Endpoints (AWS PrivateLink)

Interface endpoints use AWS PrivateLink to create an Elastic Network Interface (ENI) in your subnet with a private IP address. Traffic to the target service routes to this ENI instead of the public endpoint. Interface endpoints are available for most AWS services — including SQS, SNS, Secrets Manager, CloudWatch, EC2 Systems Manager, Bedrock, and SageMaker.

Interface endpoints cost $0.01/hour per AZ plus $0.01/GB of data processed. For a service that processes significant traffic — particularly AI/ML pipelines that move large training datasets or inference outputs through S3 — the data transfer savings can far exceed the endpoint cost.

Common VPC Architectures

3-Tier Web Application

The most common production architecture. Traffic enters through an Application Load Balancer in the public subnet, routes to application servers (EC2, ECS, or EKS) in private app subnets, which query databases in isolated data subnets. Each tier communicates only with the adjacent tier via security group rules. This architecture is the baseline for most web applications and APIs deployed on AWS.

Microservices Architecture

Microservices architectures on AWS commonly use EKS (Kubernetes) with worker nodes in private subnets. The cluster API endpoint can be private-only (accessible only from within the VPC or peered networks), and inter-service communication happens within the cluster via Kubernetes service discovery. An API Gateway or Application Load Balancer in the public subnet is the single entry point for external traffic. This pattern is more complex to set up but provides fine-grained network isolation between services.

A critical consideration for EKS in private subnets: your nodes need to reach ECR to pull container images. Without VPC endpoints for ECR, all image pulls route through the NAT Gateway — and with large container images, this generates significant NAT Gateway data processing charges. ECR VPC endpoints eliminate this entirely.

VPC for AI/ML Workloads

For AI/ML workloads, always create a Bedrock Interface Endpoint (routes inference traffic privately), an S3 Gateway Endpoint (eliminates NAT charges for training data — a 500GB training job costs $22.50 in NAT data charges without it), and ECR Interface Endpoints for private container image pulls by EKS nodes. Training jobs move hundreds of gigabytes between S3 and GPU instances, and inference calls to Bedrock should not route over the public internet for regulated workloads.

Private Endpoints for Bedrock and SageMaker

AWS Bedrock and SageMaker both support VPC Interface endpoints. For workloads handling sensitive data — healthcare records, financial data, government-classified information — routing inference calls through a private endpoint is often a compliance requirement, not just a best practice. With a Bedrock Interface endpoint, your application sends prompts and receives completions entirely within the AWS private network.

High-Bandwidth Training Architecture

SageMaker training jobs that use large datasets benefit significantly from an S3 Gateway endpoint. Without it, training data flowing from S3 to GPU instances passes through NAT Gateway, generating substantial data processing charges at $0.045/GB. A training job that reads 500 GB of data costs $22.50 in NAT Gateway charges alone — on top of the GPU instance cost. The S3 Gateway endpoint is free and routes that traffic privately, eliminating the charge entirely.

For large-scale distributed training across multiple instances, place all training instances in the same Availability Zone when possible. Cross-AZ data transfer within a VPC costs $0.01/GB in each direction. For a distributed training job moving significant data between nodes across AZs, this cost compounds quickly.

AWS AI Service	Endpoint Type	Key Benefit
Amazon Bedrock	Interface (PrivateLink)	Private inference calls, compliance for regulated data
SageMaker API	Interface (PrivateLink)	Private endpoint management, job creation
SageMaker Runtime	Interface (PrivateLink)	Private inference against deployed endpoints
S3 (training data)	Gateway (free)	Eliminates NAT Gateway data charges for training I/O
ECR (container images)	Interface (PrivateLink)	Private image pulls for custom training containers

AWS Networking Costs That Surprise Teams

The five AWS networking costs that consistently surprise teams in production: NAT Gateway at $0.045/hour plus $0.045/GB data processed ($32–65/month before any traffic), cross-AZ transfer at $0.01/GB per direction, data egress to the internet at $0.09/GB, Interface Endpoint fees at $0.01/hour per AZ, and VPC Flow Logs ingestion into CloudWatch at $0.50/GB (route to S3 instead — 80% cheaper). The free tier hides these during development; production traffic reveals them all at once.

The Cost Buckets Teams Miss

• NAT Gateway hourly charge: $0.045/hour per gateway = $32.40/month minimum, before any data processing. Multi-AZ deployments (correct for HA) run $64.80+/month in NAT Gateway fees before a single byte of traffic flows.
• NAT Gateway data processing: $0.045/GB processed in both directions. A service that pulls 1 TB/month through NAT for software updates or Docker image pulls adds $46 in data processing charges.
• Cross-AZ data transfer: $0.01/GB in each direction. For microservices deployed across multiple AZs that communicate frequently, this compounds. A Kubernetes service making 1 TB of cross-AZ calls per month pays $10 in transfer charges — which sounds small but multiplied across dozens of services it becomes significant.
• VPC Interface endpoint hourly charge: $0.01/hour per AZ = $7.20/month per AZ per endpoint. A VPC with 10 Interface endpoints in 2 AZs pays $144/month in endpoint fees — but often saves more than that in NAT Gateway data processing charges.
• Data transfer out to internet: $0.09/GB for the first 10 TB. Any API response, file download, or media delivery that exits AWS costs this. CloudFront reduces this significantly for public-facing content.
• VPC Flow Logs: Flow logs are invaluable for security monitoring and debugging, but if you send them to CloudWatch Logs, you pay per GB of ingestion and storage. For a busy VPC, this can be $50–200/month. Consider sending Flow Logs to S3 instead, which costs roughly 80% less.

Security Best Practices for Production VPCs

Production VPC security follows defense-in-depth: custom VPC (never default), three-tier subnet architecture, databases with no internet route and app-tier-only security group access, NAT Gateway for private outbound traffic, free S3/DynamoDB Gateway Endpoints, VPC Flow Logs to S3, and AWS Systems Manager replacing bastion hosts entirely. The following practices separate production-grade VPCs from environments that merely pass a basic security review.

1. Never Put Databases in Public Subnets

This sounds obvious, but the default VPC has no private subnets — which means teams who launch RDS in the default VPC without customization end up with publicly-reachable database endpoints. The only reason a database should ever be in a public subnet is if it was accidentally placed there. Data subnets should have no route to the internet gateway, no route to the NAT gateway, and security groups that accept connections only from the application tier's security group.

2. Use IAM Policies Alongside Security Groups

Security groups control network-layer access. IAM policies control API-level access. For AWS services like S3, DynamoDB, Secrets Manager, and Bedrock, a VPC endpoint policy can restrict which principals can use the endpoint and which resources they can access — adding a second layer of control beyond security groups.

3. Enable VPC Flow Logs

VPC Flow Logs capture metadata about accepted and rejected network connections in your VPC. They do not capture packet content — just the 5-tuple (source IP, destination IP, source port, destination port, protocol) plus action (ACCEPT or REJECT) and bytes transferred. This is essential for security incident investigation, unexpected traffic pattern detection, and verifying that security group rules are actually blocking what you think they are.

4. Eliminate Bastion Hosts with AWS Systems Manager

Bastion hosts — EC2 instances in the public subnet used as a jump point for SSH access to private subnet instances — are an operational burden and an attack surface. AWS Systems Manager Session Manager provides browser-based and CLI shell access to EC2 instances without any inbound security group rules, no public IP, and no SSH keys to manage. Fully audit-logged. Requires SSM VPC endpoints in private subnets (or NAT Gateway access).

5. Restrict Outbound Traffic from Private Subnets

Most teams configure inbound security group rules carefully but leave outbound rules as "allow all." For truly defense-in-depth security, restrict outbound traffic from sensitive subnets to only the required destinations: specific ports to specific security groups. An RDS instance should never need to initiate outbound connections to anything. An application server should only need outbound to specific downstream services. Locking down outbound rules limits the damage from a compromised instance.

The bottom line: A production AWS VPC requires a custom three-tier subnet architecture (public, private-app, private-data) across two AZs, security groups as the primary access control layer, a NAT Gateway for private subnet outbound traffic, free Gateway Endpoints for S3 and DynamoDB, and VPC Flow Logs for security visibility. Get the networking right at the start — retrofitting VPC architecture into a running production system is one of the most painful migrations in cloud infrastructure.

Frequently Asked Questions

What is an AWS VPC and why do I need one?

An AWS VPC (Virtual Private Cloud) is a logically isolated section of the AWS cloud where you launch resources in a network you define. Every AWS account gets a default VPC, but production workloads should use a custom VPC so you control the IP address ranges, subnet topology, routing, and security rules. Without a properly designed VPC, your databases and internal services may be reachable from the public internet by default. A custom VPC with public and private subnets, proper route tables, and security groups is the foundational security layer every production AWS environment requires.

What is the difference between a security group and a NACL in AWS?

Security groups are stateful firewalls attached to individual AWS resources (EC2 instances, RDS databases, Lambda functions, etc.). If you allow inbound traffic on port 443, the return traffic is automatically allowed — you do not need a separate outbound rule. NACLs (Network Access Control Lists) are stateless firewalls attached to subnets. They evaluate inbound and outbound traffic independently, which means you must explicitly configure both directions including ephemeral return ports (1024–65535). Security groups handle almost all access control in typical architectures. NACLs are a secondary layer used for explicit IP blocking and defense-in-depth compliance requirements.

What is VPC peering vs Transit Gateway, and when do I use each?

VPC peering creates a direct private network connection between two VPCs. It is simple and cost-effective for connecting two or three VPCs. The limitation is that peering is non-transitive — VPC A cannot reach VPC C by routing through a peered VPC B. AWS Transit Gateway solves this by acting as a central hub that routes traffic between many VPCs and on-premises networks. If you have four or more VPCs that need to communicate, or you are connecting VPCs to an on-premises environment via VPN or Direct Connect, Transit Gateway is almost always the right choice despite its higher per-attachment cost.

How do VPC endpoints save money and improve security for AWS services?

By default, when your EC2 instance or Lambda calls an AWS service like S3, Bedrock, or SageMaker, that traffic routes over the public internet — even though both are in AWS. This means you pay NAT Gateway data processing charges ($0.045/GB) plus the risk of public internet exposure. VPC endpoints route that traffic through the AWS private network instead. S3 and DynamoDB Gateway endpoints are completely free — there is no reason not to enable them in every VPC. Interface endpoints for services like Secrets Manager, ECR, SageMaker, and Bedrock cost $0.01/hour per AZ but eliminate NAT Gateway charges and keep sensitive traffic entirely within the AWS network — a compliance requirement for many regulated industries.

Sources: AWS Documentation, Gartner Cloud Strategy, CNCF Annual Survey