This is a high-level overview about the most foundational and important pieces that make up the AWS cloud. Some prior knowledge of IP addresses would be beneficial, but not crucial.
Not fully understanding the minutiae of how all the parts of the final architecture of your first cloud environment fit together can feel pretty demoralizing. There are guides out there where you configure VPCs, create private and public subnets, bring up internet gateways, set up route tables and security groups, learn about CIDR values and more overly technical and monotonous topics prior to setting up an actual resource. In this guide we'll cheat a little and work backwards.
High-Level Overview
A computer on the cloud is called an instance. An instance in the cloud needs to be surrounded by several logical parts.
A VPC (Virtual Private Cloud) to exist inside of. The VPC acts as a big network foundation you put your resources into. You can have multiple VPCs on your AWS account, but we will be dealing with only one.
Computers also need a subnet to also exist inside of. Subnets logically divide up your VPC networks. You can have over 200 subnets in your VPC, but ours will have 2 public subnets, and 2 private subnets.
Public subnets are networks that are set up in a way that makes them capable of sending outbound connections and receiving inbound connections. We place resources such as instances in a public subnet only when we want them to be publicly accessible. Resources in a public subnet have public IP addresses, but still need to communicate via gateways.
Internet Gateways (IGW) allow communication between your VPC and the internet. Any messages going out or coming into your VPC go through internet gateways. The IGW in our example will allow resources in our public subnets to communicate in and out of the VPC.
Private subnets are locked-down networks for more security-sensitive resources. We usually customize these subnets to not allow any outbound or inbound internet traffic at all. Private subnets usually only allow incoming traffic originating from inside the VPC. Resources in private subnets have private IP addresses, and as such can not directly communicate with entities outside their own subnets.
Egress-only internet gateways are IGWs that only allow outgoing connections. They're perfect for resources in private subnets that need to send data out, but restrict data coming in. Our Egress-only IGW will allow resources in our private subnets to communicate out.
Putting our Pieces Together
How do our resources know the path to take to talk to each other? How would an instance in one of our subnets know the route to take to get to the internet? That's where route tables and security groups come in.
Don't worry too much about the difference between IPv4 and IPv6 for this next part, as it's not directly pertinent to learning about route tables and security groups.
Route tables are the rules/routes that your subnets and gateways use to tell where network traffic should go. You can associate route tables with VPCs, subnets, and gateways to create granular rules.
The traffic (the combined one-way arrows) from our two private subnets will check their associated route tables to see how to get out to the internet. They need to get to the destination IPv6 address of ::/0 (all IPv6 addresses). Their associated route table would look like this (if our EIGW were named eigw-085cafaa7d336afe3):
Similarly, the traffic (the combined omni-directional arrows) from our two public subnets will check their associated route tables to see how to get out to the internet in the same way the private subnets do. However, they also are able to route locally within the VPC to each other. To route somewhere within the VPC, they need to look locally. To get online, they need to get to the destination IPv4 address of 0.0.0.0/0 (all IPv4) addresses).
Their associated route table would look like this (if our IGW were named igw-000a3e7df40c14edd):
You can think of the arrows in our diagrams as visual representations of our route tables. A one-way arrow allows one-way traffic, and a two-way arrow allows omni-directional traffic. I've added some bolded omni-directional arrows to the center of our diagram for our next step:
Now all our subnets, both public and private, have routes to each other. The route tables for our private subnets look like this:
The route tables for our public subnets look like this:
There you have it. A segmented group of two public subnets, two private subnets, one IGW, and one EIGW all communicating with each other within a VPC. Any resources in our private subnets can send data out, and any resources in our public subnets can send and receive data.
There's a lot more to complexity that comes into play once you put resources like instances or databases into these subnets. I will be following up this post with an incredibly easy way to bring up all the resources we covered in this post. It will be linked here when it's up.
