SCP en AWS Organizations: por qué un Allow no alcanza

En pocas palabras: Una SCP en AWS Organizations no otorga permisos, solo pone un techo máximo. Para producción, hace falta habilitar “all features”, evaluar el Allow en cada nivel (root, OUs hasta cinco niveles, cuenta) y recordar que nunca restringe a la cuenta de management ni a roles vinculados a servicios.

Una SCP (service control policy) en AWS Organizations define el techo máximo de permisos para las cuentas miembro de una organización: no otorga acceso por sí sola, solo lo limita, y AWS la evalúa en cada nivel del árbol organizacional (root, cada OU en el camino y la cuenta) antes de que el IAM local entre en juego.

AWS Organizations es el servicio que agrupa varias cuentas de AWS bajo una sola estructura de control y facturación. La cuenta es el límite duro de recursos, seguridad y billing: IAM administra identidades dentro de una cuenta, mientras que Organizations administra las cuentas entre sí, según explica la documentación oficial de AWS. Esa separación es la base del modelo multi-cuenta que usan la mayoría de los landing zones en producción.

¿Qué es AWS Organizations y por qué la cuenta es el límite de seguridad?

La cuenta de AWS es el límite físico de aislamiento: recursos, facturación y radio de impacto de un incidente quedan contenidos ahí adentro. IAM gestiona quién puede hacer qué dentro de esa cuenta. AWS Organizations gestiona el conjunto de cuentas, y ahí es donde vive el verdadero control: guardrails que se adjuntan arriba del árbol y bajan a todo lo que está debajo.

Esto no es un detalle técnico menor. Separar cargas en cuentas distintas te da aislamiento de blast radius (si algo se rompe en una cuenta, no contamina las demás), atribución de costos limpia por equipo o proyecto, y un lugar para poner controles que nadie adentro de la cuenta puede desactivar. Si alguna vez armaste una sola cuenta gigante con todo mezclado, ya sabés lo incómodo que es después separar prod de desarrollo o auditar quién tocó qué.

Ojo: esta arquitectura no es gratis en complejidad. Cuantas más cuentas y OU tenés, más superficie hay para debuggear cuando algo falla. Pero la alternativa (todo en una cuenta) es peor a mediano plazo. Esto se conecta con lo que analizamos en cómo resolver errores de trust policy en OIDC.

¿Cómo se estructura una organización de AWS en producción? (management account, root, OUs y cuentas miembro)

Una organización de AWS tiene cinco piezas: una cuenta de management, un root, unidades organizacionales (OU) que pueden anidarse hasta 5 niveles, cuentas miembro y las políticas que se adjuntan en cualquiera de esos puntos. La cuenta de management es la dueña de la organización y la que paga; debería usarse solo para tareas de billing y administración, nunca para correr workloads.

Un layout base que funciona bien en producción, según describe el análisis técnico de Rafa Gross, agrupa las cuentas así:

• Security: Log Archive centraliza los logs de toda la organización, y Security Tooling (o Audit) queda como delegated administrator para GuardDuty, Security Hub y servicios similares.
• Infrastructure: cuentas de Network y Shared Services para tránsito, DNS y herramientas compartidas.
• Workloads: Prod y NonProd separadas, para que los guardrails puedan ser distintos según el ciclo de vida.
• Sandbox: una cuenta por desarrollador o equipo, con controles más laxos para experimentar.
• Suspended: cuarentena deny-all para cuentas en proceso de cierre.

El tip que más vale de esta estructura: diseñá las OU alrededor de los controles y el ciclo de vida que necesitás aplicar, no del organigrama de la empresa. Los equipos se reorganizan cada seis meses; la necesidad de que prod tenga guardrails más estrictos que sandbox no cambia nunca.

Un detalle que se pasa por alto: Organizations tiene dos modos. El modo consolidated-billing solo une facturas. El modo “all features” agrega las políticas de autorización (SCP, RCP), políticas de gestión (tags, backup, EC2), acceso confiable para integraciones de servicios y delegated administrators. Si estás armando un landing zone serio, necesitás “all features” habilitado, sin excepción.

¿Cómo se evalúan las SCP y por qué un Allow no se hereda como esperás?

Un Deny en una SCP se hereda de forma simple: lo adjuntás en cualquier punto del árbol y aplica a todo lo que está debajo. Un Allow no funciona igual. Para que una acción esté permitida en una cuenta, tiene que existir un Allow en todos los niveles del camino: el root, cada OU intermedia y la cuenta misma. Si falta en cualquiera de esos niveles, la acción queda denegada de forma implícita, aunque una política de IAM en la cuenta otorgue *:*. Tema relacionado: nuestra guía de arquitectura AWS en producción.

El ejemplo que usa la fuente técnica lo deja clarísimo:

