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 para un bucket s3 llamado raw del entorno de producción de la región de Frankfurt.
El campo resource 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 env 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 entornos se etiquetarán como shared mediante la abreviatura shr.
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. Aquellos recursos compartidos entre regiones se etiquetarán como globales mediante la abreviatura glo.
Finalmente, el campo suffix es él atributo que proporciona mediante 5 caracteres en minúsculas un nombre único a los recursos a crear. Se trata de un valor indispensable tanto para diferenciar las instancias cuando el resto de atributos coincidían, como por ejemplo, las maquinas virtuales de un cluster de Kubernetes, o para aquellos elementos que requieran de un nombre único global, como por ejemplo, un bucket S3.
Dictionary
A continuación se proporcionan un diccionario abreviaciones para los campos previamente descritos.
Resource Type
El siguiente listado resume las abreviaciones para los tipos de recursos mas comunes de AWS.
Athena
Resource type
Example
Athena Database
athdb
Athena Query
athqry
Athena Workgroup
athwg
Certificate Manager
Resource type
Example
Certificate Manager Certificate
acmcert
Certificate Manager Certificate Validation
acmcertval
CodeArtifact
Resource type
Example
CodeArtifact Domain
cadom
CodeArtifact Domain Permissions Policy
cadompermplcy
CodeArtifact Repository
carepo
CodeArtifact Repository Permissions Policy
carepopermplcy
CodeBuild
Resource type
Example
CodeBuild Project
cbprj
CodeBuild Webhook
cbwh
CodeCommit
Resource type
Example
CodeCommit Repository
ccrepo
CodeCommit Trigger
cctrig
CodeDeploy
Resource type
Example
CodeDeploy App
cdapp
CodeDeploy Config
cdconf
CodeDeploy Group
cdgrp
CodePipeline
Resource type
Example
CodePipeline
cp
CodePipeline Webhook
cpwh
Cognito
Resource type
Example
Cognito Identity Pool
cogidpl
Cognito Identity Pool Provider
cogidplprov
Cognito User Pool
coguserpl
Cognito User Pool Client
coguserplcli
Cognito User Pool Domain
coguserpldom
DocumentDB
Resource type
Example
DocumentDB Cluster
docclu
DocumentDB Cluster Instance
doccluins
DocumentDB Cluster Snapshot
docclusnap
DocumentDB Parameter Group
docpg
DocumentDB Subnet Group
docsntg
DynamoDB
Resource type
Example
DynamoDB Global Table
dynglotbl
DynamoDB Table
dyntbl
DynamoDB Table Item
dyntblitem
DynamoDB Table Tag
dyntbltag
Elastic Container Service (ECS)
Resource type
Example
Elastic Container Service Cluster
ecsclu
Elastic Container Service Service
ecsserv
EC2
Resource type
Example
AMI
ami
Auto Scalling Group
asg
EC2
ec2
Elastic IP Adress
eip
Key Pair
kp
Transit Gateway
tgw
Transit Gateway Route Table
tgwrtb
Transit Gateway Route Table Association
tgwrtbassc
Transit Gateway VPC Attachment
tgwvpcatt
Elasticsearch
Resource type
Example
Elasticsearch Domain
esdom
Elasticsearch Domain Policy
esdomplcy
Elastic Cache
Resource type
Example
ElasticCache Cluster
eccclu
ElastiCache Parameter Group
eccpg
ElastiCache Security Group
eccsg
ElastiCache Subnet Group
eccsntg
ElastiCache User
eccuser
ElastiCache User Group
eccusergrp
Elastic Container Registry (ECR)
Resource type
Example
ECR Lifecycle Policy
ecrlcplcy
ECR Registry Policy
ecrregplcy
ECR Replication Configuration
ecrrepconf
ECR Repository
ecrrepo
ECR Repository Policy
ecrrepoplcy
Elastic Load Balancing
Resource type
Example
Load Balancer
alb
Load Balancer Listener
alblsnr
Load Balancer Listener Certificate
alblsnrcert
Load Balancer Listener Rule
alblsnrulw
Load Balancer Target Group
albtg
Load Balancer Target Group Attachment
albtgatt
Elastic Kubernetes Service (EKS)
Resource type
Example
EKS Addon
eksadd
EKS Cluster
eksclu
EKS Node Group
eksng
EMR
Resource type
Example
EMR Cluster
emrclu
EMR Instance Fleet
emrinsflt
EMR Instance Group
emrinsgrp
EMR Security Configuration
emrsecconf
Identity and Access Management (IAM)
Resource type
Example
IAM Group
iamgrp
IAM Group Policy
iamgrpplcy
IAM Group Policy Attachment
iamgrpplcyatt
IAM Policy
iamplcy
IAM Role
iamrole
IAM Role Policy
iamroleplcy
IAM Role Policy Attachment
iamroleplcyatt
IAM User
iamuser
IAM User Group Membership
iamusergrpmem
IAM User Policy
iamuserplcy
IAM User Policy Attachment
iamuserplcyatt
Key Management Service (KMS)
Resource type
Example
KMS Alias
kmsals
KMS Grant
kmsgnt
KMS Key
kmskey
Kinesis
Resource type
Example
Kinesis Stream
kinstm
Kinesis Stream Consumer
kinstmcon
Lambda
Resource type
Example
Lambda Function
lambfunc
Lambda Alias
lambals
Managed Streaming for Apache Kafka (MSK)
Resource type
Example
Managed Streaming for Apache Kafka Cluster
mskclu
Managed Streaming for Apache Kafka Config
mskconf
Neptune
Resource type
Example
Neptune Cluster
nepclu
Neptune Cluster Endpoint
nepcluept
Neptune Cluster Snapshot
nepclusnap
Neptune Cluster Instance
nepcluins
Neptune Cluster Parameter Group
nepclupg
Neptune Event Subscription
nepevtsubs
Neptune Instance Parameter Group
nepinspg
Neptune Instance Subnet Group
nepsntg
Redshift
Resource type
Example
Redshift Cluster
redclu
RedShift Event Subscription
redevtsubs
Redshift Parameter Group
redpg
Redshift Security Group
redsg
Redshift Subnet Group
redsntg
Relational Database Service (RDS)
Resource type
Example
RDS Cluster
rdsclu
RDS Endpoint
rdscluept
RDS Instance
rdscluins
RDS Parameter Group
rdsclupg
RDS Snapshot
rdsclusnap
RDS Instance
rdsins
RDS Option Group
rdsop
RDS Parameter Group
rdspg
RDS Security Group
rdssg
RDS Subnet Group
rdssnt
Route53
Resource type
Example
Route53 Record
r53rec
Route53 Query Log
r53qrylog
Route53 Zone
r53resruleassc
Route53 Zone Association
r53resruleqrylog
Route53 Resolver
Resource type
Example
Route53 Resolver Endpoint
r53resept
Route53 Resolver Rule
r53resrule
Route53 Resolver Rule Association
r53resruleassc
Route53 Resolver Rule Query Log
r53resruleqrylog
Secrets Manager
Resource type
Example
Secrets Manager Secret
smsec
Secrets Manager Secret Policy
smsecplcy
Secrets Manager Secret Rotation
smsecrot
Secrets Manager Secret Version
smsecver
S3
Resource type
Example
S3 Access Point
s3accpt
S3 Bucket
s3bkt
S3 Bucket Inventory
s3bktinvt
S3 Bucket Metric
s3bktmtc
S3 Bucket Notification
s3bktnt
S3 Bucket Object
s3bktobj
S3 Bucket Policy
s3bktplcy
S3 Bucket Public Access Block
s3bktpubaccblk
Timestream
Resource type
Example
Timestream Database
timdb
Timestream Table
timtbl
VPC
Resource type
Example
Access Control List
acl
Access Control List Rule
aclrule
Egress Only Internet Gateway
eig
Internet Gateway
igw
Nat Gateway
ngw
Route Table
rtb
Route Table Association
rtbassn
Security Group
sgp
Subnet
snet
Virtual Private Cloud
vpc
Environment
El siguiente listado resumen las abreviaciones para los tipos de entorno mas comunes en el desarrollo del software.
Resource type
Example
Development
dev
Testing
tst
Staging
stg
Production
pro
Region
El siguiente listado resume las abreviaciones para todas las regiones disponibles en AWS.
Asia Pacific
Resource type
Example
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 type
Example
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 type
Example
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 type
Example
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:
Mikel's TechBlog 