Tres lecciones han resuelto la mitad del quinto problema: la infraestructura de MercadoFresco es reproducible, está en un repositorio, pasa por revisión y se despliega desde un pipeline que se actualiza a sí mismo. Pero hay una frase que ha aparecido en las tres y que ninguna ha resuelto: los tres entornos comparten la cuenta 111122223333.

Mientras eso siga siendo cierto, un cdk destroy mal dirigido alcanza producción, un despliegue de desarrollo puede agotar una cuota que necesita producción, ninguna política de IAM aísla del todo a quien ya tiene permisos amplios, y la factura no separa de verdad lo que cuesta cada entorno. AWS Organizations es la respuesta: separar los entornos en cuentas distintas y gobernar el conjunto desde arriba.

Aviso de coste. Organizations es gratuito: no cobra por cuentas, ni por unidades organizativas, ni por políticas de control de servicios. Control Tower tampoco cobra por sí mismo, pero activa servicios que sí cuestan: CloudTrail, Config y las notificaciones de la línea base rondan los 10-25 USD al mes por cuenta, y el grabador de Config es la parte más cara. Las cuentas nuevas empiezan con su propia capa gratuita. Cuentas y datos ficticios.

1. Por qué una sola cuenta se queda corta
2. Conceptos: organización, cuenta de gestión, OU y cuentas miembro
3. La estructura de MercadoFresco
4. Crear e invitar cuentas: correo, contactos y raíz
5. Políticas de control de servicios: qué son y qué no
6. Cuatro SCP reales para MercadoFresco
7. Políticas de etiquetas, de copias de seguridad y de IA
8. Facturación consolidada
9. Control Tower, zona de aterrizaje y Account Factory
10. IAM Identity Center: tres personas, cinco cuentas
11. Roles entre cuentas y sts:AssumeRole
12. Servicios a nivel de organización
13. El plan de migración de MercadoFresco
14. Coste y limpieza
15. Errores comunes y consejos
16. Ejercicios
17. Conclusión: cierre del módulo

La cuenta de AWS no es solo una unidad de facturación: es la frontera de aislamiento más fuerte que existe en la plataforma. Todo lo demás —IAM, VPC, etiquetas— es una frontera dentro de la misma casa.

Conviene ver dónde encaja la cuenta entre las fronteras que el curso ya ha usado:

El caso que más asusta a Marta es el primero, y no es teórico: en 09-02 apareció tres veces. cdk destroy MercadoFrescoRedProduccion está a un autocompletado de distancia de MercadoFrescoRedDesarrollo, y ni la protección de terminación ni la disciplina de no usar --all son garantías: son parches. En cuentas separadas, el comando simplemente no tiene permisos para alcanzar producción, porque las credenciales con las que se ejecuta pertenecen a otra cuenta.

El segundo tampoco es teórico. Las cuotas de EC2 —vCPU por familia, IP elásticas, interfaces de red— son por cuenta y región. Una prueba de carga en desarrollo que levanta veinte instancias consume vCPU del mismo cupo que el autoescalado de la tienda, y el viernes a las 19:00, con 900 pedidos/hora, el ASG puede quedarse sin poder crecer por culpa de una prueba lanzada el jueves.

• Organización: el conjunto de cuentas gestionadas de forma centralizada. Tiene una raíz (root), que es el nodo superior del árbol.
• Cuenta de gestión (management account): la cuenta que crea la organización. Es la que paga, la que invita cuentas y la única desde la que se aplican políticas.
• Unidad organizativa (OU): un contenedor de cuentas y de otras OU. Es donde se aplican las políticas, y el motivo por el que existe: agrupar cuentas que deben ser gobernadas igual.
• Cuenta miembro: cualquier cuenta de la organización que no sea la de gestión. Aquí vive todo el trabajo.

Hay una regla que conviene grabar antes de seguir: en la cuenta de gestión no se trabaja. No se despliegan cargas, no se crean usuarios de trabajo, no se ejecutan pipelines. Tres razones:

1. Las SCP no se aplican a la cuenta de gestión. Ni siquiera si la pones dentro de una OU. Cualquier recurso que viva ahí queda fuera de todas las barreras que diseñes.
2. Es la cuenta con más poder de la organización: puede crear cuentas, cambiar políticas y, en último término, sacar cuentas de la organización. Comprometerla es comprometerlo todo.
3. Facturación y gobierno son responsabilidades distintas de las cargas. Mezclarlas hace imposible auditar quién hizo qué.

Un límite útil: la profundidad máxima del árbol de OU es de cinco niveles por debajo de la raíz, y una cuenta pertenece exactamente a una OU.

Seis cuentas, cinco de ellas de trabajo. Las decisiones que hay detrás merecen justificarse una a una:

