In-Depth

Best Practices for Managing AWS EC2 Security Groups

• By Brien Posey
• 09/03/2024

Security groups act as firewalls for your EC2 virtual machine (VM) instances. Being that security groups play such a crucial role in keeping your VM instances secure, I wanted to take the opportunity to share some best practices for working with security groups.

Avoid Complexity
Although the EC2 console doesn't make it super obvious, you can assign multiple security groups to an individual VM instance. As such, some organizations like to create extremely granular security groups and then apply the security group combination that makes sense for a particular VM. For example, the organization might create one security group that allows HTTP and HTTPS traffic. A completely separate security group might allow RDP traffic. The organization would pick and choose the security group combination that makes the most sense for a given instance.

While this approach can work, you have to be really careful when using it. Otherwise, you may end up with security groups that contain overlapping sets of rules. It's also easy to accidentally omit a required security group or apply a security group that you did not intend to.

That being said, my advice is to keep things simple. Rather than creating a separate security group for each rule that you need, it's better to create security groups based on roles. You might for instance create a security group for your Web servers and another security group for your database servers. The advantages to using this approach are simplicity and consistency. In other words, you don't have to deal with the hassles of applying multiple security groups. Better still, you can be sure that all of your servers in a given category (database servers, web servers, etc.) have the same set of rules applied to them, and are thereby configured in a consistent manner.

Don't Neglect the Security Groups
I recently heard a story about someone who had created one single security group for their entire AWS environment. That security group was completely open ended and allowed all traffic, regardless of the type. The rationale behind this decision (as it was explained to me) was that the Windows firewall was active on all of the organization's EC2 instances, thereby making the security groups unnecessary.

While you can and should leave OS-level firewalls enabled, it's important to practice defense in depth. To put it another way, two firewalls are better than one.

Practice Least Privilege Access
The concept of Least Privilege Access is normally used in the context of granting users access to a particular resource. However, the concept also loosely applies to firewalls in that it's important to only open the ports that are absolutely necessary.

It's usually pretty easy to figure out which ports an instance needs to have open in order to function. However, you do have to consider what to do about management traffic (SSH, RDP, etc.).

The way that I like to handle management traffic is to provision each instance with multiple virtual network adapters, each connected to a different subnet. By doing so, you can assign a different security group to each virtual network adapter. That way, you can avoid opening any management ports on the network adapter through which the machine communicates on the primary virtual network segment. Instead, you can limit all of your management traffic to a secure and isolated subnet.

Some organizations even go so far as to create a management instance that exists for the sole purpose of managing your EC2 instances. This management instance is likely to be the only instance that is accessible from the outside world. Once connected to the management instance however, you can use RDP or SSH to connect to the other instances that you have created inside of AWS. In other words, the instances accept RDP or SSH traffic, but only from one very specific location (the management instance). If someone were to try to RDP into one of these instances from the outside world, the security group would deny the connection.

As a side note, if you are going to create an EC2 instance to act as a designated management node, then there are a whole laundry list of things that you need to do to harden that instance. There are also some practical steps that you will need to take to make sure that the instance continues to function as intended. My advice would be to assign the instance a static IP address, because that will make it easier to create the security group rule that allows the other instances to be managed by your management instance. I also strongly recommend enabling termination protection on your management instance so that it is never accidentally deleted (since it represents the only option for managing your other instances).

Keep Your Security Groups Manageable
As previously noted, each security group should serve a specific purpose and contain only the rules necessary to serve that purpose. At the same time, it's also a good idea to try to avoid creating an excessive number of security groups, because having a large number of security groups can make the security groups collectively more difficult to manage.

As a best practice, you should adopt a standard naming convention for your security groups so that there is no ambiguity with regard to what a particular security group does. Tagging can also help you to keep track of your security groups.

Regardless of how you create, manage, and use security groups within your organization, it is important to periodically audit all of your security groups as a way of verifying that they have not been modified without authorization.