Cloud Networking Fundamentals: VPC, Subnets, and Security Groups

The first thing to do when going to the cloud, most people intuitively think "spin up a VM." Wrong. What you should really get your hands on first is the network.

A real incident: a team, "for debugging convenience," opened RDS's port 3306 to 0.0.0.0/0, thinking the password was complex anyway. Two weeks later, the database was siphoned empty; the logs showed an overseas IP running a weak-password dictionary all night. Whether the password was complex or not didn't matter at all — a database exposed on the public internet is like moving a safe to the side of the road and trusting no one will pry it open.

The root cause of this kind of incident isn't the password policy, isn't the database version — it's that the network wasn't understood. Cloud networking (VPC, subnets, security groups, NAT) is the foundation of the entire security model. Get the foundation wrong, and no matter how much hardening you pile on top, it's a castle in the air. This article explains the most core things about cloud networking: why cloud networking differs from the datacenter, what a VPC is, how to divide public and private subnets, how to configure security groups and NACLs, what NAT is for, and finally gives a classic "two-tier subnet + minimal exposure" architecture.

One: Cloud Networking Isn't "Moving the Switches to the Cloud"

Many people understand cloud networking as "moving the datacenter's setup to the cloud," which is a dangerous misconception. Cloud networking is software-defined networking (SDN), and it has three fundamental differences from traditional networking:

• Logical isolation, not physical isolation. In the datacenter, to isolate two sets of business, you need to run two sets of cables, two switches, physically separated. Cloud isolation is logical — you define a CIDR segment (VPC), and that address space belongs only to you. The same physical rack might be running dozens of tenants' VMs, but your traffic can't reach others, relying on the cloud's underlying network virtualization (VPC, VXLAN and such), not cables.
• The security model is "default deny." Traditional networks are often "trust the internal network by default"; the cloud is the exact opposite — everything is denied by default; only when you explicitly allow it does it become reachable. Security groups default to all-deny; this is the baseline of cloud security.
• Everything is programmable. Subnets, routes, firewall rules are all API objects, creatable with code (Terraform/Pulumi), committable to Git, reviewable, rollback-able. This is the foundation of IaC, and also where cloud networking beats datacenter networking.

Once you understand these three points, the following concepts fall into place. Cloud networking isn't a more complex version of datacenter networking; it's a different paradigm.

Two: VPC: Your Private Territory in the Cloud

A VPC (Virtual Private Cloud) is a segment of private IP space allocated to you on the cloud. AWS, Alibaba Cloud, and GCP all have this concept (Alibaba Cloud calls it VPC, GCP calls it VPC network); the essence is the same.

You can think of a VPC as a private campus carved out for you in the cloud:

• It has a CIDR segment (e.g., 10.0.0.0/16, 65536 IPs).
• Inside the campus, these IPs are mutually reachable; outside the campus (other tenants, the public internet) can't get in by default.
• How you carve up subnets inside the campus, how you lay out routes, is up to you.
• A VPC is a region-level resource; to achieve high availability across Availability Zones (AZ), you create subnets across AZs within one VPC.

Key insight: A VPC itself isn't connected to the public internet. A freshly created VPC is an "island"; machines inside can reach each other, but can't access the internet, and the public internet can't access it. To connect to the public internet, you must explicitly add two things — an Internet Gateway (to reach the internet) and a NAT Gateway (to go out to the internet). This is the origin of the subnet classification in the next section.

Three: Subnets: Public vs. Private, Where to Put the Database

A VPC is carved into subnets, and subnets are AZ-level — each subnet falls within some Availability Zone. By "whether it can be directly accessed from the public internet," subnets fall into two categories:

Public Subnet: the route table has a default route pointing to an Internet Gateway (IGW) (0.0.0.0/0 → IGW). Instances here, as long as they're given a public IP / Elastic IP, can be directly accessed from the public internet. What goes here? Entries facing the public internet — load balancers (ALB/NLB), bastion hosts (Bastion), the NAT gateway itself, API gateways that need a public IP.

Private Subnet: no route to the IGW. Machines here have no public IP, and the public internet can't access them. What goes here? Things that shouldn't be directly accessed from the public internet — databases (RDS/Redis/Elasticsearch), application servers, internal microservices, message queues.

To judge whether a subnet is public or private, don't look at the name (names can be arbitrary); look at whether the route table has that 0.0.0.0/0 → IGW rule. That's the only criterion.

Remember an ironclad rule: databases always go in private subnets. No exceptions. If someone says "let me put it in a public subnet for testing convenience," you can stop them directly — the cost of testing convenience could be a database dump.

Four: Security Groups: Instance-Level Firewalls, Default Deny

Just putting the database in a private subnet isn't enough — machines within a private subnet are still reachable to each other by default. To further control traffic, use Security Groups.

A security group is a stateful firewall bound to an instance's network interface (ENI). Its key characteristics:

• Stateful: you allowed inbound, the outbound reply packets are automatically allowed; no need to write a separate reverse rule. This differs from NACL, covered later.
• Default deny: a newly created security group has no inbound rules at all — all denied. You must explicitly write rules for anything to be reachable.
• Whitelist model: you write "allow who from which port in," not "deny who." When configuring, always ask "what other allow rule is needed," not "who else to block."
• Reference rather than write IPs: security group rules can reference another security group, e.g., "allow the sg-app security group to access 3306," rather than writing 10.0.10.0/24. IPs change; security group IDs don't, making maintenance much more stable.

A reasonable configuration looks like this: the app security group's inbound allows only port 8080 from the ALB security group; the DB security group's inbound allows only port 3306 from the app security group. Layered references; no one can skip over.

