Linux and networking
Cloud networking and VPCs
VPCs, subnets, routing, NAT, security groups and private connectivity in AWS and GCP, plus a three-AZ reference architecture and how to debug when A cannot reach B.
Every cloud workload runs inside a virtual network that you design, whether you noticed or not. Defaults get a demo working. Production needs a plan for address ranges, public and private placement, routing, firewall rules and admin access that does not leave SSH open to the world. Get this wrong and you pay for idle NAT gateways, cannot peer with another team, or spend an incident wondering why a database is "down" when a security group never allowed its port.
This topic applies to AWS VPCs and GCP VPC networks. The names differ, but the hop-by-hop model does not. It builds on networking basics and feeds load balancers, DNS and the edge.
The concept pages
| Step | Concept | What it answers |
|---|---|---|
| 1 | CIDR and VPC basics | How do you split an address range without overlaps? |
| 2 | Routes, internet gateways and NAT | How does a packet find its next hop? |
| 3 | Security groups and NACLs | Which traffic is allowed, and on which side? |
| 4 | Connecting VPCs and private endpoints | How do networks and cloud APIs talk without the internet? |
| 5 | Debugging connectivity | When A cannot reach B, where do you look first? |
How a request moves
A user request crosses several boundaries, and each one has a rule. DNS resolves the name to a public load balancer. The load balancer, in a public subnet, forwards to an app instance in a private subnet, and its security group allows only the load balancer's port. The app instance reaches the database in a private data subnet, which accepts connections only from the app's security group. If the app needs an outside API, its outbound packet goes through NAT in a public subnet. If it needs S3, an endpoint keeps the packet off NAT altogether.
Each hop can fail in its own way, so the rest of this topic goes through them one at a time.
Reference architecture
A three-tier service across three zones, with no bastion host, looks like this.
The load balancer sits in public subnets. Application and database subnets are private. Security groups allow only the traffic each tier needs. Operators reach machines through SSM Session Manager or an IAP tunnel, which need IAM and leave an audit trail, instead of an open port 22.
Common mistakes
- Opening SSH to
0.0.0.0/0. Use Session Manager or IAP, and restrict by IAM. - Overlapping address ranges. Peering later fails, and the fix is a new network and a migration.
- One NAT gateway for production. It is cheaper, but a single point of failure for all outbound traffic.
- Assuming "private" means safe. Private subnets still need security groups.
Key takeaways
- Plan non-overlapping address ranges with headroom, one subnet per zone per tier.
- Route tables decide the next hop. Internet gateways serve public subnets, and NAT serves private egress.
- Security groups are the primary control and are stateful. Keep NACLs simple.
- Use Reachability Analyzer and flow logs when a path breaks, and prefer IAM-based admin access.
Further learning
A developer-focused talk walks through VPCs, subnets, security groups, NAT, endpoints and hybrid connectivity without assuming a networking background.
Next, start with the address plan: CIDR and VPC basics.
Related
Networking: IP, TCP and UDP
Packets, addresses, ports, and the handshakes and congestion control that decide how fast your bytes arrive. Explains why a new connection is slow and how to check it on the wire.
Load balancers, DNS and the edge in the cloud
Configuring the traffic layer, from DNS and cloud load balancers through TLS, WAF and CDN to a regional traffic shift. Start here for the map of edge pages.
IAM and least privilege
How cloud identity works, why least privilege is a habit rather than a checkbox, and where the org-level guardrails sit. Start here for the map of IAM pages.