But one last thing to mention first:

Public vs Elastic IPs

One thing we haven't talked about is public IP addresses. All the IP addresses I've mentioned so far are local to within the VPC, but you also need some sort of public IP address that people on the internet can visit to connect to your server.

You can create an EC2 instance with a public IP address. The key thing to note with public IPs though, is whenever you stop your instance, the public IP will change, so it’s not a good idea to point your domain name to your public IP. For that you need an Elastic IP. Request an Elastic IP from AWS, and then you can attach it to a particular EC2 instance (or to a load balancer, or a NAT gateway). I’ll show how to do this below.

Terraform walkthrough

With that explained, here is the complete Terraform code you need to get a server up and running on AWS. You can get the entire thing in one file from here:

• ec2 with public IP

• ec2 with elastic IP

Here's a visual summary of what we're going to do:

EC2 with public IP example

Boilerplate terraform initialization code:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}
provider "aws" {
  region = "us-west-1"
  # Optional, this will tag all resources we create
  # so we can easily find them later to delete.
  default_tags {
    tags = {
      Terraform = "true"
    }
  }
}

This is just boilerplate code you will need when using Terraform with AWS.

VPC

Now let’s create the VPC. It needs a CIDR block. The CIDR block can be anything, but I recommend using /16 as the suffix.

resource "aws_vpc" "main" {
  cidr_block       = "10.0.0.0/16"
  # If you set the `Name` tag, AWS will use it
  # for adding a name to your resource in the console view.
  # This works for some resources but not others.
  tags = {
    Name = "terraform"
  }
}

Subnet

Create the subnet and associate it with the VPC. Notice the CIDR block for the subnet is a subset of the CIDR block for the VPC.

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

AMI for EC2 instance

Now we want to create the EC2 instance and put it in the subnet. Every EC2 instance needs an AMI (Amazon Machine Image). You can get the ID for the AMI you want from AWS here: https://console.aws.amazon.com/ec2/

Or you can just look it up in Terraform like this:

data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  owners = ["099720109477"] # Canonical
}

EC2 instance

Now let's create an EC2 instance that uses that AMI.

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  # assign it a public ip so we can connect to it
  associate_public_ip_address = true

  # references security group created below
  vpc_security_group_ids = [aws_security_group.sg.id]
  lifecycle {
    replace_triggered_by = [aws_security_group.sg]
  }

  # subnet to launch the instance in
  subnet_id = aws_subnet.public.id

  # simple server running on port 80 so we can verify
  # that the instance is up and we can connect to it
  user_data = <<-EOF
              #!/bin/bash
              echo "Hello, World" > index.html
              nohup busybox httpd -f -p "80" &
              EOF
}

Security group

We'll also create a security group that allows inbound HTTP traffic on port 80 from anywhere:

resource "aws_security_group" "sg" {
  name = "terraform"

  # We need to explicitly put the security group in this VPC
  vpc_id = aws_vpc.main.id

  # Inbound HTTP from anywhere
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

IGW

Create an internet gateway and associate it with the VPC

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
}

Route table

Create a new route table and route and add a route to the internet gateway

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
}

Associate our public subnet with this route table:

resource "aws_route_table_association" "public_subnet_asso" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}

Finally, we need to output the public IP of the instance so we can connect to it.

output "public-ip" {
  value = aws_instance.web.public_ip
}

# Optionally, output a URL for convenience
output "url" {
  value = "http://${aws_instance.web.public_ip}"
}

Try it!

Put all that in a file called main.tf. Run terraform init and terraform apply. I'm glossing over the details of how to use Terraform here, since there are other tutorials on that. After the changes apply, Terraform will print out the IP address and URL.

Hit the url that gets printed out using curl <url>. You may need to give it a few minutes for the instance to boot up.

If you get an error:

• If you get an error right away, that means everything works and you can hit your instance, but the server isn't up for some reason.

• If there's a wait before you get the error, that means you weren't able to connect to your instance at all. This could be any number of things, such as the IP you're using is wrong, or your security group or NACL are not set up to allow traffic in.