The most common disaster configuration is 0.0.0.0/0 allowing all ports — especially 22 (SSH), 3306, 6379. Once written, it's equivalent to hanging the service naked on the public internet. Every time you review security groups, first grep for this rule.

Five: NACL: The Subnet-Level Second Gate

A NACL (Network ACL) is a stateless firewall bound to a subnet. It and security groups are two different layers:

NACLs are used less, but there are two scenarios worth using them: one is when a subnet runs multiple tenants' instances and you want a layer of hard isolation at the subnet boundary; the other is blocking known malicious IP ranges — a NACL can explicitly DENY; security groups can only ALLOW.

For the vast majority of small-to-medium projects, security groups configured well is enough; keep NACLs at default. But know they exist, because NACLs are stateless — if you only allowed inbound 80 in the NACL but didn't allow outbound ephemeral ports, the connection just won't work; this kind of pit is extremely time-consuming to troubleshoot.

Six: NAT Gateway: Let Private Subnets "Go Out, Not Come In"

Machines in private subnets have no public IP, but they often need to actively access the public internet — download system updates, pull Docker images, call external APIs, report monitoring. How to let them go out without exposing themselves? NAT Gateway.

A NAT (Network Address Translation) gateway is placed in a public subnet, and its purpose in one sentence: translate the outbound traffic from private-subnet machines into its own public IP and forward it out; translate the returning packets back to that machine. The effect is — private machines can actively connect out, but the outside can't actively connect in (because the NAT table has no corresponding entry).

The configuration is fixed: in the private subnet's route table, add a 0.0.0.0/0 → NAT Gateway entry. From then on, app machines can apt update, can curl api.github.com, but the public internet can't scan them.

One pit: NAT gateways are billed on usage, and not cheap. They have an hourly fee + a per-GB processing fee. A service that does heavy image pulls or TB-scale daily egress can see NAT take up a big chunk of the bill. Optimization directions: put commonly-used images in an internal image registry (VPC Endpoint / private link) to bypass NAT; do bulk data transfers over VPC peering or Direct Connect.

Seven: Classic Architecture: Two-Tier Subnets + Minimal Exposure

Putting the above together gives the most classic security architecture on the cloud — public subnet + private subnet, layered isolation, minimal exposure:

                      Internet
                         │
                  ┌──────┴──────┐
                  │  IGW Gateway │
                  └──────┬──────┘
                         │
   ┌─────────────────────┴──────────────────────┐
   │            VPC 10.0.0.0/16                  │
   │                                             │
   │  Public subnet 10.0.1.0/24 (has IGW route)  │
   │   └─ ALB / Bastion / NAT Gateway            │
   │           │                                 │
   │  Private subnet 10.0.10.0/24 (app)          │
   │   └─ App containers / API services          │
   │      │  ↑ SG: allow only ALB's 8080          │
   │      │  ↓ SG: allow only access to DB's 3306 │
   │  Private subnet 10.0.20.0/24 (db)           │
   │   └─ RDS / Redis  ← no public IP, no IGW route │
   │           SG: allow only app SG's 3306/6379 │
   └─────────────────────────────────────────────┘

The flow direction: User → ALB (public subnet) → app (private subnet) → DB (private subnet). Each hop is tightened by security groups; the database trusts only the app, the app trusts only the ALB, and the ALB opens only 443 to the public internet. Even if any layer is breached, the attacker can't directly jump to the next layer, because they have no corresponding allow rule — this is "minimal exposure."

For cross-AZ high availability, build each subnet in 2-3 AZs; ALB and RDS are naturally multi-AZ. The architectural skeleton stays the same.

Eight: Four Pitfalls You'll Hit Every Time

• Database open to the public internet. The incident described earlier — the root cause was exactly this. The moment you see 0.0.0.0/0 → 3306 in the RDS security group, delete it immediately. Databases are always in private subnets, always only open ports to the app security group.
• Security group wide open to 0.0.0.0/0. Ports 22, 3306, 6379, 5432 especially must not be open to the public internet. For SSH, use a bastion host or SSM Session Manager; don't hang directly on the public internet.
• NAT gateway bill ambush. It's per-usage + per-GB; high-traffic egress is expensive. Route high-frequency access like image sources, object storage, and third-party APIs through VPC Endpoints or private connections to bypass NAT.
• Forgot to open a security group port, then suspect the code has a bug. When machines can't connect to each other, 90% of the time it's not a code problem — it's that the security group didn't allow it. When troubleshooting, first telnet / nc to test the port, then look at both sides' security group inbound/outbound rules, and only then look at application logs. Get the order wrong and you'll debug all night.

Summary

• Cloud networking is software-defined + default deny + everything programmable, not a replica of the datacenter's physical networking. Change the foundational mindset first.
• A VPC is your private IP space, an island by default. To connect to the public internet you must explicitly add an IGW (in) or NAT (out); this is the root of subnet classification.
• Public subnets hold entry points (ALB/bastion); private subnets hold data (DB/app). Judge by whether the route table has 0.0.0.0/0 → IGW, not by the name.
• Security groups are instance-level stateful whitelists, default deny; rules should reference other security groups rather than hardcoding IPs; NACLs are subnet-level and stateless; most projects can keep them at default.
• NAT lets private subnets "go out, not come in," but is billed on usage — don't abuse it; the classic "public subnet → app → DB" two-tier architecture, with layered tightening and minimal exposure, is the standard for cloud security.

One-sentence closer: On the cloud, 90% of security is at the network layer, not the application layer. An architecture with a cleanly partitioned VPC, neatly divided subnets, and security groups that open only necessary ports has already blocked the vast majority of attacks for you — the rest, like passwords, patches, and encryption, are hardening on top of the network foundation. Get the network understood first, then talk about the rest.