AWS Networking Demystified - Part 1

Explaining AWS networking with simple home analogies, and pictures!

Introduction

Cloud networking can feel like an alphabet soup with all the fancy words and acronyms—VPC, NATs, firewalls, subnets—oh my!

Fear not, today we’re going to demystify the basics of cloud networking by explaining it as if it’s your own home network! I’ve found myself using this approach to teach AWS networking many times, and the relief I hear when it “clicks” for someone is always a joy. This post is geared towards beginners, so if you’re someone that already know what a route table is and how to manage PrivateLink connections, please subscribe for future content and save yourself the reading.

Although I’m focusing on AWS, the concepts are essentially the same in Azure or GCP, though names of services may vary.

What is a VPC?

Let’s start with the Virtual Private Cloud, or VPC if you like acronyms. My Azure pals will know this as a Virtual Network, or VNet, and I have to give credit to Microsoft for the better name here. Why?

Because the VPC is just a network in the cloud. But forget about the cloud for a sec, what is a network? You’re on one right now—the one you used to access this web page and read this article. Most of us have at least one network at home, with WiFi.

WiFi is just the way that you connect wirelessly to the network though, it isn’t the network itself. Alternatively you could be on your home network by physically connecting via Ethernet cable, and some other ways we won’t get into.

VPC IP Addresses

Networks have a range of IP addresses, aka a CIDR block, such as 192.168.1.0/24. When a device connects to the network, it gets an IP address assigned, such as 192.168.1.30. Every network is totally isolated, so their IP addresses are considered “private", also known as a Local Area Network (LAN).

In fact, two different networks could have the same IP address ranges, which is fine, because they don’t communicate with each other. For example, most consumer routers you buy and probably have at home right now are going to use the very same CIDR I shared above, 192.168.1.0/24, as this is just a very common private IP range.

So think of a VPC as another network, like the one you have at home. Or to make it more fun, flip it: think of your home network as the VPC going forward.

Subnets

Next is subjects. If you have an IT background or learned networking before cloud computing was all the rage, you’d know these as VLANs.

Subnets simply divide your VPC—or network—into smaller chunks. Subnets have two primary uses:

1. Organize parts of the network for logical purposes

2. Distinguish with parts of the network are public vs. private

Again, all of this can be done at home as well, using VLANs you would typically configure in your home gateway or router.

Logical Separation

Organizing chunks of the network for different logical purposes is useful for maintainability, security, and scalability.

For example, say you start using a ton of IoT devices like smart bulbs and plugs at home. IoT devices are notorious for having more security risk, so we’d ideally want to segregate those to their own subnet/VLAN so they can’t reach our important trusted devices like mobile phones, laptops, desktops.

Each of these devices connects to the network, so they each get an IP address. So we’d need to size their subnet accordingly, making sure it has enough available IP addresses to give to each IoT device and allow room for future expansion. Still, other subnets may only require a few IP addresses. Sizing subnets is important because it can be difficult to change afterwards.

Public vs. Private Subnets

The other use for subnets I mentioned was private vs. public. By default, our subnets can’t access the Internet—we’ll get to that next.

Coming from outside-in though, we sometimes need to reach a device, or IP, from outside our network. One of the ways to do this is by connecting over the public Internet. Earlier I said networks are private though? Right, so do this we need a public IP address. Unlike the private IP addresses (e.g. 192.168.1.30), a public IP is one that anyone in the world on the public Internet can see and reach.

In the cloud, public subnets are the only ones that can have public IPs. Though this doesn’t mean every IP in a public subnet is a public IP. That said, for security we should try to only use public subnets for things that must have a public IP address, such as a public-facing application load balancer, SSH and FTP servers, etc.

Gateways: Internet Access

So how does stuff in the network access the Internet? Sure, that’s pretty important for most networks, whether we’re just loading web pages at home, or having an application download its dependencies.

This is where gateways come in, and again you’re actually using one right now to read this article!

There’s two types of gateways to know about:

1. NAT Gateway: lets private subnets access the Internet, but not the other way around.

2. Internet Gateway (IGW): lets public subnets have both inbound & outbound Internet access.

NAT Gateway

NAT stands for Network Address Translation. Just a fancy way of saying that it translates private IP addresses (e.g. 192.168.1.30) to a single public IP address on the Internet.

For example, pick two different computers/phones at home right now and on each of them go to https://www.whatsmyip.org/. You’ll see the same public IP address reported, even though you used two different devices. That’s because most consumer-grade home routers also serve as the NAT Gateway in home networks.

In more technical terms, that public IP address you saw was the current public IP address assigned by your Internet Service Provider (ISP) to your Wide Area Network (WAN). Note: your ISP may change your public IP at any point, and this is quite common for dynamic IPs.

So think of it like a funnel for your private network to access the Internet, and remember this behavior of the single public IP address. It will come in handy when we talk about firewalls.

Internet Gateway (IGW)

The other is Internet Gateways. Internet Gateways are for public subnets, and they can allow inbound traffic from the Internet too.

Put simply, if your instance/machine has a public IP, you need a Internet Gateway for it to communicate with the Internet.

Security Groups

The last piece we’ll learn today is Security Groups. These are a virtual firewall for your networks or instances. That means it has ingress and egress rules that define what IP ranges and ports are allowed to receive or transmit on respectively.

By default, everything on the same network can reach one another. To lock things down, we use Security Groups and set ingress and egress rules. For example, only allowing things from a “Application” private subnet to talk to a “Databases” subnet on port 3306 for MySQL. Or opening port 443 for a public web server.

An easy way to test if you can reach a certain port at a target IP is with nc -vz <ip> <port> like: nc -vz 10.0.0.92 3306

Let’s wrap up

These are the same essentials you’ll use in cloud providers like AWS! No voodoo magic going on here, just good ol’ networking but shifted into on-demand scalable cloud computing! Now go tell your friends, family, or neighbors how simple it all is!

Want more?

If this has helped you understand cloud networking better, please consider following/subscribing to my newsletter!

You may be wondering how to secure traffic across private networks without it going over the public Internet. On that note, if I see enough interest through comments/likes, I’ll create a Part 2 to go into intermediate concepts like VPC peering, Transit Gateway, and PrivateLink!