• Seguridad aísla lo que debe sobrevivir a un incidente en las cuentas de carga: el destino del trail de la organización, el agregador de Config, Security Hub y GuardDuty. Si alguien compromete producción, no puede borrar las pruebas, porque están en otra cuenta a la que no tiene acceso.
• Infraestructura aloja lo compartido entre entornos: el pipeline, mercadofresco-artefactos y los repositorios de imágenes. Separarlo evita la paradoja de que el pipeline que despliega producción viva en producción.
• Cargas agrupa los tres entornos, con una OU por entorno para poder aplicarles políticas distintas. Producción tolera menos que desarrollo, y desarrollo necesita restricciones de coste que producción no.
• Aislamiento está vacía y ese es su propósito: es el destino de una cuenta comprometida. Lleva una SCP que deniega todo, de modo que mover una cuenta ahí la congela en un solo paso, sin tocar sus credenciales ni sus recursos, dejando la evidencia intacta para la investigación.

Y una decisión pragmática que ahorra semanas: la cuenta actual 111122223333 se convierte en producción. Migrar producción es lo más caro y lo más arriesgado; reutilizarla y crear cuentas nuevas para todo lo demás reduce la migración a lo que sí se puede recrear con las plantillas de 09-01 y el CDK de 09-02.

Hay dos formas de que una cuenta entre en la organización: crearla desde dentro o invitar una existente.

--feature-set ALL es importante: la alternativa, CONSOLIDATED_BILLING, solo agrupa la facturación y no permite políticas de control de servicios, que es la mitad del valor de Organizations.

Cuatro detalles operativos que causan problemas si se descuidan:

• Cada cuenta necesita un correo único, y ese correo controla la recuperación del usuario raíz. La práctica correcta es una lista de distribución —[email protected]— que llegue a Marta y a una segunda persona, nunca el correo personal de alguien que puede irse de la empresa. Los alias con + funcionan en la mayoría de proveedores y hacen esto trivial.
• El usuario raíz de cada cuenta miembro se blinda y se olvida: contraseña larga en el gestor de secretos del equipo, MFA activado, y sin claves de acceso. Todo el trabajo diario pasa por Identity Center.
• OrganizationAccountAccessRole se crea automáticamente en las cuentas creadas desde la organización, y permite a la cuenta de gestión asumir un rol de administrador en ellas. En las cuentas invitadas no existe y hay que crearlo a mano antes de invitarlas, o quedarán inaccesibles desde la gestión.
• Los contactos alternativos —facturación, operaciones y seguridad— se rellenan por cuenta y se pueden fijar desde la organización. Es donde AWS avisa de un abuso o de un problema de seguridad, y una cuenta sin ellos recibe los avisos únicamente en el correo del usuario raíz.

Una política de control de servicios (SCP) define el máximo de permisos que pueden ejercerse en una cuenta. Y aquí está la frase que hay que memorizar: una SCP nunca concede permisos, solo los limita.

El permiso efectivo es la intersección: lo que permite la SCP y lo que permite IAM. Consecuencias prácticas:

• Una SCP que permite s3:* no da acceso a S3 a nadie: solo deja que IAM pueda darlo.
• Una SCP que deniega s3:DeleteBucket impide borrar buckets incluso al administrador de la cuenta, incluso con AdministratorAccess. Es su valor principal: limita a quien ya lo puede todo.
• Las SCP no se aplican a la cuenta de gestión ni a los roles vinculados a servicios (AWSServiceRoleFor*).

Hay dos estrategias, y la elección tiene consecuencias enormes:

MercadoFresco elige lista de denegados, que es lo recomendable para el 90 % de las organizaciones: un equipo de tres personas no puede mantener una lista de permitidos sin convertirla en un cuello de botella. La lista de permitidos tiene sentido en entornos muy regulados o en OU con un propósito único.

El reparto habitual de políticas por nivel, que es el que MercadoFresco adopta:

La herencia es acumulativa hacia abajo: una cuenta está sujeta a las SCP de su OU, de las OU superiores y de la raíz, todas a la vez. Y como los Deny siempre ganan, basta con que una sola política del camino deniegue una acción para que quede prohibida. Esa es la razón de la advertencia clásica que viene a continuación.

1. Limitar las regiones. Se aplica en la raíz. Impide crear recursos fuera de eu-west-1, con la excepción obligada de us-east-1, donde viven CloudFront, WAF para CloudFront y los certificados de ACM asociados.

NotAction es imprescindible: los servicios globales se resuelven contra us-east-1 en la API, y denegarlos por región rompería IAM, Route 53 y la propia consola de facturación. Es el error número uno al escribir esta política.

2. Proteger la auditoría. Se aplica en la raíz. Impide que nadie —ni un administrador de producción— borre el rastro.

Esto cierra un hueco real de 05-03: hasta ahora, quien tenía AdministratorAccess en la cuenta podía apagar CloudTrail antes de hacer algo. Ya no.

3. Exigir cifrado en S3. Se aplica en la OU Cargas. Deniega subir objetos sin cifrado y crear buckets sin bloqueo de acceso público.

La segunda declaración usa el patrón de excepción por principal: nadie puede desactivar el bloqueo de acceso público salvo un rol concreto de seguridad. Es la forma correcta de dejar una válvula de escape sin abrir la puerta.

