Cloud Networking: VPCs, Subnets, and Security Groups

What Is a Virtual Private Cloud?

A Virtual Private Cloud (VPC) is a logically isolated section of a public cloud provider's network where you can launch resources in a virtual network that you define. Think of it as your own private data center inside the cloud — you control the IP address ranges, subnets, route tables, and network gateways. AWS, Azure, and Google Cloud all offer this concept under slightly different names, but the principles are the same across providers.

When you create a VPC, you assign it a CIDR block — a range of IP addresses expressed in Classless Inter-Domain Routing notation. A common starting point is a /16 block such as 10.0.0.0/16, which provides 65,536 addresses for your use inside that VPC.

Subnets: Public vs. Private

Within a VPC you divide the address space into subnets. A subnet is simply a smaller CIDR block carved out of the VPC range. Two subnet types matter most in this lesson.

Public subnet — A subnet whose route table contains a route that sends internet-bound traffic (0.0.0.0/0) to an internet gateway. Instances here can communicate directly with the internet if they also have a public IP address.

Private subnet — A subnet whose route table has no route to an internet gateway. Instances here cannot be reached directly from the internet and cannot initiate outbound internet connections unless additional components (such as a NAT gateway) are in place.

A /24 subnet such as 10.0.1.0/24 provides 256 addresses (with a few reserved by the provider for internal use). Placing your web servers in the public subnet and your databases in the private subnet is a foundational security pattern you will see in almost every production architecture.

Internet Gateways and Route Tables

An internet gateway is a horizontally scaled, redundant VPC component that allows communication between your VPC and the internet. Attaching one to your VPC is not enough on its own — you must also add a route in the public subnet's route table that points 0.0.0.0/0 (all traffic) toward the internet gateway.

A route table is a set of rules (routes) that determines where network traffic is directed. Each subnet is associated with exactly one route table at a time. The local route (for example, 10.0.0.0/16 → local) is always present and allows all instances within the VPC to reach each other. You add the internet gateway route only in the route table associated with your public subnet.

Security Groups: Stateful Firewalls

A security group acts as a virtual firewall for EC2 instances, controlling inbound and outbound traffic at the instance level. Security groups are stateful, meaning that if you allow an inbound connection, the return traffic is automatically allowed regardless of outbound rules — and vice versa. This differs from network ACLs, which are stateless.

When you add a security group rule, you specify:

• Protocol (TCP, UDP, ICMP, or all)
• Port range (for example, port 80 for HTTP, port 22 for SSH)
• Source or destination (an IP address, a CIDR block, or another security group)

For a public web server you would typically allow inbound TCP port 80 (HTTP) and port 443 (HTTPS) from anywhere (0.0.0.0/0), and inbound TCP port 22 (SSH) from your specific management IP only. Restricting SSH to known IP ranges is an important security practice — leaving SSH open to the world exposes the instance to brute-force attacks.

How Traffic Flows: Putting It Together

When a browser on the internet requests a page from your public EC2 instance, the traffic path is: Internet → Internet Gateway → Public Subnet Route Table → Security Group Inbound Rules → Instance. The response follows the reverse path, allowed automatically because security groups are stateful.

When you try to reach your private EC2 instance from the internet, the VPC has no route to forward that traffic — the private subnet route table only contains the local route. The connection fails at the network level before it even reaches any security group. This is the core of network-layer isolation.

If the public instance tries to reach the private instance, it stays inside the VPC on the local route. Success or failure then depends on the private instance's security group — if the security group allows ICMP (ping) from the public subnet's CIDR, the ping succeeds.

Safety and Best Practices

Cloud misconfigurations are one of the most common causes of data breaches in enterprise environments. Treat security group rules with the same discipline you would apply to physical access controls:

• Principle of least privilege — Open only the ports and protocols that are required. Close everything else.
• Never expose management ports (SSH/RDP) to 0.0.0.0/0 in a production environment.
• Document every rule — Your lab log is practice for the change-management records required in real workplaces.
• Verify your work — Always confirm that private resources are unreachable from the internet after configuration. Assume nothing; test everything.
• When working in a shared lab sandbox, stay inside your assigned VPC and CIDR range to avoid conflicting with classmates' work.