Aprovisionamiento multi-cuenta y multi-región

Todo lo del tema anterior daba por sentada una sola cuenta. Las organizaciones reales corren decenas, y el mismo template, el mismo transit gateway y el mismo conjunto de bloques aprobados tienen que llegar a todas sin que una persona haga clic cuenta por cuenta. Este tema cubre los tres mecanismos que AWS ofrece para eso, y la frontera entre ellos es donde vive la mayoría de las preguntas del examen.

Qué cubre este tema

• CloudFormation StackSets: stack sets, stack instances y stacks, y por qué una instance puede existir sin stack
• Permisos self-managed contra service-managed, los dos roles IAM con nombre fijo, el trusted access con AWS Organizations y los delegated administrators
• Targets de despliegue, apuntar a OUs con filtros de cuenta, concurrencia, tolerancia a fallas por región y orden de despliegue entre regiones
• Detección de drift de un stack set, los estados que exigen acción, y la operación que reporta SUCCEEDED mientras hubo stacks fallidos
• AWS RAM: resource shares, managed permissions, invitaciones contra compartición dentro de la organización, y qué tipos de recurso pueden salir de ella
• Subnets de VPC compartidas: qué controla el dueño, qué puede construir un participante, las referencias a security groups entre cuentas, y por qué importan los Availability Zone ID
• Service Catalog: productos, portfolios, launch roles y los cinco tipos de constraint, más catálogos compartidos contra copiados
• AWS Control Tower: la estructura de la landing zone, las cuentas Log Archive y Audit, los controles preventivos, detectivos y proactivos, Account Factory y el drift

Por qué importa

La habilidad 3.1.4 de la guía del examen SOA-C03 nombra AWS RAM y CloudFormation StackSets directamente, y los servicios de gobernanza que los rodean aparecen también en los dominios de seguridad y de redes. Las preguntas de acá casi nunca piden qué es un servicio. Describen un rollout que llegó a 37 de 40 cuentas, una subnet desde la que una cuenta participante no puede salir a internet, o alguien que necesita lanzar una base de datos sin permisos sobre bases de datos, y piden el mecanismo o el arreglo.

La presión del trabajo es igual. En multi-cuenta los errores chicos se multiplican: un baseline que salteó en silencio la cuenta de administración, un resource share que dejó de funcionar después de reorganizar OUs, un launch role tan amplio que el autoservicio se volvió una forma de saltarse los permisos. Saber qué mecanismo se hace cargo de qué problema es lo que mantiene administrable una estructura de cuentas que crece, en vez de convertirla en cuarenta entornos separados que comparten una factura.