Pipeline CI/CD multi-cuenta
GitHubCodePipelineCodeBuildCloudFormationAWS CDK

Pipeline CI/CD multi-cuenta

Qué es: una arquitectura de despliegue donde una Tooling Account central contiene la pipeline y promueve el mismo artefacto validado hacia cuentas separadas de DEV, QA y PROD. Cada ambiente vive en su propio límite de confianza, con roles cross-account, aprobaciones explícitas y trazabilidad de punta a punta.

Por qué existe: llega un punto en el que desplegar producción sin una estrategia clara se vuelve el riesgo más grande del equipo. DEV necesita libertad para romper cosas, QA necesita una copia realista para validar con stakeholders y PROD necesita máxima protección. Cuando todo vive en una sola cuenta, los permisos se mezclan, un error en QA puede tocar recursos productivos y el alcance de un incidente es más difícil de contener.

  • Aislamiento real por ambiente: cada cuenta tiene sus propios permisos, límites y controles.
  • Promoción controlada: PROD no recibe cambios que no hayan pasado antes por DEV y QA.
  • Mismo artefacto en todos los ambientes: se evita recompilar o cambiar el paquete entre validación y producción.
  • Aprobaciones visibles: los pasos sensibles quedan registrados en la pipeline, no escondidos en procesos manuales.

Decisión clave: la promoción entre ambientes no debería depender de ramas de Git. Git modela historial de código; la pipeline modela despliegues, evidencias, aprobaciones y artefactos. Con trunk-based development, el equipo mantiene una rama principal limpia y deja que la infraestructura controle cuándo y cómo se mueve un release.

Beneficios: reduce el blast radius, mejora auditoría, separa responsabilidades entre código y despliegue, y hace más difícil que alguien salte accidentalmente los controles de producción. Es especialmente útil en organizaciones con compliance, múltiples equipos o workloads donde un incidente en PROD tiene costo alto.

Trade-off: agrega complejidad real: más cuentas, más roles IAM, más configuración de CI/CD y más gobierno operativo. Para proyectos pequeños puede ser overengineering. Vale la pena cuando el costo de un incidente supera el costo de mantener esta disciplina.

© 2026 Daniel Castillo. Todos los derechos reservados.