4. Acotar el coste en desarrollo. Se aplica solo en la OU Desarrollo.

La segunda declaración evita un tipo de error que no se deshace: comprar un compromiso de un año desde la cuenta de desarrollo. Los Savings Plans y las instancias reservadas se compran desde la cuenta de gestión, y se reparten solos por toda la organización (11-05).

Una condición que aparece en casi todas las organizaciones y conviene conocer es aws:PrincipalOrgID, que identifica a la organización entera. Permite escribir políticas de recurso del tipo «este bucket es accesible desde cualquier cuenta de mi organización, y solo desde ellas», sin enumerar identificadores de cuenta que cambian con el tiempo:

Es la forma correcta de compartir el bucket de artefactos entre la cuenta de herramientas y las tres de carga: un solo documento que no hay que tocar cuando entre una cuenta nueva. Su hermana aws:PrincipalOrgPaths permite acotar además por OU, por ejemplo para que solo las cuentas de Cargas puedan leer.

Nunca pruebes una SCP nueva aplicándola primero en la raíz. Es el error que convierte una tarde de mejoras en un incidente, y ocurre por dos razones combinadas: las SCP afectan a todas las cuentas de golpe, y sus efectos no siempre son evidentes —un Deny sobre ec2:* rompe también servicios que crean interfaces de red, como Lambda en VPC o RDS—.

El procedimiento correcto tiene cuatro pasos:

1. Escribir la política y revisarla en PR, como cualquier otro código: las SCP viven en mercadofresco-infra.
2. Aplicarla a una sola cuenta de desarrollo y ejecutar allí el pipeline completo, un despliegue y las pruebas de humo.
3. Subirla a la OU Desarrollo, esperar unos días y revisar AccessDenied en CloudTrail.
4. Promocionarla a Cargas o a la raíz.

Y una salvaguarda que evita el peor escenario: la cuenta de gestión no está sujeta a las SCP, así que siempre queda un camino para deshacer una política que haya bloqueado la organización. Es una de las razones por las que su acceso debe estar protegido con MFA y usarse lo menos posible.

Organizations tiene otros tres tipos de política, menos conocidos y muy útiles.

Las políticas de etiquetas definen etiquetas obligatorias, sus valores válidos y sobre qué recursos se exigen. Resuelven el problema que MercadoFresco arrastra desde el módulo 1: que el etiquetado obligatorio depende de que la gente se acuerde.

Con enforced_for, una operación que cree un recurso de esos tipos con un valor de Entorno distinto de los tres permitidos falla. Sin enforced_for, la política solo informa: aparece un informe de incumplimiento y nada más. Esa diferencia es exactamente la de 08-02 entre avisar y bloquear.

Las políticas de copias de seguridad aplican planes de AWS Backup a toda la organización: qué recursos se copian, con qué frecuencia y con qué retención, sin depender de que cada cuenta lo configure. Para MercadoFresco es la garantía de que una cuenta nueva nace con copias, en lugar de descubrirlo el día que hacen falta.

Las políticas de IA (AI services opt-out) permiten excluir a toda la organización del uso de sus datos para mejorar los servicios de IA de AWS. Es una decisión que en Europa suele tomar el área legal, y basta activarla una vez en la raíz.

La facturación consolidada es la parte que menos entusiasma técnicamente y la que más rápido se nota:

• Una sola factura para toda la organización, con desglose por cuenta.
• Descuentos por volumen agregados: los precios escalonados de S3 o de transferencia de datos se calculan sobre el uso sumado de todas las cuentas, así que separar en cuentas no encarece nada. Al contrario: cinco cuentas pequeñas alcanzan antes un escalón de descuento que cinco proyectos aislados en cuentas independientes.
• Reparto automático de Savings Plans e instancias reservadas: un compromiso comprado desde la cuenta de gestión se aplica a cualquier cuenta de la organización que tenga uso elegible. Si producción no consume todo el compromiso una noche, lo aprovecha preproducción. Se detalla en 11-05.
• Capa gratuita: se comparte a nivel de organización, no se multiplica por cuenta.

Y lo más importante para el problema que abrió esta lección: la separación por cuenta hace que la pregunta «¿cuánto cuesta preproducción?» tenga una respuesta exacta y sin trabajo. Antes dependía de que todos los recursos estuvieran bien etiquetados, y en 09-01 se vio que no lo estaban. Ahora es una dimensión nativa de Cost Explorer (11-03).

Dos ajustes que conviene hacer el primer día: activar el uso compartido de descuentos (está activo por omisión, pero se puede desactivar por cuenta si un equipo debe ver su coste sin subvenciones cruzadas) y habilitar las etiquetas de asignación de costes en la cuenta de gestión, ya que solo desde ahí se activan para toda la organización (11-02).

Todo lo anterior se puede montar a mano con la CLI. AWS Control Tower lo hace por ti y añade gobierno continuo.

