La nueva forma de iniciar sesión en AWS: lo que cambia (y lo que no) desde la seguridad
Nueva forma de creacion e inicio de sesion en aws
Desde el 16 de septiembre de 2026, una cuenta nueva de AWS ya no nace con un root user y una contraseña: nace con tu identidad de Google, GitHub, Apple o Amazon, dentro de un Project con guardrails ya aplicados. Para quienes venimos de seguridad, esto es lo más grande que le ha pasado al sign-in de AWS en años.
Durante más de una década, el primer paso en AWS fue el mismo: correo, contraseña, tarjeta de crédito y un root user con poder absoluto. El segundo paso, que muchos nunca daban, era protegerlo con MFA y dejar de usarlo. En mis clases y talleres sigo viendo cuentas personales con root activo y access keys en
~/.aws/credentials.En este artículo reviso, con lentes de Cloud Security, qué cambió, qué hay debajo del capó, qué mejora tu postura y qué deberías vigilar. Al final conecto todo con
aws login, la otra pieza que elimina las access keys de tu laptop.Qué cambió en el inicio de sesión
AWS anunció una experiencia simplificada para builders que empiezan un proyecto nuevo. Se está liberando de forma gradual y solo aplica a cuentas nuevas.
| Antes | Ahora (nueva experiencia) |
|---|---|
| Correo + contraseña del root user | Identidad existente: Google, GitHub, Apple o Amazon (AWS Builder ID) |
| Tarjeta de crédito obligatoria | La mayoría de clientes nuevos no la necesita; incluye créditos del Free Tier |
| Una cuenta "vacía" que tú configuras | Un Project: cuenta AWS + configuración de colaboración + controles de seguridad aplicados |
| Crear IAM users para tu equipo | Invitas colaboradores por correo; su acceso se configura solo |
| Budgets y alarmas manuales | Spend limit mensual desde 20 USD; si se alcanza, el proyecto se pausa ese mes |
| Configurar CLI y credenciales a mano | Un prompt para tu coding agent instala AWS CLI y el Agent Toolkit for AWS |
Un detalle clave: cada login con Builder ID envía un código de verificación al correo, así que hay un segundo factor desde el día uno. Y cuando necesites más (varias regiones, políticas propias de Organizations), activas las advanced features sin migración ni downtime.
Bajo el capó: una AWS Organization que no ves
El Project no es una cuenta suelta. Según el análisis de Scott Piper en Wiz , AWS crea por detrás una AWS Organization con tres cuentas, y tú solo accedes a una.
- Management account (oculta): desde aquí AWS aplica SCPs y RCPs a tu cuenta. Obtienes acceso al activar las advanced features.
- Identity account (oculta): soporta el acceso con Builder ID.
- Tu cuenta de trabajo: donde creas recursos. Su acceso lo gestiona el nuevo servicio Account Access, mediante el rol
AccountFullAccessRoleque confía enaccount-access.amazonaws.com.
Los guardrails principales, documentados en SCPs and RCPs for projects :
- FreeTierSCP: un
DenyconNotActionque funciona como allowlist de servicios mientras estás en el sandbox. - BudgetsSpendLimitDenyNewWorkloads: se aplica automáticamente si el budget de 20 USD se va a superar; bloquea la creación de cómputo y otros recursos.
- ManagedAccountSecurityControlPolicy: impide salir de la Organization y protege el rol
AWSManagedAccountManagementAccessRole. - AdvancedModeRegionRestrictionSecurityControlPolicy: mantiene el proyecto en una sola región.
- RCP de data perimeter: niega acceso a principals de fuera de la Organization sobre los recursos protegidos.
Además, la experiencia habilita IAM Role Manager: cuando AWS crea roles por ti (por ejemplo, desde la consola), los crea con
PowerUserAccess.Lo bueno desde seguridad
- Adiós al root user como primer contacto. No puedes usar root hasta activar las advanced features. Eso elimina el patrón clásico de compartir la contraseña root y complica mucho menos un incident response.
- Segundo factor por defecto. El código por correo en cada login no es FIDO2, pero es mejor que el "ya pondré MFA después" que vemos en tantas cuentas.
- Sin IAM users para el equipo. Invitar por correo evita crear usuarios con contraseña y access keys de larga duración solo para colaborar.
- Spend limit como control de seguridad. Una cuenta comprometida usada para cryptomining es un incidente de seguridad y financiero. Un tope de gasto con SCP automático corta ese impacto.
- Data perimeter desde el inicio. La RCP impide que principals externos a tu Organization lleguen a tus recursos protegidos, incluso si alguien publica una policy demasiado abierta.
- Defaults más seguros. Los buckets nuevos nacen con S3 Block Public Access y las instancias EC2 con IMDSv2 por defecto.
Lo que debes vigilar
El sandbox está optimizado para simplicidad y control de costos, no para máxima seguridad. Estos son los puntos que yo revisaría:
- Sin CloudTrail trail configurado. Solo tienes Event History (90 días, consulta limitada). Sin un trail no hay retención ni integración con EventBridge para detectar cambios como un
AuthorizeSecurityGroupIngresshacia0.0.0.0/0. - Servicios de seguridad bloqueados. La allowlist del sandbox niega GuardDuty, Security Hub, Detective, Inspector, Macie y Access Analyzer, incluso sus funciones gratuitas. AWS Config y CloudTrail sí están permitidos.
- IAM Role Manager con
PowerUserAccess. Es casi admin. Pasas de least privilege por diseño a reducir permisos después, y ese "después" casi nunca llega. - Todos los colaboradores son admin. Invitar es fácil; revisar quién tiene acceso no tanto: desde la cuenta no hay API para verlo, se consulta en
settings.aws.com. - Los defaults se pueden desactivar. Wiz logró crear un IAM user con access key, un bucket público (quitando el Block Public Access del bucket) y una EC2 con IMDSv1. Hay advertencias, pero no bloqueos.
- La RCP rompe integraciones cross-account. Bloquea
sts:AssumeRoledesde otras cuentas, así que herramientas de terceros que usan roles no funcionan hasta hacer upgrade. El riesgo: que alguien vuelva a usar access keys como atajo. - Monitoreo de root post-upgrade. Desde septiembre, el login de root se atiende en tres regiones (us-east-1, us-east-2, us-west-2) y el evento
ConsoleLoginqueda en la región que lo procesó. Si alertas solo en us-east-1, ya tienes un punto ciego.
Conclusión
AWS por fin cambió el punto de partida: identidad federada, sin root, sin tarjeta y con guardrails desde el primer minuto. Es una gran noticia para quien empieza y para quienes enseñamos cloud. Pero un sandbox seguro para aprender no es un baseline seguro para producción. Usa la nueva experiencia para moverte rápido, y cuando tu proyecto tenga datos reales, activa las advanced features y haz el trabajo de seguridad completo.
¿Ya probaste la nueva experiencia o sigues con access keys en tu laptop? Cuéntamelo en los comentarios.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article