Semana 1 · Módulo 1 de 11

Fundamentos de AWS e IAM a fondo

Infraestructura global, cuenta y herramientas de acceso, modelo de responsabilidad compartida, IAM de principio a fin (con su lógica de evaluación de políticas), federación, multicuenta con Organizations y Control Tower, y la introducción al Well-Architected Framework. Es la base del dominio 1 (30 % del examen).

Reparto de la semana

Por qué importa

El dominio 1 (Design Secure Architectures) pesa un 30 % del examen y la tarea 1.1 (Design secure access to AWS resources) es la puerta de entrada: casi cualquier pregunta de seguridad acaba en «¿quién puede hacer qué, desde dónde y con qué credenciales?». Además, la infraestructura global (regiones y zonas de disponibilidad) aparece en los dominios 2, 3 y 4: es imposible diseñar alta disponibilidad o reducir costes de red sin entenderla.

Cómo lo pregunta el examen:

• Un escenario con varias cuentas y un requisito de gobierno («impedir que nadie desactive CloudTrail en ninguna cuenta») → SCP en AWS Organizations.
• Una aplicación en EC2 que necesita leer de S3 → rol de IAM con perfil de instancia, nunca claves de acceso en el código.
• Empleados que ya tienen usuario en Active Directory y tienen que entrar en la consola → federación (IAM Identity Center o SAML), no crear usuarios IAM.
• «Un auditor externo necesita acceso de solo lectura a nuestra cuenta» → rol entre cuentas con external ID.
• «Aplicar el principle of least privilege» → políticas acotadas por acción, recurso y condición, y herramientas como IAM Access Analyzer.

1. La infraestructura global de AWS

1.1 Regiones y zonas de disponibilidad

• AWS Region (región): ubicación geográfica con varias zonas de disponibilidad, aislada física e independientemente de las demás. Cada región tiene un código (eu-south-2 = Europa (España), eu-west-1 = Irlanda, us-east-1 = Norte de Virginia).
• Availability Zone (AZ, zona de disponibilidad): uno o varios centros de datos con energía, red y conectividad redundantes, en instalaciones separadas del resto de AZ de la región pero unidas con enlaces de baja latencia. Se nombran con el código de región más una letra (eu-south-2a). El nombre es un alias por cuenta; el identificador estable entre cuentas es el AZ ID (por ejemplo euw1-az1), útil cuando dos cuentas quieren coordinar recursos en la misma AZ física.

A 30/09/2026 la página oficial de infraestructura global indica 39 regiones y 124 AZ lanzadas (la cifra cambia a menudo: consúltala en la página de infraestructura global). En el examen no te preguntarán cifras, sino qué diseño sobrevive a qué fallo:

flowchart TB
  subgraph R["Región eu-south-2 (España)"]
    subgraph A["AZ eu-south-2a"]
      A1["Centro de datos"]
    end
    subgraph B["AZ eu-south-2b"]
      B1["Centro de datos"]
    end
    subgraph C["AZ eu-south-2c"]
      C1["Centro de datos"]
    end
    A1 <-->|"red privada de baja latencia"| B1
    B1 <--> C1
    A1 <--> C1
  end
  R <-->|"red troncal global de AWS"| R2["Otra región (p. ej. eu-west-1)"]
  E["Edge locations / PoP de CloudFront"] --- R

Cómo elegir región (los cuatro criterios clásicos):

1. Cumplimiento y residencia de datos: si la ley o el contrato exigen que los datos no salgan de la UE o de España, eso manda sobre todo lo demás. Los datos no salen de una región salvo que tú los copies o configures replicación.
2. Latencia: cerca de tus usuarios.
3. Disponibilidad de servicios y funciones: no todas las regiones tienen todos los servicios ni todos los tipos de instancia el mismo día. Compruébalo en la lista de servicios por región.
4. Precio: varía entre regiones.

Regiones opt-in (de activación voluntaria). Las regiones lanzadas después del 20/03/2019 vienen desactivadas en las cuentas nuevas y hay que activarlas (sin coste) antes de usarlas. Europa (España) eu-south-2 es opt-in, igual que Milán o Zúrich; Irlanda, Fráncfort, Londres, París y Estocolmo están activadas por defecto. Al activar una región, AWS propaga allí tus datos de IAM; el proceso tarda de minutos a horas. Lo harás en el lab 01.