EC2 instance with elastic IP

All of the above, plus:

Request an Elastic IP and associate it with your instance:

resource "aws_eip" "lb" {
  instance = aws_instance.web.id
  domain   = "vpc"
}
# print the elastic IP
output "elastic-ip" {
  value = aws_eip.lb.public_ip
}

The end

And that's it! That is my introductory guide to networking for AWS. To close out, please enjoy this drawing of Nicholas Cage.

Back to index

We’re connecting an EC2 instance to the internet. We have learned a ton, but we still can’t connect to the internet, because we haven’t taken care of…

…security.

Here’s where we are now:

Setting up subnets, route tables etc is not enough. You also need to allow internet connections to pass through security: through your security groups, and through your NACLs. Those are two different things, and operate on different levels:

• Security groups operate at the firewall (or EC2 instance) level

• NACLs operate at the network (or subnet) level.

Security Groups

By default, your instance's security group is not set up for it to talk to the internet. You will have to explicitly set this up.

To set up a security group to talk to the internet, you need to set up rules. A security group has inbound rules and outbound rules.

• Inbound requests are requests coming from outside to your EC2 instance.

• Outbound requests are requests going from your EC2 instance to the broader internet.

Let’s look at an outbound rule that says you can connect to the internet. No inbound rules. That means that your servers can hit the internet, but no one from the internet can connect to your server.

Here’s a security group that allows outbound traffic to anywhere:

