Let’s start with a simple, precise definition.

The Simple Definition

Amazon VPC (Virtual Private Cloud) is a logically isolated section of the AWS cloud where you can launch resources — like servers, databases, and load balancers — inside a network that you define and fully control. It is “virtual” because it isn’t a physical, separate data center; it’s a software-defined network carved out of AWS’s shared infrastructure just for you.

Why “Isolated” Matters

Even though thousands of customers share the same underlying AWS hardware, each VPC is logically separated so that traffic and resources inside one customer’s VPC are invisible and unreachable from another customer’s VPC unless a deliberate connection is configured.

To appreciate why VPC exists, picture what cloud computing would look like without it.

A Shared, Chaotic Cloud Without Boundaries

AWS runs enormous shared data centers used by millions of customers simultaneously. Without some way to divide and isolate network traffic, one company’s servers could potentially see or interfere with another company’s servers — a serious security nightmare.

The Need for Controlled Exposure

Not every resource should be reachable from the internet. A public website needs to be open to visitors, but the database behind it should never be directly reachable by the outside world. Without a proper network design, it becomes very difficult to enforce this kind of separation safely.

A handful of vocabulary words form the foundation for everything else in this guide.

Let’s walk through the building blocks that together form a complete VPC design.

The VPC Itself

Every VPC is created with a primary IPv4 CIDR block, defining the total pool of private IP addresses available to everything inside it. A VPC always exists within a single AWS Region, but its subnets can spread across multiple Availability Zones within that region.

Subnets: Public vs Private

A public subnet is one whose route table sends internet-bound traffic to an Internet Gateway, making resources inside it reachable from (and able to reach) the public internet. A private subnet has no such route, keeping its resources hidden from direct internet access.

Internet Gateway

An Internet Gateway is a horizontally scaled, highly available AWS-managed component that connects your VPC to the public internet. Only one can be attached to a VPC at a time, and it must be explicitly referenced in a route table to have any effect.

NAT Gateway

A NAT (Network Address Translation) Gateway lives inside a public subnet and allows resources in a private subnet to initiate outbound connections to the internet (for example, downloading software updates) without allowing unsolicited inbound connections from the internet.

graph TD
    Internet((Internet)) --- IGW[Internet Gateway]
    IGW --- PubSub[Public Subnet]
    PubSub --- NAT[NAT Gateway]
    NAT --- PrivSub[Private Subnet]
    PubSub --- WebServer[Web Server]
    PrivSub --- DB[(Database Server)]
        

Route Tables

Each subnet is associated with a route table that defines where network traffic is sent based on its destination address. A public subnet’s route table typically routes internet-bound traffic (0.0.0.0/0) to the Internet Gateway; a private subnet’s route table typically sends it to a NAT Gateway instead.

Here is what really happens when a request travels from the internet to your application and back.

sequenceDiagram
    participant User as User
    participant IGW as Internet Gateway
    participant Web as Web Server (Public Subnet)
    participant DB as Database (Private Subnet)
    User->>IGW: HTTPS Request
    IGW->>Web: Route via Route Table
    Web->>DB: Internal Query
    DB-->>Web: Return Data
    Web-->>User: HTTPS Response
        

VPC provides several layered tools for controlling exactly what traffic is allowed to move where.

Security Groups: Stateful Firewalls

Security groups act as a virtual firewall at the resource level (such as one attached to a single server). They are “stateful,” meaning if you allow inbound traffic from a certain source, the matching outbound response is automatically allowed too, without needing a separate rule.

Network ACLs: Stateless Firewalls

Network ACLs operate at the subnet level and are “stateless,” meaning inbound and outbound rules must both be explicitly defined, since allowing traffic in one direction does not automatically allow the response in the other direction.

Private Subnets and Least Exposure

A core security principle in VPC design is placing anything that does not need direct internet access — like databases and internal services — into private subnets, drastically reducing the attack surface available to outside attackers.

A well-designed VPC helps applications survive failures gracefully rather than going down entirely.

Spreading Subnets Across Multiple Availability Zones

By creating subnets in at least two different Availability Zones and deploying duplicate resources across them, a failure in one data center does not take down your entire application.

graph TD
    VPC[VPC: 10.0.0.0/16] --> AZ1[Availability Zone A]
    VPC --> AZ2[Availability Zone B]
    AZ1 --> PubA[Public Subnet A]
    AZ1 --> PrivA[Private Subnet A]
    AZ2 --> PubB[Public Subnet B]
    AZ2 --> PrivB[Private Subnet B]
        

Redundant Internet Gateways and NAT Gateways

The Internet Gateway is inherently highly available and does not require redundancy planning. NAT Gateways, however, are created per Availability Zone, so best practice is to deploy one NAT Gateway in each AZ to avoid a single point of failure for outbound private traffic.

Understanding what is actually happening on your network is essential for both security and troubleshooting.

VPC Flow Logs

VPC Flow Logs capture information about the IP traffic going to and from network interfaces in your VPC, including source, destination, port, and whether the traffic was accepted or rejected. These logs can be sent to Amazon CloudWatch Logs or Amazon S3 for analysis.

Certain VPC layouts have become standard best practice, while other habits create ongoing risk.

Practical guidance that helps beginners avoid the most common VPC pitfalls.

VPC concepts appear everywhere, even if end users never see them directly.

No. Every AWS account comes with a default VPC in each region that works for simple experiments, but production applications typically use a custom VPC designed around specific security and networking needs.

A public subnet’s route table sends internet-bound traffic to an Internet Gateway, making its resources reachable from the internet. A private subnet has no such route, keeping its resources hidden from direct internet access.

Private resources often still need to reach the internet for things like software updates, which is handled safely through a NAT Gateway that allows outbound connections without allowing unsolicited inbound ones.

Yes, through VPC Peering for simple point-to-point connections, or through AWS Transit Gateway when connecting many VPCs together in a more scalable, centralized way.

A security group is a stateful firewall attached to individual resources, while a Network ACL is a stateless firewall applied at the subnet level, requiring both inbound and outbound rules to be explicitly defined.

Common options include a Site-to-Site VPN connection over the public internet, or AWS Direct Connect for a dedicated, private network link between your data center and AWS.

Amazon VPC is the invisible foundation underneath almost everything you build on AWS. By giving you full control over IP address ranges, subnets, routing, and firewalls, VPC lets you design a network that is exactly as open or as locked-down as your application needs. Getting comfortable with public and private subnets, Internet and NAT Gateways, route tables, and layered security controls is one of the most valuable foundational skills for working confidently and safely in the AWS cloud.