A medida que una empresa crece, tambien lo hace su numero de cuentas AWS. El equipo de desarrollo tiene una cuenta, el equipo de operaciones tiene otra, el equipo de seguridad tiene otra. Como gestionas todo esto de forma sistematica y compartes recursos de forma segura? Esta guia explica los conceptos clave de los entornos multi-cuenta para principiantes.
AWS Organizations — Unificar multiples cuentas
AWS Organizations es como el organigrama de una empresa. Imagina una gran corporacion. Debajo de la sede central tienes el departamento de marketing, el departamento de ingenieria y el departamento de finanzas. Debajo de cada departamento hay equipos individuales. AWS Organizations tiene la misma estructura.
La Cuenta de Administracion es la sede central de tu organizacion. Crea y gestiona todas las cuentas miembro, y la facturacion se consolida aqui. Solo hay una cuenta de administracion por organizacion, y los SCPs no se aplican a ella.
Las Unidades Organizativas (OUs) son los departamentos. Agrupas cuentas logicamente en OUs como una OU de desarrollo, OU de produccion y OU de seguridad. Las OUs pueden contener otras OUs, creando una jerarquia.
Las Cuentas Miembro son los equipos individuales. Son las cuentas donde se crean y utilizan los recursos reales de AWS.
La Facturacion Consolidada es una de las mayores ventajas de Organizations. Los costos de todas las cuentas miembro aparecen en una sola factura en la cuenta de administracion. Lo mas importante son los descuentos por volumen: el uso de todas las cuentas se combina para alcanzar niveles de descuento mas altos. Las Instancias Reservadas tambien se pueden compartir entre cuentas de la organizacion, amplificando el ahorro en costos.
Punto de examen: "Consolidar la facturacion en multiples cuentas y beneficiarse de descuentos por volumen" — la respuesta es Facturacion Consolidada de Organizations.
SCPs — Aplicar reglas en toda la organizacion
SCP significa Service Control Policy (Politica de Control de Servicios). Piensalo como el sistema de control de acceso en un edificio. "Todos en este piso no pueden entrar a esa zona restringida", ese tipo de regla, aplicada a nivel de servicio AWS.
Lo mas importante que debes entender sobre los SCPs es lo que no hacen. Los SCPs no otorgan permisos. Solo restringen permisos que IAM ya ha permitido. Incluso si el usuario IAM de una cuenta de desarrollo tiene acceso de administrador completo, un SCP que bloquea un servicio especifico significa que ese servicio esta completamente no disponible, independientemente de IAM.
Los SCPs no se aplican a la cuenta de administracion. Aplicar un SCP a una OU hereda automaticamente hacia todas las cuentas miembro y OUs hijas dentro de ella.
Hay dos estrategias SCP. La estrategia de lista de permisos dice "solo los servicios explicitamente listados son utilizables", para entornos que requieren control de seguridad estricto. La estrategia de lista de denegacion dice "solo los servicios o regiones especificamente bloqueados estan prohibidos", que permite flexibilidad mientras restringe cosas especificas.
Ejemplos practicos: si la politica de la empresa requiere usar solo las regiones us-east-1 y us-west-2, crea un SCP que deniegue todas las acciones en cualquier otra region. Si quieres bloquear servicios de mineria de criptomonedas en toda la organizacion, crea un SCP que deniegue todas las acciones para ese servicio.
Punto de examen: "Restringir regiones o servicios especificos en toda la organizacion" — la respuesta es SCP.
AWS RAM — Compartir recursos de forma segura
Imagina que multiples cuentas necesitan usar la misma infraestructura de red. Crear una VPC separada para cada cuenta aumenta la complejidad y el costo. AWS RAM (Resource Access Manager) te permite compartir recursos de forma segura entre cuentas.
Piensa en una sala de conferencias compartida. La sala pertenece a la empresa, pero multiples equipos pueden reservarla y usarla. AWS RAM funciona de manera similar. La cuenta que posee un recurso lo comparte con otras cuentas a traves de RAM. Esas cuentas pueden entonces usar el recurso compartido.
El recurso compartido mas frecuentemente en los examenes es las subredes VPC. Una cuenta de red dedicada posee la VPC y las subredes, y las comparte a traves de RAM con cuentas de desarrollo, produccion y analitica. Cada una de esas cuentas puede luego lanzar instancias EC2, bases de datos RDS y otros recursos en las subredes compartidas.
Hay una limitacion importante. Las cuentas que reciben subredes compartidas pueden desplegar recursos en ellas pero no pueden modificar la VPC en si ni cambiar la configuracion de las subredes. La autoridad de gestion de red permanece exclusivamente en la cuenta propietaria.
Otros recursos comunmente compartidos con RAM incluyen: Transit Gateway, reglas de Route 53 Resolver, clusters de Aurora DB, configuraciones de AWS License Manager y proyectos de AWS CodeBuild.
Punto de examen: "Multiples cuentas necesitan desplegar recursos en la misma subred" — la respuesta es compartir subredes con AWS RAM.
Cross-Account IAM Role — Acceder a recursos de otra cuenta de forma segura
Una aplicacion en la cuenta de desarrollo necesita leer archivos del bucket S3 de la cuenta de produccion. Como lo configuras? Crear un usuario IAM en la cuenta de produccion y compartir esas credenciales con el equipo de desarrollo es extremadamente arriesgado. Los Cross-Account IAM Roles son la solucion correcta.
Piensa en una tarjeta de acceso de hotel. Cuando un huesped de otro piso necesita acceso temporal a tu habitacion, la recepcion emite una tarjeta temporal en lugar de copiar la tuya. Esa tarjeta temporal expira despues de un tiempo establecido.
El Cross-Account IAM Role funciona igual. El proceso tiene tres pasos. Primero, en la cuenta de produccion (B), crea un rol IAM y especifica la cuenta de desarrollo (A) en la Trust Policy. Segundo, la aplicacion de la cuenta de desarrollo (A) llama a la API AssumeRole de AWS STS y se emiten credenciales temporales. Tercero, la aplicacion usa esas credenciales temporales para acceder al bucket S3 de la cuenta de produccion (B). Las credenciales temporales normalmente expiran entre una y doce horas.
El External ID es una medida de seguridad adicional usada cuando se delega un rol a un tercero. Imagina que contratas una empresa de auditoria de seguridad externa. Les das un rol para analizar tu cuenta. Pero esa misma empresa de auditoria sirve a muchos clientes. Si un actor malicioso engana a la empresa de auditoria para asumir tu rol pensando que acceden a una cuenta diferente, eso se llama "Confused Deputy Problem". Agregar una condicion External ID a la Trust Policy significa que el rol solo puede asumirse cuando se proporciona el External ID correcto, previniendo esa confusion.
Punto de examen: "Delegar un rol a un tercero mientras se previene el acceso accidental a la cuenta equivocada" — la respuesta es External ID.
AWS Control Tower — Configuracion automatizada multi-cuenta
Una nueva empresa adopta AWS y quiere configurar un entorno multi-cuenta adecuado desde el principio. Seguir manualmente las mejores practicas de AWS para la estructura de cuentas, configuraciones de seguridad y registros lleva mucho tiempo y es propenso a errores. Control Tower automatiza todo esto.
Control Tower se basa en tres conceptos principales.
La Landing Zone configura automaticamente un entorno multi-cuenta siguiendo las mejores practicas de AWS. Crea automaticamente la estructura de cuentas recomendada incluyendo una cuenta de archivo de registros, una cuenta de auditoria y una cuenta sandbox.
Los Guardrails son reglas de gobernanza automatizadas aplicadas en toda la organizacion. Los guardrails preventivos se basan en SCPs y bloquean completamente ciertas acciones. Los guardrails de deteccion se basan en reglas de AWS Config y detectan violaciones de politicas, enviando notificaciones cuando ocurren.
Account Factory automatiza la creacion de nuevas cuentas con configuraciones estandarizadas. Cuando se une un nuevo equipo, Account Factory puede generar una cuenta completamente configurada, con todas las politicas de la empresa aplicadas, en solo unos pocos clics.
Punto de examen: "Configurar rapidamente un nuevo entorno multi-cuenta siguiendo las mejores practicas de AWS" — la respuesta es Control Tower.
Estrategia multi-cuenta
Que criterios deben guiar la separacion de cuentas?
| Base de separacion | Proposito | Ejemplos | |-------------------|-----------|---------| | Entorno | Aislar completamente dev de prod | OU dev, OU staging, OU prod | | Departamento | Seguimiento de costos y separacion de permisos | OU marketing, OU ingenieria | | Cumplimiento | Cumplir requisitos regulatorios | Cuenta HIPAA, cuenta PCI | | Funcion | Cuentas de proposito especializado | Cuenta de archivo de logs, Cuenta de seguridad |
Mas cuentas significa mas complejidad, pero una buena separacion limita el alcance del dano de un incidente de seguridad a una sola cuenta.
!4 herramientas de uso compartido entre cuentas
Trusted Access — Permitir que los servicios operen en toda la organizacion
Para que servicios AWS como CloudFormation StackSets, AWS Config y CloudTrail operen en todas las cuentas de una organizacion, debes habilitar Trusted Access. Esto permite que esos servicios usen la API de Organizations para acceder automaticamente a las cuentas miembro.
Por ejemplo, para aplicar CloudTrail en toda la organizacion, habilita Trusted Access para CloudTrail. Luego desde la cuenta de administracion puedes configurar la recopilacion centralizada de registros de todas las cuentas miembro.
Puntos clave para el examen
"Consolidar facturacion y aplicar descuentos por volumen en multiples cuentas" -- Facturacion Consolidada de Organizations
"Permitir solo regiones especificas o bloquear servicios especificos en toda la organizacion" -- SCP
"Multiples cuentas comparten la mism