Welcome to part 12 of a multiple part course on passing your AWS Architect, Developer & Sysops Associate exams. The best part…this course is totally free of charge!
This is the last of our series on Virtual Private Clouds (VPCs). VPC’s are by far the hardest part of the aws associate exams. So I want you to really focus on them. If you haven’t read my earlier posts on VPCs then I highly recommend going through them and then returning to this summary post. Although I do go over the main topics in those articles here.
In this article we’ll review all you need to know about VPCs for the exams and cover a few smaller topics that don’t warrant their own posts.
The article will take just 10 minutes to read and after doing so you’ll have all you need to know to answer any VPC questions to pass the AWS certifications.
If you are studying for the:
- AWS Associate Architect
- AWS Associate Developer
- AWS Associate SysOps
Or you are using AWS and want to learn more about VPCs then this is the article for you.
OK let’s dive in…
Below is a typical example of a VPC setup. It’s usually made of up several components including:
Internet Gateway: Each VPC has only one internet gateway. It allows the instances inside your VPC access to the internet and allows vise versa.
Virtual Private Gateway: Again, very similar to the internet gateway, allowing an entry point to access the VPC from a remote session.
Router: Dictates where traffic entering the VPC should be sent to.
Router Table: contains a subset of rules determining which subnet traffic is sent to. All subnets must be associated with a route table.
Network Access Control List (NACL): acts as an optional firewall that sits outside of your subnet. All the rules defined in the nacl apply to all of the instances in the subnet.
Subnet: a range of IP addresses that house instances. Each subnet must be allocated a availability zone.
NAT gateway: a means for instances that reside in private subnets to access the internet for tasks such as software updates.
For more information on VPC overviews checkout my VPC introduction article.
VPCs are region specific and there is a “limit” on the number of VPC’s you can have per region. That limit is 5. However you can easily increase that limit simply by contacting AWS support and requesting the limit be increased.
You can not specify multiple internet gateways per VPC. You get only 1 per VPC. This shouldn’t be an issue as they are highly available and if one were to fail then another availability zone would take over.
A concept that is important to get your head around early on is that a subnet does not span multiple availability zones. This basically means that the hardware that the subnet lives on is all roughly in the same place. I suspect this is for performance reasons but you don’t really have to understand why, just that this is a restriction on subnets.
The default VPC that gets created when you account is setup has subnets associated with it. However they all have internet exposure. None of them are private. This is to make setting up AWS resources simpler initially.
Lastly, Network Area Control Lists or NACLs for short let you block specific IP address and allow others for your VPC and subnets. This gives a much greater level of control.
NAT gateways are generally prefered against NAT instances.
For nat instance, you must remember to disable source/destination check for each nat instance.
NAT gateways/instances must be placed in public subnets.
You’ll need to configure the routing table of the private subnet to receive traffic via the nat gateway/instance.
You bandwidth for nat instances is limited by the size of the instance it’s running on.
You can achieve high availability from a nat instances via auto scaling groups and you can achieve high availability from nat gateways via multiple availability zones.
For more information on NATs check out NAT Instance vs NAT Gateway Certification Guide.
When you create a VPC or use the default VPC that gets created with your AWS account. AWS will automatically create a NACL inside it that all subnets will connect to by default unless you point them to another NACL instead. This default NACL will allow all inbound and outbound traffic.
When you create a nacl, unlike the one that gets created with your VPC. This one will deny all inbound and outbound traffic until you add rules to the contrary.
As we touched on in the What is a NACL section a nacl can be associated with many subnets. However you can’t associate a subnet with many nacls. Once you associate it with one, if it were linked to another previously, then that link would be removed. By default subnets are associated with the default nacl created when the VPC was set up.
Rules for nacls are evaluated in numerical order. Where as security groups evaluate all rules regardless of their order.
Security group rules apply to both inbound and outbound traffic where as nacls can specify rules for both.
NACLs can be used to block specific IP addresses from accessing your subnet.
For more information on Network ACLs checkout AWS Network ACLs vs Security Groups – A Comprehensive Review
While we’ve covered that majority of what you need to know about VPCs in the past 4 VPC articles. There is a few smaller categories you should know about that are too small to warrant their own posts. Therefore I’ve bunched them up into the remainder of this article.
Read through them and you won’t need to understand them at any greater detail that what’s outlined here.
VPC flow logs are a way of capturing and recording IP traffic data that enters your VPC from its network interfaces. As the data is collected it is stored in Amazon CloudWatch Logs. When a flow log is up and running you can review and retrieve data in Amazon CloudWatch Logs.
Flow logs can be created at 3 levels:
- Network Interface Level
Tags are currently not supported by flow logs.
After a flow log is created, you can NOT change its configuration
You can not enable flow logs for VPCs that are peered with your VPC, unless you enable VPC peering for your account.
Not all traffic is monitored by flow logs, notable exceptions include:
DNS server traffic from your VPC instances.
Traffic generated by windows instances searching for windows license activation.
Traffic from the reserved IP address for the default VPC router.
Chances are you’re going to see 1 question tops around this subject in any of the exams.
ELBs are covered in greater detail in the EC2 section of the course so we won’t go over that ground again here. Instead all you need to know is that when associating a VPC with an ELB you must place your load balancer in a publically facing subnet.
In addition you must all allocate at least 2 availability zones for it. This is to increase availability. If you attempt to set only one then the AWS console will prevent you from doing so.
VPC endpoints simply allow for you private instances to access AWS resources such as S3 without the need to gain public internet access. Which of course instances that reside in a private subnet won’t have. By configuring a vpc endpoint those private instances will now be able to access services such as S3 without the next to go via a NAT gateway.
VPC peering is essentially a strong link between 2 separate VPCs. It allows for communication between the 2 VPCs over private IP addresses as if they were in the same network. You create VPC peering between VPCs within the same account or even VPCs across multiple accounts provided they are in the same region.
Things to note about VPC peering is that you can’t peer 2 VPCs if they share overlapping IP address ranges.
Put simply, a bastion server is a way to access at an administrative level instances that reside in private subnets. While a NAT instance/gateway is useful for those private instances to download updates for operating systems and software they can not be used to directly SSH into the instance itself remotely.
This is where a bastion server comes in handy. Typically you’d have a setup where 1 bastion server that resides on a public subnet can then connect to many private instances in your private subnets. The reason behind this is you increase security by having a single entry point for multiple servers as opposed to multiple bastions which would all need strong security put in place.
That’s pretty much all you need to know about bastion servers for the exam.
VPC is by far the hardest section to learn when taking on the AWS association exams. Take the time to really get to know them and have a go at creating a VPC from scratch in the AWS console. I highly recommend you get some hands on use of VPCs and don’t really solely on learning the theory.
After All it’s pretty likely that if you are going to work with AWS regularly then you’re going to be working with VPC’s a lot!
Ok that’s the end of our VPC section. Next we’ll take a look at the newest kid on the block and my personal favorite… Lambda.