AWS Builder Center
Module 5 of My AWS Cloud Foundations Journey
Networking and Content Delivery

Module 5 of My AWS Cloud Foundations Journey Networking and Content Delivery

Module 3 covered where AWS runs. This module covers the network you build inside it — and it was the first module where I already knew most of the ideas under different names.

Series: My AWS Cloud Foundations Journey (5 articles)

  1. …
  2. 5
    Module 5 of My AWS Cloud Foundations Journey Networking and Content Delivery This article
KEY CONCEPTS
Amazon VPC — A Virtual Private Cloud is your own isolated network inside AWS. You choose its address range when you create it, written in CIDR (Classless Inter-Domain Routing) notation: 10.0.0.0/16 means every address is starting with 10.0.x.x, which is about 65,000 addresses. A VPC spans a Region, and nothing inside it is reachable from outside unless you configure that deliberately.
Subnets — A VPC is divided into subnets, and each subnet lives entirely within one Availability Zone. In the lab I built four: 10.0.0.0/24 and 10.0.1.0/24 in one AZ, 10.0.2.0/24 and 10.0.3.0/24 in a second. The /24 means each holds addresses ending .0 to .255, of which about 251 are usable.
Putting subnets in two Availability Zones is what makes high availability possible, which is the failure model from Module 3 applied to your own network.
Internet Gateway — A component attached to the VPC that allows traffic between resources inside it and the internet. Without one, nothing in the VPC can reach out or be reached.
NAT Gateway — Lets resources in private subnets reach the internet for things like software updates, without being reachable from the internet themselves. Traffic goes out and replies come back, but nobody outside can start a conversation.
Route tables — A set of rules determining where network traffic is sent. Every subnet must be associated with one.
This is where public and private subnets are actually decided, and it is more literal than I expected. A public subnet is not a different kind of subnet. It is a subnet whose route table sends 0.0.0.0/0 — meaning everything not local — to the Internet Gateway. A private subnet's route table sends the same 0.0.0.0/0 to the NAT Gateway instead.
The public subnet’s route table: 0.0.0.0/0 goes to the internet gateway.
The private subnet’s route table: same destination, but 0.0.0.0/0 goes to the NAT gateway instead.
Both tables also carry a route you cannot remove: 10.0.0.0/16 to "local". That is what lets every subnet in the VPC reach every other one. So the only difference between public and private is the second row of a table.
Security groups — A virtual firewall attached to an instance rather than to a subnet. You write rules for what traffic is allowed in, and they are stateful: if you allow a request in, the reply is allowed out automatically without a matching rule. Security groups only have allow rules, so anything you have not permitted is denied by default.
In the lab I created one permitting HTTP from anywhere and attached it to the web server.
Network ACLs — A second firewall, operating at the subnet level rather than the instance level, so it covers everything inside that subnet.
Two differences matter. Network ACLs are stateless, meaning return traffic is not automatically permitted and you must write rules for both directions. And they support deny rules as well as allow, which security groups do not.
That makes them useful for blocking something specific, such as a single address range, across a whole subnet at once. Most of the time security groups do the work and the default network ACL is left permissive.
VPC peering — A connection between two VPCs that lets resources in each reach the other using private addresses, as though they were on one network. Useful when two parts of an organisation run in separate VPCs and need to talk without going over the public internet.
One limitation worth knowing: peering is not transitive. If VPC A is peered with B, and B with C, A still cannot reach C. Each pair needs its own connection.
Amazon Route 53 — AWS's DNS service, which translates a domain name into the address of whatever should answer it. Beyond basic lookups it can route by latency, sending each user to whichever Region responds fastest for them, and it performs health checks so traffic stops being sent to something that has failed.
It runs at the edge locations from Module 3, which is why lookups are answered from somewhere nearby.
Amazon CloudFront — The content delivery network, also running at edge locations. It caches your content close to users so repeat requests are served nearby rather than travelling back to the Region every time. A file originating in Ireland can be served to someone in Lagos from a site much closer to them.
It also terminates TLS at the edge, which makes connection setup faster, and it can sit in front of an application rather than only static files.
WHAT CLICKED FOR ME ?
Every piece of this module was something I had already done by hand, without knowing it had a name in AWS.
Three weeks ago I built a network scanner in Python on an Ubuntu virtual machine. To make it work I had to find my subnet, work out that a /24 meant hosts 1 to 254, and eventually diagnose why no traffic was leaving the machine. In doing that I ran ip route and saw a line beginning "default via", pointing at my gateway. I turned on ufw and watched my VM stop answering pings.
Those are the same five concepts. A VPC is the private network. Subnetting is the arithmetic I did from ip addr show. A route table is ip route. The Internet Gateway is that "default via" line. A security group is ufw.
What AWS adds is that you draw it instead of wiring it, and you can create a second Availability Zone's worth of it in about thirty seconds.
The other thing I will keep is from debugging the lab. My web server returned nothing, and the browser said ERR_CONNECTION_TIMED_OUT. That is a different error from "connection refused" — refused means a machine answered and said nothing is listening, timed out means nothing answered at all. One points at the application, the other at the network. Reading which error you got tells you which layer to look at before you check anything.
Connecting it
Each module has added a question to ask about any AWS service: where it sits on the IaaS to SaaS scale, what drives its cost, where it physically runs, and where my security responsibility begins. This one adds the most concrete question of the five — what can reach this, and by what route.
Part of my AWS Academy Cloud Foundations learning series.

Series: My AWS Cloud Foundations Journey (5 articles)

  1. …
  2. 5
    Module 5 of My AWS Cloud Foundations Journey Networking and Content Delivery This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article