aws account enable-region --region-name eu-south-2
aws account get-region-opt-status --region-name eu-south-2

1.2 Servicios globales, regionales y zonales

Saber el «alcance» de cada recurso evita muchos errores de diseño:

1.3 Más cerca del usuario: edge, Local Zones, Wavelength y Outposts

2. Tu cuenta y cómo accedes a AWS

2.1 La cuenta, el usuario root y los planes de la capa gratuita

Una cuenta de AWS es a la vez un contenedor de recursos, un límite de seguridad (por defecto, nadie de otra cuenta puede tocar tus recursos) y una unidad de facturación. Al darla de alta se crea el usuario root (AWS account root user): la identidad del correo con el que te registras, con acceso total e ilimitado, incluida la facturación. No se le pueden quitar permisos con políticas de IAM (solo las SCP limitan al root de una cuenta miembro).

Desde el 15/07/2025, al crear una cuenta eliges entre dos planes (documentación oficial):

Las cinco actividades que dan 20 USD cada una son: lanzar (y terminar) una instancia EC2, crear una base de datos RDS, crear una aplicación web con Lambda, usar un modelo en el playground de Amazon Bedrock y crear un presupuesto en AWS Budgets. En el lab 01 verás cómo afecta esto a tu estrategia de cuenta.

2.2 AWS Management Console, AWS CLI y AWS CloudShell

Todo en AWS es una llamada a una API firmada. Hay tres formas de hacerla:

• AWS Management Console: interfaz web. Cómoda para explorar; mala para repetir cosas. Cada consola de servicio es regional salvo los servicios globales.
• AWS CLI (versión 2): línea de comandos. Se configura con perfiles en ~/.aws/config. La forma recomendada de autenticarse es IAM Identity Center (aws configure sso y aws sso login), que da credenciales temporales renovables; las claves de acceso de larga duración (aws configure con access key) son el último recurso.
• AWS CloudShell: un terminal en el navegador, ya autenticado con tu sesión de consola, con la CLI v2 preinstalada. Sin coste adicional, 1 GB de almacenamiento persistente por región en $HOME (se borra tras 120 días sin usar la región), hasta 10 shells simultáneos por región, la sesión termina tras 20-30 minutos de inactividad o unas 12 horas seguidas, y no admite conexiones entrantes. Es lo que usarás en todos los labs.

# Configurar un perfil con IAM Identity Center (en tu ordenador; en CloudShell no hace falta)
aws configure sso
aws sso login --profile admin-lab
aws sts get-caller-identity --profile admin-lab

aws sts get-caller-identity es el comando más útil de la semana: te dice quién eres para AWS (cuenta, ARN del usuario o del rol asumido).

3. El modelo de responsabilidad compartida

AWS lo resume así: AWS es responsable de la seguridad de la nube (security OF the cloud); el cliente, de la seguridad en la nube (security IN the cloud).

• AWS: instalaciones físicas, hardware, red global, hipervisor, y el software de los servicios gestionados.
• Cliente: sus datos, quién accede (IAM), la configuración de red (security groups, NACL), el cifrado que elija activar, y todo lo que instale.

La frontera se mueve según el tipo de servicio:

Hay además controles compartidos: la gestión de parches (AWS parchea la infraestructura, tú tus sistemas), la gestión de configuración y la formación (AWS forma a su personal, tú al tuyo). AWS Artifact (módulo 07) te da acceso a los informes de cumplimiento de AWS.

4. IAM a fondo

AWS Identity and Access Management (IAM) es el servicio global y gratuito que decide quién (autenticación) puede hacer qué sobre qué recursos y en qué condiciones (autorización).

4.1 Vocabulario imprescindible