Una zona de aterrizaje (landing zone) es un entorno multicuenta preconfigurado y conforme a buenas prácticas. Control Tower la crea en unas dos horas: la organización, las OU de seguridad y cargas, una cuenta de archivo de registros, una cuenta de auditoría, un CloudTrail de organización, un agregador de Config, IAM Identity Center configurado y un conjunto de controles activos.

Los controles (guardrails) son de tres tipos, y la distinción importa:

El Account Factory es el aprovisionamiento de cuentas: se rellena un formulario —nombre, correo, OU— y sale una cuenta con la línea base aplicada, la red creada y el acceso configurado. Con Account Factory for Terraform o con StackSets, todo eso se puede disparar desde un pipeline.

¿Cuándo usar Control Tower? El criterio es sencillo:

Para MercadoFresco, con seis cuentas y un equipo que ya domina CDK, la decisión de Marta es empezar con Organizations a mano —las políticas son pocas y quiere entenderlas— y dejar Control Tower anotado para cuando la organización pase de diez cuentas. Es una decisión defendible; la contraria también lo sería.

Con seis cuentas, la pregunta operativa es inmediata: ¿Marta necesita seis usuarios? La respuesta es que necesita cero usuarios de IAM.

IAM Identity Center (antes AWS SSO) proporciona un directorio de identidades —propio, o federado con Entra ID, Okta o Google Workspace— y asigna conjuntos de permisos a combinaciones de usuario o grupo y cuenta. Al iniciar sesión, cada persona ve un portal con las cuentas y roles a los que tiene acceso, y al entrar recibe credenciales temporales: no hay claves de acceso de larga duración en ningún portátil.

Un conjunto de permisos es una plantilla de rol que Identity Center materializa en cada cuenta asignada. El diseño de MercadoFresco:

Cuatro decisiones de diseño que merecen explicación:

• Luis no tiene administración en producción. Tiene lectura y permiso para lanzar el pipeline, que es lo que de verdad necesita: desde 08-04, desplegar es aprobar una transición, no ejecutar comandos. Este es el punto donde el pipeline deja de ser una comodidad y pasa a ser un control de seguridad.
• Las sesiones administrativas duran una hora. Una sesión larga con permisos altos es una credencial olvidada en un terminal.
• RespuestaIncidentes es un acceso de emergencia deliberadamente incómodo: requiere aprobación y su uso dispara una notificación a alertas-mercadofresco. Existe para las tres de la mañana, no para el martes por la tarde.
• Sara solo entra en producción, y solo a datos. No necesita desarrollo ni preproducción, y darle acceso «por si acaso» es exactamente lo que 04-01 desaconseja.

Y el uso diario desde la CLI, que sustituye al perfil mercadofresco-dev con claves estáticas del módulo 1:

Identity Center resuelve el acceso de personas. El acceso entre servicios de cuentas distintas se resuelve con roles y sts:AssumeRole, exactamente el mecanismo de 04-01 cruzando la frontera de cuenta.

El caso concreto de MercadoFresco: el pipeline vive en herramientas-mercadofresco (555566667777) y tiene que desplegar en las tres cuentas de carga.

Ese documento es la política de confianza del rol rol-despliegue-mercadofresco en la cuenta de producción: dice quién puede asumirlo. La política de permisos del rol, aparte, dice qué puede hacer una vez asumido. Son dos cosas distintas y ambas deben ser restrictivas: una política de confianza que acepte "AWS": "111122223333" sin más permite a cualquier principal de esa cuenta asumir el rol.

En CDK, el bootstrap ya contempla esto: cdk bootstrap --trust 555566667777 crea los roles de despliegue de la cuenta destino confiando en la cuenta de herramientas, y a partir de ahí cdk deploy funciona entre cuentas sin más configuración. Es el motivo por el que en 09-02 se insistía en declarar env con cuenta explícita: con varias cuentas, la cuenta destino deja de ser un detalle y pasa a ser parte de la definición de la pila.

Muchos servicios de seguridad y gobierno se pueden activar para toda la organización desde una cuenta de administrador delegado —típicamente seguridad-mercadofresco—, de modo que las cuentas nuevas quedan cubiertas automáticamente.

La pieza que cierra el círculo del módulo es la última fila. El StackSet ss-mercadofresco-linea-base de 09-01, con --permission-model SERVICE_MANAGED y --auto-deployment Enabled=true, hace que cualquier cuenta que entre en una OU reciba la línea base sin que nadie haga nada: alarma de facturación, roles de acceso, configuración de contactos, bloqueo de acceso público de S3 y suscripción al agregador de Config.

Ese comando es la respuesta a «cómo garantizamos que la cuenta que creemos dentro de seis meses tenga todo lo que debe tener». La respuesta es: no lo garantiza una persona, lo garantiza una OU.

La migración de una cuenta a cinco de trabajo —más la de gestión— se hace en seis fases, sin cortar el servicio. La regla que ordena todo el plan es: primero lo que se recrea, después lo que se mueve, y los datos al final, con permiso.

