Home / Posts / AWS Organizations: Gestioná múltiples cuentas como un Profesional

AWS Organizations: Gestioná múltiples cuentas como un Profesional

23 May 2026 · 8 min de lectura
AWS Organizations Seguridad

Ya tenemos nuestra cuenta asegurada, entendemos cómo funcionan los permisos con IAM, usamos S3 y configuramos alertas de costos con Budgets. Hasta ahora todo lo hicimos dentro de una sola cuenta, pero en el mundo real las empresas (y hasta los que estamos aprendiendo) necesitan separar ambientes, proyectos o equipos en distintas cuentas. Para eso existe AWS Organizations. En este post vamos a ver qué es, para qué sirve y cómo crear nuestra primera Organización.

¿Por qué usar múltiples cuentas?

Puede parecer raro hablar de “múltiples cuentas” cuando apenas estamos empezando, pero entender este concepto desde el principio es muy valioso. Las razones principales para separar en cuentas distintas son:

  • Aislamiento de Seguridad: Si algo sale mal en una cuenta (un recurso comprometido, un permiso mal configurado), las demás cuentas no se ven afectadas.
  • Separación de Ambientes: Podés tener una cuenta para desarrollo, otra para testing y otra para producción, sin riesgo de que se mezclen.
  • Control de Costos: Cada cuenta tiene su propia facturación, lo que facilita saber cuánto gasta cada proyecto o equipo.
  • Límites de Servicio Independientes: Los Service Quotas de AWS se aplican por cuenta, así que una cuenta con mucho uso no bloquea a las demás.

AWS recomienda una estrategia Multi Cuenta como buena práctica, y AWS Organizations es la herramienta que nos permite gestionarlas de forma centralizada.

¿Qué es AWS Organizations?

AWS Organizations es un servicio gratuito que permite crear y administrar múltiples cuentas de AWS bajo una misma Organización. Desde una cuenta central (la Management Account) podemos:

  • Crear nuevas cuentas de AWS o invitar cuentas existentes.
  • Agrupar cuentas en Organizational Units (OUs) para organizarlas.
  • Aplicar Service Control Policies (SCPs) para definir qué pueden y qué no pueden hacer las cuentas.
  • Consolidar la facturación de todas las cuentas en una sola factura.

Es como tener un Centro de Administración que agrupa todas nuestras cuentas y nos da control centralizado sobre ellas.

Conceptos clave

Antes de crear nuestra organización, entendamos los componentes principales:

Management Account (Cuenta de administración)

Es la cuenta desde la cual creamos la organización. Tiene el control total: puede crear cuentas, mover cuentas entre OUs, aplicar políticas y gestionar la facturación consolidada. Nuestra cuenta actual va a ser la management account. Por seguridad, AWS recomienda no usar esta cuenta para desplegar workloads, solo para administrar la organización.

Member Accounts (Cuentas miembro)

Son todas las demás cuentas dentro de la organización. Cada una opera de forma independiente con sus propios recursos, usuarios y permisos, pero está sujeta a las políticas que se apliquen desde la management account.

Organizational Units (OUs)

Son “carpetas” que nos permiten agrupar cuentas de forma lógica. Por ejemplo, podríamos tener un OU llamado Producción y otro llamado Desarrollo, cada uno con sus propias cuentas y políticas. Los OUs pueden anidarse (un OU dentro de otro), creando una estructura jerárquica.

Service Control Policies (SCPs)

Son políticas que se aplican a nivel de organización o de OU. A diferencia de las IAM Policies que vimos en posts anteriores (que otorgan permisos), las SCPs definen el límite máximo de permisos que las cuentas pueden tener. Funcionan como un filtro: aunque un usuario tenga AdministratorAccess en su cuenta, si hay una SCP que bloquea un servicio, ese usuario no va a poder usarlo. Las SCPs no aplican a la management account.

Root

Es el contenedor de nivel más alto de la organización. Todas las cuentas y OUs cuelgan del root. Cuando creamos la organización, el root se crea automáticamente.

Paso 1: Acceder a AWS Organizations

Desde la consola de AWS, buscamos Organizations en la barra de búsqueda y hacemos clic en el resultado.

Buscar Organizations en la consola de AWS

Paso 2: Página principal de AWS Organizations

Al entrar vemos la página principal del servicio, donde AWS nos explica que Organizations permite gestionar de forma centralizada un entorno Multi Cuenta. A la derecha vemos el botón Create an organization y un detalle importante: “There is no cost to use AWS Organizations”, el servicio es completamente gratuito. Hacemos clic en Create an organization.

Página principal de AWS Organizations con el botón Create an organization

Paso 3: Consideraciones antes de crear

Antes de confirmar, AWS nos muestra una pantalla con consideraciones importantes sobre la Management Account:

  • Esta cuenta se va a convertir en la Management Account de la Organización.
  • Se recomienda usar una cuenta sin recursos ni workloads.
  • La Management Account no se puede cambiar después de crear la Organización.

Esto refuerza la buena práctica que mencionamos antes: la Management Account debería usarse solo para administrar, no para desplegar servicios. Hacemos clic en Create an organization para confirmar.

Consideraciones para la Management Account antes de crear la Organización

Paso 4: Organización creada

