VPC - An analogy about shared resources
Public subnets and Internet Gateway
Load balancing - one front door, many clerks
<aside> 🚧
This page is currently under construction. Please check back later.
</aside>
<aside> 🧑🎓
It is recommended to refresh your memory around basics network concepts by going through Week 9 - Networking and APIs from the Core Program
</aside>
A VPC seems straightforward at first. It can be described as your own private network inside the AWS infrastructure: it isolates your resources from other people's resources and from the internet, and it gives you full control over how traffic flows.
A VPC is one of the fundamental building blocks that almost every piece of AWS architecture sits on, and it has a lot of nuances. Not understanding this fundamental leads to a lot of frustration later on.
Because of this, we will start with an analogy, and build the technical knowledge on top of it.
<aside> 🎯
By the end of this page you should be able to say, in your own words:
Planet AWS. Each city is a region (Frankfurt, Cape Town...), and each district inside a city is an Availability Zone. The buildings you control is within your VPC: it belongs to one city, and it can hold blocks of rooms (subnets) in several districts of that city.
Source: https://excalidraw.com/#json=14T1eEBY8p6F03-Jp88VA,48V5lso5ZF1bR8PbaIpkXQ
There is a planet called AWS, and on this planet there are cities (called regions). Within each city there are several districts (called Availability Zones). In those districts there are houses and buildings that people built for themselves.
On this planet there is a ruler called Amazon. The ruler owns most of the infrastructure — the roads, the land — and it provides pre-made houses, buildings, doors and entire rooms. If you need a house, Amazon deals with everything so that your house can live happily in one of the districts of one of the cities of planet AWS.
One day, a stranger asked Amazon to be allowed to organise their own building the way they liked. For example, they wanted the top floor to be on its own, isolated from all the other floors, and they wanted certain rooms to be grouped together so they could find each other easily.
What Amazon did was to give the person a bucket of labels from A to Z (the IP addresses inside a CIDR range — this is the VPC) and it told them:
With those, Amazon also gave a private post office (route tables) so you can write the rules for how packages travel from one door to another.
The person mentioned to Amazon that when they arrived on the planet, they were already given one building in each city, with one block of rooms already prepared in every district of that city.
Those, said Amazon, are your default VPCs — one per city, given to you at the beginning of your time on the planet. They are not empty: they already come with blocks (subnets), a door to the outside world and a working post office. You can use them as you wish, with certain restrictions that you will learn about in the next chapters.
Now that you have your own labels to address your private resources as you wish, said Amazon, I have other things to help you live happily in the city: a private road between two of your buildings so they can exchange packages without going through the public street (VPC peering), the ability for your post office to send and receive packages from outside your building (Internet gateway), and much more.
This gives you the flexibility to organise each of your buildings the way you see fit, while deciding exactly what is exposed to the internet and to the other inhabitants of planet AWS.
| In the story | In AWS |
|---|---|
| The planet | AWS itself |
| A city | A region (e.g. Frankfurt, eu-central-1) |
| A district inside a city | An Availability Zone (AZ) |
| Your building | Your VPC — one VPC per city |
| Your bucket of labels | The CIDR range of the VPC |
| A block of labels | A subnet — one block assigned to a district |
| One label | One private IP address |
| A door | A resource (its network interface) |
| The post office rules | A route table |
| A door to the public street | An internet gateway |
| A private road between two of your buildings | Endpoints (or VPC peering for cross regions) |
Keep this table in mind for the rest of the week — the next pages build directly on it.
One VPC in the Frankfurt region, split into two subnets — one in each Availability Zone.
Earlier in the course you saw briefly that a VPC is what isolates your resources from other people's resources and from the internet. With the city analogy in hand, we can now be more precise.
What a VPC actually is: a range of IP addresses (a CIDR) that belongs to you, inside one region, which you can cut into blocks, assign to Availability Zones, and route as you see fit between the services you own.
<aside> ⚠️
A VPC belongs to exactly one region, and it spans all the Availability Zones of that region. A subnet is the opposite: it lives in exactly one Availability Zone. If you need resources in two regions, you need two VPCs.
</aside>
Let's take an example: you have 4 machines, 2 in Availability Zone A and 2 in Availability Zone B, in the Frankfurt region (eu-central-1).
You request a VPC with the CIDR 10.0.0.0/16 (we will look at how CIDR works in more depth later in the course). That range covers 65,536 addresses, from 10.0.0.0 to 10.0.255.255 — far more than you need today, and that is fine: the CIDR of a VPC cannot be changed after creation, so it is normal to ask for a large range and use only a small part of it.
Since a subnet belongs to exactly one Availability Zone, and you are using two of them, you need two blocks (subnets):
Subnet A — 10.0.1.0/24 — Availability Zone A |
Subnet B — 10.0.3.0/24 — Availability Zone B |
|---|---|
256 addresses: 10.0.1.0 → 10.0.1.255 |
|
| of which 251 are usable | 256 addresses: 10.0.3.0 → 10.0.3.255 |
| of which 251 are usable | |
Machine 1: 10.0.1.10 |
|
Machine 2: 10.0.1.11 |
Machine 3: 10.0.3.10 |
Machine 4: 10.0.3.11 |
You now have two subnets, one per Availability Zone, and plenty of addresses in each of them for your machines.
<aside> 🧮
Why 251 usable and not 256?
AWS reserves 5 addresses in every subnet: the network address, the VPC router, the DNS server, one address kept for future use, and the broadcast address.
This is also why AWS refuses subnets smaller than a /28: a /28 contains 16 addresses, so only 11 of them are usable. It is one of the most common surprises for beginners.
</aside>
Two more rules that will save you time later:
So at this point, your machines can speak to each other — and that is all they can do. Nothing comes in, nothing goes out.
The rest of this week is dedicated to the different ways you can let those machines talk to the internet, to AWS services and to each other under controlled rules, so that you can build complex applications while keeping a secure, controlled and isolated environment.
This video presents another way of thinking about a VPC. Watching it is optional, but a second angle on the same concept often helps it stick.
https://www.youtube.com/watch?v=7_NNlnH7sAg&
Out of the box, AWS provides you with one default VPC per region, containing one public subnet in each Availability Zone of that region, an internet gateway, and DNS resolution already enabled.
The goal is to let you start quickly on simple things — a static website server, a blog — that need to be reachable from the internet. If you are curious about what exactly is in the box, you can read more here.
<aside> 💭
In most projects you will want to create one or more VPCs dedicated to your own application, rather than using the default one. That way you control your architecture and your security from the ground up.
</aside>
By the end of the week you should be able to answer questions such as:
/28 CIDR. How many EC2 instances can you launch into it?Right now your machines can only talk to each other. Next stop: opening one of your subnets to the internet, with Public subnets and Internet Gateway