Fase 1: crear la organización y las cuentas (día 1). Se crea una cuenta de gestión nueva y vacía —999988887777—, se crea la organización con --feature-set ALL y se invita a la cuenta actual 111122223333, que se convierte en producción y se coloca en su OU. Se crean las otras cuatro cuentas. Nada cambia para el servicio: la cuenta de producción sigue funcionando exactamente igual.

Fase 2: acceso y línea base (días 2-5). IAM Identity Center con los conjuntos de permisos, y el StackSet de línea base sobre todas las OU. Los usuarios de IAM del módulo 1 se desactivan pero no se borran hasta comprobar que nada automatizado los usaba. CloudTrail de organización y agregador de Config, con destino en la cuenta de seguridad.

Fase 3: entornos nuevos desde código (semanas 2-3). Aquí se cobra el trabajo de las tres lecciones anteriores. Desarrollo y preproducción se recrean desde cero en sus cuentas con el CDK de 09-02: cdk bootstrap en cada cuenta y cdk deploy con env apuntando a la cuenta correspondiente. No se migra nada: se despliega. Si algo no se puede recrear, es que faltaba en el código, y ese descubrimiento es en sí mismo valioso.

Fase 4: pipeline y herramientas (semana 4). El pipeline se mueve a herramientas-mercadofresco y se le dan roles entre cuentas hacia las tres de carga. Se despliega a desarrollo y preproducción desde la cuenta nueva y se verifica de extremo a extremo antes de tocar producción.

Fase 5: SCP progresivas (semanas 4-6). Las políticas se aplican en el orden de la advertencia: primero una cuenta de desarrollo, luego la OU Desarrollo, luego Cargas, y solo al final las dos de la raíz. Entre escalón y escalón, revisión de AccessDenied en CloudTrail.

Fase 6: los viejos entornos (semana 7). Se apagan los recursos de desarrollo y preproducción que quedaban en la cuenta de producción. Esto libera cuota, reduce el ruido y es donde aparece el ahorro: unos 340 USD al mes de recursos duplicados que nadie sabía que seguían encendidos.

Los datos son la parte delicada y merecen su propio apartado, con tres reglas.

Producción no se mueve. Al reutilizar 111122223333 como cuenta de producción, Aurora, DynamoDB, Redshift y los cinco buckets se quedan donde están. Es la decisión que elimina el 90 % del riesgo del proyecto.

Los datos de desarrollo y preproducción no se copian: se generan. Es una oportunidad para hacer lo que debía estar hecho: preproducción se puebla con datos sintéticos o anonimizados, no con una copia de producción. Además de ser más seguro, elimina una fuente de deriva.

Y aquí hay un aviso que no es técnico. Si en algún momento se plantea copiar datos de producción a otra cuenta para pruebas, eso es un tratamiento de datos personales de clientes y cae bajo el RGPD: nombres, direcciones de reparto, teléfonos e historial de compra. Una copia a otra cuenta —aunque sea de la misma organización y la misma región— es una transferencia que debe estar justificada, documentada y limitada en el tiempo, y la anonimización debe ser real, no un cambio de nombre. Esta decisión no la toma el equipo técnico solo: la revisa quien lleva cumplimiento. Marta lo deja escrito en el plan como requisito bloqueante, no como recomendación.

Organizations, las OU y las SCP son gratuitas. Lo que cuesta es lo que se activa con ellas:

Para MercadoFresco, el gobierno completo sale por unos 90 USD al mes, frente a los 340 USD que se ahorran al apagar los entornos duplicados. La migración se paga sola.

Sobre la limpieza, dos avisos serios. Cerrar una cuenta de AWS no es inmediato: queda en estado suspendido 90 días antes de cerrarse definitivamente, y durante ese tiempo no se pueden recuperar sus recursos ni reutilizar su correo. Y una cuenta que sale de la organización necesita su propio método de pago y sus contactos completos, o quedará bloqueada. Nunca saques una cuenta de la organización sin haberla preparado antes.

Error: trabajar en la cuenta de gestión. Es el error estructural más caro, porque las SCP no la protegen y todo lo que despliegues ahí queda fuera de las barreras. Consejo: cuenta de gestión vacía, acceso con MFA y uso excepcional.

Error: probar una SCP en la raíz. Un Deny mal calibrado puede dejar la organización sin poder desplegar. Consejo: el orden de la advertencia —una cuenta, una OU, la raíz—, siempre con revisión de AccessDenied en CloudTrail entre pasos.

Error: denegar por región sin NotAction. Rompe IAM, Route 53, CloudFront y la consola de facturación, porque los servicios globales se resuelven contra us-east-1. Consejo: la lista de exclusiones de la primera SCP de esta lección.

Error: correos personales como raíz de las cuentas. El día que esa persona se va, la cuenta queda huérfana. Consejo: listas de distribución con al menos dos destinatarios, y contactos alternativos rellenados.

Error: invitar una cuenta sin crear antes OrganizationAccountAccessRole. En cuentas invitadas no existe, y sin él la cuenta de gestión no puede entrar. Consejo: crearlo antes de invitar.

