AWS VPC — 101
I think networking in AWS is a topic that easily gets me jumping in my seat to either read up on or learn more about. I have loved learning about it and if I can share even a smidge of that excitement and fun with you I’ll be over the moon!!
When you can create your own custom VPC from scratch, and understand the bits and pieces that go into making it functional, secure and scalable you’ll really feel the power go straight to your head.
In this short blog, well I’m planning a short blog let’s see how this actually goes, I will be covering the following:
- What in the AWS world is a VPC?!?
- What’s in your pie? I mean your VPC**
- Subnets — mini VPCs
- NACLs — what goes in must always/maybe/sometimes come out
- It’s not about the destination, it’s about the journey, except in this case it is about both
So without further ado, let’s go go goLang!
What in the AWS world is a VPC?!?
I want you to imagine a datacenter, a single entity. In the middle of nowhere, disconnected from anything and everything. Life is good, security is easy, just remember to lock the front door and all is good in the world.
Now that’s great if you don’t need to connect to anything and nothing needs to connect to you, but in the real world things are a litttttllleeee more complicated. Annoyingly, everyone wants to connect, the nerve smh. So what we have to do is control what goes out, and more importantly, what comes in.
A VPC is basically a massive ring fence around your AWS services. It is a logical isolation, a mini datacenter in the cloud in terms of connectivity. And you can have up to 5 VPCs per region per AWS account. They can be completely private, like our lovely datacenter in the middle of nowhere example above, completely public, or more appropriately you can configure them to be a bit of both. And VPCs operate in the private zone in AWS.
This is where you can think about AWS services that exist in one of two different zones, one being the public zone, and the other being the private zone. The public zone hosts AWS services that are accessible over the public internet, services such as S3, SNS etc. and to interact with these services you need to go via the public internet and that means configuring your VPC for internet access.
Private zones are those that host services within your VPC and network traffic stays within the AWS network without needing to travel over the internet… stuff like EC2 and SQS etc. hence the P for Private in VPC.
This is an important concept to have in mind when we later explore enabling our private services to reach out to the public internet. But I’m jumping ahead slightly.
What’s in your pie? I mean your VPC**
Creating your first custom VPC from scratch is really a coming of age task that shows you are levelling up in your AWS knowledge. So let’s walk through what you’ll need to know before you attempt this 😊
Before you go creating ANYTHING, you’re going to need a CIDR range for your VPC (Classless Inter-Domain Routing). This is the chunk of pie you allocate to your VPC, it says I am allocating this many IPs to the resources in my VPC. Be careful in your allocation, as VPC CIDR blocks can’t be modified later on (there are ways around adding more but you can’t directly modify the CIDR block of a VPC you made). So allocate wisely.
This VPC CIDR block is where your resources will get their private IPs from, and how you can further segregate your network into subnets. These private IPs are how components and services interact and recognise each other. Try looking for a friend of yours in a dark room where no one has a name, other than a creepy good idea for a book this is precisely how a no IP world looks like.
Without enough free private IPs your resources will fail to launch.
The minimum size your VPC can be is a /16 and the maximum being a /28 with 65,536 and 16 IPs respectively.
Once you have your perfect CIDR range you’re ready to do business 😎
Subnets — mini VPCs
Subnets are just that, sub-nets. They are a portion of the VPC, almost like mini VPCs, they have their own access controls defined called Network Access Control Lists (or NACLs if you’re part of the cool acronyms gang). Again exactly as they sound, they are quite literally a list of rules that define what can access the subnet from a network perspective. They also have CIDR ranges, again these are derived from the CIDR range of the VPC. Where the VPC is the pie, the subnet is a delicious slice.
The size of the subnet is also very configurable. Since you have to have at least 1 subnet in the VPC the max size of a subnet can be equal to the size of the VPC it is in (/16). And like every other serving of pie, your slice, once removed and gobbled up isn’t available to anyone else. In the same way subnet CIDR ranges, if you have more than one subnet, can not overlap. Joey doesn’t share food and subnets don’t share CIDR ranges.
AWS services and resources are deployed into subnets. And subnets are generally used to purposefully separate your services into those that should be publicly accessible (e.g. a web server) to those that shouldn’t be (e.g. a database server). I’ll summarise what we’ve covered so far in the diagram below. We’ve only started peeling the onion but already so far we’ve covered a lot of ground so well done!
Next up we have …..
NACLs — what goes in must always/maybe/sometimes come out
NACLs (Network Access Control Lists) are where many of your unnecessary connectivity woes will come from, unless you understand them properly and implement them correctly.
For each subnet you have an assigned NACL. A literal list of INBOUND and OUTBOUND rules, for which every connection coming IN or going OUT of the subnet is evaluated against.
The order of the rules in the list is VERY important, the rules are evaluated in order and the first rule that matches the incoming or outgoing traffic is immediately applied. So none of the subsequent rules are considered, this is another very IMPORTANT point to keep in mind… that’s why I said “IMPORTANT” and not just “important”. Rules can explicitly ACCEPT or DENY traffic that matches.
Your default NACL rule will normally start at 100 — as you can see in the image above. And the subsequent rules will be in increments of 100 so that you can easily add rules in-between (e.g. 99) should you need to quickly add a matching DENY to block an IP.
So say you know there is a malicious person trying to gain access to your systems or maybe your aunt is annoying you so you don’t want her accessing your web server, been there done that 👍 . All you need to do is get her public IP address on the down low, sneaky sneaky, and add an INBOUND DENY rule for it. Serves her right tbh!
NACLs are super useful, all you have to do is create an inbound rule with a low enough rule number to ensure no other rules prior to it match — NACLs generally start from 100 so you have the chance to create an earlier rule with ID 99. And set the inbound rule to DENY traffic from your selected IP address.
Make sure you don’t have a rule that’ll be evaluated and match earlier than the one you have added. If you have a rule that has an ID of 99 (that’s execute before your rule with ID 100), and it states all traffic from everywhere is ALLOWED. Well guess who’s aunt still has access… 😓
NACLs are also STATELESS (unlike Security Groups). Remember this phrase. It is very important. This means connections made into the subnet are seen as separate to their responses. For example, a request from your laptop to an EC2 in a public subnet is seen as as inbound connection, one that has to be allowed via your NACL (Rule #1). But, if you don’t also allow the response traffic via an outbound rule (Rule #2), your systems will behave strangely and look all healthy and happy from the server side but you’re going to have some very annoyed customer and one really annoyed aunt… so a lose-win scenario here 😂
It’s not about the destination, it’s about the journey, except in this case it is about both
Now you’ve got your fancy new VPC, with your public and private subnets allocated and a few resources deployed you say: “Hamzah, you said subnets are like mini VPCs, with NACLs controlling access… but how do the subnets talk to EACH OTHER?!?”
Great question!
This is where routers and route tables come in. Routers are implicitly created in AWS so you don’t need to worry about their existence, creating them or ever worrying about them, AWS will do that for you, nice, right? Routers will use routes defined in the route table to route your traffic. Route tables — a thing you DO have to worry about!
You can have more than one route table, this is normally how subnets are categorised as private or public, private subnets are associated to route tables that don’t have public routing available. Can’t go anywhere that isn’t defined in a route table 🤷♂️
Each entry in the route table defines a destination your resources want to reach, and a means of getting there, whether that is local to the VPC, via a gateway (in the above figure of a sample route table we have an internet gateway: igw-7572670e), a network interface or another target.
By default, you have a main route table that connects all the subnets so the resources in each can speak to each other (the local target defined above). If you create your own route tables and subnets however, which you really really reaaaalllyy should for private resources, you have to associate the subnet with the route table.
Each subnet can only be associated with 1 route table — to define the routes for its resources. BUUTTTT route tables can each have many subnets. So that many subnets can share routing to the same destinations 😊
Note: the AWS public and private zone are not the same as your public and private subnets. The public subnet accesses the internet via a gateway, more on this in a later article, I’m bouncing in my seat just thinking about it!
Those are the main aspects of a VPC, but before we finish a little bonus content I want to cover because I can’t wait and really it helps clarify the public zone and private AWS zones I mentioned earlier is…
VPC Endpoints
Its funny because we’re at the “end” of the blog and I’m talking about VPC ENDpoints… 😂 thank you, thank you, I’ll be here all night ✌️
When you’re building out infrastructure in AWS it is easy to forget, or more so it is difficult to notice that not all services you connect to are via the ginormous AWS network backbone. That is until you’re trying to list your S3 buckets from an EC2 in a private subnet and for some reason it just won’t work because you didn’t read this section that told you: Services that exist in the public AWS zone are accessed through the pubic internet. Shame, shame.
This means your traffic must leave the comfort and safety of the AWS backbone network and travel into the accessible and open public internet, not always a path everyone wants to take.
Anything inside a VPC exists in the private AWS zone. To ensure connectivity from say, for example, your EC2 instance in a VPC to S3 — one of the most popular AWS services, you have to configure your VPC to access the internet (something we’ll look at in a later blog post). That’s fine and no biggie, but it’s a big biggie if you operate in a sector where security is more than a mild concern — this should probably be every sector tbh 😅
Say you can not have certain data you store in S3 travel over the public internet, you need it to go over the AWS private backbone network. This is exactly where VPC endpoints come in.
Using a service called Private Link, these otherwise public zone services are injected into your VPC and become accessible even if your VPC is configured to be private — no public internet access. Works like magic!
VPC Endpoints are a big topic, one that’ll need their own write up, but I hope you’ve enjoyed the taste of VPC life so far, and you’re now comfortable with some of the terminology and what NACLs and Route Tables are used for. I will have deep dives into each of these and how they allow you to secure and scale your networks coming soon 🙌🏼
Until then stay safe, stay fresh and keep being AWSome 😎
