Executive summary
AWS STS “now enforces a single 4,096-byte size limit on session tokens”, replacing what were previously “separate limits on session token size and passed-in parameters (i.e., inline policies, managed policies, and session tags).”
This is a small announcement about an unglamorous constraint, and it is worth attention because of how that constraint fails. A session token that grows too large does not degrade — it breaks the call, in a component that usually has no idea what a session tag is. Federation with many attributes, role chaining, an ABAC model that tags generously: all of them spend from a budget that, until now, you could not read.
Two things come with the consolidation. STS now returns “response elements indicating session token size and percentage utilization relative to the token size limit”, logged in CloudTrail and published to CloudWatch. And there is an opt-in fault-injection parameter: “a new optional API parameter also lets you generate larger session tokens (up to the 4,096-byte limit) to test whether your applications and infrastructure can handle them.”
What changed
Three things, and only the first is the headline.
One limit instead of several. A single 4,096-byte ceiling on the session token, rather than a token limit plus separate allowances for what you passed in. Fewer numbers to reason about, and one number that can actually be measured.
Utilisation is now observable. Size and percentage-of-limit come back on the response, land in CloudTrail, and are published to CloudWatch. That converts a cliff into a gauge — you can see a session at 80% before you meet the one at 101%.
You can deliberately make it big. The optional parameter that generates an oversized token is the most unusual part of this release. AWS shipping a supported way to produce the bad case, so you can find out which proxy, SDK or gateway falls over, is a testing affordance that most limits never get.
Availability is broad from the start: all commercial Regions, GovCloud (US), and the European Sovereign Cloud Region.
Architecture
To know whether this matters to you, it helps to know what spends the budget.
Session tags. Up to 50 of them, with a tag key limit of 128 characters and a tag value limit of 256 characters. An ABAC model that passes department, cost centre, project and environment on every session is spending real budget on every call.
Session policies. “The size of the passed JSON policy document and all passed managed policy ARN characters combined can't exceed 2,048 characters”, with a maximum of 10 managed policy ARNs and exactly one JSON document. Note that the ARNs count as characters, so ten long ARNs consume the allowance before any policy is written.
And the console adds its own. A detail worth carrying: AWS recommends passing session policies via CLI or API because “the AWS Management Console might increase the session token size by adding session information.” The same role assumed two ways does not produce the same token size — which is exactly the sort of thing that makes this class of failure reproduce in one path and not another.
Business value
The value is diagnostic time on a failure that is genuinely horrible to debug.
An oversized session token does not announce itself as a size problem. It surfaces as a request rejected by a load balancer, a proxy returning 400 on a header it considers too large, or an SDK failing in a way that points at anything but STS. Teams lose days to this, because the thing that failed is not the thing that grew.
A percentage-of-limit figure in CloudTrail changes that from an investigation into a lookup. And for anyone rolling out ABAC or adding attributes to a federation, it converts “will this fit?” from a question answered in production into one answered before merge.
Security considerations
No permission boundary changes here, and it would be wrong to imply one. Nothing about who can assume what has moved.
The security-adjacent point is about what teams do when they hit the old limit. The usual workarounds are to drop session tags or to loosen a session policy — both of which weaken the controls those features exist to provide. ABAC depends on the tags arriving; a session policy is a least-privilege narrowing at assume time. Trimming them to fit a budget nobody could measure is a security decision made for a size reason, and a measurable budget lets that trade-off be made knowingly rather than by trial and error.
Worth noting the surrounding session settings while you are in this area: role session duration runs from 900 seconds up to a maximum of 12 hours, and “if you don't specify a value for the DurationSeconds parameter, your security credentials are valid for one hour.” Duration and size are independent budgets, and only one of them has just become visible.
Cost considerations
No pricing change is stated, and STS itself is not charged per call.
There is a modest indirect cost if you act on the new telemetry: these values are published to CloudWatch, and a custom metric or a CloudTrail-derived alarm on session token utilisation is billable like any other. That is a small, deliberate spend and an easy one to justify against the debugging time it replaces.
The adjacent quota worth knowing is the request rate rather than the size: “the default request quota is 600 requests per second, per account, per Region”, shared across AssumeRole, GetCallerIdentity, GetSessionToken and the rest. Size and rate are separate ceilings and are hit by different workloads.
Operational considerations
The deprecation is the action item, and it is not in the announcement. The IAM quota reference states it: “The PackedPolicySize response element is deprecated. Use SessionTokenUtilization instead.”
That matters more than a rename. PackedPolicySize reported the packed size of the policies you passed — a component of the problem, not the problem. SessionTokenUtilization reports the percentage of the actual token limit consumed, which is the number that decides whether the call works. Anything logging, alarming on, or asserting against the old element is reading a deprecated field that measured a different quantity.
Test with the new parameter before you need it. The ability to generate a deliberately large token is worth spending an afternoon on, because the failure lands outside AWS — in an ALB, an API gateway, a reverse proxy, a CI runner's environment size. Those are the components that will decide whether a future ABAC expansion is survivable, and none of them are covered by an AWS limit document.
Check the paths separately. Since the console may add to token size, a session that fits when assumed programmatically is not proof that the same role fits when assumed in the console. Test the path your users actually take.
Tradeoffs
Consolidation is simpler and slightly less forgiving. One 4,096-byte ceiling is far easier to reason about than a token limit plus separate parameter allowances. But a single shared budget means the components now compete directly: more session tags leaves less room for session policy, and the trade is explicit rather than absorbed by whichever sub-limit had slack.
Visibility invites a new alarm, which invites new noise. A utilisation metric is genuinely useful and will tempt a threshold alarm on every assume-role. Worth scoping to the sessions that actually vary — federated and ABAC-heavy paths — rather than every service-role assumption in the estate.
A test parameter is a capability like any other. Generating oversized tokens on purpose is exactly right in a test account and not something to leave reachable in production. It belongs behind the same controls as any other fault-injection tool.
Implementation guidance
Grep for PackedPolicySize first. It is the fastest audit available and it has a definite answer. Anywhere it appears — log parsers, dashboards, integration test assertions, a custom CloudWatch metric filter — is a place now reading a deprecated element.
Then measure your worst real session. Find the assume-role path with the most session tags and the largest session policy, and read the utilisation figure. That single number tells you how much headroom the estate has before an ABAC expansion becomes an outage.
Use the oversize parameter against your edge, not your code. The interesting failures are in the components between the client and AWS. Point the test at the real path — proxy, gateway, load balancer — because your own SDK almost certainly handles it fine.
Record the budget next to the ABAC design. If a tagging strategy is documented, note what it costs against 4,096 bytes. The next person adding two tags will otherwise discover the limit the same way the last one did.
Best practices
Pass session policies through the CLI or API. It is AWS's own recommendation, and the reason is size — the console may add session information of its own.
Treat managed policy ARNs as characters, not slots. The 2,048-character allowance covers the JSON document and every ARN together. Long ARNs with long paths are not free.
Measure before expanding, not after. The whole value of this release is that the answer is now available before the failure. Reading it only after an incident wastes the improvement.
Who should adopt this
The consolidated limit and the new response elements are already live everywhere, with nothing to enable.
The people who should act are narrower: anyone using session tags for ABAC, anyone passing session policies at assume time, anyone federating with an identity provider that carries many attributes, and anyone doing role chaining. If none of those apply, your session tokens are small, stable and uninteresting — and the only thing worth doing is the PackedPolicySize grep.
Key takeaways
- STS now enforces one 4,096-byte session token limit, replacing separate limits on the token and on passed-in parameters.
- Session token size and percentage utilisation are now returned on the response, logged in CloudTrail, and published to CloudWatch.
PackedPolicySizeis deprecated in favour ofSessionTokenUtilization— stated in the quota reference, not the announcement.- The two elements do not measure the same thing: one was packed policy size, the other is percentage of the token limit.
- An optional parameter generates deliberately oversized tokens so you can test the components that actually break — proxies, gateways, load balancers.
- Spending the budget: up to 50 session tags, and 2,048 characters covering the session policy document plus all 10 possible managed policy ARNs.
- The console may add to token size, so a programmatic assume-role is not proof the console path fits.
Comments