📖 Capítulo 6: La importancia del objetivo de un proyecto en IaC y su despliegue en múltiples regiones
- 16 may
- 3 Min. de lectura
En este capítulo comenzaremos a trabajar sobre el core principal de este proyecto: la replicación multi-regional en Amazon S3. Y aunque inicialmente podría parecer simplemente “replicar archivos entre buckets”, en realidad este proyecto tiene un objetivo mucho más importante:
Comprender cómo desplegar infraestructura distribuida entre múltiples regiones utilizando Infraestructura como Código.
🟦 ¿Por qué replicar información entre regiones?
Amazon S3 permite replicar automáticamente información entre buckets ubicados en diferentes regiones de AWS. Esto evita tener que copiar manualmente archivos entre regiones y facilita muchísimo arquitecturas distribuidas.
Gracias a ello, un bucket principal puede replicar automáticamente su contenido hacia otros buckets ubicados en distintas regiones. Y aquí aparecen conceptos fundamentales dentro de arquitectura cloud:
resiliencia,
recuperación ante desastres,
redundancia geográfica,
continuidad operativa,
tolerancia a fallos.
🟦 El verdadero valor de una arquitectura multi-región
Uno de los escenarios donde una arquitectura multi-región cobra muchísimo valor ocurre durante incidentes regionales o eventos de disaster recovery. Recordemos que regiones críticas como: us-east-1 en AWS, han llegado a presentar incidentes importantes que afectaron múltiples plataformas y servicios ampliamente utilizados.
Ahora imaginemos el siguiente escenario:
nuestros backups,
nuestros archivos críticos,
nuestros datos empresariales,
dependen únicamente de una sola región.
Y, si dicha región presenta problemas operativos importantes, nuestra capacidad de recuperación puede verse seriamente afectada. Por ello, distribuir datos entre múltiples regiones independientes puede aumentar significativamente:
disponibilidad,
resiliencia,
recuperación ante fallos,
y continuidad operativa.
🟦 Amazon S3 y la replicación multi-regional
Amazon S3 incorpora capacidades nativas para replicación entre regiones mediante funcionalidades como:
Cross-Region Replication (CRR)
Same-Region Replication (SRR)
Gracias a ello, AWS automatiza gran parte del proceso de replicación. Sin embargo, es importante entender algo: la replicación NO funciona únicamente activando una opción. Internamente, AWS requiere múltiples componentes importantes:
versioning habilitado,
permisos entre buckets,
políticas IAM,
roles específicos,
reglas de replicación,
configuraciones adecuadas.
Y justamente ahí es donde este proyecto tiene muchísimo valor educativo:
👉 comprender cómo desplegar toda esa arquitectura mediante IaC.
🟦 El verdadero objetivo de este proyecto
El objetivo de este proyecto no es únicamente crear buckets S3, sino, consiste en comprender:
cómo desplegar recursos en distintas regiones,
cómo automatizar infraestructura distribuida,
cómo gestionar dependencias multi-región,
cómo organizar despliegues regionales,
y cómo diseñar arquitecturas resilientes utilizando IaC.
🟦 ¿Cómo desplegar infraestructura en múltiples regiones?
Existen múltiples mecanismos para realizar despliegues multi-región en AWS. Por ejemplo:
StackSets,
pipelines CI/CD,
automatizaciones,
herramientas DevOps,
scripts de orquestación.
Sin embargo, para este proyecto utilizaremos inicialmente un enfoque más simple y pedagógico:
Automatizar despliegues regionales mediante scripts de ejecución.
Esto permitirá comprender primero cómo CloudFormation administra recursos regionales antes de introducir mecanismos más avanzados.
🟦 ¿Por qué utilizamos dos templates distintos?
Aquí aparece una pregunta bastante interesante:
¿Por qué utilizar dos templates distintos si ambos recursos pertenecen al servicio S3?
La respuesta está directamente relacionada con el comportamiento regional de CloudFormation.
🟦 El comportamiento regional de CloudFormation
Cada Stack individual de CloudFormation opera dentro de:
una única cuenta AWS,
y una única región.
Por ejemplo:
un Stack desplegado en us-east-1
no desplegará automáticamente recursos en us-west-2.
Y aquí es donde muchas veces aparecen confusiones cuando comenzamos con Infraestructura como Código, el template puede reutilizarse múltiples veces. Pero:
El despliegue del Stack siempre ocurre sobre una región específica.
Por ello, en este proyecto:
desplegaremos un Stack para el bucket origen,
desplegaremos otro Stack para el bucket destino,
y cada uno operará dentro de su región correspondiente.
🟦 Sobre las regiones y los templates
Es importante aclarar algo:
Los templates sí pueden contener:
parámetros,
mappings,
condiciones,
pseudo parámetros regionales.
Sin embargo:
👉 el template por sí solo NO controla automáticamente despliegues multi-región.
La región final dependerá de:
dónde desplegamos el Stack,
StackSets,
automatizaciones,
pipelines CI/CD,
scripts de despliegue.
🟦 Templates utilizados en este capítulo
Aquí puedes revisar los templates correspondientes a los buckets origen y destino utilizados para la replicación multi-regional:
🔗 GitHub: Templates-Buckets-S3
Comentarios