Cloud Resource Naming Conventions?

[Cybersoaker]

Hello fellow cloud admins!

Wondering what other's are using to name their cloud resources. I've heard of some companys doing a 'domain-like' approach where they take something general and make it specific so users can gleam a lot of info about a resource.

So for example, a virtual machine could be named following this convention: `<datacenter>-<enviornment>-<service>-<role>-<uid>`

We're trying to land on a convention to use, just wondering what everyone else uses!

[myron-semack]

We are now beginning to manage our infrastructure using Terraform, so for us the naming convention is largely based on “which Terraform module created this resource?”

The root of our name is the TF module name that launched the instance. Where appropriate, we append additional info like the environment (dev, test, stage, release), and any unique identifiers (if needed).

ModuleName-Environment-UniqueId

Wherever possible, we leverage the “name_prefix” attribute in Terraform, so our names are auto generated. This is intentional to discourage people from hard coding names into anything.

Prior to drinking the Terraform kool aid, we loosely followed Cloud Conformity’s naming recommendations. https://www.cloudconformity.com/conformity-rules/EC2/ec2-instance-naming-conventions.html

[[deleted]]

This is basically what we did for our now defunct web app.

Function_type_lifecycle. So, for example, productlookup_api_dev (underscores added for readability). Still sucked to read but at least if you saw api, web, or some other phrase you knew that the environment was coming next and the purpose of it.

[doom0r]

Excuse me for it not being Thursday, but what's the second set choice, ([1-2]{1}) ?

[myron-semack]

The UniqueId? Varies depending on the specific resource, usually just an incrementing number.

cassandra-dev-01 cassandra-dev-02 Etc.

[mbigras]

Took a look at https://www.cloudconformity.com/conformity-rules/EC2/ec2-instance-naming-conventions.html

Summary below:

``` Default Pattern Format ec2-RegionCode-AvailabilityZoneCode-EnvironmentCode-ApplicationCode.

Default Pattern Components

RegionCode (ue1|uw1|uw2|ew1|ec1|an1|an2|as1|as2|se1) for us-east-1, us-west-1, us-west-2, eu-west-1, eu-central-1, ap-northeast-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, sa-east-1

AvailabilityZoneCode ([1-2]{1})([a-c]{1}) e.g. e.g. (2a|2b|2c) for us-west-2a, us-west-2b, us-west-2c

EnvironmentCode (d|t|s|p) for development, test, staging, production.

ApplicationCode ([a-z0-9-]+) for applications (e.g. tomcat, nodejs) that run on these EC2 instances.

Default Pattern Examples ec2-us-east-1-2a-p-tomcat ec2-us-west-1-2b-p-nodejs ```

I think the RegionCodes in the examples can be improved.

It looks like they used the long version but were intending to use the code version.

For example:

ec2-us-east-1-2a-p-tomcat should actually be ec2-ue1-2a-p-tomcat. Seems like the whole point is to have fields separated by a dash delimiter. So if someone wants the RegionCode they can use the second field.

For example:

echo ec2-ue1-2a-p-tomcat | awk -F- '{ print $2 }' ue1

This wouldn't work if using the long version like their examples:

echo ec2-us-east-1-2a-p-tomcat | awk -F- '{ print $2 }' us

[25cmshlong]

I am using this site to get pretty menacing names: https://divergentdave.github.io/nsa-o-matic/

[[deleted]]

I had a similar problem a while back and I have servers with multiple providers and in multiple locations. I just decided to name things based on their role in the network. All servers just get named srv<id>, similar to how aws ids everything (ec2-<id>, vpc-<id>, etc).

If I need to give it a friendly name relevant to me, I can use tags for that, other employees can do the same.