Working With AWS Security Groups by Reference

AWS Security Groups by Reference Simplified

Whether the AWS products and services in your architecture exposes an IP address or not, AWS Security Groups by reference is a great way to enable/lockdown access to individual components of your architecture.

Let’s start with this simple architecture example.

Here we have an Elastic Application Load Balancer which is pointing to an EC2 instance.  

The stack has the following security groups.

Note: The EC2 instance has the ELB security group ID as it’s inbound traffic source.

The rules above mean traffic can ONLY communicate with the EC2 instance via port 443 (HTTPS) from the ELB.

In fact, the EC2 instance rules above are quite opinionated and you would get the same result if you set the type to “All traffic” on the EC2 instance’s security group, like so.

Remember that AWS Security Groups have a wildcard DENY rule set for all of its components by default. This means unless you specifically set a rule on each port that you want to ALLOW traffic to access, the component will DENY all connections.

In our example above, this means that the EC2 instance is protected from all traffic unless it is via port 443 from the ELB as referenced. Direct connections to the EC2 instance (bypassing the ELB) via port 443 will be denied access.

Below is a simple flow diagram to illustrate how this works for our example.

Daisy-chaining AWS Security Groups by Reference

If you require an opinionate firewall setup or use AWS products and services that do not expose an IP address, daisy-chaining AWS Security Groups is an excellent methodology for allowing access to each component of your architecture.

For this example, we are going to make sure that the database in the below architecture diagram can only be accessed if the request has come through the ELB and via the other components of the architecture.

Here we have an Elastic Application Load Balancer, pointing to an EC2 instance auto-scaling group, which in turn communicates to a database for storing its data.

The stack has the following security groups.

This time I am going to explain how AWS checks daisy-chained referenced Security Groups in a little more detail than the previous flow diagram above.

Before going any further I would like to add a caveat that I do not know the full inner workings of the AWS Security Group firewall logic (partly because they do not publish it) but from my years of experience with it, the following describes the concept very well. 

When a request is made at the start of the chain, in this case the ELB. The firewall stores a reference of the request (ref1). This reference is then checked at each stage of the chain and the access is determined based on the AWS Security Groups rule set and whether the request has the required reference (ref1).

Below is a flow diagram to illustrate the concept against our example scenario.

Conclusion

AWS Security Groups by reference is a great way to enable access to your architecture, but it is not a replacement for CIDR notation rule sets nor will it meet all of your requirements when securing your architecture. You may in fact have the requirement to leave certain ports such as HTTP/HTTPS open to the world so that your server can perform its own updates. In that instance, AWS Security Groups by reference or CIDR notation will not help you at all as your firewall requirements need to be move a level above into the VPC configuration, in which a NAT Gateway interface would be required to securely access the internet while protecting your network to inbound request. 

This is will be my next article for you. Until then, watch this space!