Error: creer que una SCP concede permisos. Un Allow en una SCP no da acceso a nadie: solo levanta el techo. Consejo: interiorizar que el permiso efectivo es la intersección de SCP e IAM.

Consejo: guarda las SCP y la estructura de OU en mercadofresco-infra. Todo lo de este módulo aplica también aquí: las políticas son código, se revisan en PR y se despliegan desde el pipeline.

Consejo: activa el administrador delegado de los servicios de seguridad. Mantiene la cuenta de gestión vacía y da a seguridad su propio ámbito.

Consejo: usa aws:PrincipalOrgID en las políticas de recurso compartidas. Evita listas de cuentas que hay que mantener y se ajusta solo cuando entra una cuenta nueva.

Consejo: crea la OU de aislamiento antes de necesitarla. Vacía y con su Deny puesto, es un movimiento de treinta segundos el día de un incidente; improvisarla ese día no lo es.

Consejo: pon un presupuesto por cuenta el primer día. Con la separación por cuenta, AWS Budgets (11-04) se vuelve preciso: una alerta por cuenta detecta antes una fuga que un presupuesto global.

Marta aplica en la OU Cargas una SCP que deniega todas las acciones de iam:* salvo lectura, con el argumento de que solo el CDK debe crear roles. Al día siguiente, el pipeline falla en todos los entornos con AccessDenied al desplegar la pila de aplicación, y además una función Lambda nueva no consigue arrancar. Explica (a) por qué falla exactamente el pipeline; (b) por qué falla la Lambda, que es un fallo distinto; (c) cómo se diagnostica con las herramientas del módulo 5; (d) cómo se corrige la política manteniendo la intención original; y (e) qué paso del procedimiento correcto se saltó Marta.

MercadoFresco contrata a Elena, desarrolladora, que se incorpora al equipo de Luis. Debe poder desarrollar con libertad, ver qué pasa en producción cuando hay un incidente, lanzar despliegues a preproducción pero no a producción, y no debe poder leer datos personales de clientes. Diseña sus accesos: qué grupos, qué conjuntos de permisos, en qué cuentas, con qué duración de sesión y qué mecanismo usarías para lo de los datos personales. Indica también qué no le darías aunque lo pidiera, y cómo gestionarías el día que necesite acceso de emergencia a producción.

Un compañero propone acelerar el plan: crear las cinco cuentas el lunes, mover producción a una cuenta nueva y limpia el martes por la noche —«así todo queda ordenado desde el principio»—, y aplicar todas las SCP el miércoles. Argumenta que hacerlo de golpe evita meses de estado intermedio. Responde: (a) tres riesgos concretos de mover producción a una cuenta nueva; (b) qué le ocurre a Aurora, a los buckets y a la zona de Route 53 en ese movimiento; (c) por qué aplicar todas las SCP el miércoles es peor idea todavía; (d) qué parte de su propuesta sí es razonable; y (e) cómo se lo explicarías en una frase.

Solución 1

(a) El pipeline falla porque CloudFormation necesita iam:CreateRole y iam:PassRole. La pila de aplicación crea el perfil de instancia del ASG y el rol de ejecución de las Lambdas; ambos requieren crear roles y pasarlos al servicio que los usará. iam:PassRole es especialmente fácil de olvidar porque no crea nada: autoriza a entregar un rol existente a un servicio, y sin él el despliegue falla aunque el rol ya exista.

(b) La Lambda falla por un motivo distinto y más sutil: los roles vinculados a servicios. Cuando una Lambda se asocia a una VPC, AWS crea AWSServiceRoleForLambdaReplicator o similares mediante iam:CreateServiceLinkedRole. Aunque las SCP no se aplican a los principales de servicio, sí se aplican a la llamada que hace tu rol al pedir la creación de ese rol vinculado. Es la categoría de fallo que hace que las SCP sean peligrosas: rompen cosas que nadie relaciona con IAM.

(c) El diagnóstico. CloudTrail (05-03) es la herramienta: los eventos denegados aparecen con errorCode: AccessDenied y, cuando la causa es una SCP, con un mensaje que menciona explícitamente una política de control de servicios. Una consulta a Athena sobre el trail de la organización filtrando por errorCode en las últimas 24 horas devuelve la lista completa de acciones bloqueadas, que es exactamente la información que hacía falta para calibrar la política. Es también el mecanismo del paso 3 del procedimiento correcto.

(d) La corrección. La intención —que nadie cree roles a mano— es buena; la implementación es demasiado gruesa. Se mantiene el Deny sobre las acciones de escritura de IAM pero se exceptúan los principales legítimos y las acciones necesarias:

Con esto, solo los roles de despliegue del CDK y del pipeline pueden crear roles, y PassRole y CreateServiceLinkedRole quedan fuera del bloqueo. Una alternativa complementaria es exigir un límite de permisos (iam:PermissionsBoundary) en todo rol creado, que acota lo que esos roles podrán hacer aunque alguien los cree.

