📖 Capítulo 5: Lo que nadie te explica de los Templates Unificados
- 14 may
- 3 Min. de lectura
Hasta este punto hemos trabajado construyendo templates orientados a recursos individuales dentro de AWS. Sin embargo, cuando comenzamos a trabajar en escenarios más cercanos a proyectos reales, aparece una necesidad importante:
👉 organizar correctamente la infraestructura.
Y aquí es donde entran los llamados Templates Unificados.
🟦 ¿Qué son los Templates Unificados?
En muchos proyectos pequeños o medianos, no suele ser recomendable fragmentar excesivamente la infraestructura creando un template independiente para cada recurso individual. Por ejemplo:
un template para un usuario IAM,
otro para un rol IAM,
otro para una política IAM.
Muchas veces resulta más mantenible agrupar recursos relacionados dentro de un único template orientado a un dominio funcional específico. En este proyecto llamaremos a este enfoque:
Templates Unificados
Es decir: Templates que agrupan múltiples recursos relacionados bajo una misma lógica de despliegue.
🟦 La verdadera ventaja de unificar templates
La ventaja principal no consiste simplemente en “juntar archivos”. Sino, la verdadera ventaja aparece cuando:
reutilizamos lógica previamente validada,
reducimos fragmentación innecesaria,
simplificamos despliegues,
facilitamos mantenimiento,
mejoramos legibilidad arquitectónica,
y centralizamos configuraciones relacionadas.
🧠 Un punto importante que aprendí
Primero debemos:
construir recursos individualmente,
validar comportamiento,
verificar permisos,
comprender dependencias,
analizar errores.
Y recién después:
👉 unificar la lógica dentro de un template más grande y organizado.
Esto ayuda muchísimo a entender cómo interactúan realmente los recursos entre sí.
🟦 Casos donde sí conviene separar templates
Sin embargo, existen escenarios donde sí resulta recomendable dividir despliegues o reutilizar templates de forma independiente. Por ejemplo:
arquitecturas multi-región,
despliegues multi-cuenta,
stacks independientes,
componentes reutilizables,
equipos distintos administrando infraestructura diferente.
En dichos casos, muchas veces reutilizamos templates parametrizados o dividimos infraestructura en múltiples stacks según la arquitectura requerida.
🟦 Ejemplo práctico utilizado en este proyecto
En este proyecto, previamente construimos el template correspondiente a la política IAM utilizada para la replicación multi-regional en S3. Asimismo, en este capítulo se a creado el rol IAM que será utilizado posteriormente por el bucket origen para ejecutar correctamente el proceso de replicación entre regiones.
Posteriormente, dicho recurso será integrado dentro de un template unificado junto con la política IAM personalizada previamente creada. 🔗 Rol-IAM-Replicacion-MultiRegion-S3
🟦 Recomendaciones importantes al construir Templates Unificados
Comprender correctamente las dependencias
Uno de los puntos más importantes es entender qué recursos dependen de otros para poder crearse correctamente. Por ejemplo:
Un rol IAM puede necesitar previamente una política IAM personalizada.
Aquí utilizamos: DependsOn. Esta propiedad permite definir explícitamente que un recurso debe crearse antes que otro.
⚠️ Importante sobre DependsOn:
CloudFormation muchas veces detecta dependencias automáticamente utilizando referencias implícitas como:
!Ref
!GetAtt
Por ello:
👉 no siempre necesitaremos utilizar DependsOn.
Sin embargo, en algunos escenarios específicos sí resulta útil para forzar explícitamente el orden de creación. Conceptualmente, es bastante similar a cómo Docker Compose utiliza depends_on para coordinar contenedores.
Comprender qué necesita un recurso de otro
Una vez identificadas las dependencias, debemos preguntarnos: ¿Qué necesita exactamente mi recurso B de mi recurso A?. Y aquí dependerá completamente del servicio AWS involucrado.
Muchas veces AWS solicitará:
ARNs,
IDs,
nombres,
atributos específicos,
endpoints,
configuraciones dinámicas.
Por ejemplo:
el rol IAM utilizado en este proyecto necesita asociarse posteriormente a una política IAM personalizada.
Exponer correctamente los Outputs es fundamental
Los Outputs son extremadamente importantes cuando trabajamos con múltiples stacks.
¿Por qué?. Porque permiten reutilizar información generada dinámicamente por un Stack dentro de otros despliegues.
🟦 TEMPLATE — STACK 1
🟦 TEMPLATE — STACK 2
🧠 ¿Qué hace !ImportValue?
!ImportValue permite importar valores previamente exportados desde otro Stack.
Esto facilita muchísimo:
desacoplamiento,
modularidad,
reutilización,
integración entre stacks.
⚠️ Limitaciones importantes de !ImportValue
Es importante tener en cuenta que:
funciona dentro de la misma cuenta AWS,
funciona dentro de la misma región,
y los nombres exportados deben ser únicos.
🟦 Reflexión final sobre Templates Unificados
Estas son recomendaciones que personalmente me hubiese gustado conocer al iniciar en Infraestructura como Código. Porque normalmente al comenzar en CloudFormation:
👉 nos enfocamos únicamente en crear recursos.
Pero no en cómo organizarlos correctamente. Y ahí es donde realmente aparece la complejidad arquitectónica de IaC:
La dificultad no está únicamente en escribir YAML.
La verdadera complejidad aparece cuando debemos:
mantener infraestructura,
reutilizar componentes,
escalar despliegues,
comprender dependencias,
desacoplar arquitectura,
y evitar templates inmantenibles.
Por ello, más allá de aprender sintaxis, es importante comprender la lógica arquitectónica detrás de los templates
🟦 Repositorio del ejemplo completo
Puedes revisar el ejemplo completo del template unificado utilizado en este capítulo aquí:
Comentarios