resource "aws_security_group" "sg" {
  name = "terraform"

  # We need to explicitly put the security group in this VPC
  vpc_id = aws_vpc.main.id

  # Outbound HTTP to anywhere
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

We’ll cover the options shortly. For now just know we just defined a security group with a rule using terraform, and that rules.

Here’s another security group example. This one allows inbound traffic to port 80 from anywhere:

resource "aws_security_group" "sg" {
  name = "terraform"

  # We need to explicitly put the security group in this VPC
  vpc_id = aws_vpc.main.id

  # Inbound HTTP from anywhere
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

You’ll want that one if you’re trying to put a server online.

Lets break down those fields

For the inbound rule above, we're saying that

• We allow connections only on port 80

• The server is running on port 80

• We allow the TCP protocol

• We allow connections from any IP.

The outbound rule we had seen above is even more permissive. That rule allows connections from and to any port, using any protocol, from any IP.

Note: On a toy server, you probably want that outbound rule so you can install packages on your EC2 instance. On production servers, people often don't have an outbound rule. This is so if a hacker gains access to the EC2 instance, they can't phone home. Users can still connect to their server because they have an inbound rule.

Here’s one more useful one – ssh from anywhere:

  # ssh from anywhere
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

Useful so you can log on to your box. People often recommend making this more restrictive, so only your IP address is allowed to SSH onto the server.

State your purpose

Going back to that outbound rule example. Now we can hit google.com from our server (an outbound request). But wait: the response from Google would be inbound traffic. And we have no inbound rules!

nuance incoming

Normally that inbound traffic wouldn’t be allowed, but since this is a response to your request, it is allowed. However, if Google wanted to initiate a connection, that would not be allowed.

Sometimes you will hear security groups described as stateful. This is what that means. Stateful means the response to a request is allowed, even if inbound requests aren’t allowed. You don’t need to do anything special to enable this: it’s just how it works.

A couple misc notes

You attach a security group to an instance. An instance can have multiple security groups attached to it, and you can attach a security group to multiple instances, so it's a many-to-many relationship.

Now, before we move on to NACLs, here's a quick debugging tip.

• If you try to connect to your server and the connection just hangs for a long time, the issue is probably your security group.

• But if it connects but fails instantly, it's because your server is not running.

NACLs

We won't talk too much about Network ACLs, or NACLs, because the good news is, NACLs by default allow you to connect to the internet. You shouldn't need to do anything here.

Most of the time, if you want to make a security change, you will be making it to your security group.

So why use NACLs? It's useful to use a NACL when you want to block a specific IP.

Notice that you can only allow connections using security groups. You can't create a rule that would deny a connection. That plus the fact that we use CIDR blocks to specify IP addresses, means you can't really block a single IP address using security groups. But you can using NACLs. With NACLs, you specify a bunch of rules with a priority level, and rules with a smaller priority level are applied first. You can use this functionality to block specific IPs.

Summary

• You don't need to change your NACL.

• You do need to change your security group to explicitly allow inbound connections.

• You attach your security group to one or more EC2 instances.

• If you can't connect to your EC2 instance, and the request just hangs forever, it's probably because of your security group.

Thanks for reading. In the next post, we'll put it all together, and finally talk to the internet!

Chapter 6: Terraform

Hi reader! This is part of a series on AWS Networking. The story so far: we've learned about VPCs. We've learned about subnets. We created a subnet and an internet gateway. Now we want to connect our subnet to the internet gateway. In order to do that, we need to learn about CIDR notation and route tables. This chapter is on route tables (“root tables”?).

tl;dr

1. Make a new route table

2. Add a rule to route to your internet gateway

3. Associate this route table with a subnet

Code for doing this

Longer explanation:

Here comes a packet

Someone wants to connect to your server. A packet comes in, with a destination IP address, and says "help I'm trying to go to 175.88.11.12". How do we know where the packet needs to go?

Another packet comes up and says "help I'm trying to get to 142.250.191.110". This packet actually wants to go out to the internet. How do we direct this packet?

The answer to both questions is a route table! A route table will map a destination to a target.

Route tables are mappings from a destination to a target

Route tables are set up so given a destination, the route table tells you the next step to take. It's just like if you're trying to go to a city:

In this example, the route table would look like this

The destination you're trying to get to is Mumbai, and the next step you need to go to is the airport.

Nuance! The route table doesn't tell the packet how to get to its final destination. It just tells the packet the NEXT STEP to take.

We want to connect a subnet to an internet gateway. The route table for that might look like this:

Lets break down what this table is saying.

Local or internet?

Suppose a packet comes in with a destination IP address. That IP address can be within your VPC, in which case the route table should route it locally

The route table tells the packet where to go next. If it's any other IP address, it should route it to your internet gateway

What does the route table for the logic above look like? Well, to start we need two routes:

1. If our EC2 instance wants to hit an IP address inside our VPC, we route that request locally inside the VPC

2. if it wants to hit any other IP address, we route that request to the internet, through the internet gateway

Here's what the route table for the logic above would look like:

You’ll notice we are using CIDR notation to specify a range of IP addresses (quick tutorial on CIDR here). The first rule says, any IP address that starts with 175.88 should get routed locally. The second rule says, all IP addresses should get routed to the internet gateway.

You can add routes for specific IP addresses,

but typically you will create routes for CIDR ranges.

Route tables pick the most specific route that matches

The route table in our example had two routes

Notice that one of the routes matches any IP address

while the other one matches only IP addresses in your VPC

So if a packet comes in with a local IP address, technically it matches both routes. Where will it go? Route tables will always try to match the most specific route.

Psst… how is the matching done? Using something called a Genmask. This isn't need-to-know information, so I won't describe it here, but now you know the word and can look it up if you want to.

The main route table

Route tables are created at the VPC level.

This means VPCs can have many route tables. Every VPC comes with a route table, called the main route table. This route table will have a route by default that maps your VPC's CIDR range to the local target. Typically, you want to leave this as is.

Subnets and route tables

All subnets are associated with the main route table by default. Suppose you have two subnets, both private. You're trying to make one of them public, i.e. giving it a connection to the internet. You do this by attaching it to an internet gateway. To do that, you need to add a route to your route table. Suppose you add a route like this to your main route table:

This works, and one of your subnets is now public. Unfortunately, all of your subnets are now public! Since you made this change on the main route table, and all subnets are associated with the main route table by default, all your subnets are now public.

To make a subnet public, you instead want to make a new route table and associate your subnet with that route table.

But there's a gotcha here. Subnets can only be associated with one route table at a time, so now your subnet will no longer be associated with the main route table. Remember that the main route table had that route for local traffic. Now your public subnet can no longer handle local traffic! If you want the subnet to handle local traffic, you'll have to add a route to your new route table to handle local traffic.

Terraform

# Make a route table with one route,
# which matches any IP address and
# sends it to the internet gateway.
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
}

# Associate the route table with the subnet.
resource "aws_route_table_association" "public_subnet_asso" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}

