Todo entorno de AWS que heredamos está en algún punto de la misma recta. En un extremo, una sola cuenta donde producción, staging y el proyecto personal de alguien comparten VPC. En el otro, cuarenta cuentas creadas en tres años por gente distinta, sin logging común y con cuatro formas de obtener credenciales. Los dos son el mismo problema: nunca se le dio un trabajo al límite de cuenta.
Una cuenta en AWS es el radio de explosión más fuerte que tienes. Las cuotas de servicio, IAM, la facturación y casi todos los controles de seguridad se paran en su borde. Así que la pregunta de diseño no es "cuántas cuentas", sino "qué protege este límite".
El mapa de cuentas
Esto es lo que desplegamos para un equipo de plataforma mediano, y ha sobrevivido al contacto con auditores más de una vez.
- Cuenta de gestión. Organizations, facturación y nada más. Sin cargas de trabajo, sin humanos con acceso diario, sin estado de Terraform. Es la cuenta que puede disolver todo tu entorno, así que se mantiene aburrida.
- Archivo de logs. Destino de solo escritura para los trails de organización de CloudTrail, Config, flow logs de VPC y logs de ALB. Las políticas de bucket deniegan borrados, el object lock está activo y la retención coincide con lo que diga tu marco de cumplimiento.
- Herramientas de seguridad. Administrador delegado de GuardDuty, Security Hub, Access Analyzer, Detective e Inspector. El equipo de seguridad es admin aquí y solo lectura en el resto.
- Red compartida. Transit Gateway, zonas privadas de Route 53, la terminación de la VPN o Direct Connect y una VPC de salida centralizada si la tienes. Las cuentas de carga consumen subredes por Resource Access Manager y nunca son dueñas del backbone.
- Servicios compartidos. El registro de artefactos, los runners de CI, el pipeline de AMIs base, el mirror de paquetes interno.
- Una cuenta por carga de trabajo y entorno.
pagos-prod,pagos-staging,analitica-prod. Ni una cuenta por equipo, ni una por entorno. Por carga y entorno.
Esa última línea es donde se tuercen casi todos los diseños. Una única cuenta produccion con once servicios significa once servicios compartiendo la cuota de concurrencia de Lambda, compartiendo superficie de IAM y compartiendo el día en que un rol mal configurado te levanta de madrugada.
Las tres barreras
Un mapa de cuentas sin controles es solo una factura más larga. Tres cosas lo sostienen.
Service control policies, aplicadas a unidades organizativas, no a cuentas. Pocas y contundentes: denegar salir de la organización, denegar desactivar CloudTrail o GuardDuty, denegar regiones en las que no operas, denegar acciones del usuario root fuera del acceso de emergencia. La OU de producción lleva una más: denegar el borrado de los buckets de logs. Resiste la tentación de escribir lógica fina de permisos en las SCP; eso va en los roles de IAM, y depurar SCPs es miserable.
Identidad por IAM Identity Center, sin usuarios IAM en ningún sitio. Los permission sets mapean a grupos de tu proveedor de identidad. Un desarrollador de pagos tiene PowerUser en pagos-staging y ReadOnly más un rol estrecho de emergencia en pagos-prod. Las claves de acceso dejan de existir; casi todo lo demás se deriva de ese único cambio.
Una base que es código, aplicada por pipeline. Cada cuenta nueva arranca igual: grabador de Config activo, GuardDuty encendido, cifrado por defecto de EBS, bloqueo de acceso público a S3 a nivel de cuenta, la VPC por defecto borrada y el rol de ejecución de Terraform creado. Esto lo ejecutamos desde un pipeline en una cuenta dedicada, no desde un portátil. Si crear una cuenta es una checklist manual, las cuentas derivarán, y la deriva es justo lo que encuentran los auditores.
Estructura de Terraform
Un fichero de estado por cuenta y capa, remoto en S3 con bloqueo en DynamoDB, y el bucket del backend vive en la cuenta a la que sirve. Las referencias entre cuentas van por data sources o parámetros de SSM, nunca leyendo el estado remoto de otro. Esa regla sola evita casi todos los incidentes de "hice apply y borró su subred".
El pipeline asume un rol por cuenta, y ese rol es lo único que puede escribir. Los humanos tienen solo lectura en producción y abren un PR. Es más lento el primer día y mucho más rápido en el primer incidente.
Lo que cuesta
Multicuenta no es gratis. Cuenta con más NAT gateways salvo que centralices la salida, algo de duplicidad en herramientas de seguridad y una semana real de trabajo para mover una carga existente. A cambio: atribución de coste por carga sin heroicidades de etiquetado, un radio de explosión de IAM que puedes explicar y una historia de cumplimiento que no tienes que inventar el día de la auditoría.
Si migras desde una cuenta grande, hazlo de una carga en una, empezando por la menos crítica, y deja la cuenta vieja como una zona legacy que encoge en lugar de intentar vaciarla de golpe. Nuestro trabajo de consultoría cloud suele empezar dibujando el mapa actual, porque casi ningún equipo ha visto el suyo en una sola página — que es exactamente lo que Skyline pinta en una tarde.
Qué hacer esta semana
Abre Organizations y lista tus cuentas. Para cada una, escribe una sola frase que diga qué protege. Las cuentas donde no puedas terminar la frase son las primeras que hay que arreglar.