AWS VPC Explained in Simple Terms

Summary:

• AWS VPC acts as your private, isolated network within the AWS cloud, giving you complete control over IP addressing, subnets, routing, and security boundaries.
• Core components like subnets, route tables, internet gateways, and NAT gateways work together to define how traffic flows between your resources and the outside world.
• Security in a VPC operates at two levels: security groups provide stateful instance-level protection, while network ACLs offer stateless subnet-level filtering.
• Connectivity options range from VPC peering for simple two-network links to Transit Gateway for hub-and-spoke architectures and PrivateLink for secure service access without public internet exposure.
• Understanding cost drivers like NAT gateway data processing fees, VPC endpoint pricing, and IPv4 address charges helps you architect cost-effective solutions in 2026.

Imagine moving into a massive apartment complex where every tenant shares the same hallways, elevators, and front door. Now imagine you could instead build your own private wing with dedicated entrances, custom security checkpoints, and complete control over who visits which rooms. That is precisely what Amazon Virtual Private Cloud delivers within the sprawling infrastructure of AWS. Whether you are deploying a simple web application or architecting a multi-region enterprise platform, understanding AWS VPC fundamentals separates engineers who merely use cloud services from those who truly command them.

The following illustration shows how a VPC creates an isolated network boundary within the broader AWS cloud infrastructure, with distinct public and private subnets spanning multiple Availability Zones.

What is AWS VPC and why it matters

AWS VPC, or Amazon Virtual Private Cloud, is a logically isolated virtual network that you define within the AWS cloud. Think of it as your own private data center floor within a shared building, except you never worry about physical hardware, cooling systems, or rack space. You control the IP address ranges, create subnets, configure route tables, and establish security rules. Every resource you launch, from EC2 instances to RDS databases, lives inside a VPC and inherits its network configuration.

The significance of VPC extends beyond simple isolation. It provides the foundational layer for implementing defense-in-depth security strategies, meeting compliance requirements, and designing architectures that can scale from prototype to production without network redesign. AWS operates a global backbone with an availability SLA of 99.99% for critical VPC components like NAT Gateways and PrivateLink. This means your VPC traffic travels across one of the most reliable networks ever built. As of 2026, each AWS account supports up to 5 VPCs per region by default, with the ability to request increases up to 100 VPCs when your architecture demands it.

Core components that power your VPC

Building a functional VPC requires understanding how its fundamental components interact. Each piece serves a specific purpose, and misconfiguring any single element can leave your resources unreachable or, worse, exposed to unintended traffic. Consider the following components as the building blocks of your private cloud network.

Subnets and availability zone placement

Subnets divide your VPC’s IP address range into smaller segments, each residing in a single Availability Zone. A public subnet has a route to an internet gateway, allowing resources with public IP addresses to communicate directly with the internet. A private subnet lacks this route, forcing outbound traffic through a NAT gateway or keeping resources entirely internal. This separation forms the basis of secure architecture patterns where web servers face the public internet while databases remain hidden.

When planning subnet sizes, remember that AWS reserves five IP addresses in each subnet for internal purposes. These are the network address, the VPC router, DNS server, future use, and broadcast address. A /24 subnet provides 251 usable addresses, not 256. For production workloads, most architects create at least two subnets per tier (public and private) across two or more Availability Zones to ensure high availability.

Route tables and traffic direction

Every subnet associates with exactly one route table, though a single route table can serve multiple subnets. Route tables contain rules that determine where network traffic travels based on destination IP addresses. The most specific matching route wins. A custom VPC includes a main route table with a local route enabling communication between all subnets, but you must explicitly add routes for internet access, VPN connections, or peering relationships (unlike a default VPC, which includes a pre-configured route to an internet gateway).

Internet gateway versus NAT gateway

An internet gateway (IGW) enables bidirectional communication between your VPC and the public internet. It performs network address translation for instances with public IPv4 addresses and serves as the target in route tables for internet-bound traffic. You attach exactly one IGW per VPC, and it scales automatically without bandwidth constraints.

