Diseño de despliegues CI/CD entre cuentas en AWS
Separar desarrollo, staging y producción en distintas cuentas de AWS mejora el aislamiento, pero genera una pregunta inmediata sobre el despliegue: ¿cómo puede un mismo pipeline desplegar de forma segura en todas ellas?
Una respuesta práctica es centralizar el CI/CD en una cuenta de tooling y darle al pipeline roles con permisos acotados que pueda asumir en cada cuenta destino.
Qué significa realmente el CI/CD entre cuentas
Considera esta estructura de cuentas:
Organización de AWS
├── Cuenta de Tooling
├── Cuenta de Desarrollo
├── Cuenta de Staging
└── Cuenta de ProducciónLa cuenta de tooling es dueña del pipeline. Desarrollo, staging y producción son dueñas de la infraestructura de la aplicación.
El pipeline no recibe credenciales de administrador permanentes para cada cuenta. En su lugar, cada cuenta de carga de trabajo expone un rol IAM de despliegue que confía en la cuenta de tooling.
El pipeline asume ese rol temporalmente mediante AWS Security Token Service (STS) cuando necesita desplegar.
Conceptualmente:
CodePipeline / GitHub Actions
|
v
Cuenta de Tooling
|
| AssumeRole
v
+-------+-------+-------+
| | |
Dev Staging Producción
Role Role RoleLa distinción importa: el pipeline obtiene solo los permisos necesarios para ese despliegue, y solo mientras dura la sesión del rol.
Un patrón práctico de CI/CD entre cuentas
1. Mantén el CI/CD en una cuenta dedicada
Coloca servicios como CodePipeline, CodeBuild o tus runners de CI autogestionados en una cuenta de tooling.
Esto separa la infraestructura de despliegue de las aplicaciones que se están desplegando, y te da un solo lugar para controlar permisos del pipeline, logs, artefactos y políticas de release.
El mismo modelo funciona también cuando GitHub Actions u otra plataforma de CI externa inicia los despliegues.
2. Crea un rol de despliegue en cada cuenta destino
Cada entorno recibe su propio rol IAM:
DevDeploymentRole
StagingDeploymentRole
ProductionDeploymentRoleLa política de confianza permite que la identidad autorizada del pipeline en la cuenta de tooling asuma el rol.
Los permisos adjuntos al rol determinan qué puede modificar el pipeline.
Evita esto:
AdministratorAccesscuando la aplicación solo requiere CloudFormation, Lambda, API Gateway, DynamoDB u un conjunto limitado de operaciones de infraestructura.
Producción puede usar un rol más restrictivo que desarrollo.
3. Construye una sola vez
El pipeline debería construir el artefacto de la aplicación una sola vez:
Source
↓
Build
↓
Test
↓
ArtefactoAlmacena ese artefacto inmutable en S3 o, para contenedores, en Amazon ECR.
No reconstruyas la aplicación por separado para staging y producción.
De lo contrario, el artefacto que pasó staging no es necesariamente el artefacto desplegado a producción.
4. Promueve el artefacto a través de las cuentas
El flujo de release queda así:
Build
↓
Desarrollo
↓
Pruebas de Integración
↓
Staging
↓
Pruebas de Aceptación
↓
Aprobación
↓
ProducciónSolo debería cambiar la configuración específica de cada entorno.
Por ejemplo:
DATABASE_NAME
LOG_LEVEL
DOMAIN_NAME
SCALING_LIMITEl binario de la aplicación o la imagen de contenedor deben permanecer sin cambios.
AWS CodePipeline admite acciones de despliegue entre cuentas usando roles IAM. Cuando los artefactos del pipeline se comparten entre cuentas, los permisos del bucket de artefactos y la configuración de cifrado también deben permitir el acceso desde la cuenta destino.
5. Trata a producción de forma distinta
Automatización no significa que producción deba desplegarse automáticamente después de cada commit.
Una etapa de producción puede requerir:
- pruebas exitosas en staging;
- una aprobación manual;
- verificaciones automatizadas de seguridad;
- validación de ventana de cambio;
- políticas de despliegue adicionales.
CodePipeline ofrece acciones de aprobación que pueden insertarse directamente en el flujo de despliegue.
El objetivo no es hacer lento el despliegue a producción. Es hacer que la transición hacia producción sea explícita y observable.
Ejemplo: despliegue de una API serverless
Supongamos que una aplicación usa:
API Gateway
Lambda
DynamoDB
S3AWS CDK define la infraestructura.
La cuenta de tooling construye el paquete de Lambda y sintetiza las plantillas de CloudFormation.
El despliegue procede así:
Cuenta de Tooling
|
+--> Assume DevDeploymentRole
| ↓
| Dev
|
+--> Assume StagingDeploymentRole
| ↓
| Staging
|
+--> Assume ProductionDeploymentRole
↓
ProducciónCon AWS CDK, los entornos destino pueden hacer bootstrap para confiar en la cuenta que contiene el pipeline de despliegue. AWS ofrece opciones de bootstrap específicamente para permitir que otra cuenta de AWS despliegue en un entorno.
El código de la aplicación se construye una sola vez. La configuración de CDK provee valores específicos de cada entorno, como el ID de cuenta, la región, el dominio y los límites de capacidad.
Trade-offs y errores comunes
El CI/CD entre cuentas introduce configuración adicional de IAM, cifrado, acceso a artefactos y bootstrapping.
Esa complejidad se justifica cuando los límites de cuenta importan, pero puede ser innecesaria para una carga de trabajo experimental pequeña sin un entorno de producción real.
El error más común es resolver el acceso entre cuentas otorgando permisos excesivos al pipeline.
Otro es construir de forma independiente en cada entorno:
Build Dev
Build Staging
Build ProducciónEso debilita la idea de promoción, porque cada build podría en teoría producir algo distinto.
El manejo de artefactos también merece atención. CodePipeline aplica reglas específicas sobre cómo los artefactos pueden moverse entre cuentas, y los pipelines entre cuentas comúnmente requieren permisos explícitos de bucket S3 y de AWS KMS.
Finalmente, evita colocar secretos de la aplicación directamente en variables del pipeline. El pipeline debería desplegar referencias a secretos específicos de cada entorno almacenados en servicios como AWS Secrets Manager o Systems Manager Parameter Store.
Una lista de verificación simple para el despliegue
Antes de implementar CI/CD entre cuentas, verifica:
- Cada entorno tiene su propia cuenta de AWS.
- El CI/CD se ejecuta desde una cuenta de tooling controlada o una identidad externa confiable.
- Cada cuenta destino expone un rol de despliegue de mínimo privilegio.
- Los artefactos se construyen una sola vez y se promueven.
- El almacenamiento de artefactos y el cifrado admiten el acceso entre cuentas requerido.
- Producción tiene controles de despliegue más estrictos que desarrollo.
- CloudTrail y los logs del pipeline proveen un rastro de auditoría de los despliegues.
Conclusión
El CI/CD entre cuentas es, en gran medida, un problema de diseño de identidad y confianza. El pipeline debería construir una sola vez, asumir roles con permisos acotados en cada entorno y promover el mismo artefacto desde desarrollo hasta producción.
Empieza dibujando las relaciones de confianza entre tu cuenta de tooling y las cuentas de carga de trabajo. Si esas relaciones no son claras o dependen de acceso de administrador amplio, esa es la primera parte del pipeline que debes rediseñar.