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> 🧱
Step 1 of 3 — building the week's architecture
The diagram on the Week 4 overview page has three machines sitting in three different subnets. We are going to build that diagram one layer at a time, and each section adds exactly one layer:
By the end of the third section you will have rebuilt the whole diagram yourself, and the last page will put it back together as one picture.
</aside>
So far we have seen that:
For an EC2 instance to be able to be given an IP address you will need to split your VPC into separate blocks tied to Availability Zones, called Subnets.
Think back to the building analogy: the VPC is your bucket of address labels, and a subnet is the block of labels you assign to one floor of one building, in one district. Nothing can move in until a floor exists.
In this section we build the first floor that faces the street: a subnet whose traffic is allowed to reach the internet, with a web server in it. This is the only tier of the whole architecture that the outside world will ever talk to directly — everything we add in the next two sections is deliberately hidden behind it.
By the end of this section you will have this:
A VPC is defined first and foremost by a CIDR block: the range of private IP addresses you get to carve up yourself. Creating one is essentially asking AWS: "reserve me this range of addresses, in this region, and let me organise it as I see fit."
eu-central-1 — Frankfurt, same city as our earlier example).hyf-week4-vpc.10.0.0.0/16 (65,536 addresses — more than enough to experiment with).
At this point you have a private address range and nothing else — no subnet, no way in or out. Exactly as the analogy predicted: a VPC on its own is just a bucket of labels, not yet a building.
A subnet slices your VPC's CIDR block into a smaller range, and — critically — ties that slice to a single Availability Zone.
hyf-week4-public-subnet-a.eu-central-1a.10.0.1.0/24 (256 addresses).
<aside> 💭
A subnet isn't "public" or "private" by nature — nothing about it says so yet. What decides that is entirely the route table we attach to it in Step 3. "Public subnet" is really just shorthand for "a subnet whose route table sends internet-bound traffic to an Internet Gateway", not a special kind of subnet. We will see more about this in the next section.
</aside>
CIDR (Classless Inter-Domain Routing) notation expresses a range of IP addresses as <address>/<prefix length>. The prefix length tells you how many of the leading bits are fixed (the network part); the rest are free to vary and address individual resources (the host part).
A smaller number after the slash means a bigger range:
/16 → 65,536 addresses — a typical VPC size/24 → 256 addresses — a typical subnet size/28 → 16 addresses — a small subnet, e.g. dedicated to a NAT GatewayAWS also reserves the first 4 and the last 1 address of every subnet for its own use (network address, VPC router, DNS, future use, and broadcast) — so a /24 subnet gives you 251 usable addresses, not 256.
Use the tools below to build intuition before typing CIDR blocks into the console:
https://mxtoolbox.com/SubnetCalculator.aspx https://cidr.xyz
https://www.youtube.com/watch?v=KiWXRL-2TnY
<aside> 💭
To link here once it exists: the previous week's page covering the EC2 basics (launching an instance, AMIs, instance types, key pairs).
</aside>
This instance is the web tier of the architecture we are building — the only machine of the three that will ever have a public IP address. In the final picture it is the one receiving requests from real users; the app server and the database we add later sit behind it.
You already know the basics of launching an EC2 instance from the previous week — refer back to that walkthrough for the full flow. The only things that change this time:
hyf-web so you can tell the three machines apart later.hyf-week4-vpc / hyf-week4-public-subnet-a) instead of the default ones.hyf-web-sg that allows inbound SSH (port 22) from your own IP only, and inbound HTTP (port 80) from 0.0.0.0/0 so the web server can actually serve the internet.<aside> 💭
You just created your first security group without us explaining it properly — that is on purpose. For now, read it as "the list of traffic this machine accepts". In section 3 we come back to security groups seriously and use them to build the isolation between the three tiers.
</aside>
Note that in the current state, your EC2 machine have no public internet IP address and can not be reached from nor reach the outside. Don't worry if you can't reach it yet: without an Internet Gateway and a route to it, this instance is still cut off from the outside world. these are the next resources we will create
An Internet Gateway (IGW) is the door between your VPC and the internet. It's a horizontally scaled, redundant component fully managed by AWS — you don't configure bandwidth or availability for it, you just attach it to a VPC. A VPC can have at most one Internet Gateway attached at a time.
On its own, an Internet Gateway does nothing: it needs to be both attached to a VPC and referenced by a route table before any traffic actually flows through it. Creating and attaching it is only half the job — the route table in Step 3 is what turns "a door exists" into "traffic uses the door".
hyf-week4-igw.
A route table is a set of rules ("routes") that decide where network traffic from a subnet is sent, based on its destination address. Every subnet is associated with exactly one route table — if you don't explicitly associate one, it silently uses the VPC's main route table.
This is the step that actually makes a subnet "public": adding a route that says "any traffic that isn't for someone else in my VPC (0.0.0.0/0) should go to the Internet Gateway".
hyf-week4-public-rt, associated with your VPC.<aside> ⚠️
</aside>
0.0.0.0/0, target → your Internet Gateway.