NAT gateways solve a different problem. They allow private subnet resources to initiate outbound connections while blocking unsolicited inbound traffic. Common use cases include software updates, API calls to external services, and accessing AWS services without public endpoints. NAT gateways are managed services that AWS operates in a specific Availability Zone, so production architectures typically deploy one per AZ for resilience.

The critical distinction between these components:

• Internet gateway: Enables public-facing resources to receive inbound connections from the internet
• NAT gateway: Enables private resources to reach the internet without accepting inbound connections
• NAT instance: A self-managed EC2 instance performing NAT, offering more control but requiring maintenance

The following diagram illustrates how traffic flows differently through internet gateways and NAT gateways depending on subnet type.

Addressing and connectivity options

After establishing core components, architects must decide how to address resources and connect VPCs to each other, to on-premises networks, and to AWS services. These decisions have long-term implications for scalability, security, and operational complexity.

CIDR blocks and IP addressing

When creating a VPC, you specify a primary IPv4 CIDR block between /16 (65,536 addresses) and /28 (16 addresses). AWS recommends using RFC 1918 private ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. You can associate up to five secondary IPv4 CIDR blocks with a single VPC, enabling expansion without recreating your network. IPv6 adoption continues growing, and AWS assigns a /56 IPv6 CIDR block from Amazon’s pool when you enable dual-stack networking.

Connecting VPCs together

As organizations grow, workloads often span multiple VPCs for isolation, compliance, or organizational boundaries. AWS provides three primary connectivity patterns, each with distinct trade-offs. The table below compares these options across key dimensions that influence architectural decisions.

VPC peering creates a direct network route between two VPCs, but connections are non-transitive. If VPC A peers with VPC B and VPC B peers with VPC C, traffic cannot flow from A to C through B. Transit Gateway solves this limitation by acting as a regional network hub, enabling any-to-any connectivity among attached VPCs and on-premises networks. PrivateLink takes a fundamentally different approach by exposing specific services through private endpoints without merging network address spaces.

Hybrid connectivity with on-premises networks

Enterprises rarely operate exclusively in the cloud. Connecting AWS VPC to on-premises data centers requires either AWS Site-to-Site VPN or AWS Direct Connect. VPN establishes encrypted tunnels over the public internet, offering quick setup and lower cost but variable latency. Direct Connect provides dedicated physical connections through AWS partner facilities, delivering consistent performance and reduced data transfer costs for high-volume workloads.

Security controls at the network layer

Network security in AWS VPC operates through complementary mechanisms that filter traffic at different levels. Understanding when to use each control, and how they interact, is essential for both passing technical interviews and building production systems.

Security groups as stateful firewalls

Security groups act as virtual firewalls attached to elastic network interfaces (ENIs). They evaluate rules based on protocol, port, and source or destination. Critically, they are stateful. When you allow inbound traffic on port 443, the return traffic automatically flows back without an explicit outbound rule. Security groups default to denying all inbound traffic and allowing all outbound traffic. You can reference other security groups as sources, enabling patterns like “allow traffic only from the web tier security group.”

Network ACLs as stateless boundaries

Network Access Control Lists operate at the subnet level and evaluate traffic in both directions independently. Unlike security groups, NACLs are stateless. This means you must explicitly allow both inbound and outbound traffic for a connection to succeed. NACLs process rules in numerical order, and the first matching rule applies. This makes rule ordering critical. Most architects use NACLs as a coarse-grained backup control while relying on security groups for primary traffic filtering.

The key differences between these controls:

1. Scope: Security groups attach to ENIs. NACLs attach to subnets.
2. State: Security groups track connection state. NACLs evaluate each packet independently.
3. Default behavior: Security groups deny all inbound by default. Default NACLs allow all traffic.
4. Rule evaluation: Security groups evaluate all rules. NACLs stop at first match.

