A knowledge of Amazon Virtual Private Cloud (VPC) is needed to understand some of the underpinning concepts of AWS. You would have had some exposure to it if you did any of the EC2 tutorials in the previous article.
Now, I never experienced ‘direct’ questions about VPC in my practice papers or in my exam itself, but that doesn’t mean you won’t. In this article I’d like to go through VPC so you have some awareness of its place within the AWS ecosystem.
Tldr: most of this is for your own understanding of how to do the job, rather than just stuff for the exam. So you can skip this week if you really want, but I think an understanding wouldn’t hurt.
VPC is the way by which we launch resources into a virtual network (after all these cloud resources need to live somewhere). The idea is to combine the flexibility in configuration that you have in your own networks but with the ease of management (in theory) of AWS.
The VPC Whitepaper is a bit dry, but you can read if you wish. Most of what you need for an overview can come from the user guide itself, and just having an understanding of what the routing options are.
So even though I already know a bit about VPC from work, I’m taking the opportunity to give myself a refresher. I’ll try and combine the high level players with their connections/interdependencies to see if I really understand them.
The VPC is the where my AWS account is associated with ‘network space’ – in other words, where I ‘pretend’ that I’m actually a private network. For example in my VPC setup here, we can see there are 2 VPCs here with private addresses of Class B.
We use these to segregate resources. A classic example of this might be one subnet for EC2 instances reachable from the outside world and another for an RDS instance.
My account can create multiple VPCs and each VPC has an overarching CIDR block. I can break down the VPC CIDR blocks into different subnets to deploy/segregate resources.
Notice how my original 10.0.0.0/16 CIDR block associated with the vpc starting vpc-of4dad has been broken down and associated with 2 subnets 10.0.0.0/24 and 10.0.1.0/24. There are plenty of tools to help if you want to experiment with/learn about CIDR.
Subnets go hand in hand with availability zones too, looking at the diagram above, the 172.31 subnets all have distinct availability zones. So it’s both a mechanism for segregation of resources and designing for failover.
You can set up rules at both the subnet and VPC level (more specifically for the larger CIDR range of the VPC). This is just like routing you would do on any other network, although you should know about the ‘implied router‘.
Think of it as if you were to SSH onto an EC2 instance within the subnet and run the route command. You’d see an entry that tells you that you need to go via the IP of 10.1.24.1 as your default gateway – so the host 10.1.24.1 is the implied router.
It’s not much use having these private network resources if we can’t get to them from the outside world one way or another. So when resources need to reach the outside world (or be reachable) we use an internet gateway.
A gateway is assigned to a VPC, and then it’s up to the routing tables as to whether allow instances to use that gateway. The route table below, for example allows access to the gateway for any destination that’s outside of the 172.31.0.0/16 range.
There is (recently) such a thing an an egress only gateway, whereby you can reach out to (and get replies from) the internet, but not accept connections initiated from the outside word.
The internet gateway might be ok for resources themselves but the VPC endpoint is something a little different. This is a way of setting up a ‘private channel’ between a VPC and other AWS resources, but without going out via the internet.
That takes us back to the first point about the illusion of the private network. If we’re able to reach resources in other VPCs and and AWS accounts, and we’re able to do so without leaving the AWS backbone, we must ultimately all be under the same network, albeit segregated, and subnetted from each other.
VPC Routing Options
The white paper lists various routing options – I think it’s enough to just be aware of the different types until you day job calls for it.
The main types of connection that I took from the guide was.
- Connecting your network into AMazon VPC
- Connecting VPCs to other VPCs
- Connecting an internal user to a VPC
If you’re interested in my take from the white paper, you can view my flashcard set here.
VPC Security and Network Access Control Lists
Since security is a big part of the AWS exam, how it fits into the VPC is something we should focus on.
We covered EC2 instances and you should be aware that instances get assigned the default security group of the VPC if you don’t specify otherwise. That might not be what you want when trying to lock down instances so be aware of which group is being assigned and for which reason.
I have made a questions sheet for you if you want to skim that before reading through the documentation.
If you do want to try out VPC ‘in anger; then I got a lot of value out Ben Piper’s course on Pluralsight, but I had an existing subscription and what I learned was for my day job, and not this exam. (But then that was my motivation for writing this study plan, to be able to actually understand the concepts).
If you’re after a free tutorial, this one comes with decent ratings, but I haven’t followed it myself. Also, by doing EC2 tutorials, you will get some exposure to VPC concepts anyway.
The VPC underpins so many technologies in AWS that I think it’s worth investing time in it. Even some indirect knowledge that you gain from understanding it can pay dividends when you come to the exam.