What is VPC in AWS? Plain English Explanation

VPC stands for Virtual Private Cloud, and the name is actually fairly descriptive once you unpack it: it's your own private, isolated section of the AWS network, where you control what can talk to what.

A useful VPC design does four things: allocates address space that will not create avoidable conflicts, separates workloads by exposure and responsibility, provides only the required traffic paths, and produces enough logs and ownership information to troubleshoot those paths.

Think of it like a building

Imagine AWS as a huge shared office building. A VPC is like renting your own floor — you decide where the walls go (subnets), who can walk through which doors (security groups and network ACLs), and which rooms can be seen from the street (public vs. private subnets). Without a VPC, you'd effectively be working in an open-plan space with everyone else, which nobody actually wants for anything beyond the most trivial project — which is why AWS gives every account a default VPC automatically.

Public and private subnets

Within a VPC, you divide space into subnets. A public subnet has a route to the internet — this is where your web servers or load balancers typically live, since they need to be reachable. A private subnet has no direct internet route — this is where you'd put a database, since there's no legitimate reason for it to be directly reachable from the public internet.

Why this matters in practice

A common and avoidable security issue is a database sitting in a public subnet with a security group that's more permissive than it should be. Structuring your VPC properly — database in a private subnet, web server in a public one, with tightly scoped security groups controlling what can talk to what — closes off an entire category of exposure before it becomes a problem.

Route tables and gateways

A route table determines where traffic from a subnet is allowed to go. An Internet Gateway connects a VPC to the public internet (this is what makes a subnet "public"). A NAT Gateway allows resources in a private subnet to reach the internet for outbound requests (like downloading updates) without being directly reachable from the internet themselves.

Route tables establish reachability; they do not replace authorization. Security groups control permitted traffic at attached resources, while network ACLs provide stateless controls at the subnet boundary. Use the simplest rule set that expresses the required path and can be reviewed by an operator.

What actually makes a subnet public?

Component	What it does	What it does not do
Route table	Selects the next hop for destination traffic	Does not authorize an application request
Internet gateway	Provides a route target between a VPC and the internet	Does not automatically make every resource public
Public IP	Gives IPv4 internet addressing to a resource	Does not override security-group rules
NAT gateway	Allows initiated outbound IPv4 connections from private subnets	Does not accept unsolicited inbound internet connections
Security group	Permits specified traffic to and from attached resources	Does not define whether a subnet is public

AWS defines a public subnet by its route to an internet gateway. A resource still needs suitable addressing and security rules to communicate. A private subnet can use NAT for outbound IPv4 access while preventing unsolicited inbound connections.

A practical production layout

A common two-Availability Zone web architecture uses:

1. Public subnets for an internet-facing load balancer and regional egress components where required.
2. Private application subnets for EC2 instances or container tasks.
3. Isolated or private data subnets for RDS and caches.
4. Separate route tables where traffic requirements differ.
5. Security-group references between tiers instead of broad CIDR rules where supported.

This is a pattern, not a requirement. A small single-server workload may not justify every component. A highly regulated or hybrid environment may require inspection, centralized egress, multiple accounts or dedicated connectivity.

Plan address space before connecting networks

Choose a private CIDR range large enough for expected subnets and growth, but check for overlap with office networks, customer environments, other VPCs and future VPN or transit connections. Overlapping ranges make routing and connectivity substantially harder.

Leave room for additional Availability Zones and environments. Renumbering live workloads later is more disruptive than reserving a sensible address plan early.

Understand the cost-bearing components

Creating a VPC, subnet, route table, internet gateway or security group does not by itself create an hourly charge. Components commonly added to the design can:

• NAT Gateways charge for time and processed data.
• Interface VPC endpoints charge per endpoint-hour and data processed.
• Transit Gateway charges for attachments and data processing.
• Traffic across Availability Zones can incur transfer charges.
• Network Firewall, load balancers, public IPv4 addresses and detailed logs have their own pricing dimensions.

Do not add one NAT Gateway per Availability Zone without understanding the availability requirement and traffic volume, but do not centralize egress blindly if it creates a failure dependency or cross-zone processing cost. Model both architecture and failure behaviour.

Visibility and troubleshooting

VPC Flow Logs record metadata about accepted and rejected IP traffic at supported interfaces, subnets or VPCs. They do not capture application payloads, and their delivery and aggregation timing should be understood before relying on them during an incident.

Combine flow evidence with load-balancer logs, operating-system logs, application traces and route configuration. When a connection fails, verify DNS resolution, the route in both directions, security groups, network ACLs, the listening service and any intermediate inspection or NAT component.

Common design mistakes

• Using an overlapping CIDR that later prevents private connectivity
• Placing a database in a public subnet when no public path is required
• Opening administrative ports to the entire internet
• Assuming a private subnet automatically has outbound internet access
• Routing large AWS-service traffic through NAT without evaluating endpoints
• Sharing one broad security group across unrelated tiers
• Enabling flow logs without retention, analysis or an owner
• Building multi-AZ diagrams while leaving NAT, databases or application state as single points of failure

Verify with AWS

• Internet gateways and public subnets
• NAT devices for private subnets
• VPC Flow Logs
• AWS PrivateLink and VPC endpoints

Do you need to think about this yourself?

If you're using a simple Lightsail setup, much of this is abstracted away. Once you use EC2, containers, managed databases, private service access, VPNs or multiple AWS environments, VPC structure becomes an operational and security decision.

If you are diagnosing a live connectivity problem, follow the AWS outage checklist. For a new or redesigned environment, our AWS network routing service covers address planning, subnet design, controlled ingress and egress, DNS and connectivity validation.

Related reading: Load Balancer vs Auto Scaling: What's the Difference?, How to Secure an AWS Server: Checklist