(Excuse the lack of syntax highlighting — Substack doesn’t have that)

Here is the Terraform code for everything we have learned so far, including making a VPC, subnet, etc: Github gist

Bonus command line tip!

If you are SSHed into an EC2 instance, you can see the route table by using the route command. You can also do netstat -r, which just calls route -e in the background.

Summary

Phew! You finally have a route in place, and your subnet is connected to the internet gateway. Here's what we have so far:

Bullet points

• To connect a subnet to the internet, you need a route.

• Routes are defined as rules in a route table.

• A route table matches a destination to a target.

• Destinations are usually specified as CIDR ranges.

• Route tables are created on the VPC level. Each VPC comes with a default route table called the main route table.

• You probably want to create a new route table and associate it with a subnet. Subnets can only be associated with one route table at a time.

Your subnet is now connected to the internet, but you still need to set up your security rules to allow traffic in. We’ll see that next!

Chapter 5: Security groups

Hello AWS adventurer, and welcome back to Chapter 3! So far we have learned about VPCs, internet gateways, and subnets. We have learned that a VPC is our own private network on AWS. We have learned that we need to create instances inside subnets. And finally, we have learned that to connect our servers to the internet, we need to connect our subnet to an internet gateway.

In order to connect our subnet to an internet gateway, we need to use a route table. And to use a route table, we need to know about CIDR notation. So this chapter is about CIDR notation.

What is CIDR notation? Well, to recap, this is an IP address

Instead of a single address, CIDR notation lets you specify a range of IP addresses.

This particular notation is equivalent to saying

Let's dig into what this notation means. In an IP address, you have four numbers. Each number is 8 bits, so it can be a number from 0 to 255

Lets look at the CIDR range 175.88.0.0/16. The 16 means the first 16 bits are fixed, which means the last 16 bits can change.

You can equivalently say this as the last two numbers can change,

or replace the last two numbers with x's,

or say this range

All of those are the same.

That /16 is called a CIDR suffix.

Here's another example

This is a /30, so the first 30 bits are fixed, and the last two can change. Note that it's convention that the numbers that can change are written as zeros, but you don't need to.

And, of course, when using CIDR notation, the last number can be a zero as well

In that case, we're talking about all IP addresses. This is more commonly written like this

You may see this notation in a route table. For example, if you have a route table where a connection to any IP address gets routed to an internet gateway, you would write it like that

(We'll talk about route tables in the next chapter, so don't worry if you don't understand this image).

VPC CIDR Ranges

BTW, each VPC you create will have a CIDR range. That means it's assigned a range of IP addresses, and the resources within that VPC have IP addresses that are somewhere in that range. For example, say the range for this VPC is 172.98.0.1 to 172.98.255.254. Any resource in this VPC will have an IP address somewhere in that range. That means that every resource in this VPC will have an IP address that starts with 172.98.

Subnets have their own CIDR ranges, and since each subnet is inside a VPC, its CIDR range is within the VPC's CIDR range.

For example:

Notice the /24 is a smaller range than the /16, even though the number is bigger.

That's all there is to it! Explanations for CIDR notation can get complicated, but at its heart, we just use it to specify a range of IP addresses.

In the next chapter, we will learn more about route tables. We’re about halfway through our journey, at the end of which, we will be able to connect an EC2 instance to the internet. Yes, it’s a long journey. But I'm glad to be with you, Samwise Gamgee.

Summary

• CIDR notation lets you specify a range of IP addresses.

• Each number is 8 bits.

• The bigger the suffix, the smaller the range.

Chapter 4: Route tables

In the last chapter, we talked about VPCs, and how a VPC is a private network inside AWS. It's like a big bubble of protection that we've built around our instances.

There are other people using AWS, and some of them might be bad people who want to connect to our instances and steal our data. But our instances are in a private network that no one else can get into.

If you haven't read the chapter on VPCs,

Read the chapter on VPCs

The benefit of having a protective bubble is that no one can connect to our instances. The downside of having a protective bubble is that no one can connect to our instances! We're building a website, after all, aren't we? How's anyone supposed to connect to our servers with this darned bubble in place?

We need to poke a hole in our bubble so we can talk to the internet.

Internet Gateways

An internet gateway is like a hole you poke in your VPC so you can talk to the internet.

Simple.

End of section.

Terraform code:

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
}