• Root: SCP FullAWSAccess (permite todo)
• OU Workloads: SCP AllowOnlyApprovedSvc (permite ec2:*, s3:*, pero no dynamodb:*)
• Cuenta Prod: SCP FullAWSAccess (permite todo)

Resultado en Prod: dynamodb:* queda denegado, aunque el root y la cuenta lo permitan, porque la OU nunca lo autorizó. Este comportamiento es el motivo por el que existe la política FullAWSAccess por defecto en cada nivel: si la reemplazás por una allow-list en una OU, esa allow-list se convierte en el techo para cada cuenta que esté debajo, te des cuenta o no.

¿Y en qué se diferencia esto de una política de IAM normal? Una política de IAM otorga permisos a un usuario o rol concreto. Una SCP nunca otorga nada: solo define el máximo posible. Los permisos efectivos son la intersección lógica entre lo que permite la SCP (y la RCP, si aplica) y lo que permite la política de identidad o de recurso, tal como lo detalla la guía oficial de SCP effects on permissions. Si un usuario no tiene ninguna política de IAM adjunta, no tiene acceso, sin importar cuán permisiva sea la SCP.

Para debuggear un AccessDenied en una cuenta miembro cuando la política de IAM parece correcta, hay que revisar las SCP en cada nodo del camino de esa cuenta, no solo las que están adjuntas directamente en la cuenta. Ese es, probablemente, el paso que más gente se salta.

Tipo de política	Qué controla	¿Otorga permisos?
SCP (service control policy)	Techo máximo para usuarios y roles IAM en cuentas miembro	No
RCP (resource control policy)	Techo máximo sobre recursos (S3, KMS, Secrets Manager, SQS y otros), sin importar quién llama	No
Tag policy	Estandariza claves y valores de tags para cost allocation y ABAC	No aplica
Backup policy	Despliega planes de AWS Backup en cuentas y regiones de forma centralizada	No aplica
EC2 policy (declarativa)	Baseline org-wide para EC2, VPC y EBS: IMDS, bloqueo de AMI/snapshot públicos, consola serial, VPC Block Public Access	No aplica

¿Qué errores de producción cometen los equipos con SCP y landing zones?

El incidente más común con SCP no es exótico: alguien desadjunta FullAWSAccess de una OU mientras prueba una allow-list, y todas las cuentas debajo pierden acceso a cualquier servicio que no estaba en la lista. Pasa más seguido de lo que debería.

Hay una lista corta de gotchas que conviene tener memorizada antes de tocar SCP en producción: Complementá con el tutorial para desplegar Coolify en EC2.

• Las SCP y RCP nunca restringen la cuenta de management. Todo lo que corras ahí queda fuera de tus guardrails, razón de más para no meter workloads en esa cuenta.
• Las SCP no afectan a los service-linked roles. Los servicios de AWS que actúan a través de esos roles no están limitados por tus políticas.
• Las SCP sí aplican a las cuentas delegated administrator. Son cuentas miembro como cualquier otra; asegurate de que tus guardrails no bloqueen los servicios de seguridad que delegaste ahí.
• Las OU se anidan como máximo 5 niveles. Una jerarquía profunda también es más difícil de razonar en medio de un incidente. Mantenela lo más chata posible.
• Los límites son duros: 10.240 caracteres por documento SCP y hasta 10 SCP por target. Planificá la consolidación de statements antes de que te quedes sin espacio.

La propia documentación de AWS lo dice sin vueltas: no hay que adjuntar SCP al root sin testear el impacto antes. La recomendación es crear una OU de prueba, mover cuentas de a una o en lotes chicos, y usar los datos de “service last accessed” en IAM para saber qué servicios usa realmente cada cuenta antes de restringirlos.

¿Cómo armar un landing zone multi-cuenta en AWS?

Un landing zone en AWS separa el plano de gobierno del plano de workloads: la cuenta de management queda restringida a tareas de org y billing, la OU de Security concentra logs y herramientas de seguridad, la OU de Infrastructure maneja networking, y la OU de Workloads separa prod de non-prod para que los guardrails puedan diferir entre ambos.

AWS Control Tower orquesta todo esto arriba de Organizations. Tiene Account Factory para provisionar cuentas nuevas, controles gestionados (preventivos vía SCP/RCP, detectivos vía AWS Config, proactivos vía hooks de CloudFormation) y detección de drift. Si tu equipo maneja infraestructura como código, Account Factory for Terraform (AFT) provisiona las cuentas a través de un pipeline de Terraform en vez de clickear en la consola.

