AWS STS unifica el límite de tamaño del session token
En pocas palabras: Desde el anuncio de AWS del 15 de septiembre de 2026, STS reemplazó los dos límites previos por uno solo de 4096 bytes para el session token completo, y ahora reporta su tamaño en respuestas de API, CloudWatch y CloudTrail.
AWS unificó los límites de tamaño del session token en STS: antes había dos límites separados (el de la política empaquetada y el del token completo), ahora hay uno solo de 4096 bytes, según el anuncio oficial de AWS del 15 de septiembre de 2026. Además, sumó tres canales de monitoreo nuevos para ver el tamaño real de cada token que emitís.
AWS Security Token Service (STS) es el servicio que genera credenciales temporales (access key, secret key y session token) cuando asumís un rol con operaciones como AssumeRole o AssumeRoleWithWebIdentity. El session token es la cadena opaca que codifica las políticas de sesión y los tags que pasás, más el contexto que agrega AWS. Con el cambio anunciado, ese token pasó a tener un límite único de 4096 bytes.
En este artículo:
- En 30 segundos
- ¿Qué es exactamente un session token de AWS STS?
- ¿Cuál es el nuevo límite de tamaño del session token en AWS STS?
- ¿Qué pasa ahora con el error PackedPolicyTooLargeException?
- ¿Cómo funciona el monitoreo de tamaño del session token en AWS STS?
- ¿Cómo se usa MinimumSessionTokenSize para probar la infraestructura?
- ¿Qué deben hacer los equipos que ya usan AWS STS en producción?
- Errores comunes al migrar al nuevo límite de session token
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- AWS reemplazó los dos límites previos (packed policy size y tamaño total del token) por uno solo de 4096 bytes para el session token completo.
- El error PackedPolicyTooLargeException sigue existiendo, pero ahora el mensaje muestra el tamaño real del token y el máximo permitido en bytes.
- Hay tres campos nuevos para monitorear: SessionTokenSize, SessionTokenUtilization y, por compatibilidad hacia atrás, PackedPolicySize.
- El parámetro MinimumSessionTokenSize (de 0 a 4096 bytes) permite forzar tokens grandes para testear infraestructura, disponible en las versiones más recientes del AWS CLI, los SDKs de AWS y Tools for PowerShell.
- CloudWatch publica las métricas SessionTokenSize y SessionTokenMaxSize en el namespace AWS/STS.
¿Qué es exactamente un session token de AWS STS?
El session token es la tercera pieza de las credenciales temporales que devuelve STS, junto al access key ID y la secret access key. Lo generan operaciones como AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, GetSessionToken y GetFederationToken, y sirve para autenticar cada llamada posterior a la API de AWS.
Ese token no es texto plano legible. STS toma las políticas de sesión y los tags que le pasás, los comprime y los serializa en un formato empaquetado, y a eso le suma metadata propia del servicio. El resultado es una cadena que tu SDK maneja de forma transparente, pero que en algunos escenarios (proxies, balanceadores, bases de datos que la guardan) tenés que tratar como cualquier otro string con un límite de tamaño. Esto se conecta con lo que analizamos en montar una arquitectura AWS de producción.
¿Cuál es el nuevo límite de tamaño del session token en AWS STS?
El límite de tamaño del session token de AWS STS pasó a ser único: 4096 bytes para el token ensamblado, sin importar de dónde venga ese peso. Antes existían dos límites independientes, uno para la “packed policy” (la compresión de tus tags y políticas) y otro para el token completo ya armado, y una solicitud podía fallar contra cualquiera de los dos sin que pudieras distinguir cuál.
Ojo con esto: el límite de 2048 caracteres para el texto plano de las políticas inline o administradas en AssumeRole sigue existiendo tal cual, según la documentación de referencia de la API. Es un límite de entrada, distinto del límite de salida del token comprimido que acaba de cambiar. No los confundas.
¿Qué pasa ahora con el error PackedPolicyTooLargeException?
PackedPolicyTooLargeException sigue siendo la excepción que devuelve STS cuando el token supera el límite, así que no hace falta tocar tu manejo de errores existente. Lo que cambió es el mensaje: ahora incluye el tamaño real de tu token y el máximo permitido, los dos en bytes, algo que antes no existía.
¿Por qué era un problema el esquema viejo? Porque la misma excepción se disparaba tanto si excedías el límite de la packed policy como si excedías el límite del token total, y no había forma de saber cuál de los dos habías pisado. Si alguna vez armaste una sesión con muchos tags de ABAC y te topaste con este error sin poder diagnosticarlo, sabés de qué hablo. El artículo del centro de conocimiento de AWS sobre este error, actualizado el 24 de agosto de 2026 según su propio historial de revisiones, ya refleja el comportamiento nuevo.
| Aspecto | Antes | Ahora |
|---|---|---|
| Límites enforced | Dos: packed policy size y tamaño del token ensamblado | Uno solo: tamaño del session token (4096 bytes) |
| Mensaje de error | PackedPolicyTooLargeException sin indicar cuál límite se excedió | PackedPolicyTooLargeException con tamaño real y máximo en bytes |
| Visibilidad del tamaño | No se reportaba en ningún lado | API, CloudWatch y CloudTrail lo reportan |
| Testeo de infraestructura | No había mecanismo | Parámetro MinimumSessionTokenSize |
¿Cómo funciona el monitoreo de tamaño del session token en AWS STS?
STS reporta el tamaño del token por tres canales distintos: la respuesta de la API, CloudWatch y CloudTrail. Cada uno sirve para algo diferente, y podés usarlos en combinación según qué tan actualizado tengas tu SDK. Para más detalles técnicos, mirá una correcta implementación de IAM en AWS.
- En la respuesta de la API: cada llamada exitosa a una operación de STS devuelve SessionTokenSize (bytes) y SessionTokenUtilization (porcentaje del límite de 4096 bytes consumido). También sigue devolviendo PackedPolicySize por compatibilidad, campo que ahora reporta el mismo valor que SessionTokenUtilization.
- En CloudWatch: el namespace AWS/STS publica las métricas SessionTokenSize y SessionTokenMaxSize, que podés graficar en un dashboard o usar para armar una alarma.
- En CloudTrail: cada evento de tipo AssumeRole u otra operación de vending registra sessionTokenSize y sessionTokenUtilization dentro de responseElements, junto con packedPolicySize para retrocompatibilidad.
Un ejemplo real de respuesta, tal como lo muestra el propio anuncio de AWS, se ve así: "PackedPolicySize": 61, "SessionTokenSize": 2532, "SessionTokenUtilization": 61. Ese token está usando 2532 de los 4096 bytes disponibles, un 61% del límite. Si tu SDK todavía no expone SessionTokenUtilization, PackedPolicySize te da el mismo dato sin necesidad de actualizar nada.
¿Cómo se usa MinimumSessionTokenSize para probar la infraestructura?
MinimumSessionTokenSize es un parámetro opcional que fuerza a STS a inflar el token hasta el tamaño que le indiques, entre 0 y 4096 bytes, sin importar cuánto pesen tus políticas y tags reales. Sirve para simular el peor caso antes de que te explote en producción.
Pensalo así: subís una política chica, todo funciona bárbaro en tu ambiente de dev, la mandás a producción y de repente el balanceador de carga corta la conexión porque nunca vio un token de más de 3000 bytes. Con este parámetro podés reproducir ese escenario a propósito, en lugar de esperar a que pase solo. Te puede servir nuestra cobertura de los checks de seguridad en tu pipeline AWS.
aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/MyRole \ --role-session-name validation-test \ --minimum-session-token-size 4096
La recomendación es arrancar directo en 4096 para testear contra el peor escenario posible. Si algo trunca o rechaza el token (un load balancer, un proxy, una columna varchar(2048) en tu base de datos), bajás el valor hasta encontrar el techo real de ese sistema. El parámetro está disponible en las versiones más recientes del AWS CLI, los SDKs y Tools for PowerShell.
¿Qué deben hacer los equipos que ya usan AWS STS en producción?
Si nunca te topaste con un error de tamaño de token, probablemente no notes ningún cambio inmediato, pero tus tokens van a tener más margen y con el tiempo podrían crecer más de lo que tus sistemas manejaron antes. Si alguna vez sufriste PackedPolicyTooLargeException, revisá los workarounds que armaste para esquivarlo (tags recortados, políticas partidas en varias) porque quizás ya no los necesitás bajo el límite único.
El tema es que si tu aplicación usa un SDK de AWS para hacer las llamadas, el tamaño del token no te afecta directamente porque el SDK lo maneja internamente. Donde sí tenés que poner atención es en los sistemas que guardan o reenvían el token: bases de datos con columnas de ancho fijo, caches, proxies. AWS recomienda tres pasos concretos, y no son sugerencias vagas: Relacionado: qué hacer si comprometen una clave AWS.
- Validar el máximo que soporta cada sistema usando MinimumSessionTokenSize antes de que un token grande rompa algo en silencio.
- Monitorear con CloudWatch y CloudTrail, seteando la alarma contra el límite real de tu infraestructura, no contra el máximo de 4096 bytes (que es igual para todas las cuentas y no te dice nada sobre tu propio cuello de botella).
- Usar el campo correcto según tu SDK: SessionTokenUtilization si tu versión lo expone, PackedPolicySize si todavía no la actualizaste.
Errores comunes al migrar al nuevo límite de session token
- Hardcodear 4096 en el código. El propio anuncio de AWS aclara que ese número es el máximo actual, no un techo permanente, y podría subir cuando se sumen capacidades que necesiten más espacio en el token (nuevas context keys, metadata de auditoría, firmas más largas por criptografía post-cuántica).
- Confundir el límite de 2048 caracteres de texto plano de las políticas con el límite de 4096 bytes del token comprimido. Son dos cosas distintas: una es sobre el JSON que escribís, la otra es sobre el resultado ya empaquetado que arma STS.
- Setear la alarma de CloudWatch contra el máximo de la cuenta en vez del máximo de tu propia infraestructura. El límite de 4096 bytes es igual para todo el mundo; el que importa es el que descubriste probando con MinimumSessionTokenSize.
- Asumir que actualizar el SDK es obligatorio de entrada. No lo es: podés seguir monitoreando con PackedPolicySize desde CloudTrail sin tocar tu versión, aunque conviene migrar quirúrgicamente cuando puedas.
Preguntas Frecuentes
¿Qué cambió en el límite de tamaño del session token de AWS STS?
AWS reemplazó los dos límites anteriores (packed policy size y tamaño total del token) por un límite único de 4096 bytes para el session token ensamblado. El cambio se aplica a AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, GetSessionToken y GetFederationToken, según detalla el anuncio oficial de AWS del 15 de septiembre de 2026.
¿Cómo se soluciona el error PackedPolicyTooLargeException ahora?
No requiere cambios de código: la excepción sigue siendo la misma, pero ahora el mensaje incluye el tamaño real de tu token y el máximo permitido en bytes. Muchas solicitudes que antes fallaban contra el límite viejo de la packed policy ahora pasan sin problema bajo el límite único.
¿Qué es MinimumSessionTokenSize y para qué sirve?
MinimumSessionTokenSize es un parámetro opcional de las APIs de STS que infla el token hasta el tamaño que especifiques, entre 0 y 4096 bytes, sin importar el contenido real de tus políticas y tags. Sirve para probar de forma controlada si tus sistemas (bases de datos, proxies, balanceadores) soportan tokens grandes antes de que pase en producción.
¿Dónde se puede ver el tamaño del session token en CloudWatch o CloudTrail?
En CloudWatch, las métricas SessionTokenSize y SessionTokenMaxSize se publican en el namespace AWS/STS. En CloudTrail, cada evento exitoso de una operación de vending de STS incluye los campos sessionTokenSize y sessionTokenUtilization dentro de responseElements.
¿El límite de 4096 bytes es definitivo o puede cambiar en el futuro?
No es definitivo. AWS aclaró en su anuncio que 4096 bytes refleja las necesidades actuales y que el límite podría crecer cuando se agreguen nuevas capacidades que requieran más espacio en el token, así que no conviene hardcodear ese número en tus sistemas.
Conclusión
El cambio es chico en superficie pero resuelve un dolor de cabeza real: ya no vas a perder tiempo adivinando cuál de dos límites pisaste cuando te explota PackedPolicyTooLargeException. Con un límite único de 4096 bytes, mensajes de error más claros y visibilidad completa vía API, CloudWatch y CloudTrail, tenés todo lo necesario para dejar de operar a ciegas con el tamaño de tus tokens.
Lo que sí te toca hacer vos: correr MinimumSessionTokenSize contra tus sistemas críticos (esas bases de datos con columnas varchar de hace cinco años son sospechosas número uno), armar una alarma en CloudWatch contra tu propio límite real, y no asumir que 4096 va a ser el techo para siempre. Es una tarea de una tarde, no de un sprint entero, y te ahorra un incidente en producción el día que AWS decida subir ese número.