Now you have an internet gateway (aka an IGW, pronounced "igwoo"). Here's what we have so far:

Here's what the internet gateway looks like in the AWS docs:

Let's zoom in:

Zoom in some more:

Beautiful. Like the Gateway of India, but online.

So now we have an internet gateway (IGW), we can connect to the internet, right?

No! Not even close! Muahahahaaaaaa

Let's zoom out. First we need instances.

But before that (so zeroth), we need a place to put them in. See that green box labeled subnet?

Subnets

You can't connect your EC2 instance to an internet gateway directly! Only a subnet can be connected to the internet gateway. You need to put your instance inside a subnet, and connect that subnet to the internet gateway.

A subnet is a way to group your instances. It's sort of like tagging them. Here I have four instances

and now I've tagged them with subnet A or subnet B

To connect an instance to the internet, you need to put it in a subnet that is connected to the internet. Notice I said "put it in a subnet", but the subnet's not like a basket you're putting your instances into. It's just a tag, or a connection. Or an assignment.

Public and private subnets

By default, subnets can't talk to the internet. Subnets without a connection to the internet are called private subnets. Subnets that have a connection to the internet are called public subnets. To get your instance connected to the internet, one of the steps you need to take is assign it to a public subnet.

Sidebar: Why do we need to put our instance in a subnet? Well, we can't just put an instance in a VPC, because remember, the VPC spans all the availability zones in a region. To create an instance, we need to specify which availability zone we want to create the instance in. That way, we can create instances in multiple availability zones, to guard against outages. VPCs are region-scoped, but subnets are availability zone-scoped. To assign our instance an AZ, we assign it a subnet.

Now we have something like this

And to connect to the internet here's what we need:

Everything is ready, but to connect the subnet to the internet gateway, we need a route.

Terraform code for creating a subnet:

resource "aws_subnet" "subnet_name" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24" # see next chapter
}

Routes

A route is a connection from your subnet to the internet gateway so that your subnet can talk to the internet.

We need to create a route from our subnet to the internet gateway. To do that, we need to learn two new concepts first: CIDR notation, and route tables. The next chapter will talk about these stimulating concepts.

Summary

• An internet gateway is like a hole you poke in your VPC so you can talk to the internet.

• You can't connect your EC2 instance to an internet gateway directly. You need to put it in a subnet, and connect that subnet to the IGW.

• Subnets without a connection to the internet are called private subnets. Subnets with a connection to the internet are called public subnets.

Chapter 3: CIDR

One reader added some fascinating insights:

