Empezamos la Parte VI: AWS avanzado, centrada en los aspectos transversales que distinguen a un profesional: seguridad, observabilidad y costes. Y arrancamos por la seguridad en profundidad. El primer concepto es organizativo y muy poderoso: cómo gestionar varias cuentas de AWS de forma centralizada con AWS Organizations, y cómo poner «barreras» de seguridad con las Service Control Policies (SCP).

Hasta ahora hemos trabajado, implícitamente, con una cuenta de AWS. Para aprender está bien, pero las empresas reales pronto se topan con problemas si lo meten todo en una sola cuenta:

• Sin aislamiento: desarrollo y producción comparten cuenta; un error en pruebas puede afectar a producción.
• Difícil controlar costes por equipo o proyecto (todo se mezcla en una factura).
• Permisos enrevesados: cuesta separar quién puede tocar qué.
• Riesgo concentrado: si la cuenta se ve comprometida, todo está en peligro.

La solución profesional es usar varias cuentas (una para producción, otra para desarrollo, otra para cada equipo...) y gestionarlas de forma centralizada. Veremos la estrategia multi-cuenta a fondo en el Capítulo 30; aquí vemos la herramienta base.

AWS Organizations es el servicio que te permite crear y gestionar múltiples cuentas de AWS de forma centralizada, agrupadas bajo una organización. Tienes una cuenta «raíz» (de gestión) y desde ella administras todas las demás.

Beneficios principales:

• Gestión centralizada de todas las cuentas desde un sitio.
• Facturación consolidada: una sola factura para toda la organización (y descuentos por volumen agregado).
• Control centralizado de la seguridad mediante las SCP (lo vemos enseguida).

Dentro de una organización, las cuentas se agrupan en Unidades Organizativas (OU, Organizational Units), como carpetas. Esto te permite aplicar reglas a grupos de cuentas de forma ordenada:

Analogía: una organización con OUs es como una empresa con departamentos. La dirección (cuenta de gestión) establece normas generales, y cada departamento (OU) agrupa empleados (cuentas) a los que se aplican ciertas reglas. Puedes dar instrucciones a «todo el departamento de producción» de una vez.

Aquí está la pieza de seguridad clave. Una Service Control Policy (SCP) es una regla que define el límite máximo de lo que se puede hacer en una cuenta u OU. Son como barreras de seguridad (guardrails): establecen lo que está permitido como máximo, sin importar lo que digan los permisos individuales.

Importante — la diferencia con IAM: recuerda IAM (Capítulo 7), que concede permisos a usuarios y roles. Las SCP son distintas: no conceden nada, sino que ponen un techo. Aunque un usuario tenga permisos IAM de administrador, no puede hacer algo que una SCP prohíba. La SCP gana siempre.

Analogía: las SCP son como las leyes de un país, e IAM como los permisos de tu trabajo. Tu jefe puede autorizarte muchas cosas (IAM), pero ninguna autorización laboral te permite saltarte la ley (SCP). La ley marca el límite absoluto que nadie puede cruzar.

Las SCP permiten imponer reglas innegociables a toda la organización, que nadie puede saltarse, ni siquiera un administrador de una cuenta. Ejemplos típicos de barreras de seguridad:

• Restringir regiones: «solo se pueden crear recursos en Europa» (por normativa de datos, recuerda la soberanía del subcapítulo 3.4).
• Proteger la auditoría: «nadie puede desactivar CloudTrail ni los logs de seguridad» (para que siempre haya rastro).
• Prohibir servicios concretos: «en las cuentas de desarrollo no se pueden usar servicios caros X o Y».
• Impedir acciones peligrosas: «nadie puede borrar ciertos recursos críticos o las claves de cifrado».

El permiso real de alguien es la intersección: solo puede hacer lo que IAM le concede Y que la SCP permite. Si cualquiera de los dos lo prohíbe, no puede.

Ejemplo del mundo real: una empresa con requisitos de protección de datos europea aplica una SCP a toda la organización: «prohibido crear recursos fuera de las regiones de la UE». A partir de ese momento, da igual que un desarrollador tenga permisos de administrador: si intenta lanzar un servidor en EE. UU., AWS se lo deniega. La regla de cumplimiento queda garantizada técnicamente, no solo en una política escrita que alguien podría ignorar.

Las SCP son la capa más externa de la seguridad de tu organización, el marco dentro del cual operan todas las demás (IAM, Security Groups, WAF...). Recuerda la defensa en profundidad del subcapítulo 16.4: múltiples capas que se refuerzan. Las SCP ponen los límites máximos a nivel de organización; dentro de ellos, IAM afina los permisos concretos, y los demás controles protegen cada recurso.

• Una sola cuenta de AWS no escala para empresas (sin aislamiento, costes mezclados, riesgo concentrado); la solución es usar varias cuentas gestionadas de forma centralizada.
• AWS Organizations permite crear y gestionar múltiples cuentas centralizadamente, con facturación consolidada y agrupadas en Unidades Organizativas (OU) (como departamentos).
• Las Service Control Policies (SCP) son barreras de seguridad que definen el límite máximo de lo permitido en una cuenta u OU. A diferencia de IAM (que concede permisos), las SCP ponen un techo que nadie puede superar, ni un administrador.
• Como las leyes de un país frente a los permisos de tu trabajo: ninguna autorización te permite saltarte la ley.
• El permiso real es la intersección de IAM y SCP. Usos típicos: restringir regiones, proteger la auditoría, prohibir servicios o acciones peligrosas.
• Las SCP son la capa más externa de la defensa en profundidad a nivel de organización.

En el siguiente subcapítulo veremos cómo asegurar que tus recursos cumplen continuamente las reglas con AWS Config.