A well-developed naming convention saves time, reduces mistakes, and increases security.

The veracity of that statement may seem questionable at first glance. Does it matter what an AWS security group is named? The name has no impact on functionality, so it may seem like a waste of time to create governance around it.

However, as Shakespeare explored in Romeo and Juliet, even though a name doesn’t impact the smell of a rose, the meaning a name carries is significant to us humans.

A rose by any other name would smell as sweet” — Romeo and Juliet

Names Matter

Organizations without a standardized naming convention risk creating AWS security groups with similar or wildly different names. Both can lead to the unintended exposure of resources as developers are unsure which group to use and what permissions it might have. In addition, the problem compounds as an organization grows, becoming unmanageable over time.

Organizations using default AWS security group naming will quickly end up in a situation where they are impossible to tell apart.

A list of security groups numerated from 1 to 6

"A rose by any other name would smell as sweet" -- Romeo and Juliet

Trying to come up with a unique name on the spot leads to a jumbled mess as each developer uses a different naming pattern.

Thankfully, we aren’t alone in this naming challenge. The need for good naming schemes has been around for a long time. There are even whole fields of study dedicated to naming things. The solution is to define consistent, logical nomenclature that packs valuable information into the semantics of the name.

Significant Part Numbering System

Manufacturing engineers refer to this as a significant part numbering system.

From Wikipedia:

In a significant part numbering system, the part numbers are assigned intelligently, according to an encoding system, and thus they give an indication of salient characteristics of the component. For example, a screw may have the part number “HSC0424PP”; in this case, the letters indicate characteristics of the component:

  • H = “Hardware”
  • S = “Machine Screw”
  • C0424 = “4-40, 3/4″ long”
  • PP = “Panhead Phillips”

Setting Conventions

To save time, reduce mistakes, and increase security, a security group naming convention needs to do a few things.

Be consistent across your organization.

Once trained, anyone at the organization coming across the name should know what it does.

Be easily identifiable

The name should be simple enough that developers don’t need reference material to understand.

Provide enough information to be useful

Reduce misconfigurations due to misunderstanding of a group’s purpose. For example, a wrongly assigned security group could stop an asset from working correctly or provide overly permissive access creating a security risk.


Using a significant security group numbering system provides several advantages.

  1. Consistency
  2. Good Governance
  3. Organized groups
  4. No collisions
  5. Easier ownership


Let’s look at how others tackled their naming conventions. Organizations use various naming strategies for security groups. Below is an example strategy shared by the co-founder of Invisibl Cloud.

A screenshot reading: "AWS Region+ Environment Code+ OS Type+Tier+Application Code"Security Group Name - EU-P-LWA001 AWS Region ( 2 char ) = EU, VA, CA etc Environment Code (1 Char) = P-Production , Q-QA, T-testing, D-Development etc OS Type (1 Char)= L -Linux, W-Windows etc Tier (1 Char)= W-Web, A-App, C-Cache, D-DB etc Application Code ( 4 Chars) = A001

An example of AWS security group naming conventions. (Source)

Below is another example of a naming convention that is somewhat descriptive, revealing information about the type of application and its streaming methodology.

A list of 3 security groups: ste-blog-p-cin-euwe1a-nginx-408f ste-blog-p-cin-euwe1a-nginx-c338 ste-blog-p-cin-euwe1a-nginx-d7aa

An organization should consider what is important to them and then define code for applications that are well understood internally. When using an application code, the organization must have a written naming strategy that defines the mappings. Such as Blog = A001, and Gaming Application = A002. Avoid getting too complicated, or the process can become unwieldy.

Once defined, the next step is to automate and audit the use of the naming convention.


Automating the creation of security groups reduces errors and increases consistency. For example, teams can use Infrastructure-as-Code, like a CloudFormation template or a free, open-source Terraform script, to define their security groups. These templates or scripts create security groups the same way every time.


Naming governance is only helpful if followed. Naming convention audits should regularly occur. After an organization adopts a naming convention, the first audit takes a disproportionate amount of time since nothing will be compliant. A free, open-source tool like Paladin Cloud can significantly speed up conducting audits by inventorying and monitoring your security groups.

In addition to existing malformed security group names, we have found that it is common for large organizations to discover thousands of unused security groups sitting around the first time they do an audit.

Notifying everyone and then removing those manually in AWS can be time-consuming. Using Paladin Cloud’s auto-fix, developers can get a list of all their unused security groups and automatically remediate them. The administrator defines a grace period for unused security group violations, often 48 hours after being unused for 90 days. After that, Paladin Cloud will notify the owners of security groups violating the unused security group policy. Then the system will automatically remove unused security groups if that group hasn’t been deleted or used by the end of the auto-fix grace period.

Paladin Cloud provides quick clean-up of current unused security groups and continuously monitors for security groups that are no longer in use.

Naming governance is only helpful if followed


The names we choose have a very real impact on the security of our cloud environment. Using a well-thought-out nomenclature for security groups makes identification more manageable and removes avenues for bad actors to exploit. Once an organization’s security group nomenclature has been defined and is part of the governance process, the implementation should be automated. After that, regular audits should be done to catch groups that may slip through the cracks. Using a tool like Paladin Cloud to assist in automating audits allows for real-time reporting on your security group policy violations.


For a deeper dive into this topic: AWS Security Group Naming Conventions.

The names we choose have a very real impact on the security of our cloud environment.