What Is a VPC: Subnets, Security Groups and Gateways Explained

What a VPC is

A VPC (Virtual Private Cloud) is a private network you create inside a public cloud. Physically your servers share hardware with other customers, but logically they live in their own address space that nobody else can see or reach unless you allow it.

When you create a VPC, you choose an IP range in CIDR notation, for example 10.0.0.0/16. Every server, database and load balancer you launch inside gets a private address from that range. By default, resources in different VPCs cannot talk to each other, and nothing from the internet can get in.

AWS and Google Cloud call it a VPC, Azure calls the same idea a Virtual Network (VNet). The details differ, but the building blocks below exist everywhere.

Subnets: public and private

A subnet is a smaller slice of the VPC range, for example 10.0.1.0/24. In AWS each subnet lives in one availability zone, so you usually create subnets in at least two zones for fault tolerance.

What makes a subnet "public" or "private" is not a checkbox but its route table:

• Public subnet — its route table sends traffic for 0.0.0.0/0 (everything outside the VPC) to an internet gateway. Resources with a public IP here can be reached from the internet.
• Private subnet — there is no route to the internet gateway. Resources have only private addresses and cannot be reached from outside.

Rule of thumb: put in public subnets only what must accept connections from the internet, such as a load balancer. Everything else goes private.

Gateways: how traffic gets in and out

A NAT gateway sits in a public subnet. Private servers send outbound requests through it and receive the replies, but nobody outside can start a connection to them. A managed NAT gateway is billed separately, so check your provider's pricing before adding one in every zone.

Security groups and network ACLs

A security group is a virtual firewall attached to a resource: a server, a database, a load balancer. Its key properties in AWS:

• it contains only allow rules; everything not allowed is blocked;
• it is stateful: if an inbound request is allowed, the reply goes out automatically;
• a rule can reference another security group instead of an IP range, for example "allow port 5432 only from the app servers' group".

A network ACL works at the subnet level, is stateless and supports deny rules. Most small projects keep the default ACLs and do all filtering with security groups.

A typical layout for a web app

For an application with a backend and a database:

1. VPC 10.0.0.0/16 spanning two availability zones.
2. Public subnets (one per zone): the load balancer and the NAT gateway.
3. Private app subnets: application servers or containers.
4. Private data subnets: the database, with no route to the internet at all.

Security groups:

• lb-sg: allow 443 (and 80 for redirects) from 0.0.0.0/0;
• app-sg: allow the app port only from lb-sg;
• db-sg: allow the database port only from app-sg.

The only entry point from the internet is the load balancer. The database stays unreachable from outside even if someone learns its address.

For admin access, do not open SSH to the world. Use the provider's session manager, a bastion host with strict rules, or a VPN.

Common mistakes

• Database in a public subnet "just for a quick connection from a laptop". It tends to stay that way.
• Port 22 or 3306 open to 0.0.0.0/0 in a security group.
• Overlapping CIDR ranges between VPCs or with the office network, which later blocks peering or VPN.
• Too small a range: changing a VPC later is harder than planning a /16 from the start.
• Running production in the default VPC without reviewing its settings.