AWS resource naming strategy

Si alguien os preguntará si alguna vez habéis iniciado un proyecto en la nube sin haber definido previamente una convención de nombres para los recursos a crear, el 99,999999999% respondería de forma afirmativa. ¡Y quién no! Nadie pone en duda que las diferencias son lo que nos hacen únicos, pero este es uno de esos casos en los que una estandarización, al menos a nivel de proyecto y preferiblemente a nivel de organización, puede evitar mas de un dolor de cabeza a medio-largo plazo, especialmente para aquellos equipos involucrados en la tareas de gestión o mantenimiento. Parece evidente, ¿no?

El problema es que el modelo oficial que propone AWS es algo escueto, especialmente si se compara con el de Azure, y no profundiza lo suficiente como para seguirlo al pie de la letra. Es por ello que en el presente artículo se pretende describir una convención de nombres sencilla y consistente, a la par que completa, para los recursos de Amazon Web Services, que pueda ser utilizada independientemente de la índole del proyecto.

Naming convention basics

Una convención de nombres efectiva debe, por encima de todo, describir los atributos más importantes de los recursos a generar, de una forma única, concisa y homogénea.

Lo primero de todo, en este contexto la palabra homogénea implica que el nombre de cada uno de los elementos debe estar compuestos por el mismo número y tipo de propiedades, cumpliendo así con el formato definido para ello. Si el resultado final del mismo es o no bonito, no es importante, ya que al haber tantos recursos y casos de uso, se darán todo tipo de resultados. Lo primordial es garantizar la consistencia.

En lo que a la definición de los atributos que componen el nombre se refiere, puede resultar un ejercicio un tanto subjetivo y cambiante en función del proyecto, su tamaño o la organización, por lo que se propone un patrón estándar compuesto por el tipo de recurso, carga de trabajo o aplicación, entorno, región e instancias, escritas completamente en minúsculas y separados por una guión medio.

El siguiente ejemplo muestra el nombre de la primera instancia EC2 de un cluster de Kubernetes del entorno de producción de la región de Frankfurt.

El campo resource type es él atributo que identifica mediante una abreviatura atómica y en minúsculas el tipo de recurso a crear. Lo ideal es que sea fácilmente legible y reconocible, compuesto de 2 a 4 caracteres si identifica directamente el recurso, con bloques de 2 a 4 caracteres adicionales si identifica una propiedad del tipo de recurso.

El campo workload es el atributo comodín que identifica, preferiblemente mediante una abreviatura atómica y en minúsculas, el nombre del recurso, aplicación, proyecto o incluso todos ellos juntos. Como se ha explicado previamente, no todos los proyectos tienen la misma organización ni envergadura, por lo que se trata de un campo flexible a personalizar en función del caso de uso. Así, se recomienda encarecidamente, siempre que sea posible, establecer el mismo workload para aquellos recursos que tengan una relación de dependencia entre ellos.

El campo environment es el atributo que identifica mediante una abreviatura atómica de 3 caracteres y en minúsculas el entorno en el que desplegar los recursos a crear. No hay mucho misterio, los clásicos dev, tst, stg y pro son valores perfectamente validos. Aquellos recursos compartidos entre recursos se etiquetarán como globales mediante la abreviatura glo.

El campo region es el atributo que identifica mediante una abreviatura atómica de 4 caracteres y en minúsculas la región de AWS en el que desplegar los recursos a crear. Alguno podría caer en la tentación de eliminar este campo, pensando que su proyecto se desplegará en una única region. No lo hagáis, recordar que la convención de nombres esta pensada para ser aplicada a nivel global y no solo con un ámbito de proyecto.

Finalmente, el campo instance es él atributo que identifica numéricamente la instancia de los recursos a crear, ya que, tal y como ilustra el ejemplo anterior, habrá casos en las que se requiera más de una. También se utiliza para dar un nombre único al recurso en aquellos casos en los que el resto de atributos coincidían.

Dictionary

A continuación se proporcionan un diccionario abreviaciones para los campos previamente descritos.

Resource Type

El siguiente listado resumen las abreviaciones para los tipos de recursos mas comunes de AWS.

Athena

Resource typeExample
Athena Databaseathdb
Athena Queryathqry
Athena Workgroupathwg

Certificate Manager

Resource typeExample
Certificate Manager Certificateacmcert
Certificate Manager Certificate Validationacmcertval

CodeArtifact

