VPC Security and Control
AWS Networking Components
AWS Network Performance
DNS & Content Delivery on AWS
The course is part of this learning path
This section of the SysOps Administrator - Associate learning path introduces you to the core networking concepts and services relevant to the SOA-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 services to meet specific design scenarios relevant to the SysOps Administrator exam
- Get a foundational understanding of VPCs, their security, and connectivity
- Understand the basics of networking including Elastic IP addresses, Elastic Network Interfaces, networking with EC2, VPC endpoints, and AWS Global Accelerator
- Understand how to connect multiple AWS networks together using different solutions
- Learn about the DNS and content delivery services Amazon Route 53 and Amazon CloudFront
So, staying with security, I now want to talk to you about security groups. Now these are similar to network access controllers where they filter traffic both inbound and outbound but whereas NACLs worked at the subnet level, security groups work at the instance level and I'll explain more about this as we go.
So let's say we have three subnets, okay, so we just draw these out quickly and these would be three private subnets, for example. Each of them will have their IP addresses listed, first one being 10.0.1.0/24. .2.0. And the last one, 3.0. Now this first subnet will have EC2 instances in them. The second subnet will have RDS instances running MySQL or Aurora and the last subnet here will also have EC2 instances in them.
Now each of these three subnets are associated to the same network access control list. So, this one is linked with this one and also this one. And this network access control list looks like this. And this is simply saying that any traffic that is running a TCP Protocol across any port range from any source, then allow it and deny all other traffic. So, between these subnets, any TCP Protocol on any port can be used and for simplicity, the same NACL rules are being used for both inbound and outbound. Now that's not very secure, it's not very restrictive but from a subnet network level, that is what it's controlling. Now what we want to do is restrict access to which instances can actually talk to our RDS and Aurora databases here.
Now we only want to allow access from this subnet over here and deny access from this subnet here and we can use security groups to do just that. So, let's take a look at the security group for this subnet here, from where our databases are. Now security groups have similar fields to NACLs but there's just a couple less. So, there's no rule number with the security group which means all the rules within the security group will be assessed before a decision is made on the action and you'll also notice, there's no allow or deny either. With security groups, if there's a rule in there, then it's considered allowed, if there's no rule, then all traffic is dropped by default, so with this security group is stating that any MySQL or Aurora traffic using a TCP Protocol on the port 3306 from the source 10.0.1.0 which is this subnet here, then it's considered allowed as we don't have another rule in this security group for the source of 10.0.3.0/24 which is this subnet here. Then it's considered denied. It doesn't exist, so it's not allowed access, so how do both these NACLs and security groups work together?
Well, the NACL works at the subnet level, so let's say the NACL is this purple line and as this NACL is associated to this subnet as an example, let's just put that NACL around the edge of the subnet like so and let's say this orange is our security group and that security group is associated to our databases inside this subnet. So, let's assume that our EC2 instances here are looking to communicate with the RDS and Aurora databases over here, so let's have a look how that traffic would flow through the NACL and also the security group.
So, the request would be sent, it would get to the NACL and the NACL say okay, is this traffic TCP traffic within this port range from any source? And it is. So, the traffic is allowed. So, that traffic is now allowed inside the subnet. It then hits the security group and the security group says is this a MySQL or Aurora traffic running the TCP Protocol using port range 3306 coming from 10.0.1.0? And it is as we're trying to communicate with the databases, then access is allowed. Now if we look from this subnet here, the 10.0.3.0 and do the same thing where these two EC2 instances are trying to communicate with the RDS and Aurora instances using port 3306, let's follow the same process.
So, the request is sent, it hits the NACL, the NACL says are you running TCP within this port range from any source? The answer is yes, so access is allowed. It then hits a security group and it says is this traffic MySQL or Aurora using TCP Protocol on port range 3306? At this point, everything is correct, yes. However, the source is different. We don't have a source address of 10.0.3.0. It doesn't exist in the security group. So, at this point, the traffic is dropped at the security group and access is not allowed.
So, you can see how NACLs and security groups can be used to filter traffic at different layers. The NACLs are used for the subnet and network layer and the security groups are used at the instance layer. Now one final thing I wanna say about security groups is that unlike NACLs which are stateless by design, security groups are stateful which means you don't have to configure specific rules to allow return traffic from requests like you have to do with NACLs.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
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.