Una sola cuenta de AWS para todo funciona hasta que deja de funcionar. Un script de pruebas borra un bucket de producción. Finanzas no puede repartir la factura por equipos. Un auditor pregunta quién puede modificar los registros de auditoría, y la respuesta honesta es «cualquiera con permisos de administrador». Una landing zone es la base multicuenta que montas antes de que lleguen las cargas de trabajo: la estructura de cuentas, la identidad, los guardarraíles, los registros y la red que hereda cada cuenta nueva.
Este artículo recorre el diseño de una landing zone con un diagrama: por qué varias cuentas, las unidades organizativas recomendadas, las cuentas base, los guardarraíles con políticas de control de servicios (SCP), políticas de control de recursos (RCP) y políticas declarativas, la identidad, los registros centralizados y las herramientas de seguridad, la red, y cómo construirlo todo con Control Tower, incluido lo que cambió en la landing zone 4.0, o con Terraform.
Por qué varias cuentas
Una cuenta de AWS es el límite de aislamiento más fuerte que ofrece AWS. Los permisos de IAM, las cuotas de servicio, los costes y la mayoría de los fallos se detienen en su borde. Las cuentas separadas te dan:
- Radio de impacto acotado. Un error o una credencial comprometida en una sandbox no puede tocar producción.
- Propiedad y facturación claras por equipo, aplicación o entorno.
- Permisos más sencillos. En lugar de una cuenta llena de condiciones sobre etiquetas, cada cuenta recibe el acceso que necesita su equipo.
- Cuotas independientes, para que la prueba de carga de un equipo no agote los límites de otro.
El coste es la coordinación: la identidad, los registros, los guardarraíles y la red tienen que funcionar en decenas de cuentas. Esa coordinación es lo que aporta una landing zone.
La estructura: unidades organizativas
AWS Organizations agrupa las cuentas en unidades organizativas (OU), y las políticas asociadas a una OU se aplican a todas las cuentas que tiene debajo. El whitepaper de AWS sobre cómo organizar tu entorno recomienda un conjunto de OU para empezar:
| OU | Propósito | Cuentas típicas |
|---|---|---|
| Security | Seguridad, gobierno y cumplimiento en toda la organización | Log Archive, Security Tooling |
| Infrastructure | Infraestructura y red compartidas | Network, Shared Services |
| Workloads | Aplicaciones de negocio, de producción y no producción | Una por aplicación y entorno |
| Sandbox | Experimentos con acceso limitado a producción | Una por desarrollador o equipo |
| Exceptions | Cargas de trabajo que necesitan políticas fuera del modelo estándar | Pocas, revisadas con regularidad |
| Transitional | Cuentas que se están migrando o reestructurando | Temporales |
Divide pronto Workloads en sub-OU Prod y Non-prod. Los guardarraíles difieren entre ellas, y mover cuentas más tarde es doloroso. Añade una OU Suspended con una política que lo deniega todo para las cuentas pendientes de cierre.
La cuenta de administración
La cuenta de administración es dueña de la organización, la facturación consolidada y Control Tower. Mantén las cargas de trabajo fuera de ella por una razón decisiva: las SCP no afectan a los usuarios ni a los roles de la cuenta de administración, como indica la documentación de Organizations. Nada de lo que despliegues allí queda limitado por tus guardarraíles, así que dale tan pocos usuarios y recursos como sea posible.
Cuentas base
- Log Archive. Recibe el trail de CloudTrail de la organización y el historial de AWS Config en S3. Casi nadie tiene acceso de escritura o borrado; plantéate S3 Object Lock para que ni los administradores puedan alterar los registros.
- Security Tooling, también llamada Audit. Es la administradora delegada de GuardDuty, Security Hub, IAM Access Analyzer y el agregador de AWS Config, para que el equipo de seguridad vea todas las cuentas desde un solo lugar sin acceso a la cuenta de administración.
- Network. Es dueña del Transit Gateway, la conectividad privada con los centros de datos, los resolvedores DNS y la gestión de direcciones IP, compartidos con las cuentas de cargas de trabajo mediante AWS Resource Access Manager.
- Shared Services. CI/CD, repositorios de artefactos y otras herramientas que usan muchos equipos.
Guardarraíles: SCP, RCP y políticas declarativas
Organizations ofrece varios tipos de política, y responden a preguntas distintas:
| Tipo de política | Qué limita | Ejemplo |
|---|---|---|
| Política de control de servicios (SCP) | Los permisos máximos de las entidades principales en las cuentas miembro | Nadie puede detener CloudTrail ni salir de la organización |
| Política de control de recursos (RCP) | Los permisos máximos sobre los recursos, añadida en noviembre de 2024 | Ningún bucket de S3 puede dar acceso a entidades principales de fuera de la organización |
| Política declarativa | Configuración duradera de servicios, añadida en diciembre de 2024 | Bloquear el uso compartido público de AMI y snapshots |
| Políticas de etiquetas y de copias de seguridad | Reglas de etiquetado y planes de copia de seguridad | Todo recurso lleva una etiqueta cost-center |
Las políticas solo restringen; nunca conceden permisos. Empieza con una lista corta de guardarraíles de alto valor:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyLeavingOrganization",
"Effect": "Deny",
"Action": "organizations:LeaveOrganization",
"Resource": "*"
},
{
"Sid": "ProtectCloudTrail",
"Effect": "Deny",
"Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
"Resource": "*"
}
]
}
Las restricciones de región son populares y fáciles de hacer mal, porque los servicios globales como IAM deben seguir permitidos. Prueba cada política nueva en una OU de staging con una cuenta representativa antes de asociarla a Workloads.
Control Tower empaqueta los guardarraíles como controles de tres tipos: controles preventivos implementados con SCP y RCP, controles de detección implementados con reglas de AWS Config y controles proactivos que comprueban los recursos antes de que CloudFormation los cree.
Identidad
Las personas nunca deberían tener usuarios de IAM con claves de larga duración en las cuentas de cargas de trabajo. Conecta IAM Identity Center a tu proveedor de identidad corporativo, aprovisiona usuarios y grupos con SCIM y concede el acceso mediante conjuntos de permisos asignados a grupos por cuenta: por ejemplo, los desarrolladores obtienen acceso de power user en Non-prod y de solo lectura en Prod.
Mantén dos identidades de emergencia (break-glass) con MFA de hardware, guardadas sin conexión y vigiladas. Para los usuarios raíz, IAM ya puede gestionar de forma centralizada el acceso raíz de las cuentas miembro, una función introducida en noviembre de 2024, así que puedes eliminar por completo las credenciales raíz de las cuentas miembro y hacer las pocas tareas exclusivas del usuario raíz desde un lugar central.
Registros y detección
- Un trail de organización en CloudTrail registra la actividad de la API en todas las cuentas y regiones en la cuenta Log Archive.
- AWS Config registra la configuración de los recursos en todas partes, con un agregador en Security Tooling.
- GuardDuty y Security Hub se activan en toda la organización, con Security Tooling como administradora delegada, para que las cuentas nuevas queden cubiertas automáticamente.
- Los hallazgos van a tu SIEM o a tus herramientas de guardia.
Red
Las cuentas de cargas de trabajo son dueñas de sus VPC, pero no de su conectividad. La cuenta Network aporta un Transit Gateway compartido mediante Resource Access Manager, salida e inspección centralizadas, resolución DNS entre la nube y el centro de datos, y un plan de direcciones IP, idealmente gestionado con Amazon VPC IP Address Manager para que no se solapen dos VPC. El diagrama de VPC de AWS cubre lo que va dentro de cada VPC de carga de trabajo, y el diagrama de arquitectura multirregión de AWS cubre cómo extender el diseño a varias regiones.
Cómo construirla: Control Tower o Terraform
AWS Control Tower configura la organización, las cuentas base, un trail de organización, Config y un catálogo de controles, y ofrece Account Factory para crear cuentas nuevas. La versión 4.0 de la landing zone, publicada el 17 de noviembre de 2025, lo hizo bastante más flexible, según las notas de la versión de Control Tower:
- Las integraciones de AWS Config, CloudTrail, roles de seguridad y AWS Backup pasaron a ser opcionales.
- Ya no se exige una OU Security; puedes definir tu propia estructura de OU.
- Una configuración mínima puede usar solo la integración con Organizations y los controles.
- Config y CloudTrail reciben recursos dedicados, y un agregador de Config vinculado al servicio sustituye a la agregación anterior.
Los equipos de Terraform suelen combinar Control Tower con Account Factory for Terraform (AFT), que aprovisiona y personaliza cuentas desde un repositorio Git. Desde septiembre de 2026, AFT puede ejecutar las personalizaciones en modo solo plan para previsualizar los cambios antes de aplicarlos. Otros gestionan Organizations por completo con Terraform o usan la solución Landing Zone Accelerator on AWS. Las tres opciones funcionan; lo importante es que la creación de cuentas esté automatizada y sea repetible.
Vending de cuentas
Las cuentas nuevas deberían llegar listas para usar: una solicitud, a menudo un pull request, crea la cuenta en la OU correcta, aplica la base (asignaciones de Identity Center, presupuestos y alertas, una VPC conectada al Transit Gateway, servicios de seguridad por defecto) y se la entrega al equipo. Organizations limita por defecto una organización a 10 cuentas, ajustable mediante Service Quotas, así que pide el aumento antes de necesitarlo.
Errores comunes
- Cargas de trabajo en la cuenta de administración, donde no se aplica ninguna SCP.
- Una única OU Workloads plana, de modo que producción y desarrollo comparten guardarraíles.
- Guardarraíles escritos después de que los equipos hayan construido sobre supuestos que esos guardarraíles rompen.
- Una cuenta Log Archive que los administradores pueden modificar.
- Cuentas creadas a mano, cada una ligeramente distinta.
El diagrama de la landing zone
Contenido del diagrama
- Management account: Organizations, SCPs, billing
- IAM Identity Center + corporate IdP
- Security OU
- Log Archive: org trail + Config
- Security Tooling (delegated admin)
- Infrastructure OU
- Network: Transit Gateway, IPAM
- Shared Services: CI/CD
- Workloads OU
- Prod: app-a
- Non-prod: app-a
- Sandbox OU
- Sandbox: team-x
- SCPs + RCPs
- guardrails
- permission sets
- TGW via RAM
- CloudTrail + Config logs from every account
Cómo leerlo:
- La cuenta de administración, arriba, contiene la organización y las políticas; sus aristas hacia cada OU son asociaciones de guardarraíles.
- La OU Security contiene Log Archive, que recibe los registros de todas las cuentas, y Security Tooling, que administra GuardDuty y Security Hub.
- La OU Infrastructure contiene la cuenta Network, cuyo Transit Gateway conecta las VPC de las cargas de trabajo, y Shared Services para CI/CD.
- La OU Workloads separa las cuentas Prod y Non-prod; la OU Sandbox queda aislada.
- IAM Identity Center, a la derecha, da acceso a las personas mediante conjuntos de permisos.
- El bloque Markdown enumera los guardarraíles iniciales.
Dibujar estructuras de cuentas con claridad
- Dibuja las OU como contenedores y coloca las cuentas dentro; la jerarquía es el modelo de políticas.
- Muestra la cuenta de administración aparte. Está fuera de tus guardarraíles, y el dibujo debe decirlo.
- Dibuja solo los flujos que cruzan cuentas: registros hacia el archivo, conexiones de red, administración delegada, identidad.
- Nombra las cuentas por su función, no por su número de cuenta.
Para el modelo de seguridad que hay detrás, consulta el diagrama de arquitectura zero trust. Si gestionas la infraestructura como código, el diagrama de arquitectura de Terraform muestra cómo dibujar entornos gestionados con Terraform.
Constrúyelo en Archboard
- Inicia sesión con Google o GitHub y crea un diagrama.
- Añade un nodo Política del pack Seguridad para la cuenta de administración y un Proveedor de identidad para IAM Identity Center.
- Añade cuatro nodos Marco del pack Básico para las OU: Security, Infrastructure, Workloads y Sandbox.
- En Security, añade un nodo Almacenamiento de objetos del pack Nube para Log Archive y un nodo Alerta del pack DevOps para Security Tooling. En Infrastructure, añade un Enrutador del pack Red para la cuenta Network y una Canalización del pack DevOps para Shared Services.
- Añade nodos Instancia de cómputo del pack Nube para las cuentas Prod, Non-prod y Sandbox.
- Conecta la cuenta de administración con cada OU, las cuentas con Log Archive y la cuenta Network con las cargas de trabajo, y añade un bloque Markdown del pack Básico con los guardarraíles.
El ejemplo usa 14 nodos de diagrama, dentro del plan Free.
Preguntas frecuentes
¿Qué es una landing zone de AWS? Un entorno de AWS multicuenta configurado según tus estándares de seguridad y operación antes de que lleguen las cargas de trabajo: unidades organizativas, cuentas base, identidad, guardarraíles, registros y red.
¿Necesito AWS Control Tower para una landing zone? No. Control Tower es la forma gestionada de construirla, y la versión 4.0 lo hizo más flexible. También puedes gestionar Organizations con Terraform, Account Factory for Terraform o Landing Zone Accelerator.
¿Qué diferencia hay entre una SCP y una RCP? Una SCP limita lo que pueden hacer las entidades principales de las cuentas miembro. Una RCP limita lo que se puede hacer con los recursos de las cuentas miembro, por ejemplo impedir que los buckets se compartan fuera de la organización. Ninguna de las dos concede permisos.
¿Por qué la cuenta de administración debe quedar vacía? Las SCP no se aplican a los usuarios y roles de la cuenta de administración, así que todo lo que haya allí queda fuera de tus guardarraíles. Además controla la facturación y la propia organización, lo que la convierte en la cuenta más sensible que tienes.
¿Cuántas cuentas puede tener una organización? Diez por defecto. La cuota se puede ajustar mediante Service Quotas, y solo la cuenta de administración puede solicitar el aumento.