Cloud Networking Basics

Getting a request from the internet to a private database, safely

2 lessons ago, an e-commerce database sat safely in a relational database, storing orders that had to stay consistent with real customers and real inventory. That database is useless if a shopper's browser cannot reach it, and dangerous if anyone on the internet can reach it directly. Cloud networking is the layer that resolves that tension: it gets a request from a user's browser to the right application server and the right database, while keeping the database itself unreachable from the outside world entirely. This lesson builds that path piece by piece.

The VPC: your own private network, virtualized

A virtual private cloud (VPC) is a logically isolated virtual network dedicated to your account. You choose an IP address range for it, then add subnets, gateways, and security controls, the same building blocks you would configure in a physical data center network, except there is no cabling and no hardware to rack. Every resource you launch, a virtual machine, a database instance, lives inside a VPC, which is what makes the next piece, subnets, meaningful.

Subnets: public versus private

A subnet is a range of IP addresses inside a VPC, and, on AWS, a subnet lives entirely within 1 Availability Zone, the same AZ concept from earlier in this topic, now applied to networking. What makes a subnet public or private is not its name but its route table: a public subnet has a route to an internet gateway, so its resources can be reached from, and can reach, the internet; a private subnet has no such route, so nothing outside the VPC can reach it directly.

This is exactly the shape of the RDS reference architecture: application servers sit in public subnets across 2 Availability Zones, reachable by users, and the database instances sit in private subnets in those same 2 AZs, reachable only by the application servers inside the VPC, never directly from the internet. A resource in a private subnet is not cut off entirely; it can still reach the internet outbound, to download a software update, for instance, through a separate NAT gateway, but nothing outside can initiate a connection in.

Security groups and network ACLs: 2 different locks on 2 different doors

Getting the placement right is only half the job. The other half is deciding exactly what traffic each piece is allowed to see, and AWS gives you 2 different tools for that, at 2 different scopes.

A security group is a virtual firewall attached to an individual instance, like a doorman standing at one specific door who remembers everyone he has let in: once he allows a request out, he automatically lets the matching response back in without checking his list again. That memory is what "stateful" means. A security group only supports allow rules, and it checks every rule before deciding, since there is nothing to deny, only permission to grant or withhold.

A network ACL works at the subnet level instead, more like a building's front desk that checks every single person crossing the threshold, in either direction, against a written list, with no memory of who it let through 5 minutes ago. That is "stateless": a network ACL supports both allow and deny rules, and it stops at the first rule that matches, checked in order, rather than reviewing every rule the way a security group does.

AWS's own guidance is to use security groups as your primary access control and add network ACLs as a secondary, coarser layer on top. The reason is straightforward: a network ACL guards the whole subnet, so it keeps working as a backstop even in the rare case an instance gets launched without the right security group attached. 2 layers that can fail in different ways protect you better than 1 layer that has to be perfect every time.

The load balancer: spreading traffic across healthy targets

Recall the compute lesson's horizontal scaling: adding more instances of the same size instead of resizing one. Splitting the load across 4 identical app servers only works if something decides which of the 4 handles each incoming request, and that something is a load balancer. A load balancer sits in front of a group of targets, health-checks each one, and routes traffic only to the targets currently passing those checks, automatically routing around an instance that has stopped responding.

The full path, assembled

Put every piece from this lesson together and the path a request actually takes looks like this: a user's request enters the VPC through an internet gateway, reaches a load balancer, which routes it to one of several healthy app servers sitting in a public subnet, protected by that instance's security group. The app server then reaches into a private subnet to read or write the database, a connection allowed only because both sides sit inside the same VPC, never because the database is reachable from the internet. A network ACL watches each subnet boundary the whole way through, as the coarse-grained backstop behind every security group.

Where this leaves you

Networking is not a single setting, it is a stack of decisions: which subnet a resource lives in decides whether the internet can reach it at all, security groups decide exactly which traffic reaches a specific instance, network ACLs back that up at the subnet level, and a load balancer decides which of several healthy instances actually answers a given request. Every service this topic covered, compute, storage, databases, sits somewhere inside this network, and none of it is reachable, or protected, without it. The next topic in this domain, Modern Cloud Architectures, builds on every one of these building blocks to cover the patterns teams actually deploy today: serverless computing, containers and microservices, and infrastructure as code.