Build1 publisher2 min readPublished
MinimumSessionTokenSize inflates an STS session token until your own stack refuses it
AWS collapsed two STS size limits into one 4,096-byte cap and now reports the assembled token's actual size in API responses, CloudWatch and CloudTrail, with a new parameter that pads tokens for testing.
The Engineer · Build desk
What happened
- STS has dropped the separate packed policy size limit and now enforces one rule: the assembled session token must fit within 4,096 bytes.
- CloudWatch's AWS/STS namespace publishes SessionTokenSize and SessionTokenMaxSize, the enforced limit, and the same response fields are recorded in CloudTrail events.
- A new optional parameter, MinimumSessionTokenSize, increases a session token to at least the size the caller specifies, up to the 4,096-byte maximum.
- Requests that exceed the single limit still fail with PackedPolicyTooLargeException, so existing error handling keeps working without an SDK update.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability A failing AssumeRole call becomes attributable: with one cap and a reported byte count, the tag or policy clause that pushed the token over can be identified. The old pair of limits sharing one exception prevented that.
- exposure Systems that have handled small tokens for years are the ones newly reachable by a size they have not seen, because AWS says tokens will gain headroom and can grow larger than those systems have handled.
- decision Teams that trimmed tags or split policies purely to dodge the old failures now have to decide whether those workarounds still pay for themselves, since AWS says some of those requests succeed.
- constraint Sizing a downstream field, cookie or column at exactly 4,096 bytes bets on a number AWS says it may raise as capabilities need tokens to carry more.
STS assembles the session token from three inputs: the session policies you pass, the session tags you pass, and context that AWS adds [5]. Policies and tags are serialized and compressed into the packed policy first, and the assembled token wraps that [6]. What comes back is an opaque string [5]. The caller's process cannot measure that string in advance, so the byte count in the response is the first place the number exists [7].
MinimumSessionTokenSize pads a token up to whatever size you ask for, capped at 4,096 bytes, and AWS's stated use for it is finding the largest token your systems can handle [11][17]. The test only finds something if your code handles the raw token. AWS says an application that uses an AWS SDK to obtain temporary credentials and call AWS APIs is unaffected, because the SDK handles the session token internally [16]. So the padded token is worth pointing at the places that copy the string out of the SDK: a proxy with a header size cap, a session cookie, a credentials column sized when tokens were smaller.
One response field deserves a look before anyone builds a dashboard on it. PackedPolicySize is still returned on every success, and it now carries the same value as SessionTokenUtilization, a percentage of the 4,096-byte limit; AWS describes that as backward compatibility for applications on older SDKs [8]. The field name says size; the value is a percentage. One percentage point is 40.96 bytes [1], so a threshold set on that field resolves token growth to roughly 41 bytes, while SessionTokenSize reports the exact count [7].
The post describes the two old limits without giving their values [18]. It does repeat the compression guidance, which is the part I would act on: consistent tag casing and reused tag values compress more efficiently, and concise session policies keep the assembled token smaller [15]. Under compression, tag bytes do not add up one for one. Reusing one value across several tags costs less than several distinct values of the same length.
If your team has never seen the exception, I would run a padded call before building a dashboard on the metric. AWS's own metrics tell you where you sit against AWS's limit [10]. The padded call is what tells you the size at which your stack returns an error.
What to watch
- Whether SessionTokenMaxSize in CloudWatch ever reports a number above 4,096. That would be the first observable sign the cap moved.
- Whether current AWS SDKs surface SessionTokenSize and SessionTokenUtilization as first-class response fields, so teams stop reading PackedPolicySize at all.
- Whether AWS documents which context fields it adds to the assembled token, since that share of the 4,096 bytes is outside the caller's control.