El ciclo operativo completo tiene cuatro patas que conviene tener resueltas desde el día uno: identidad centralizada con IAM Identity Center para accesos humanos y roles cross-account para automatización; provisioning siempre vía Account Factory, AFT o la API de Organizations, nunca click-ops en producción; baseline de logging, Config y networking aplicado desde el arranque, típicamente con StackSets o Control Tower; y guardrails preventivos, detectivos y proactivos con drift detection corriendo en paralelo.

Para retirar una cuenta, el flujo es simple: la movés a la OU Suspended con una SCP deny-all, y después la cerrás. Una cuenta cerrada se puede reabrir durante un período de 90 días post-cierre, después de eso ya no hay vuelta atrás. Sobre eso hablamos en los checks de seguridad que todo pipeline necesita.

Si además de la infraestructura AWS tu organización maneja sitios web o dominios propios en Argentina, conviene separar esos workloads del resto de la cuenta: plataformas como donweb.com son una opción local a considerar para esa capa, mientras la parte de cómputo y datos queda en tu landing zone de AWS.

Errores comunes con SCP en AWS Organizations

Tres errores se repiten en casi todos los equipos que arrancan con SCP en AWS Organizations, y los tres tienen corrección conocida.

• Adjuntar SCP directo al root sin testear. Corregí esto creando una OU de prueba, moviendo cuentas de a poco, y revisando el impacto con los datos de service last accessed en IAM antes de escalar la política a OU más grandes.
• Confundir “no está en la allow-list” con “está permitido por defecto”. Si reemplazaste FullAWSAccess por una allow-list en una OU, todo lo que no listaste queda denegado para siempre en las cuentas de abajo, aunque el root o la cuenta digan lo contrario.
• Administrar servicios de seguridad desde la cuenta de management. GuardDuty, Security Hub y similares deberían delegarse a la cuenta de Security Tooling / Audit, no administrarse desde la cuenta que paga la factura.

Preguntas Frecuentes

¿Qué es una SCP en AWS Organizations?

Una SCP (service control policy) es una política de guardrail que define el máximo de permisos disponibles para los usuarios y roles IAM de las cuentas miembro de una organización. No otorga ningún permiso por sí misma: solo funciona como límite superior que después la política de IAM local tiene que cumplir.

¿Por qué AWS Organizations deniega un permiso aunque el IAM lo permita?

Porque el Allow de una SCP tiene que existir en todos los niveles del camino (root, cada OU y la cuenta) para que la acción quede habilitada. Si algún nivel intermedio no incluye ese Allow, la acción queda denegada de forma implícita sin importar lo que diga la política de IAM en la cuenta.

¿Cómo se estructura una organización de AWS en producción?

Una estructura de producción típica tiene una cuenta de management sin workloads, un root, y OU separadas por función: Security (logs y herramientas de seguridad), Infrastructure (networking), Workloads (prod y non-prod divididos) y Sandbox para experimentación. Las OU se organizan según los controles que necesitás aplicar, no según el organigrama.

¿Qué diferencia hay entre SCP y RCP en AWS?

La SCP pone el techo de permisos sobre lo que pueden hacer los usuarios y roles IAM en las cuentas miembro. La RCP pone el techo sobre los recursos mismos (S3, KMS, Secrets Manager, SQS, entre otros), sin importar quién esté haciendo la llamada. Ninguna de las dos otorga permisos por sí sola.

¿Cómo armar un landing zone multi-cuenta en AWS?

Se arma separando el plano de gobierno (management, Security, Infrastructure) de las cuentas de Workloads, y orquestando todo con AWS Control Tower para provisioning, controles y drift detection. Si el equipo trabaja con infraestructura como código, Account Factory for Terraform (AFT) permite provisionar las cuentas mediante un pipeline de Terraform en vez de crearlas manualmente.

Conclusión

El error de fondo con AWS Organizations no es técnico, es de expectativa: la mayoría de los equipos asume que las políticas se comportan como el IAM tradicional, donde un Allow en cualquier lado alcanza. Con SCP no es así. Necesitás el Allow en cada nivel del camino, y un solo eslabón roto en esa cadena (una OU con una allow-list mal armada, un FullAWSAccess desadjuntado sin querer) puede tirar abajo el acceso de decenas de cuentas de un saque.

Si estás por meter mano en SCP en producción, el orden práctico es: probar en una OU aislada, revisar service last accessed antes de restringir nada, y preferir deny-list por sobre allow-list salvo que tengas un motivo puntual para lo contrario. Nada de esto reemplaza el trabajo de diseñar bien la jerarquía de OU desde el principio, porque reorganizar cuentas después de que ya tenés workloads corriendo es bastante más doloroso que planificarla con cuidado desde el día uno.

Fuentes

• AWS Organizations User Guide – Service control policies (SCPs)
• AWS Organizations User Guide – Service control policy examples
• AWS Organizations in Production: Structure, SCP Evaluation, and Landing Zone Gotchas – Rafa Gross