Template no Portable en CloudFormation

En esta demostración veremos cómo crear nuestro primer template no portable en CloudFormation.
Aunque es una mala práctica construir un template de esta manera, resulta necesario comprender por qué. Partiremos desde cero con la creación del template, revisaremos su funcionamiento lógico y analizaremos los problemas que puede generar trabajar con un template no portable.

No se puede comenzar a crear un template desde cero; es necesario tener referencias de la estructura de CloudFormation.
Para esto tenemos múltiples páginas, pero la principal es la de AWS:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html

Creando un Template

Todo template primero tiene Resources, que contiene todos los recursos del template.

Ahora definiremos el nombre del recurso lógico que queremos crear.
Este puede ser el que queramos, pero debe permitir identificarlo fácilmente. En este caso será Bucket, ya que crearemos un bucket.

Después debemos definir qué tipo de recurso será. Para eso debemos ver cómo debe ser referenciado: vamos a la página de referencias y buscamos S3.

De esa manera se referencia dentro de CloudFormation y lo agregamos al YAML template.

Ahora debemos definir las propiedades del recurso lógico (el bucket).
Primero agregamos la siguiente línea:

Tenemos una lista inmensa de propiedades que podemos definir al crear un bucket. Para este caso práctico asignaremos solamente un nombre.
Volvemos a la página de referencia y buscamos la propiedad asignar nombre Bucket:

Como podemos ver, se define de la siguiente manera. Ahora lo agregamos al template y asignamos un nombre para nuestro bucket.
⚠️ Ojo: este nombre debe ser único a nivel global, de lo contrario el stack fallará al momento de lanzarlo.

También crearemos un segundo recurso lógico, pero primero volvemos al nivel de indentación del bucket y escribimos el nuevo recurso.

Recordemos que el Type debemos buscarlo en la página de referencias, en este caso para una instancia EC2, y lo pegamos.

A continuación, definiremos el tipo de instancia y su AMI dentro de sus propiedades.

Usaremos la instancia t2.micro y buscaremos la AMI de Amazon Linux. Para eso vamos a la consola de lanzamiento de instancias, copiamos el AMI ID y lo pegamos en el template.

Y así deberíamos tener nuestro primer template creado.

Creando un Stack

El siguiente paso es crear un Stack:

Nos dirigimos a la consola de CloudFormation → Create Stack.
Seleccionamos Cargar archivo template.
Subimos el template construido y damos Next.

Colocamos el nombre, damos siguiente, siguiente, y creamos el stack.

En Resources podemos ver que los recursos lógicos definidos en el template fueron creados como recursos físicos.
Recordemos que existe una sincronización entre los recursos lógicos y físicos: el stack puede eliminar, actualizar o agregar recursos físicos para igualarlos a los definidos en el template.

Probando limitaciones del template

Haremos otra prueba: crearemos un nuevo stack a partir del mismo template.
Subimos el archivo, asignamos un nombre distinto, damos Next → Next → Submit.

El primer stack ya estaba lanzado y en estado CREATE_COMPLETE.
Podríamos pensar que este nuevo stack también debería crearse exitosamente, pero… no es así.

¿Por qué?
Revisando los logs vemos que falló porque ya existe un bucket con el mismo nombre definido en otro stack.
⚠️ Ningún bucket en S3 puede tener el mismo nombre a nivel global.

Este es uno de los motivos por los cuales este template no es portable: no puede usarse múltiples veces, ya que el nombre del bucket está definido de forma explícita.

A continuación eliminaremos ambos stacks.
En los logs del primer stack vemos que, al eliminar los recursos lógicos, el stack automáticamente elimina también los recursos físicos para mantener la sincronización.

Problema de portabilidad entre regiones

Ahora veremos otro motivo por el cual este template no es portable.
Nos moveremos a otra región distinta de la que estábamos.

Lanzamos el template: creamos un nuevo stack, cargamos el archivo, damos nombre, Next → Next → Submit.

En teoría, este stack debería crearse ya que no existe un bucket con ese nombre en esta región.
Pero nuevamente falla…

El error indica que no se encuentra el AMI ID definido.
Esto sucede porque las AMI son únicas por región: el ID que copiamos en us-east-1 (N. Virginia) no existe en us-east-2 (Ohio).

Este es otro gran problema de portabilidad: si queremos replicar un stack en otra región (ejemplo, para un plan de Disaster Recovery), no podremos hacerlo directamente. Esto retrasa el RTO y compromete la continuidad del servicio.

Conclusión

Al definir valores explícitos en un template este deja de ser portable. Esto nos limita porque restringe la cantidad de stacks que podemos lanzar y además complica la replicación en otras regiones. Y es justamente por estas razones que se vuelve necesario avanzar hacia la creación de templates portables.

¡Gracias por leer!