(e) El paso que se saltó. El segundo y el tercero: no probó la política en una sola cuenta de desarrollo ejecutando el pipeline completo, ni la dejó reposar en la OU Desarrollo revisando AccessDenied. Aplicarla directamente a Cargas significa aplicarla a producción, y la propia lección advierte de esto. El detalle agravante es que un fallo así aparece en el siguiente despliegue, que puede ser horas después y sin relación aparente con el cambio.

Solución 2

Grupos y conjuntos de permisos. Elena entra en el grupo desarrolladores del directorio de Identity Center, que ya tiene asignaciones; no se le crea nada específico, porque los permisos individuales son deuda de gobierno.

El conjunto nuevo, LecturaOperacion, es la parte interesante: ReadOnlyAccess es demasiado amplio porque incluye leer objetos de S3 y consultar DynamoDB, es decir, datos de clientes. Lo correcto es un conjunto a medida con CloudWatch, X-Ray, la consola de ECS/EC2 y los estados de CloudFormation, y Deny explícito sobre s3:GetObject en los buckets con datos personales, dynamodb:GetItem, dynamodb:Query y rds-data:*.

El mecanismo para los datos personales tiene dos capas, y ninguna de las dos basta sola. La primera es la política del conjunto de permisos, con los Deny anteriores. La segunda es una SCP en la OU Produccion que deniegue el acceso a los buckets y tablas con datos de clientes salvo a una lista corta de roles de aplicación; así, aunque alguien amplíe el conjunto de permisos por error, la barrera sigue en pie. Es la diferencia entre una política que se puede cambiar en la cuenta y un techo que no.

Lo que no le daría aunque lo pida: administración en producción; permiso para crear usuarios o claves de acceso de IAM —desde Identity Center no hacen falta y son la principal fuente de credenciales filtradas—; y acceso permanente de escritura a preproducción por fuera del pipeline, porque volvería a abrir el camino de «desplegar a mano» que el módulo 8 cerró.

El acceso de emergencia se resuelve con RespuestaIncidentes: asignable a Elena, con sesión de una hora, aprobación de Marta y notificación automática a alertas-mercadofresco al usarlo. La regla que lo hace funcionar es que usarlo no es un problema; usarlo sin incidente sí lo es, y la notificación existe para que la revisión sea posible.

Solución 3

(a) Tres riesgos de mover producción a una cuenta nueva. Primero, los datos: Aurora, DynamoDB y los buckets tienen que replicarse o restaurarse en la cuenta destino, lo que implica una ventana de corte o una replicación con doble escritura, más una verificación de integridad de la que nadie ha hablado. Segundo, las identidades y referencias: los ARN cambian de cuenta, así que roles, políticas de bucket, claves de KMS, endpoints y todo lo que los mencione hay que revisarlo; una política de KMS que referencia la cuenta vieja deja de funcionar y produce fallos de descifrado difíciles de diagnosticar. Y tercero, lo que no está en el código: certificados de ACM, la zona de Route 53, los ajustes de CloudFront, WAF y las cuotas ampliadas por soporte, que no se migran automáticamente y suelen descubrirse a mitad de la ventana.

(b) Qué le pasa a cada cosa. Aurora no se mueve: se comparte una instantánea con la cuenta destino —lo que exige compartir también la clave de KMS— y se restaura, con lo que se obtiene un clúster nuevo con endpoint distinto, y todo lo que se conecte debe cambiar. Los buckets no se mueven: los nombres son globales, así que hay que crear buckets nuevos con otro nombre y copiar los objetos, revisando además las políticas y las URL públicas de las fotos de producto que puedan estar cacheadas en CloudFront. La zona de Route 53 sí se puede mover manteniendo los mismos servidores de nombres, que es la única buena noticia del apartado, pero exige coordinar el cambio con los registros que apuntan a recursos cuyos ARN están cambiando a la vez.

(c) Por qué aplicar todas las SCP el miércoles es peor todavía. Porque acumula tres errores a la vez: aplicarlas sin probar, aplicarlas todas juntas y aplicarlas justo después de una migración. Si algo falla el jueves —y algo fallará—, será imposible saber si la causa es una SCP, la migración o los ARN que cambiaron. El diagnóstico depende de poder aislar la variable, y esa propuesta las mezcla todas. Es el mismo principio de 08-05 con los despliegues pequeños: el ámbito de un cambio debe permitir atribuir el fallo.

(d) Lo que sí es razonable. Crear las cinco cuentas el lunes es correcto y no tiene riesgo: crear cuentas no mueve nada. También lo es la intención de fondo —no dejar un estado intermedio eterno—, que es un problema real: las migraciones a medias tienden a durar años. La respuesta a eso no es acelerar, es poner fecha límite a cada fase y tratar el plan como un proyecto con hitos, no como una intención.

(e) La frase. «Reutilizar la cuenta actual como producción nos ahorra la única parte verdaderamente peligrosa de esta migración —mover los datos— y no nos cuesta nada, porque una cuenta no tiene memoria de lo que fue: lo que importa es la OU en la que la ponemos y las políticas que le aplicamos.»