La Organización se crea en segundos. AWS nos muestra el banner verde “You successfully created an AWS organization” y nos lleva directamente a la vista de AWS accounts. Acá podemos ver:

  • En el sidebar izquierdo: las secciones disponibles como AWS accounts, Invitations, Policies, Services y Settings.
  • El Organization ID de nuestra Organización.
  • La estructura organizacional en vista jerárquica: el Root contiene nuestra cuenta con la etiqueta management account, junto con el Account ID y el email asociado.

También aparece un banner azul sobre “Centralize root access for member accounts”, esto es una funcionalidad para centralizar el acceso root de las cuentas miembro, pero no es necesario configurarlo ahora.

Organización creada exitosamente con la estructura Root y Management Account

Nota: Vas a recibir un email de verificación de AWS Organizations en la dirección de correo asociada a tu cuenta. Esto es normal y simplemente confirma que tu cuenta ahora es parte de una Organización.

Paso 5: Crear una Organizational Unit (OU)

Vamos a crear nuestro primer OU para organizar futuras cuentas. Seleccionamos el checkbox del Root y hacemos clic en Actions. En el menú desplegable, dentro de Organizational unit, seleccionamos Create new.

Seleccionar Root y Actions → Create new para crear un OU

Paso 6: Nombrar el OU

AWS nos lleva al formulario “Create organizational unit in Root”. Acá le ponemos un nombre descriptivo al OU, en nuestro caso Workloads, que es donde van a ir las cuentas que usemos para desplegar servicios y practicar. También podemos agregar Tags si queremos, pero por ahora no es necesario. Hacemos clic en Create organizational unit.

Formulario para crear el OU con nombre Workloads

Paso 7: Estructura final

AWS nos confirma con el banner verde “Successfully created organizational unit ‘Workloads’”. Ahora nuestra Organización tiene una estructura más clara: el Root contiene el OU Workloads y nuestra cuenta ojedaleonardo como Management Account. En el futuro, cuando creemos nuevas cuentas (por ejemplo, una cuenta de desarrollo o una de producción), las podemos colocar dentro de este OU.

Estructura final de la Organización con Root, OU Workloads y Management Account

¿Qué son las Service Control Policies (SCPs)?

Mencionamos las SCPs antes, pero vale la pena profundizar un poco. Las SCPs son una herramienta muy poderosa que nos permite poner barreras de seguridad a nivel organizacional. Algunos ejemplos prácticos:

  • Restringir regiones: podemos crear una SCP que impida que las cuentas miembro usen servicios fuera de regiones específicas (por ejemplo, solo permitir us-east-1 y sa-east-1).
  • Bloquear servicios costosos: podemos bloquear el uso de servicios caros como Amazon Redshift o SageMaker en cuentas de desarrollo.
  • Impedir la eliminación de logs: podemos proteger CloudTrail para que nadie desactive los logs de auditoría.

Por defecto, cuando creamos la organización, se aplica una SCP llamada FullAWSAccess que permite todo. A medida que avancemos, podemos ir restringiendo según nuestras necesidades.

Importante: Las SCPs no otorgan permisos, solo los limitan. Un usuario necesita tener permisos IAM y además que la SCP lo permita. Es como una doble verificación: IAM dice “podés hacerlo” y la SCP dice “está permitido en esta cuenta”.

Facturación consolidada

Uno de los beneficios inmediatos de usar Organizations es la facturación consolidada (Consolidated Billing). Esto significa que:

  • Todas las cuentas de la organización reciben una sola factura en la management account.
  • Podemos ver el desglose de costos por cuenta individual.
  • Se aplican descuentos por volumen: el uso de todas las cuentas se suma para calcular descuentos (por ejemplo, en S3 o EC2).
  • Los Savings Plans y Reserved Instances se pueden compartir entre cuentas.

Esto funciona automáticamente al crear la organización, no necesitamos configurar nada adicional.

Buenas prácticas

Ahora que tenemos nuestra organización creada, algunas recomendaciones:

  • No uses la management account para workloads: esta cuenta debe ser solo para administrar la organización. Los servicios y aplicaciones van en cuentas miembro.
  • Habilitá CloudTrail en la organización: así tenés un log de auditoría centralizado de todas las cuentas.
  • Usá OUs para agrupar cuentas: aunque por ahora tengamos pocas cuentas, la estructura facilita aplicar políticas en grupo.
  • Empezá con SCPs simples: no hace falta configurar SCPs complicadas desde el día uno. Podés ir agregando restricciones a medida que tu organización crece.
  • Protegé la management account: usá MFA, limitá el acceso y tratala como la cuenta más crítica de tu infraestructura.

Conclusiones

En este post creamos nuestra primera organización en AWS, entendimos conceptos clave como management account, OUs y SCPs, y preparamos la estructura para gestionar múltiples cuentas de forma profesional. Aunque por ahora solo tenemos una cuenta, esta base nos va a permitir escalar de forma ordenada y segura.

En el próximo post vamos a configurar IAM Identity Center (antes llamado AWS SSO) para poder acceder a nuestras cuentas de forma centralizada, sin necesidad de manejar usuarios IAM individuales en cada cuenta.

← AWS Budgets: controlá tus costos desde el día uno