Cost optimization and best practices

VPC itself incurs no direct charges, but the components you deploy within it can generate significant costs. Understanding these cost drivers helps architects make informed decisions during design phases rather than discovering surprises in monthly bills.

NAT gateway and endpoint pricing

NAT gateways charge both an hourly rate and a per-gigabyte data processing fee. As of 2026, US East (N. Virginia) pricing runs approximately $0.045 per hour plus $0.045 per GB processed. For workloads transferring terabytes monthly, these costs accumulate quickly.

VPC endpoints offer an alternative for accessing AWS services privately. Gateway endpoints for S3 and DynamoDB remain free, while interface endpoints charge hourly rates around $0.01 per AZ plus $0.01 per GB processed.

The following table summarizes 2026 pricing across selected regions for common VPC components:

Default VPC versus custom VPC

Every AWS account includes a default VPC in each region with pre-configured subnets, an internet gateway, and permissive security settings. While convenient for experimentation, default VPCs rarely suit production requirements. Custom VPCs allow you to define CIDR blocks that align with your IP addressing strategy, create subnet structures matching your security tiers, and implement least-privilege network controls from the start.

The visual resource map feature, which became generally available in late 2024, provides an interactive topology view of your VPC components directly in the AWS Console. This tool helps architects understand complex configurations and identify misconfigurations without manually tracing route tables and security group relationships.

Recent features and future direction

AWS continuously enhances VPC capabilities to address evolving architectural patterns. Two recent additions deserve particular attention for their impact on how engineers design modern cloud networks.

VPC Lattice for application networking

Launched in 2023 and significantly expanded through 2025, Amazon VPC Lattice provides application-layer networking that abstracts away traditional network configuration. Instead of managing IP addresses, route tables, and security groups for service-to-service communication, Lattice lets you define services and access policies at a higher level. Traffic routing, load balancing, and authentication happen automatically based on service definitions rather than network topology.

VPC Lattice particularly benefits microservices architectures where dozens or hundreds of services need to communicate across VPCs and accounts. Rather than establishing peering connections or Transit Gateway attachments, services register with Lattice and discover each other through service networks. This approach reduces operational complexity while maintaining fine-grained access control.

Enhanced flow logs and observability

VPC Flow Logs have evolved from basic traffic metadata capture to comprehensive network observability. Recent enhancements include additional fields for identifying traffic paths through Transit Gateways and NAT gateways, sublocation data for pinpointing traffic sources within Availability Zones, and organization-wide enablement that streamlines configurations automatically across multiple AWS accounts. These improvements support real-time security monitoring and faster troubleshooting of connectivity issues.

Looking ahead, AWS continues investing in simplifying multi-account networking through AWS Organizations integration, expanding IPv6 capabilities, and reducing the operational burden of managing complex network topologies. Engineers who master current VPC fundamentals position themselves to adopt these enhancements as they emerge.

Conclusion

AWS VPC serves as the foundational networking layer for virtually every cloud deployment, providing the isolation, security controls, and connectivity options that modern architectures demand. Mastering its core components, from subnets and route tables to security groups and gateways, enables you to design systems that are secure by default and scalable by design. The distinction between stateful security groups and stateless NACLs, the trade-offs between VPC peering and Transit Gateway, and the cost implications of NAT gateways versus VPC endpoints represent the kind of nuanced understanding that separates competent engineers from exceptional ones.

As AWS continues expanding VPC capabilities through services like VPC Lattice and enhanced observability features, the fundamental concepts covered here remain stable anchors. Whether you are preparing for a technical interview, designing your first production VPC, or optimizing an existing multi-account architecture, investing time in understanding these networking primitives pays dividends across your entire cloud journey. Start with clear IP addressing plans, implement defense-in-depth security, and choose connectivity patterns that match your actual requirements rather than over-engineering for hypothetical scale.