El quinto problema queda resuelto. MercadoFresco puede recrear su entorno completo desde cero con un comando, y ya no lo hace todo en la misma cuenta.

Esta lección ha convertido la cuenta única en una organización de seis cuentas con cuatro unidades organizativas. Seguridad guarda lo que debe sobrevivir a un incidente en las cuentas de carga; Infraestructura aloja el pipeline y los artefactos, resolviendo la paradoja de que lo que despliega producción viviera en producción; Cargas agrupa los tres entornos con una OU cada uno, porque producción tolera menos que desarrollo; y Aislamiento está vacía a propósito, para congelar una cuenta comprometida en un solo movimiento sin destruir la evidencia. Con la decisión pragmática que sostiene todo el plan: la cuenta 111122223333 se convierte en producción, porque migrar datos es la única parte verdaderamente peligrosa y se puede evitar entera.

Tienes las políticas de control de servicios con la frase que hay que memorizar —nunca conceden permisos, solo los limitan— y con lo que eso permite por primera vez: limitar a quien ya lo puede todo, de modo que ni un administrador de producción pueda apagar trail-mercadofresco ni desactivar Config. Cuatro políticas reales: regiones acotadas con NotAction para no romper los servicios globales, auditoría protegida, cifrado obligatorio en S3 con excepción por principal, y tipos de instancia y compras de compromiso bloqueados en desarrollo. Más la advertencia que evita convertir una tarde de mejoras en un incidente: una cuenta, luego una OU, luego la raíz, revisando AccessDenied en CloudTrail entre escalones, con la cuenta de gestión como salvavidas porque las SCP no se le aplican —y por eso mismo, en la cuenta de gestión no se trabaja—.

Tienes la facturación consolidada, que responde «¿cuánto cuesta preproducción?» sin depender de que las etiquetas estén bien puestas, conserva los descuentos por volumen agregados y reparte Savings Plans e instancias reservadas entre cuentas (11-05). El acceso correcto con IAM Identity Center: cero usuarios de IAM, credenciales temporales, y conjuntos de permisos que reflejan responsabilidades reales —Luis con lectura y permiso para lanzar el pipeline en producción, que es el punto en el que el pipeline deja de ser una comodidad y se convierte en un control de seguridad; Sara solo con datos y solo en producción; y un acceso de emergencia deliberadamente incómodo, con aprobación y notificación—. Y los roles entre cuentas con sts:AssumeRole, con la política de confianza y la de permisos como dos cosas distintas y ambas restrictivas.

Los servicios de organización cierran el círculo: CloudTrail de organización y agregador de Config en la cuenta de seguridad, Security Hub, GuardDuty, Access Analyzer y, sobre todo, el StackSet ss-mercadofresco-linea-base de 09-01 con despliegue automático, que responde a «cómo garantizamos que la cuenta que creemos dentro de seis meses tenga todo lo que debe tener»: no lo garantiza una persona, lo garantiza una OU. El plan de migración va en seis fases con una regla que las ordena —primero lo que se recrea, después lo que se mueve, los datos al final y con permiso—, con desarrollo y preproducción desplegados desde el CDK en lugar de migrados, que es donde se cobra el trabajo de las dos lecciones anteriores. Y con un requisito bloqueante que no es técnico: copiar datos de clientes entre cuentas es tratamiento de datos personales bajo el RGPD, y lo revisa cumplimiento antes de que nadie ejecute nada.

Con esto, los cinco problemas del curso están resueltos. Las caídas de los viernes, con autoescalado, caché y colas. Las copias no fiables, con instantáneas, replicación y retención. El crecimiento a más ciudades, con una arquitectura desacoplada. Los despliegues arriesgados, con un pipeline que revierte solo en cuatro minutos. Y ahora la infraestructura no gobernada, con plantillas, constructos, pruebas, cuentas separadas y barreras que se aplican solas.

Queda una cosa que ninguna de las cuatro lecciones ha tocado, y que se ve en cuanto miras las instancias. La tienda sigue ejecutándose sobre EC2 que hay que parchear, con AMI que hay que reconstruir cada vez que cambia una dependencia, y con un arranque de dos minutos que es exactamente el tiempo que sobra el viernes a las 19:00: cuando el ASG detecta el pico y lanza una instancia, los clientes ya han esperado. El CDK describe esas instancias muy bien; Beanstalk las gestionaba muy bien; pero ninguno de los dos hace que dejen de existir.

En el módulo 10, «Contenedores en AWS», atacamos precisamente eso. 10-01, «ECS y ECR», introduce la orquestación de contenedores y el registro de imágenes que sustituye a las AMI. 10-02, «Fargate», elimina las instancias del todo: sin servidores que parchear y con arranques de segundos en lugar de minutos. Y 10-03, «EKS», muestra la alternativa con Kubernetes y cuándo compensa su complejidad. La tienda de MercadoFresco va a dejar de vivir en máquinas.