VPC Security and Control
Basic Networking Concepts
Introduction to AWS PrivateLink
VPC Sharing using the AWS Resource Access Manager
Inter-Regional and Intra-Regional Communication Patterns
Understanding Direct Connect, Implementation and Configuration
Understanding AWS Direct Connect - Connectivity Options
Examining AWS Routing
DNS & Content Delivery on AWS
Managing Public and Private SSL/TLS Certificates using AWS Certificate Manager
The course is part of this learning path
This section of the AWS Certified Solutions Architect - Professional learning path introduces you to the core networking concepts and services relevant to the SAP-C02 exam. We start with an introduction to the AWS Virtual Private Network (VPC) and networking services. We then understand the options available and learn how to select and apply AWS networking, DNS, and content delivery services to meet specific design scenarios relevant to the AWS Certified Solutions Architect - Professional exam.
Want more? Try a Lab Playground or do a Lab Challenge!
- Get a foundational understanding of VPCs, their security, and connectivity
- Learn about VPC sharing using the AWS Resource Access Manager
- Discover inter-regional and intra-regional communication patterns in AWS
- Learn about AWS Direct Connect, along with its implementation, configuration, and connectivity options
- Understand routing in AWS, including static and dynamic routing
- Understand the basics of networking, including Elastic IP addresses, Elastic Network Interfaces, networking with EC2, VPC endpoints, and AWS Global Accelerator
- Learn about the DNS and content delivery services Amazon Route 53 and Amazon CloudFront
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 allowed. 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.
Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.