Resource typeExample
CodeArtifact Domaincadom
CodeArtifact Domain Permissions Policycadompermplcy
CodeArtifact Repositorycarepo
CodeArtifact Repository Permissions Policycarepopermplcy

CodeBuild

Resource typeExample
CodeBuild Projectcbproj
CodeBuild Webhookcbwh

CodeCommit

Resource typeExample
CodeCommit Repositoryccrepo
CodeCommit Triggercctrig

CodeDeploy

Resource typeExample
CodeDeploy Appcdapp
CodeDeploy Configcdconf
CodeDeploy Groupcdgrp

CodePipeline

Resource typeExample
CodePipelinecp
CodePipeline Webhookcpwh

Cognito

Resource typeExample
Cognito Identity Poolcogidpl
Cognito Identity Pool Providercogidplprov
Cognito User Poolcoguserpl
Cognito User Pool Clientcoguserplcli
Cognito User Pool Domaincoguserpldom

DocumentDB

Resource typeExample
DocumentDB Clusterdocclu
DocumentDB Cluster Instancedoccluins
DocumentDB Cluster Snapshotdocclusnap
DocumentDB Parameter Groupdocpg
DocumentDB Subnet Groupdocsntg

DynamoDB

Resource typeExample
DynamoDB Global Tabledynglotbl
DynamoDB Tabledyntbl
DynamoDB Table Itemdyntblitem
DynamoDB Table Tagdyntbltag

Elastic Container Service (ECS)

Resource typeExample
Elastic Container Service Clusterecsclu
Elastic Container Service Serviceecsserv

EC2

Resource typeExample
AMIami
Auto Scalling Groupasg
EC2ec2
Elastic IP Adresseip
Key Pairkp
Transit Gatewaytgw
Transit Gateway Route Tabletgwrtb
Transit Gateway Route Table Associationtgwrtbassc
Transit Gateway VPC Attachmenttgwvpcatt

Elasticsearch

Resource typeExample
Elasticsearch Domainesdom
Elasticsearch Domain Policyesdomplcy

Elastic Cache

Resource typeExample
ElasticCache Clustereccclu
ElastiCache Parameter Groupeccpg
ElastiCache Security Groupeccsg
ElastiCache Subnet Groupeccsntg
ElastiCache Usereccuser
ElastiCache User Groupeccusergrp

Elastic Container Registry (ECR)

Resource typeExample
ECR Lifecycle Policyecrlcplcy
ECR Registry Policyecrregplcy
ECR Replication Configurationecrrepconf
ECR Repositoryecrrepo
ECR Repository Policyecrrepoplcy

Elastic Load Balancing

Resource typeExample
Load Balanceralb
Load Balancer Listeneralblsnr
Load Balancer Listener Certificatealblsnrcert
Load Balancer Listener Rulealblsnrulw
Load Balancer Target Groupalbtg
Load Balancer Target Group Attachmentalbtgatt

Elastic Kubernetes Service (EKS)

Resource typeExample
EKS Addoneksadd
EKS Clustereksclu
EKS Node Groupeksng

EMR

Resource typeExample
EMR Clusteremrclu
EMR Instance Fleetemrinsflt
EMR Instance Groupemrinsgrp
EMR Security Configurationemrsecconf

Identity and Access Management (IAM)

Resource typeExample
IAM Groupiamgrp
IAM Group Policyiamgrpplcy
IAM Group Policy Attachmentiamgrpplcyatt
IAM Policyiamplcy
IAM Roleiamrole
IAM Role Policyiamroleplcy
IAM Role Policy Attachmentiamroleplcyatt
IAM Useriamuser
IAM User Group Membershipiamusergrpmem
IAM User Policyiamuserplcy
IAM User Policy Attachmentiamuserplcyatt

Key Management Service (KMS)

Resource typeExample
KMS Aliaskmsals
KMS Grantkmsgnt
KMS Keykmskey

Kinesis

Resource typeExample
Kinesis Streamkinstm
Kinesis Stream Consumerkinstmcon

Lambda

Resource typeExample
Lambda Functionlambfunc
Lambda Aliaslambals

Managed Streaming for Apache Kafka (MSK)

Resource typeExample
Managed Streaming for Apache Kafka Clustermskclu
Managed Streaming for Apache Kafka Configmskconf

Neptune