• Principal: quien hace la petición. Puede ser el usuario root, un usuario IAM, una sesión de rol (un rol asumido), un usuario federado o un servicio de AWS (por ejemplo ec2.amazonaws.com).
• Petición (request): acción (s3:GetObject) + recurso (ARN) + contexto (IP de origen, hora, si hay MFA, etiquetas…).
• ARN (Amazon Resource Name): identificador único de un recurso: arn:partition:service:region:account-id:resource. Ejemplos: arn:aws:iam::111122223333:role/Auditor (IAM es global, por eso la región va vacía), arn:aws:s3:::mi-bucket/* (S3 no lleva ni región ni cuenta).
• Deny implícito: por defecto, todo está denegado. Un permiso solo existe si alguna política lo concede.

4.2 El usuario root y las buenas prácticas de la cuenta

Buenas prácticas oficiales para el root (documentación):

• Contraseña fuerte y única, en un gestor de contraseñas; correo de grupo gestionado por la empresa (no el personal de alguien).
• MFA obligatoria: AWS exige que todas las cuentas (independientes, de administración y miembros) registren MFA para el root; si no está activada, hay que registrarla en un plazo de 35 días desde el primer intento de acceso a la consola. Se pueden registrar hasta 8 dispositivos MFA de cualquier combinación: llaves de seguridad FIDO (passkeys), dispositivos TOTP de hardware o aplicaciones autenticadoras virtuales. Registra al menos dos.
• Nunca crees claves de acceso para el root.
• Úsalo solo para las pocas tareas que lo exigen (por ejemplo, cambiar la configuración de la cuenta o cerrarla, restaurar permisos si el único administrador se los quitó, algunas tareas de facturación y soporte). Para todo lo demás, crea un usuario administrativo (en IAM Identity Center o, en su defecto, IAM).
• En organizaciones: gestión centralizada del acceso root para eliminar las credenciales root de las cuentas miembro, y SCP que limiten lo que el root de una cuenta miembro puede hacer.
• Vigila su uso: GuardDuty, reglas de EventBridge sobre inicios de sesión del root, y comprobaciones de AWS Config, Security Hub CSPM y Trusted Advisor (MFA en root, claves de root).

4.3 Identidades: usuarios, grupos y roles

Variantes de rol que conviene reconocer:

• Instance profile (perfil de instancia): contenedor que pasa un rol a una instancia EC2. La aplicación obtiene credenciales temporales del servicio de metadatos (IMDS) y el SDK las renueva solo. Es la forma correcta de dar permisos a EC2.
• Service role: rol que asume un servicio para actuar en tu nombre (por ejemplo, el rol de una función Lambda).
• Service-linked role: rol predefinido y vinculado a un servicio concreto, que solo ese servicio puede asumir y cuyas políticas no puedes editar. Las SCP no le afectan.
• iam:PassRole: permiso necesario para «entregar» un rol a un servicio (por ejemplo, al lanzar una instancia con un perfil). Sin él, un desarrollador podría escalar privilegios pasando un rol de administrador a una instancia que controla.

Cuotas verificadas en la documentación de cuotas (por defecto → máximo ampliable):

4.4 Políticas: tipos y anatomía

AWS managed frente a customer managed frente a inline: las administradas por AWS son cómodas pero amplias y AWS puede cambiarlas; las administradas por el cliente son reutilizables, versionadas (hasta 5 versiones) y las controlas tú; las inline viven dentro de una única identidad y se borran con ella (útiles cuando quieres una relación estricta 1:1).

Anatomía de una política de identidad:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LeerSoloMiCarpeta",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::empresa-datos/equipo-a/*",
      "Condition": {
        "Bool": { "aws:MultiFactorAuthPresent": "true" },
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

• Version: siempre 2012-10-17 (la versión del lenguaje, no una fecha tuya).
• Effect: Allow o Deny.
• Action / NotAction, Resource / NotResource: admiten comodines (s3:Get*).
• Principal: solo en políticas de recurso (quién recibe el permiso).
• Condition: operador + clave + valor. Claves globales muy preguntadas: aws:SourceIp, aws:SourceVpc, aws:SourceVpce (peticiones que llegan por un VPC endpoint), aws:RequestedRegion, aws:MultiFactorAuthPresent, aws:PrincipalOrgID (cualquiera de mi organización), aws:PrincipalTag y aws:ResourceTag (ABAC), aws:SecureTransport (exigir HTTPS).

ABAC (attribute-based access control): en lugar de una política por proyecto, una sola política compara etiquetas del principal y del recurso. Escala mejor que RBAC cuando hay muchos proyectos:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:StartInstances", "ec2:StopInstances"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:ResourceTag/Proyecto": "${aws:PrincipalTag/Proyecto}" }
      }
    }
  ]
}

Una política de recurso (bucket policy) que da lectura a un rol de otra cuenta y obliga a usar HTTPS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LecturaDesdeCuentaAnalitica",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::444455556666:role/Analitica" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::informes-ventas/*"
    },
    {
      "Sid": "SoloHTTPS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::informes-ventas", "arn:aws:s3:::informes-ventas/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

¿Cuándo usar una política de recurso en vez de un rol? Cuando el servicio la admite y quieres que el otro lado siga usando sus propios permisos a la vez (con un rol, el principal renuncia a los suyos mientras dura la sesión), cuando el que llama es un servicio de AWS (S3 invocando una Lambda, SNS escribiendo en SQS) o cuando quieres controlar el acceso en el propio recurso (por ejemplo, forzar cifrado o un VPC endpoint). Con un rol, en cambio, centralizas en un sitio muchos permisos sobre muchos recursos.

4.5 La lógica de evaluación de políticas

Es la parte más técnica del módulo y cae seguro. Tres reglas de oro (documentación oficial):

1. Por defecto, todo se deniega (salvo al root de la cuenta, que tiene acceso completo; solo una SCP puede limitar al root de una cuenta miembro).
2. Un Deny explícito en cualquier política aplicable gana siempre.
3. Para que se permita, hace falta un Allow explícito y que ninguna política «limitadora» lo impida.

Orden de evaluación dentro de una cuenta:

flowchart TD
  A["Petición autenticada"] --> B{"¿Algún Deny explícito en SCP, RCP, política de recurso, de identidad, boundary o de sesión?"}
  B -->|Sí| DENY["DENY final"]
  B -->|No| C{"¿Las RCP que aplican al recurso lo permiten?"}
  C -->|No| DENY
  C -->|Sí o no hay RCP| D{"¿Las SCP que aplican al principal lo permiten?"}
  D -->|No| DENY
  D -->|Sí o no hay SCP| E{"¿Una política de recurso lo concede directamente a este usuario IAM o sesión?"}
  E -->|Sí| ALLOW["ALLOW final"]
  E -->|No| F{"¿Alguna política de identidad lo permite?"}
  F -->|No| DENY
  F -->|Sí| G{"¿Hay permissions boundary y no lo permite?"}
  G -->|"Sí, no lo permite"| DENY
  G -->|"No hay o lo permite"| H{"¿Es una sesión con política de sesión que no lo permite?"}
  H -->|"Sí, no lo permite"| DENY
  H -->|"No"| ALLOW

Cómo se combinan los tipos (dentro de una misma cuenta):

Excepción fina que aparece en preguntas difíciles: si una política de recurso concede el permiso directamente al ARN de un usuario IAM o de una sesión de rol, un deny implícito de la política de identidad, del boundary o de la política de sesión no lo impide. En cambio, si la política de recurso nombra el ARN del rol (no el de la sesión), el boundary y la política de sesión sí limitan.

Entre cuentas (cross-account): la petición se evalúa dos veces, en la cuenta que confía (dueña del recurso) y en la cuenta de confianza (la del principal). Ambas deben dar Allow: la política de identidad del que llama debe permitir la acción sobre el ARN del recurso, y la política de recurso debe nombrar a ese principal (o a su cuenta). Las SCP de la organización del que llama también aplican.

Ejemplos rápidos (hazlos de cabeza antes de leer la solución):

4.6 AWS STS, roles y acceso entre cuentas

AWS Security Token Service (STS) emite credenciales temporales (clave de acceso, clave secreta y token de sesión) con caducidad. Operaciones que debes reconocer:

Role chaining (usar la sesión de un rol para asumir otro) limita la nueva sesión a 1 hora, salvo en los casos que la documentación excluye (credenciales de perfiles de instancia EC2, por ejemplo).

Cambio de rol en la consola (switch role): un usuario con permiso sts:AssumeRole sobre el rol pasa a trabajar con sus permisos, y deja temporalmente los suyos.

Acceso entre cuentas con rol (el patrón que más sale):

1. En la cuenta B (dueña de los recursos) se crea un rol con una trust policy que confía en la cuenta A (o en un rol concreto de A) y una política de permisos acotada.
2. En la cuenta A, la política de identidad del usuario o rol permite sts:AssumeRole sobre el ARN del rol de B.
3. El principal de A llama a AssumeRole y recibe credenciales temporales de B.

Si quien asume es un tercero (un proveedor SaaS que accede a las cuentas de muchos clientes), añade una condición sts:ExternalId en la trust policy para evitar el problema del confused deputy (que otro cliente del proveedor le haga usar tu rol):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::999988887777:root" },
      "Action": "sts:AssumeRole",
      "Condition": { "StringEquals": { "sts:ExternalId": "cliente-7f3a9" } }
    }
  ]
}

Nombrar arn:aws:iam::999988887777:root en la trust policy significa «delego en la cuenta 999988887777»: dentro de ella, solo podrán asumir el rol los principales a los que su administrador dé sts:AssumeRole.

4.7 Federación e identidades de personas

La federación permite que las personas usen identidades que ya existen fuera de IAM (un directorio corporativo, un proveedor de identidad en la nube, redes sociales) y reciban credenciales temporales de un rol. Ventajas: sin usuarios IAM que mantener, altas y bajas centralizadas, MFA del proveedor.

IAM Identity Center en detalle:

• Instancia de organización (recomendada; se crea en la cuenta de administración de AWS Organizations y es la única que da acceso a cuentas de AWS) frente a instancia de cuenta (solo para aplicaciones gestionadas de AWS dentro de una cuenta).
• Activarlo en una cuenta independiente crea una organización con esa cuenta como cuenta de administración.
• Fuentes de identidad: el directorio propio de Identity Center, Active Directory (Managed Microsoft AD o AD Connector) o un IdP externo (SAML 2.0 + SCIM).
• Permission set: plantilla de permisos (políticas administradas, inline o boundaries) que Identity Center convierte en un rol (AWSReservedSSO_...) en cada cuenta asignada.
• AWS access portal: la URL donde el usuario ve sus cuentas y roles.
• Los datos se guardan en la región donde lo activas; se puede replicar a otras regiones. Si eliges una región opt-in, todas las cuentas deben tenerla activada; por eso es más cómodo activarlo en una región activada por defecto (por ejemplo eu-west-1).

AWS Directory Service ofrece Microsoft Active Directory en AWS:

4.8 Buenas prácticas de IAM (el checklist del examen)

Según las buenas prácticas oficiales:

1. Credenciales temporales para personas (federación, Identity Center) y cargas (roles). Las claves de larga duración, solo si no hay alternativa, y rótalas.
2. MFA para el root y para cualquier acceso humano privilegiado; se puede exigir con aws:MultiFactorAuthPresent.
3. Mínimo privilegio: empieza con políticas administradas de AWS si te ayudan a arrancar y refina con políticas propias. Usa la información de último acceso (last accessed information) y la generación de políticas de IAM Access Analyzer basada en CloudTrail.
4. Condiciones para acotar aún más (IP, VPC endpoint, región, HTTPS, etiquetas).
5. Valida las políticas con IAM Access Analyzer antes de desplegarlas.
6. Guardarraíles en multicuenta: SCP y RCP; permissions boundaries para delegar.
7. Revisa y elimina usuarios, roles, permisos y credenciales sin uso; el credential report (aws iam generate-credential-report) lista todos los usuarios y el estado de sus credenciales.

4.9 IAM Access Analyzer

Herramienta de IAM con varias funciones (documentación):

• External access analyzer (sin coste): define una zona de confianza (tu cuenta o tu organización) y genera un hallazgo por cada recurso compartido fuera de ella (buckets S3, roles, claves KMS, funciones Lambda, colas SQS, secretos, temas SNS, snapshots de EBS y RDS, repositorios ECR, EFS, tablas y streams de DynamoDB…). Es regional: créalo en cada región que uses.
• Internal access analyzer y unused access analyzer (de pago): quién de dentro puede acceder a recursos críticos, y roles, claves, contraseñas y permisos sin usar.
• Validación de políticas (gramática y buenas prácticas) y custom policy checks (¿esta política concede acceso nuevo? ¿permite esta acción crítica?).
• Generación de políticas a partir de la actividad registrada en CloudTrail.

aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://politica.json

5. Seguridad multicuenta

5.1 ¿Por qué varias cuentas?

La cuenta es el límite de aislamiento más fuerte de AWS: separa permisos, cuotas de servicio, facturación y el «radio de explosión» de un error o un incidente. La estrategia recomendada (whitepaper) es agrupar cargas por función y requisitos en unidades organizativas (OU): por ejemplo Security (cuentas de seguridad y de logs), Infrastructure (red compartida), Workloads con sub-OU Prod y Dev, Sandbox (experimentos) y Suspended.

5.2 AWS Organizations

• Cuenta de administración (management account): crea la organización, paga la factura consolidada y gestiona políticas. Ninguna SCP le afecta, por eso no se despliegan cargas en ella.
• Cuentas miembro, agrupadas en OU jerárquicas bajo la raíz.
• Consolidated billing: una sola factura, y el uso se agrega para alcanzar tramos de descuento por volumen; los descuentos de Reserved Instances y Savings Plans pueden compartirse entre cuentas.
• Dos modos: solo facturación consolidada, o all features (necesario para las políticas).
• Delegated administrator: una cuenta miembro administra un servicio (GuardDuty, Security Hub, Identity Center…) sin usar la cuenta de administración.

Tipos de política (documentación):

Cómo funcionan las SCP (documentación):

• No conceden permisos; fijan el máximo. El usuario sigue necesitando políticas de IAM.
• Se heredan: una cuenta solo tiene lo que permiten todos los niveles por encima (raíz → OU → cuenta).
• Al activar las SCP se asocia la política FullAWSAccess a todo; si la quitas sin sustituirla, todo queda bloqueado.
• Afectan a todos los usuarios y roles de las cuentas miembro, incluido el root; no afectan a la cuenta de administración ni a los service-linked roles, ni a principales de fuera de la organización a los que una política de recurso dé acceso.
• Estrategias: deny list (dejar FullAWSAccess y añadir Deny concretos; lo habitual) o allow list (sustituir FullAWSAccess por una lista de servicios permitidos; más restrictivo y más trabajo).

SCP típica: impedir el uso de regiones no aprobadas, salvo servicios globales (los que se llaman a través de us-east-1):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenegarFueraDeRegionesAprobadas",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "organizations:*", "sts:*", "route53:*",
        "cloudfront:*", "support:*", "budgets:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["eu-south-2", "eu-west-1"] }
      }
    }
  ]
}

Otras SCP clásicas: impedir salir de la organización (organizations:LeaveOrganization), impedir desactivar CloudTrail o GuardDuty, exigir etiquetas al crear recursos, bloquear acciones del root de las cuentas miembro.

RCP: igual que las SCP pero aplicadas a los recursos (S3, STS, KMS, SQS, Secrets Manager, entre otros). Sirven para construir un perímetro de datos: por ejemplo, denegar el acceso a los buckets de la organización a cualquier principal cuyo aws:PrincipalOrgID no sea el tuyo, aunque alguien escriba por error una bucket policy pública.

5.3 AWS Control Tower

Servicio que orquesta Organizations, IAM Identity Center, AWS Config, CloudTrail y Service Catalog para montar en menos de una hora un entorno multicuenta según buenas prácticas (documentación):

• Landing zone: el entorno multicuenta base (OU de seguridad con una cuenta de archivo de logs y otra de auditoría, CloudTrail de organización, Identity Center configurado).
• Controls (antes guardrails): reglas de gobierno en lenguaje llano.
  • Preventivos: impiden la acción (se implementan con SCP o RCP).
  • Detectivos: detectan incumplimientos (reglas de AWS Config).
  • Proactivos: comprueban los recursos antes de crearlos (hooks de CloudFormation).
  • Por obligatoriedad: mandatory, strongly recommended y elective.
• Account Factory: plantilla para dar de alta cuentas nuevas ya configuradas y con los controles aplicados («máquina expendedora» de cuentas, construida sobre Service Catalog).
• Dashboard y detección de drift (desviaciones respecto a la configuración).

5.4 AWS Resource Access Manager (AWS RAM)

AWS RAM permite compartir recursos con otras cuentas, con toda la organización o con OU concretas, sin duplicarlos (documentación). Ejemplos: subredes de VPC (VPC sharing: una cuenta de red posee la VPC y las cuentas participantes lanzan sus recursos en las subredes compartidas), AWS Transit Gateway, reglas de Route 53 Resolver, configuraciones de License Manager, Capacity Reservations, Dedicated Hosts…

Frente a una política de recurso: con RAM puedes compartir con una OU entera sin listar cuentas, el recurso aparece en la consola del consumidor como si fuera suyo y el dueño ve quién tiene acceso. Dentro de la organización no hace falta aceptar invitaciones. RAM no tiene coste propio. Las políticas de IAM y las SCP de la cuenta consumidora siguen aplicando.

5.5 Resumen: ¿qué uso para el acceso en varias cuentas?

6. Introducción al AWS Well-Architected Framework

El examen «valida la capacidad de diseñar soluciones basadas en el AWS Well-Architected Framework», así que conviene conocerlo desde el primer día (lo trabajarás a fondo en el módulo 10). Tiene seis pilares (documentación):

La AWS Well-Architected Tool es un servicio de la consola que te guía por las preguntas de cada pilar para revisar una carga de trabajo concreta, identifica riesgos altos y medios, genera un plan de mejora, guarda hitos (milestones) para ver la evolución y admite lenses (de AWS, como Serverless Applications Lens, o personalizadas). Se integra con Trusted Advisor.

Trampas típicas del examen

• Claves de acceso en el código, en variables de entorno o en la AMI → siempre es incorrecto si existe la opción de rol (perfil de instancia, rol de ejecución de Lambda, rol de tarea de ECS).
• «Crear un usuario IAM para cada empleado de la empresa» cuando ya tienen un directorio → la respuesta es federación (Identity Center, SAML).
• Grupos como principal: no puedes poner un grupo IAM en el Principal de una bucket policy ni hacer que un grupo asuma un rol.
• Las SCP no conceden permisos y no afectan a la cuenta de administración. Si el enunciado dice «el usuario de la cuenta de administración pudo hacerlo pese a la SCP», es por eso.
• Permissions boundary ≠ política de permisos: por sí solo no concede nada.
• Deny explícito siempre gana, aunque haya un Allow en otra política o en otra cuenta.
• Acceso entre cuentas: hace falta permiso en ambos lados. Una bucket policy que permite a la cuenta A no basta si la política de identidad del usuario de A no permite s3:GetObject.
• Tercero que accede a tu cuenta → rol con external ID, nunca compartir claves ni crear un usuario IAM para él.
• Root: MFA, sin claves de acceso, sin uso diario. «Proteger la cuenta» en una pregunta de opción múltiple casi siempre incluye MFA en root.
• Control Tower frente a Organizations: Organizations es la pieza; Control Tower monta todo el entorno con guardarraíles y fábrica de cuentas.
• AD Connector frente a Managed Microsoft AD: proxy, no data stored in the cloud → AD Connector; trust relationship, AD-aware applications in AWS → Managed Microsoft AD.
• Cognito frente a Identity Center: clientes de una app → Cognito; empleados que acceden a cuentas y aplicaciones de AWS → Identity Center.
• Outposts frente a Local Zones: «los datos deben permanecer en las instalaciones del cliente» → Outposts.
• Simple AD está cerrado a clientes nuevos; si aparece como opción «barata», piénsalo dos veces (y en el examen solo sería válido para necesidades básicas de un directorio independiente).

Resumen

• Una región tiene varias AZ aisladas; multi-AZ da alta disponibilidad, multirregión da DR y cercanía global. eu-south-2 es una región opt-in.
• Edge locations (CloudFront, Route 53), Local Zones (ciudad), Wavelength (5G) y Outposts (tu centro de datos) acercan AWS al usuario.
• Responsabilidad compartida: AWS protege la nube; tú, lo que pones en ella. La frontera depende del tipo de servicio.
• Root solo para tareas de root, con MFA y sin claves. Personas → Identity Center/federación; cargas → roles.
• Políticas: identidad y recurso conceden; boundaries, SCP, RCP y políticas de sesión limitan. Deny explícito gana; por defecto todo se deniega.
• Entre cuentas: Allow en las dos cuentas. Terceros → external ID.
• STS da credenciales temporales (15 min-12 h; 1 h con role chaining).
• Organizations + SCP/RCP para guardarraíles; Control Tower para montar y gobernar el entorno; RAM para compartir recursos; Access Analyzer para detectar accesos externos y validar políticas.
• Well-Architected: 6 pilares; la Well-Architected Tool revisa cargas concretas.

Cobertura del temario

Task statement principal: 1.1 Design secure access to AWS resources. También se cubren los puntos de infraestructura global de las tareas 2.2 (y se introducen los de 3.3 y 4.2, que se completan en los módulos 02 y 04).

Practica lo aprendido

Documentación oficial para ampliar

• AWS Global Infrastructure
• IAM User Guide: Policy evaluation logic
• IAM User Guide: Security best practices in IAM
• IAM and AWS STS quotas
• What is IAM Identity Center?
• AWS Organizations: Service control policies (SCPs)
• What Is AWS Control Tower?
• AWS Directory Service: What is AWS Directory Service?
• Shared Responsibility Model
• AWS Well-Architected Framework
• Organizing Your AWS Environment Using Multiple Accounts (whitepaper)