Seguimos en la Parte VII con el Capítulo 30: Multi-cuenta y landing zones, que trata sobre cómo organizan AWS las empresas grandes. En el subcapítulo 23.1 vimos AWS Organizations y las SCP, y mencionamos que las empresas usan varias cuentas. Ahora profundizamos: ¿por qué separar las cosas en cuentas distintas en vez de meterlo todo en una? Entender esto es clave para diseñar la base de cualquier organización seria en AWS. La idea central: la cuenta de AWS es la mejor unidad de separación que existe.

Una cuenta de AWS es un «contenedor» completo y aislado de recursos, con su propia facturación y sus propios límites de seguridad. Hasta ahora hemos trabajado, implícitamente, dentro de una cuenta. Las empresas grandes, en cambio, usan muchas cuentas coordinadas (con AWS Organizations, subcapítulo 23.1). La pregunta es por qué.

Imagina una empresa con varios equipos, varios proyectos y los entornos de desarrollo, pruebas y producción, todo en una sola cuenta de AWS. Surgen problemas serios:

Es como tener a toda una empresa trabajando en una única habitación gigante sin paredes: el ruido, el desorden y los riesgos de unos afectan a todos. Hace falta poner «paredes». Y en AWS, la mejor «pared» es la cuenta.

La práctica recomendada para empresas es separar los distintos workloads (cargas de trabajo) en cuentas diferentes. Cada equipo, proyecto o entorno importante va en su propia cuenta. La cuenta es la unidad de separación más fuerte de AWS, porque ofrece aislamiento en tres dimensiones a la vez:

Analogía: separar en cuentas es como dividir un edificio en apartamentos independientes en vez de una nave diáfana. Cada apartamento tiene su puerta con llave (un problema en uno no entra en los otros: seguridad), su contador de la luz (cada uno paga lo suyo: costes), y sus propias instalaciones (uno no agota el agua del otro: límites). Vivir en apartamentos separados es mucho más ordenado y seguro que compartir una nave sin paredes. Las cuentas son esos apartamentos.

Si separas en cuentas, un problema de seguridad en una cuenta (una brecha, un error, un ataque) queda contenido en esa cuenta y no afecta a las demás. Es la aplicación máxima del «radio de explosión» limitado: si algo sale mal, el daño está acotado.

Esto es especialmente valioso para separar producción (lo crítico) de desarrollo/pruebas (donde se experimenta y hay más riesgo). Un error de un desarrollador en su cuenta de pruebas jamás debería poder tocar producción, y separar cuentas lo garantiza.

Con cada workload en su cuenta, la factura de cada uno está separada automáticamente (recuerda la facturación consolidada de Organizations, subcapítulo 23.1: ves el total, pero también el desglose por cuenta). Saber exactamente cuánto cuesta cada proyecto o equipo es esencial para la gestión de costes (recuerda FinOps, subcapítulo 25.5). En una sola cuenta, separar costes es mucho más difícil (dependes solo de etiquetas).

AWS impone ciertos límites por cuenta (cuántos recursos de cierto tipo puedes crear, etc.). Si todo está en una cuenta, un proyecto podría agotar esos límites y afectar a los demás. Con cuentas separadas, cada workload tiene sus propios límites y no estorba a los otros.

¿Cómo deciden las empresas qué va en cada cuenta? Patrones comunes:

Estas cuentas se agrupan ordenadamente en Unidades Organizativas (OU) dentro de AWS Organizations (recuerda el subcapítulo 23.1), y se les aplican reglas comunes con SCP.

Ejemplo del mundo real: una empresa con tres equipos de producto decide su estructura multi-cuenta. Cada equipo recibe dos cuentas: una de desarrollo (donde experimentan libremente) y una de producción (con controles estrictos). Además, crean una cuenta de seguridad central (para el equipo de seguridad) y una cuenta de logs (donde se centralizan todos los registros). Resultado: cuando un desarrollador rompe algo en su cuenta de desarrollo, producción ni se entera; cada equipo ve exactamente lo que cuesta su producto; y un incidente en un equipo queda aislado de los demás. La empresa pasó de un «todo mezclado» arriesgado a una estructura ordenada, segura y con costes claros. Esa separación es la base de operar a escala.

• Meter todo en una sola cuenta de AWS no escala: mezcla entornos (un error en pruebas afecta a producción), confunde costes, enreda permisos, concentra el riesgo y comparte límites. Como una empresa en una nave sin paredes.
• La práctica recomendada es separar los workloads en cuentas distintas (por entorno, equipo o proyecto). La cuenta es la unidad de aislamiento más fuerte de AWS. Como dividir un edificio en apartamentos independientes.
• Separar en cuentas aísla en tres dimensiones: seguridad (un problema no salta entre cuentas; la más importante), costes (factura separada por cuenta) y límites (cada cuenta tiene los suyos).
• Lo más valioso: separar producción de desarrollo/pruebas, para que un error o brecha en pruebas nunca pueda tocar producción.
• Las cuentas se agrupan en OU y se gobiernan con SCP (Organizations, subcap. 23.1). Patrones: por entorno, equipo, proyecto, más cuentas especiales (seguridad, logs).

En el siguiente subcapítulo veremos cómo crear y gestionar todas estas cuentas de forma automatizada y con buenas prácticas desde el inicio, con AWS Control Tower y las landing zones.