Resource typeExample
Neptune Clusternepclu
Neptune Cluster Endpointnepcluept
Neptune Cluster Snapshotnepclusnap
Neptune Cluster Instancenepcluins
Neptune Cluster Parameter Groupnepclupg
Neptune Event Subscriptionnepevtsubs
Neptune Instance Parameter Groupnepinspg
Neptune Instance Subnet Groupnepsntg

Redshift

Resource typeExample
Redshift Clusterredclu
RedShift Event Subscriptionredevtsubs
Redshift Parameter Groupredpg
Redshift Security Groupredsg
Redshift Subnet Groupredsntg

Relational Database Service (RDS)

Resource typeExample
RDS Clusterrdsclu
RDS Endpointrdscluept
RDS Instancerdscluins
RDS Parameter Grouprdsclupg
RDS Snapshotrdsclusnap
RDS Instancerdsins
RDS Option Grouprdsop
RDS Parameter Grouprdspg
RDS Security Grouprdssg
RDS Subnet Grouprdssnt

Route53

Resource typeExample
Route53 Recordr53rec
Route53 Query Logr53qrylog
Route53 Zoner53resruleassc
Route53 Zone Associationr53resruleqrylog

Route53 Resolver

Resource typeExample
Route53 Resolver Endpointr53resept
Route53 Resolver Ruler53resrule
Route53 Resolver Rule Associationr53resruleassc
Route53 Resolver Rule Query Logr53resruleqrylog

Secrets Manager

Resource typeExample
Secrets Manager Secretsmsec
Secrets Manager Secret Policysmsecplcy
Secrets Manager Secret Rotationsmsecrot
Secrets Manager Secret Versionsmsecver

S3

Resource typeExample
S3 Access Points3accpt
S3 Buckets3bckt
S3 Bucket Inventorys3bcktinvt
S3 Bucket Metrics3bcktmtc
S3 Bucket Notifications3bcktnt
S3 Bucket Objects3bcktobj
S3 Bucket Policys3bcktplcy
S3 Bucket Public Access Blocks3bcktpubaccblk

Timestream

Resource typeExample
Timestream Databasetimdb
Timestream Tabletimtbl

VPC

Resource typeExample
Access Control Listacl
Access Control List Ruleaclrule
Egress Only Internet Gatewayeig
Internet Gatewayigw
Nat Gatewayngw
Route Tablertb
Route Table Associationrtbassn
Security Groupsgp
Subnetsnet
Virtual Private Cloudvpc

Environment

El siguiente listado resumen las abreviaciones para los tipos de entorno mas comunes en el desarrollo del software.

Resource typeExample
Developmentdev
Testingtst
Stagingstg
Productionpro

Region

El siguiente listado resumen las abreviaciones para todas las regiones dispones en AWS.

Asia Pacific

Resource typeExample
af-south-1 (Cape Town)afs1
eu-central-1 (Frankfurt)euc1
eu-north-1 (Stockholm)eun1
eu-south-1 (Milan)eus1
eu-west-1 (Ireland)euw1
eu-west-2 (London)euw2
eu-west-3 (Paris)euw3
me-south-1 (Bahrain)mes1

Europe/Middle East/Africa

Resource typeExample
ap-east-1 (Hong Kong)ape1
ap-northeast-1 (Tokyo)apn1
ap-northeast-2 (Seul)apn2
ap-northeast-3 (Osaka)apn3
ap-southeast-1 (Singapore)aps1
ap-southeast-2 (Sydney)aps2
ap-south-1 (Mumbai)aps1

North America

Resource typeExample
ca-central-1 (Canada)cac1
us-east-1 (N. Virginia)use1
us-east-2 (Ohio)use2
us-west-1 (N. California)usw1
us-west-2 (Oregon)usw2

South America

Resource typeExample
sa-east-1 (São Paulo)sae1

Conclusiones

En conclusión, se propone una convención de nombres efectiva y homogénea pensada para ser utilizada independientemente de la índole del proyecto, que se compone por el tipo de recurso, carga de trabajo o aplicación, entorno, región e instancias, escritas completamente en minúsculas y separados por una guión medio.

Para ello, la clave reside en hacer un correcto uso del campo workload, ya es el atributo comodín que realmente proporciona esta flexibilidad.

Evidentemente el diccionario proporcionado no cubre todos los posibles tipos de recursos de los que dispone AWS ni mucho menos, pero la idea es ir actualizando poco a poco con el paso del tiempo.

Referencias

Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s