The course is part of these learning paths
VPC Security and Control
This course has been designed to give you an overview of the AWS Virtual Private Cloud and its associated networking components. This will help you to architect and build your VPC for a variety of different work loads and use cases. The topics covered within this course include:
- Virtual Private Clouds (VPCs)
- Route Tables
- Network Access Control Lists (NACLs)
- Security Groups
- NAT Gateways
- Bastion Hosts
- VPN and Direct connection
- VPC Peering
- AWS Transit Gateway
Who should attend this course?
Those who are relatively new to AWS to gain a better understanding of how to construct and architect virtual private cloud
Those looking to learn more about AWS networking features and components
Those studying for the AWS solutions architect certifications
- Confidently architect a VPC across multiple availability zones within a Region
- Explain different networking components commonly used within AWS VPCs
- Secure your VPCs, helping you to protect your resources within them
- Assess which method of connectivity to your VPCs would be best in different scenarios
To get the most from this course then you should have some exposure to AWS, for example, EC2, however, this is not essential.
Security is a key part of any deployment within AWS, and managing security around your virtual private cloud is no different. So I want to talk to you about a couple of different components here.
Firstly, I want to talk to you about NACLs which are network access control lists. Now these are essentially virtual network-level firewalls that are associated to each and every subnet, and they help to control both ingress and egress traffic moving in and out of your VPC and between your subnets. So let's just quickly draw out our VPC. Very simple, and let's just draw in a public subnet for example. So this is going to be public. Up here, we'll have our internet gateway attached to our VPC, and obviously, we have a route out to the gateway, which then communicates with the internet.
So what we can do here to help maintain security is to configure the network access control list associated to this subnet. Now much like route tables, whenever you create a new subnet, it will also associate a network access control list. Now by default, this NACL will allow all traffic, both inbound and outbound, so it's not very secure, so it's a really good practice to configure your NACLs to only allow the traffic that you want to come in and out of your subnet.
Now with this being a public subnet, we'll probably have some web servers in here talking over HTTP and HTTPS, so let's look at the inbound network access control list that could be associated to this subnet. Now as you can see, there's a number of different fields. We have the rule number, the type, the protocol, port range, source, and allow or deny. Now the rule numbers allow you to specify what order the rules will appear inside the NACL, and as soon as traffic hits one of these rule where it matches all of the type, protocol, port range, and source, et cetera, it will carry out the action at the end, whether that is allow or deny.
So let's look at the requirements required to match this rule here. The type of traffic will need to be HTTP under port 80 using the TCP protocol, and again, the port range is 80 as that's what used for HTTP. Now the source can be any IP address, so any IP address running HTTP coming into our subnet will be allowed. So as long as they're running this protocol, then the traffic will be allowed inbound into our public subnet.
Now let's look at the second rule. Now the second rule uses HTTPS using the TCP protocol using port 443, and again, any source, and the action will be allow. Now the last rule here, now this is a default rule that's applied at the end of every network access control list, and that's why it doesn't have a rule number, and it states that all traffic using any protocol in any port range from any IP address, then deny that access. So this rule is kind of a cover rule. So basically, what that allows you to do is ensure that any traffic that doesn't meet the rules that you've entered is deleted and denied access to your subnet.
So with this in mind, the only traffic allowed in our public subnet is essentially HTTP and HTTPS, which is exactly what we want for our web servers here, and all other traffic will be denied. So that's the inbound NACL. Let's now take a look at the outbound. Now the field types are all exactly the same other than this one here. This has a destination whereas on the inbound, it has the source. So on the outbound, we restrict traffic against its destination.
So the first rule we have here says any traffic using any protocol in any port range going to any destination, then allow that traffic. Anything else should be denied, but in this case, there won't be anything else because this outbound rule is essentially saying send any traffic you want to using any protocol out from this subnet to any destination.
Now an important point to make about NACLs is that they are stateless, and this means that any response traffic generated from a request will have to be explicitly allowed and configured in either the inbound or the outbound ruleset, depending on where the response is coming from. Now again, much like route tables, you can have the same NACL applied to a number of subnets, but only a single NACL can be associated to one subnet. So network access control lists are a great way to control traffic that comes into and out of a particular subnet.
Let me now talk about security groups, and these are another method of controlling traffic, but this time, they work at the instance level rather than the network level like NACLs do.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data centre and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 50+ courses relating to Cloud, most within the AWS category with a heavy focus on security and compliance
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.