Security Groups
Start course
3h 55m

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

Learning Objectives

  • 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

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 .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 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 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 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 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 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.

About the Author
Learning Paths

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.