Security groups were the original solution to the second problem (that everyone's servers were in the same network).

The address conflict problem transformed into another problem after VPCs. After everybody got default VPCs, companies went from conflicting with each other to conflicting with themselves. Now they have a bunch of instances with the same IPs, in different VPCs, that still need to talk to each other… a problem that needed double-sided NAT.

A big part of the first problem (IP address conflicts) was actually that AWS was about to run out of IP addresses to issue to customers.

Back then, every instance got a public address because there was no other way to ssh into your instance. Because public addresses are so expensive and limited, this was a scaling cliff for AWS, and passed on as an unnecessary cost to customers. VPCs let you use a single bastion with a public IP to access the rest of your hosts.

This series of posts will get you up to speed on AWS networking, so you can get an app up on AWS. Every post is meant to be easy to understand, and spends time really explaining the concepts, so you understand how things work, and can adapt them to fit your use case. Each post is full of illustrations that I hope will brighten your journey as you learn AWS networking. Good luck and happy reading!

Read Chapter 1: VPCs

Index

1. VPCs

2. Subnets

3. CIDR

4. Route tables

5. Security groups

6. AWS in Terraform

In this section, I talk about why VPCs were invented and how they work. This is critical to understand because almost everything you do in AWS will happen inside of VPC. If you don't understand VPCs, it will be difficult to understand any of the other networking concepts.

If you're reading this, maybe you have one of these

and you just found out that to put your app on AWS, you need all of this:

And you have no idea what VPCs, subnets and so on are.

I'll help you learn about all those pieces. A little about me, I’m a long-tailed duck, and I run a business selling phones to hackers, called Blackhatberry. Now let's get started.

This is the story of VPCs (Virtual Private Cloud)s, our first big topic. Many moons (and suns) ago, some AWS engineers were sitting in a room. They had a serious issue.

"Guys, lets talk business. Why aren't more companies moving to AWS?" they said.

"Maybe because all instances run in a single shared network, which means users can access each other's instances, and see each other's data," someone said.

"Maybe because it's hard for them to move their existing servers to AWS, because of IP address conflicts," someone else said.

"Wait… what are IP address conflicts?”

“And existing servers? Shouldn’t they be moving to our servers?”

IP address conflicts

This is the first reason people weren’t switching to AWS. Here's what I mean by IP address conflicts. I own a bunch of servers for Blackhatberry. One of them has the IP address `172.98.0.1`. Now, my neighbor also has a server for her business. She loves my ip address. “Ah, 172.98.0.1, what a beautiful destination,” she says. So she copies my address! Now we both have servers with the same IP address!

Sidebar: You can find your local IP address using `ipconfig getifaddr en1` (works for Macs for wireless internet connections).

Now you're thinking "so what?". And actually... you're totally right. Even though our servers have the same IP address, they are in different networks, so it's not an issue.

But here comes trouble. Because we both want to get on AWS. But if we have two servers with the same IP address on AWS, that's a problem!

Bam: IP address conflict. Every server in a network needs to have a unique IP address for the same reason that every house in a city needs to have a unique address. Otherwise, if someone has a package, they wouldn't know which house to deliver it to.

Now I know what you're thinking. Why don't you just get new servers in AWS? Why connect your on-prem ("on premises") servers to AWS? Isn't the whole point that you're moving to AWS?

And sure, we can afford to do that, but there are companies with dozens of on-prem servers. Migrating everything to AWS is simply not an option for them. They need functionality so they can create new servers in AWS, but also connect their existing, on-prem servers into the same network. And this does not work when everyone is part of the same network, because of IP address conflicts.

This was a huge problem for AWS! I mean, see how serious these engineers look:

This IP conflict issue meant people with on-prem servers had no easy way to gradually move to AWS. Think of all the potential customers they were losing!

I'm giving you this background so you can understand why VPCs were invented. IP address conflicts weren't the only issue. In AWS, everyone's servers used to be on the same network, which meant if you were careless, it was easy for anyone to connect to your server and look at all kinds of sensitive data!

For both these reasons, Amazon needed to give each customer their own private network, instead of having them all on the same shared network. And so VPCs were born.

Why do they call it a VPC if you can't see it!

So there are two problems we're trying to solve:

1. IP address conflicts

2. The fact that users can access each other's instances because they're in one big shared network.

Remember: duplicate IPs were totally fine when my network and my neighbor's network were separate. What Amazon needed was a way to give each person their own private network, but inside AWS. That way, they could bring their IP addresses with them, and they wouldn't conflict with anyone else's IP addresses.

Maybe you're wondering, "why can't we just change the IP addresses so all machines have a unique IP address?" Well, in networking, you set up some things based around specific IP addresses (I'll get to exactly what stuff later), so that idea would require a lot of work in practice.

Separate networks would also solve the security problem.

This is the big idea behind a VPC: everyone gets their own private network inside AWS.

By the way, why am I spending so long on VPCs? Isn't this post about putting one of these

on one of these?

Two reasons.

1. Because everything we will build happens in a VPC, so it's the starting point for things.

2. Because a VPC is not something you can see, and I like to visualize my internet architecture. Other people visualize it in a way that's really confusing for me, and I want to make it less confusing for you.

I have read guides (such as the AWS docs) where people visualize a VPC like this. First, they'll say, "Oh yeah, I created a new VPC with four subnets inside it, in two availability zones".

And they'll draw an image that looks like this:

But less pretty obviously – this is what theirs look like:

(Taken from the AWS VPC docs)

Now,

• a region is a place you can go to,

• and an availability zone has data centers you can walk inside, that hold lots of servers.

Both of those are physical places. But what is the VPC? Is it a big tarp that sits on top of the data centers? Is it a dark fog? Is it a general feeling of unease that blankets the region, as all the data centers play Radiohead's "Fitter, Happier" on repeat?

…what is it?

What is a VPC?

We've talked about why AWS needed VPCs, and the idea behind VPCs, but how are they implemented? How do they actually work?

Your instances in AWS always run inside a VPC. But in real life, of course, your instances are just running on servers in AWS datacenters.

You may have many instances running on many different servers. How does Amazon connect these instances, across different servers, into their own private network? It uses something called the mapping service.

Mapping service

Suppose I have an instance A on server 1, and I want to talk to another instance B on server 2.

All instance A knows is the IP address for instance B. It hits the mapping service with that IP address. The mapping service then checks what VPC instance A is in, finds the instance with that IP in that VPC, and forwards the request to it.

That "in that VPC" part is important. The mapping service makes it so me and my neighbor can both have instances on AWS with the same IP, but when I hit that IP address, the mapping service will connect me to the instance in my VPC, and when my neighbor hits that IP address, the mapping service connects them to the instance in their VPC.

The mapping service is what isolates our servers.

The mapping service is what ensures that we can never connect to each other's instances. Through the mapping service, all my instances are connected together, and they can have any IP address I want, because it's like they're namespaced to me. The mapping service is what creates the private network inside AWS for me.

So when you think VPC, picture a service that connects all these instances together.

Going back to this image, we can now understand what it means:

That VPC box just means the scope of the mapping service. A mapping service can connect EC2 instances that are on servers in different availability zones, which is why the VPC is overlaid over the two availability zones. But the mapping service can't connect instances in different regions, so the VPC doesn't span regions.

Today everything happens in VPCs. Your instances are always in a VPC. Everyone gets a default VPC when they open an AWS account. We no longer have the issue where users can access each other's instances, and we don't have the IP collision issue either.

So we find out that they don't play "Fitter, Happier" in the data centers after all. Maybe it's just a recording of Jeff Bezos singing "Money" by Pink Floyd.

Terraform code

Throughout this guide, I'll show you how to create AWS resources using Terraform. I find Terraform easier to follow than point-and-click on the AWS console, because you can just copy the code and run it.

Here's the Terraform code to create a VPC:

resource "aws_vpc" "main" {
  cidr_block       = "10.0.0.0/16"
}

In any Terraform file, you'll also need a couple of boilerplate blocks for terraform and provider. The full code listing is here. You can apply this code to create a new VPC. Ignore the cidr_block part for now, I'll discuss CIDR in more detail in a future section.

Summary

• In AWS, every customer has their own private network called the VPC.

• Without private networks, we run into IP address collisions.

• Without private networks, everyone is on the same network, which is really bad for security.

• VPCs are implemented using the mapping service.

Chapter 2: subnets

P.S. A reader provided me with some extra context on AWS VPCs. You can read that here.