Naming Conventions - Keep it random

Naming matters, especially for AWS resources. A good naming convention will help your team move quickly during critical moments. It will make incident resolution much easier and even simplify redeploying resources.

One part of a naming convention is… well. The “randomness” of names and why you should embrace it.

The list I follow is as follows

1. No name
2. Let Terraform generate the name
3. Well, I’ll name it but add some random characters to it
4. A third-party requires a very static name

Weird list no?

So why?

Names can put you on the wrong path

A name can mislead you in so many ways. They act as red herrings during debugging sessions. Take, for example, a security group named “allow_nlb_to_eks.” That suggests it allows the ELB to communicate with the EKS cluster… Right?

Well, maybe. Initially, probably yes. But over time, refactors happen. The cluster gets deleted, but the security group remains because it also handled a database connection to a Lambda function. Renaming it would trigger a recreation, and nobody wants downtime. The security group still exists but has lost any original meaning. The name betrays anyone who wants to debug it. The persons responsible for it are long gone. The downtime timer keeps going up. You’ve wasted so much time on this unrelated security-group when you actually needed the real “allow_nlb_to_eks_v2” security group. Or do you?

Names block things

Very important resources on AWS require unique names. So when you want to redeploy something, a hardcoded static name can be the blocker in the end. An IAM role with that name already exists, a security-group with that name already exists or even worse… a secret or KMS key. Deleting those last two ain’t that easy as they have a deletion protection timer on them. So that module that creates a secret with the name “very_important_secret” can’t be redeployed (or deployed next to each other) as the secret already exists!

Names are very personal

It is almost tradition that system administrators gave resources a name that felt close to them. How many datacenters have their original servers named after LOTR places and persons? But when the company growed, suddenly the naming list became very short. Nobody really wants to kill the tradition but in the end the names out of books are gone. Your life-partner became your ex-partner but the critical database still bear there name. It is a very limited list and after a while the good names become… very bad names.

No name

When a resource can be spun up without me defining a name, I do so. Some resources come up empty with purely an ID/ARN (which you can count as a name). Some receive a random one from Terraform or AWS.

In AWS one of the most prolifics in this sense are security-groups. If you do not define anything, a random name will be generated for you and I love it. The name is so random, that only if you encounter it many times you’ll associate it to some resources but if it vanishes, it will also vanish from my mind.

I love the name sg-0123abc456def7890, it tells me nothing.

Ok, but how do you debug a network problem from A to B? Well…

1. I use VPC Reachability Analyzer.

Honestly, that’s mostly it. If that doesn’t work, I go to the faulty resource, check which security groups are attached, and review their rules. Check up on the NACLs and the other twenty network firewalls that have been introduced since the inception of our environment.

But I never trust the name to provide any useful information.

I want to add extra information to a resource and names are so good for it

No. Use tags. A fun one I like to use is the File tag, which indicates which Terraform file created the resource.

tags = {
    File = "rds.security-group.tf"
}

You can add more like Description but I’ve never actually done that. I don’t trust the human who wrote it (that will probably be me).

Let Terraform generate the name

Ok, sometimes a name is… required. Why AWS doesn’t generate random names for these cases, I have no idea. But when that happens, I hope Terraform provides a name_prefix. This adds a timestamp of resource creation after the specified name.

Security groups allow this

resource "aws_security_group" "example" {
  name_prefix = "allow_nlb_to_eks"
  # ... other configuration ...

This generates a security group with the name allow_nlb_to_eks-20250225095045107900000005.

Now, the chance of a collision (where two different teams create a security group with the very generic name allow_nlb_to_eks) becomes extremely low thanks to the timestamp (and humans are really bad at unique names so that allow_nlb_to_eks will happen).

Very handy for clusters, S3 buckets, IAM roles,… which all have unique naming requirements!

Well, I’ll name it but add some random characters to it

Sure, why not? Sometimes the resource doesn’t support name_prefix.

Use random string/id/random pet/…

Here we use another resource coming from the random_provider

resource "random_id" "sg" {
  prefix = "allow_nlb_to_eks-"
  byte_length = 8
}

resource "aws_security_group" "example" {
  name = random_id.sg_
  # ... other configuration ...

This results in allow_nlb_to_eks-e5cbb5f74a95f7fe. I feel this one is handier when there is a naming length limit and the name_prefix of Terraform does generate a very very long timestamp. Especially ELBs will hit this one.

Use a timestamp

You started to love the timestamp format of Terraform but want it much shorter? No problem (Though this increases the risk of collisions).

Make sure to include ignore_changes, or Terraform will recreate the resource every run.

resource "aws_security_group" "example" {
  name = "allow_nlb_to_eks-${substr(timestamp(),0,10)}"
  ignore_changes = ["name"]
  # ... other configuration ...

A third-party requires a very static name

We begrudgingly hate them, try to explain them why they are wrong in 100 different ways, and then accept our fate. We implement the static name that will probably cause issues in the future. But hey, that’s a problem for future Tom!

Which resources have the prefix option?

Not all are tested, this is quickly gathered and sadly S3 has a lot of filters with prefix in the name. I occasionally remove the incorrect ones when I encounter them.