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.