What Fills an AWS STS Session Token - Session Policies, Session Tags, the Single Size Limit, and How to Measure and Test It

First Published: 2026-09-30
Last Updated: 2026-09-30

The temporary credentials returned by AWS STS operations like AssumeRole consist of three components: the access key ID, secret access key, and the session token. The session token is a string created by STS, combining the context added by AWS with the Session Policy and session tags provided by the caller. On September 15, 2026, AWS modified how it handles the size of these tokens. AWS consolidated the two previous size limits into one and began reporting the token size in API responses, CloudTrail, and CloudWatch. A new parameter was also added to allow testing the issuance of larger tokens.

Designers passing Session Policy and session tags, and those responsible for systems that store or forward session tokens, likely want to know three things: Are the workarounds implemented to avoid PackedPolicyTooLarge still necessary? Should monitoring based on PackedPolicySize remain unchanged? Can their systems that store or forward tokens handle the largest possible token size?

The information needed to answer these questions can all be found in AWS documentation. However, the information is spread across various sources, including the AWS Security Blog, What's New, STS API Reference, IAM User Guide, two articles on AWS re:Post, and the Amazon EKS documentation. There are also inconsistencies in how the information is presented across these sources. This article will compile the information, outlining what is included in the token, what changed on September 15, 2026, where to measure the size, where potential issues can arise, and how to test. This article focuses solely on the size of the token. It will not address how Session Policy is evaluated or how session tags can be used in attribute-based access control (ABAC). It will also not attempt to create formulas to estimate token size based on input.

Related articles on this site:

1. The Scope of This Article and the Date It Was Verified
2. What Goes Into a Session Token
3. What Changed on September 15, 2026
4. The Signal Table — What Drives the Size and What Reports It
5. Three Places to Measure the Size
6. Testing with MinimumSessionTokenSize
7. Where Things Break — The Systems That Carry the Token
8. Reviewing Workarounds
9. Frequently Asked Questions about Session Token Size
10. Summary
11. References

1. The Scope of This Article and the Date It Was Verified

This section confirms when and in which sources the change appeared, and states the verification date and the scope of availability. It then outlines what this article does not cover.

1.1 Dates and Sources of the Change

The dates in the following table indicate when the Internet Archive recorded the STS API Reference, when versions of the AWS CLI were released, when the AWS Security Blog was published, and when the What's New post was published.

Date	Source	Relevant to this Article
September 10, 2026	STS API Reference (Internet Archive)	Version containing previous descriptions. Contains outdated descriptions for `PackedPolicySize` and the error `PackedPolicyTooLarge`. This article compares this version with the version from September 28, 2026, in sections 3.2 and 3.3.
September 14, 2026	AWS CLI v2 changelog (2.36.45)	Update to the STS API model. This version of the CLI (section 6.4) includes the new parameter `MinimumSessionTokenSize`.
September 15, 2026	AWS Security Blog, What's New	Announcement of the changes. The Security Blog presents the changes before and after, outlining three recommended steps.

What's New describes the changes as follows:

AWS Security Token Service (STS) now enforces a single 4,096-byte size limit on session tokens. Previously, STS enforced separate limits on session token size and passed-in parameters (i.e., inline policies, managed policies, and session tags). STS has removed that separation, providing more flexibility for larger combinations of session policies and session tags.

1.2 Verification Date and Availability

The information in this article was verified against AWS documentation on September 28, 2026. What's New states the following regarding availability:

These capabilities are available in all commercial AWS Regions, the AWS GovCloud (US) Regions, and the AWS European Sovereign Cloud Region.

The China Regions are not listed.

The AWS Security Blog clarifies the following regarding the value of 4,096 bytes:

The 4,096-byte limit is the current maximum, not a permanent ceiling. AWS might increase the limit as new capabilities are added that require session tokens to carry more information.

The 4,096-byte limit mentioned in this article is a maximum value as of September 28, 2026. Section 7.3 discusses AWS's recommendation against hard-coding this value.

1.3 Items Not Covered

This article does not address the following:

Evaluation of Session Policy. IAM Policy Evaluation Logic Step-by-Step covers how a role's identity-based policies and Session Policy combine.
Use cases for session tags and ABAC design. Amazon EKS Pod Identity and IRSA Decision Guide explains the meaning of tags for Amazon EKS Pod Identity, and AWS SaaS Multi-Tenant Architecture Guide discusses tags used for tenant isolation.
Federation configuration. AWS IAM Inbound Workload Federation covers integration via OIDC for workloads and trust policies for IAM Roles Anywhere. The Pass session tags in AWS STS page in the IAM User Guide documents passing session tags from SAML or OIDC identity providers.
Tokens that AWS issues for outbound federation. The JSON Web Token issued by GetWebIdentityToken is a separate token from session tokens. AWS IAM Outbound Identity Federation covers that token.
Compression mechanisms and token size estimation. The AWS sources this article read do not describe the compression method. Section 2.5 explains why this article provides no estimates.

2. What Goes Into a Session Token

This section lists the components of a session token that AWS documentation names, differentiating between those provided by the caller and those added by AWS. Figure 1 shows how STS assembles the components and checks the result against the limit.

2.1 Items Provided by the Caller

The AWS Security Blog describes the session token that the change governs as follows:

This change governs the session token, the opaque string that STS creates from the session policies and tags you pass plus the context that AWS adds.

The AWS re:Post error article (How do I resolve the "PackedPolicyTooLarge" error when I assume an IAM role through AWS STS?) lists three items that the caller provides when assuming a role: inline Session Policy, the ARN of a managed policy, and session tags. The STS API Reference indicates that these correspond to the following parameters, respectively:

Item	Parameter (for `AssumeRole`)	Other Ways to Pass It
Inline Session Policy	`Policy`	—
Managed Session Policy	`PolicyArns`	—
Session tags	`Tags`	SAML's `PrincipalTag` attribute, OIDC token claims (IAM User Guide)
Transitive tag keys	`TransitiveTagKeys`	SAML's `TransitiveTagKeys` attribute, OIDC token claims (IAM User Guide)

The specific operation that accepts each item varies. The STS API Reference lists AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, and GetFederationToken as operations that accept Policy and PolicyArns. Neither GetSessionToken nor AssumeRoot accepts either of these (AssumeRoot instead requires TaskPolicyArn, which names one of the AWS managed policies that scope the session). The IAM User Guide lists AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, and GetFederationToken as operations that can accept session tags, noting that session tags cannot be passed when switching roles in the AWS Management Console.

The caller is not necessarily a person or application. Amazon EKS Pod Identity, for example, applies predetermined tags when assuming a role. The EKS API Reference states that it applies six tags by default. In this case, it is EKS Pod Identity, not the application, that determines which tags are included in the token.

2.2 Relationship Between Plaintext Limits and Token Limits

The values passed by the caller have individual plaintext limits. The STS API Reference and the IAM User Guide specify the following limits:

Item	Plaintext Limit
Number of session tags	50
Length of session tag keys	128 characters
Length of session tag values	256 characters
Total plaintext length for inline and managed Session Policy	2,048 characters
Number of ARNs for managed Session Policy	10

Even when all plaintext limits are adhered to, the token limit may still be exceeded. The STS API Reference describes the PackedPolicyTooLarge error as follows:

You might receive this error even though you meet the individual session policy and session tag limits. Monitor SessionTokenUtilization to track how close the session token is to the maximum allowed size.

The IAM User Guide, on the Request temporary security credentials page, also describes this relationship:

Session policies and session tags add to the session token size. If the token exceeds the size limit, your request fails, even if your plaintext is within the other limits.

Plaintext limits apply to each individual input, while the token limit applies to the assembled result. These are two separate checks.

2.3 Transitive Tags

Transitive tags are session tags that are passed to the next session when roles are chained together. The STS API Reference describes TransitiveTagKeys as follows:

If you set a tag key as transitive, the corresponding key and value passes to subsequent sessions in a role chain.

If you choose not to specify a transitive tag key, then no tags are passed from this session to any subsequent sessions.

When you call AssumeRole with temporary credentials, the new session inherits the transitive tags from the session that initiated the call. The STS API Reference, in its description of Tags, states that passing a session tag with the same key as an inherited tag will result in an operation failure. The IAM User Guide states that session tags cannot be made transitive with GetFederationToken.

The STS API Reference states that making a session tag transitive does not change the tag's size. The following sentence in the description of TransitiveTagKeys states this:

The transitive status of a session tag does not impact its packed binary size.

This sentence retains the terminology from before the change (packed binary), even after the modification on September 15, 2026. The documentation reviewed did not specify how transitive tags, inherited through a chain, are factored into the size of the token for the subsequent session. This article searched for the terms inherited, transitive, role chain, and size across the STS API Reference's six operations pages, the IAM User Guide's Pass session tags in AWS STS page, the AWS Security Blog post, and the two re:Post articles. This article does not estimate this point.

2.4 Additions from AWS

The AWS Security Blog names the context that AWS adds as one of the token's ingredients. While the specific details of this context aren't listed in the same article, the IAM User Guide pages that this article read mention two factors, in addition to the caller's input, that can affect the token's size.

The first is the AWS Management Console. The IAM User Guide page titled IAM and AWS STS quotas states the following regarding Session Policy:

We recommend that you pass session policies using the AWS CLI or AWS API. The AWS Management Console might increase the session token size by adding session information.

The second factor is whether the token is valid in all Regions. The IAM User Guide page titled Manage AWS STS in an AWS Region states that the global endpoint (https://sts.amazonaws.com) issues version 1 and version 2 tokens, and states the following about version 2:

Version 2 tokens are valid in all Regions. However, version 2 tokens include more characters and might affect systems where you temporarily store tokens.

The same page also states that session tokens from Regional AWS STS endpoints are valid in all AWS Regions, and that tokens valid in all Regions include more characters than tokens valid only in the Regions enabled by default. Neither the AWS Security Blog nor What's New, which describe the changes effective September 15, 2026, mentions these details. These statements in the IAM User Guide indicate that even with the same caller's input, the token size can vary depending on whether the operation is performed through the console and on whether the token is valid in all Regions (a Regional endpoint, or a global endpoint set to issue version 2 tokens). Section 7 discusses the implications for systems that store tokens.

2.5 Why This Article Does Not Estimate Token Size Based on Input Length

The AWS Security Blog states that STS serializes and compresses tags and Session Policy together, and notes the following.

Tip: AWS STS serializes and compresses your session policies and tags when assembling the token. Compression results vary based on the actual content, not just its length. Two sets of tags with identical character counts can produce different token sizes. This is why MinimumSessionTokenSize is a more reliable way to test your infrastructure than estimating from input length.

The re:Post error article also states:

AWS STS serializes and compresses session tokens, so you can't determine the exact assembled token size before you make the AssumeRole API call.

The size of a token can vary depending on its content, even if the character count is the same. According to AWS documentation, the exact size cannot be determined before the call is made. Therefore, this article does not include tables that estimate the number of bytes for a token based on the number of tags, nor does it provide formulas for estimation. The actual size is known after the call is made, as reported by STS (section 5). You can test the maximum size your system can handle using the MinimumSessionTokenSize parameter (section 6).

3. What Changed on September 15, 2026

This section compares the state before and after the changes. The AWS Security Blog outlines three key changes: the number of limits, size reporting, and the means of testing. This article will focus specifically on the change in the meaning of PackedPolicySize within size reporting, presenting it as a separate item. This is because this item is particularly relevant to existing monitoring systems.

3.1 Before and After the Change

The following table, based on the AWS Security Blog, outlines the state of the system before and after the change. The column labeled Previously refers to the period before September 15, 2026, while Now refers to the period on or after that date.

Behavior	Previously	Now
Number of Limits	Two: one for the maximum size of packed policies, and another for the maximum size of the assembled token as a whole.	One: the maximum size of the assembled session token (4,096 bytes).
Error Message on Failure	`PackedPolicyTooLargeException`. The message did not indicate which limit had been exceeded.	`PackedPolicyTooLargeException`. The message reports both the token size and the limit size, in bytes.
Token Size Reporting	No reporting (`PackedPolicySize` reported only the packed policy percentage; section 3.3).	API responses and CloudTrail report `SessionTokenSize`, `SessionTokenUtilization`, and `PackedPolicySize`. `PackedPolicySize` returns the same percentage as `SessionTokenUtilization` for backward compatibility (sections 3.3 and 3.4). CloudWatch reports `SessionTokenSize` and `SessionTokenMaxSize`.
Testing Methods	None.	Parameter `MinimumSessionTokenSize`.

The AWS Security Blog describes the two previous limits as follows:

A single limit: Previously, STS enforced two size limits on the session token. It serialized and compressed your session policies and tags into a form called the packed policy, which had its own limit. The assembled token, which included the packed policy, had a separate overall limit. A request could fail against either limit, and both failures returned the same PackedPolicyTooLargeException, so you couldn’t tell which one you exceeded. STS now enforces a single limit: the assembled session token must fit within 4,096 bytes. The separate packed policy limit, which made failures hard to predict, has been removed.

The exact size, in bytes, of each of the two previous limits is not documented in the sources this article read. This article does not provide estimates of those previous values.

These limits in the table refer to the maximum size of the token. The plaintext limits in section 2.2 (number of tags, character count for keys and values, character count for Session Policy, number of ARNs) – as of September 28, 2026 – remain in the STS API Reference and are checked separately from the token size limits.

3.2 Same Exception Name, New Message

Even after September 15, 2026, the exception name used when the limit is exceeded does not change. As noted in the AWS Security Blog:

When a token exceeds the assembled session token limit, STS returns PackedPolicyTooLargeException. STS continues to use the same exception, so existing error-handling code works without an SDK update.

The way the name is written varies depending on the documentation. The STS API Reference lists the error as PackedPolicyTooLarge, while the AWS Security Blog refers to it as PackedPolicyTooLargeException when describing the exception name in the SDK. Both refer to the same error.

What has changed is the message. The STS API Reference page for AssumeRole, as archived by the Internet Archive on September 10, 2026, described this error as follows:

The request was rejected because the total packed size of the session policies and session tags combined was too large. An AWS conversion compresses the session policy document, session policy ARNs, and session tags into a packed binary format that has a separate limit. The error message indicates by percentage how close the policies and tags are to the upper size limit.

As of September 28, 2026, the same page describes it in the following way:

The request was rejected because the session token exceeded the maximum allowed size. The error message reports the session token size and the maximum allowed size, both in bytes. Session policies and session tags add to the session token size.

The message prior to September 15, 2026, indicated a percentage, while the message on or after September 15, 2026, specifies the token size and limit in bytes. Error handling based on the exception name will continue to function as is. However, if your code processes the message string and extracts a percentage, that processing will need to be updated.

3.3 Change in Meaning of PackedPolicySize

The value that PackedPolicySize refers to has changed, despite the name remaining the same. The STS API Reference recorded on September 10, 2026, described this response element as follows:

A percentage value that indicates the packed size of the session policies and session tags combined passed in the request. The request fails if the packed size is greater than 100 percent, which means the policies and tags exceeded the allowed space.

As of September 28, 2026, the same page describes it as follows:

The percentage (0-100) of the maximum allowed session token size that the returned session token consumes.

This field is deprecated. Use SessionTokenUtilization instead.

Prior to September 15, 2026, PackedPolicySize represented the proportion of the packed policy and tags relative to the maximum size of the packed policy. As of September 15, 2026, PackedPolicySize is the proportion of the entire token relative to the maximum token size, and it has the same value as SessionTokenUtilization. The AWS Security Blog describes how this change might appear in monitoring as follows:

The field now reports the same value as SessionTokenUtilization: the percentage of the 4,096-byte session token size limit consumed by the token. As a result, PackedPolicySize values might appear lower even when your token content has not changed.

Even without changing the contents of the token, the value of PackedPolicySize may appear to decrease. Alarms configured with thresholds based on the previous value of PackedPolicySize will, if using the same threshold, now be monitoring a different quantity. Section 5.4 discusses which items to monitor.

3.4 How the Sources Word the Change Differently

The sources describing the change use slightly different wording to explain the same change. This article will present the information as it appears in each source, without consolidating it into a single version.

Issue	Source	Wording
What changed?	AWS Security Blog	Replaced the separate limits for packed policy size and total token size with a single limit of 4,096 bytes.
What changed?	What's New	Previously, there were separate limits for token size and the parameters passed. This separation has been removed.
What changed?	AWS CLI v2 changelog (2.36.45)	Increased the maximum session token size to 4,096 bytes and removed the limit for packed policy size.
Affected operations	AWS Security Blog	Examples include `AssumeRole`, `AssumeRoleWithSAML`, `AssumeRoleWithWebIdentity`, `GetSessionToken`, and `GetFederationToken`.
Affected operations	re:Post validation article, STS API Reference	Six operations – the five above plus `AssumeRoot` – now include `MinimumSessionTokenSize`.
Operations that return `PackedPolicySize`	AWS Security Blog	Returned in every successful response.
Operations that return `PackedPolicySize`	STS API Reference	Found in the response elements for `AssumeRole`, `AssumeRoleWithSAML`, `AssumeRoleWithWebIdentity`, and `GetFederationToken`. Not present in the response elements for `GetSessionToken` and `AssumeRoot`.
Handling of `PackedPolicySize`	AWS Security Blog	Returned for backward compatibility. Older SDKs can use this field to monitor utilization.
Handling of `PackedPolicySize`	STS API Reference, IAM User Guide, AWS CLI v2 changelog	Deprecated.
Handling of `PackedPolicySize`	AWS CLI v2 command reference (`assume-role`, as of September 28, 2026)	Still defined as the percentage of the packed size. It does not state that the field is deprecated.
Token size	IAM User Guide (`Request temporary security credentials`)	The typical token size is less than 4096 bytes, but this can vary.
Token size	STS API Reference (`Credentials` note)	The size is not fixed. AWS strongly recommends not assuming a maximum size.

According to the STS API Reference, certain operations do not return PackedPolicySize. The reference does not give a reason. GetSessionToken and AssumeRoot are also the operations that do not accept Session Policy (as described in section 2.1). When determining the size in these two operations, use SessionTokenSize and SessionTokenUtilization instead.

The STS API Reference also lists another operation that returns temporary credentials. GetDelegatedAccessToken is an operation that exchanges a trade-in token for temporary credentials. According to the STS API Reference, this operation does not have a MinimumSessionTokenSize, and the response elements do not include SessionTokenSize or SessionTokenUtilization. The documentation states that this operation does not populate the PackedPolicySize. However, the list of errors includes PackedPolicyTooLarge, which has the same description as for other operations.

Of the sources in the table above, only the AWS CLI changelog describes the change as an increase in the limit. None of the sources states how many bytes the overall token limit was before September 15, 2026. This article does not attempt to estimate the previous value based on this discrepancy.

4. The Signal Table — What Drives the Size and What Reports It

This article calls the clues that a call carries to AWS signals. This section presents a table listing the signals related to the content and size of session tokens. This website also uses the same five-column table in another article that addresses what calls carry to AWS (see section 3 of Agent Toolkit for AWS and the AWS MCP Server).

4.1 Reading the Table

The table has five columns:

Signal: This represents a condition key within a policy, a request parameter, or an item from an API response, error, CloudTrail record, or CloudWatch metric.
Who sets it: This indicates who assigns the signal – whether it's AWS or the caller.
Where a policy can test it: This specifies where the signal can be evaluated within an IAM policy. If a policy cannot evaluate the signal, it will state so.
When it is absent: This describes the scenario when the signal is not present. This is only included when documented in AWS documentation.
Where AWS says so: This references the AWS documentation that serves as the basis for the information in that row.

For any cell where AWS documentation does not provide information, the entry will read The source does not say. Before adding this entry, this article searched the full text of the sources the row cites and the pages those sources link to for keywords such as not present, absent, only when, not reported, no longer, except, and successful.

4.2 Signals Related to the Content and Size of Session Tokens

Signal	Who sets it	Where a policy can test it	When it is absent	Where AWS says so
Session tags (`aws:PrincipalTag/<key>`)	The caller. Passed via the `Tags` in `AssumeRole` and `GetFederationToken`, SAML attributes, and OIDC tokens. AWS services may also attach them as the caller, such as with EKS Pod Identity.	In the IAM policy's `Condition` (`aws:PrincipalTag`) for requests after the tags are passed. When passing, allow `sts:TagSession` (in the trust policy when assuming a role) and restrict with `aws:RequestTag` and `aws:TagKeys` in the `Condition`.	When the caller does not pass it and no transitive tags are inherited (row 2). The IAM User Guide states that session tags cannot be passed when switching roles in the console. The key `aws:PrincipalTag/<key>` is still present when the role itself has a tag with that key (IAM User Guide).	IAM User Guide, STS API Reference, EKS API Reference
Transitive Tag Keys (`TransitiveTagKeys`)	The caller. Specified in `AssumeRole`'s `TransitiveTagKeys`, SAML attributes, and OIDC tokens.	In the trust policy's `Condition` (`sts:TransitiveTagKeys`).	When not specified. The STS API Reference states that in this case, no tags are passed to the next session. However, in the IAM User Guide's role-chaining example, tags inherited as transitive tags from the previous session pass to the next session without being specified again. The IAM User Guide also states that session tags cannot be made transitive with `GetFederationToken`.	STS API Reference, IAM User Guide
Session Policy (`Policy`, `PolicyArns`)	The caller.	Not a policy condition key. Included in the evaluation as a policy to restrict session permissions.	When the caller does not pass it. `GetSessionToken` and `AssumeRoot` do not have this parameter.	STS API Reference
`MinimumSessionTokenSize`	The caller. For testing, it can be used to inflate the token to a specified size.	Not a policy condition key. There are no size-related keys in STS condition keys or global condition keys (section 4.3).	When 0 is specified, or when it is not specified. The STS API Reference states that in this case, the token size does not change.	STS API Reference, AWS re:Post validation article
Response `SessionTokenSize`	AWS (STS). In a successful response, it includes the token size in bytes.	Not a policy condition key.	In older SDKs, it cannot be read from the response. The AWS Security Blog states that the latest SDK is required to read this value from the response. The STS API Reference does not list it among the response elements of `GetDelegatedAccessToken` (section 3.4).	STS API Reference, AWS Security Blog (September 15, 2026)
Response `SessionTokenUtilization`	AWS (STS). In a successful response, it includes the percentage of the limit used (from 0 to 100).	Not a policy condition key.	In older SDKs, it cannot be read from the response. The AWS Security Blog states that the latest SDK is required to read this value from the response. The STS API Reference does not list it among the response elements of `GetDelegatedAccessToken` (section 3.4).	STS API Reference, AWS Security Blog (September 15, 2026)
Response `PackedPolicySize`	AWS (STS). Includes the same value as `SessionTokenUtilization`.	Not a policy condition key.	Responses of `GetSessionToken` and `AssumeRoot`. The STS API Reference does not list it among their response elements, and states that it is not populated for `GetDelegatedAccessToken` (section 3.4).	STS API Reference, AWS Security Blog (September 15, 2026)
CloudTrail `responseElements` `sessionTokenSize`, `sessionTokenUtilization`, `packedPolicySize`	AWS. Records the response values from STS operations.	Not a policy condition key. An item to use when searching logs.	The source does not say. The AWS Security Blog and the re:Post error article state that the values are recorded for successful calls.	AWS Security Blog (September 15, 2026), re:Post error article, IAM User Guide
CloudWatch `AWS/STS` namespace `SessionTokenSize` and `SessionTokenMaxSize` (dimension `EndpointType`)	AWS (STS). `SessionTokenMaxSize` is the limit that STS applies.	Not a policy condition key. An item to use with dashboards and alarms.	The source does not say.	AWS Security Blog (September 15, 2026), re:Post error article
Error message `PackedPolicyTooLarge`	AWS (STS). When the token exceeds the limit, it includes the token size and the limit size in bytes.	Not a policy condition key.	When the token falls within the limit.	STS API Reference, AWS Security Blog (September 15, 2026)

The fourth column on the eighth row indicates The source does not say. This is because the AWS Security Blog and the re:Post error article describe only successful calls and say nothing about failed calls. The fourth column on the ninth row indicates The source does not say. This is because the documentation explaining CloudWatch metrics consists of only two sources: the AWS Security Blog and the re:Post error article. Both of these lack information regarding instances where metrics are unavailable, or the possible values for EndpointType. As of September 28, 2026, AWS/STS was not listed in the Amazon CloudWatch User Guide's list of services that publish metrics. Furthermore, the table of contents in the IAM User Guide also lacked a section dedicated to STS metrics.

4.3 What Can Be Gleaned from the Table

The top four rows represent signals set by the caller; the first, third, and fourth rows influence the size of the token (for the second row, see section 2.3). The bottom six rows represent signals set by AWS, which indicate the token size.

There are no condition keys to inspect the token size. As of September 28, 2026, neither the Service Authorization Reference for STS nor the list of global condition keys in the IAM User Guide included any keys related to token size. STS rejects a token that exceeds the limit (PackedPolicyTooLarge) and reports the size of a successful one through the response, CloudTrail, and CloudWatch. Therefore, preparing for potential token size issues should be achieved through testing (section 6) and monitoring (section 5), rather than through policy configuration.

Among the factors that influence token size, some are not directly determined by the calling application. These include the session tags added by EKS Pod Identity (section 2.1), and the information added through the console or in tokens valid in all Regions (section 2.4). By examining the application's code alone, it is not possible to identify all factors that determine the token size.

5. Three Places to Measure the Size

This section discusses the three places where STS reports the size of tokens. The AWS Security Blog notes that these three paths serve different purposes. Figure 2 illustrates these three places and shows where the systems that receive and carry the token sit.

5.1 API Response

STS includes SessionTokenSize and SessionTokenUtilization in successful responses. The STS API Reference defines these two values as follows:

SessionTokenSize
The size, in bytes, of the session token returned in the Credentials for this response.

SessionTokenUtilization
The percentage (0-100) of the maximum allowed session token size that the returned session token consumes.

The AWS Security Blog provides the following JSON as an example of a response. The values in this example are from the AWS Security Blog and do not represent the values measured in this article.

{
  "Credentials": {
    "AccessKeyId": "REDACTED",
    "SecretAccessKey": "REDACTED",
    "SessionToken": "REDACTED",
    "Expiration": "2026-06-30T12:00:00Z"
  },
  "AssumedRoleUser": { "...": "..." },
  "PackedPolicySize": 61,
  "SessionTokenSize": 2532,
  "SessionTokenUtilization": 61
}

To read these two values from the response, a new SDK is required. The AWS Security Blog states:

In the API response: Reading SessionTokenUtilization and SessionTokenSize from the response requires the latest AWS SDK version. You can also monitor token size through CloudWatch and CloudTrail without updating your SDK.

The purpose of measuring these values in the response is to determine the size in real-time with each invocation. For example, this information can be used to verify the size before storing a token.

5.2 CloudTrail

CloudTrail logs STS operations by retaining the response values in the responseElements. The AWS Security Blog describes the logging in this way:

In CloudTrail: Each STS session-vending event records SessionTokenUtilization and SessionTokenSize for successful calls.

An example of a record from the same article is shown below. The following values are also shown as examples in the AWS Security Blog.

{
  "eventName": "AssumeRole",
  "responseElements": {
    "credentials": { "...": "..." },
    "assumedRoleUser": { "...": "..." },
    "packedPolicySize": 61,
    "sessionTokenUtilization": 61,
    "sessionTokenSize": 2532
  }
}

The calls for which the AWS Security Blog and the re:Post error article say CloudTrail records the size are successful calls. The size of calls that fail due to exceeding limits can be determined from the error message (see section 3.2). CloudTrail is useful when you need to investigate which role's sessions carry large tokens. In the example of an AssumeRoleWithSAML record shown in the IAM User Guide, the session tags passed appear in principalTags and transitiveTagKeys under requestParameters of the same record. This allows you to view the large token and the tags passed at that time in the same record.

5.3 CloudWatch AWS/STS Namespace

STS publishes SessionTokenSize and SessionTokenMaxSize to the CloudWatch AWS/STS namespace. The re:Post error article lists the dimension as follows:

AWS STS publishes SessionTokenSize and SessionTokenMaxSize metrics under the AWS/STS namespace with an EndpointType dimension in Amazon CloudWatch. Use these metrics to build dashboards and set alarms that fire before your tokens approach the size limit.

Base the alarm thresholds on the size your system can handle, rather than the 4,096-byte maximum. The AWS Security Blog states:

In CloudWatch: STS publishes SessionTokenSize and SessionTokenMaxSize in the AWS/STS namespace. Use them to build dashboards and set alarms. Set your alarm against the size limit you found during testing, not the 4,096-byte maximum. The maximum is the same for every account, so your own infrastructure limit is the one that matters.

Determine the size your system can handle by following the steps outlined in section 6. The AWS Security Blog describes SessionTokenMaxSize as the limit that STS enforces. This article reads this metric as a clue for noticing when AWS changes the limit.

This article does not specify the possible values for EndpointType, the units of the metrics, or the types of statistics. This is because AWS documentation detailing this information could not be found as of September 28, 2026. Verify these values by opening the metrics in your account's CloudWatch console.

5.4 Which Items to Monitor

The AWS Security Blog recommends the following items for monitoring:

If your SDK exposes SessionTokenUtilization, use that field because its name reflects the value’s current meaning. If an earlier SDK does not expose SessionTokenUtilization, use PackedPolicySize to monitor the same utilization percentage without updating the SDK. We recommend you monitor SessionTokenSize for the token size in bytes.

In summary:

Scenario	Items to Use
The SDK can read `SessionTokenUtilization`	`SessionTokenUtilization` (percentage) and `SessionTokenSize` (bytes)
The SDK is older and cannot read `SessionTokenUtilization`	`PackedPolicySize` (equivalent to `SessionTokenUtilization`). Alternatively, monitor using CloudTrail and CloudWatch without updating the SDK (the only option for `GetSessionToken` and `AssumeRoot`, which do not return `PackedPolicySize`).
Monitoring `PackedPolicySize` since before September 15, 2026	The meaning of the value has changed (see section 3.3). Re-evaluate the threshold or move to `SessionTokenUtilization`.

The AWS Security Blog recommends monitoring SessionTokenSize in terms of bytes. The percentage represents a value relative to the STS limit. Therefore, if AWS changes the limit, the percentage changes even for the same token. Your own system's limits are absolute sizes, not percentages of the STS limit, as the varchar(2048) example in section 7.2 shows.

6. Testing with MinimumSessionTokenSize

This section discusses the MinimumSessionTokenSize parameter, which allows you to test the generation of larger tokens. As mentioned earlier (section 2.5), the size of the tokens is not known in advance. Therefore, AWS recommends actually passing larger tokens through your systems rather than relying on estimates.

6.1 Parameter Definition and Available Operations

The STS API Reference defines MinimumSessionTokenSize as follows:

The minimum size, in bytes, of the session token that STS issues for the request. STS increases the session token to at least this size, regardless of its actual content. The value must not exceed 4,096 bytes. When set to 0 or not specified, the session token size is unchanged.

The data type is an integer, and the permissible values range from 0 to 4096. The STS API Reference lists the following six operations that utilize this parameter:

AssumeRole
AssumeRoleWithSAML
AssumeRoleWithWebIdentity
AssumeRoot
GetSessionToken
GetFederationToken

The re:Post validation article (How do I test my infrastructure against the AWS STS maximum session token size?) also lists these same six operations. Even with GetSessionToken and AssumeRoot, which do not accept Session Policy or session tags, it is possible to test with larger tokens.

6.2 Permissions Remain Unchanged

MinimumSessionTokenSize does not alter permissions. The re:Post validation article states:

Note: The MinimumSessionTokenSize parameter is for testing only. It doesn't grant additional permissions or change the security posture of the token.

The STS API Reference definition states that STS increases the token regardless of its actual content. As the re:Post article notes, setting this parameter will not grant any additional permissions through the token.

6.3 Procedure

The AWS Security Blog provides the following CLI example:

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name validation-test \
  --minimum-session-token-size 4096

Start with 4,096 bytes, and lower the value if a system cannot accept the token. As stated in the AWS Security Blog:

Start at 4,096 bytes to test against the largest possible token. If a system truncates or rejects it, lower the value to find the size your infrastructure supports, then raise that limit where you can.

The re:Post validation article outlines five steps for verification.

Set MinimumSessionTokenSize to 4096 and then invoke one of the six operations, such as AssumeRole.
Examine the SessionTokenSize in the response to confirm that it has reached the specified size.
Using the returned credentials, operate downstream systems (such as application servers, proxies, caches, or custom middleware) that will receive the token.
Verify that each system handles the token without truncation, errors, or unexpected behavior.
If any system fails, adjust its configuration to support tokens up to 4,096 bytes. The re:Post article provides examples of configuration adjustments, such as header buffer sizes, cache entry limits, and database column widths.

The two sources describe the steps to take in case of failure in slightly different ways. The re:Post validation article states that failing systems should be adjusted to support tokens up to 4,096 bytes. The AWS Security Blog suggests reducing the value until your system can successfully receive it, and, where possible, increasing the limits. If any systems remain unable to handle the full size, the smallest value found becomes the basis for the alarm threshold described in section 5.3. If different systems can handle different sizes, the smallest supported value is the maximum size that can be accommodated across the entire path.

6.4 Available CLI and SDK Versions

The AWS Security Blog states that the latest AWS SDK, AWS CLI, and AWS Tools for PowerShell support the MinimumSessionTokenSize parameter, and recommends updating older SDKs and CLIs. The AWS CLI v2 changelog, version 2.36.45, details this change.

``sts``: Increases the maximum session token size to 4,096 bytes and removes the packed policy size limit. Adds SessionTokenSize and SessionTokenUtilization fields and a new MinimumSessionTokenSize parameter. PackedPolicySize is deprecated.

If the AWS CLI v2 does not accept the --minimum-session-token-size parameter, verify that you are not using a version older than 2.36.45. Older, unsupported SDKs will not support this parameter or any new response elements. For example, the AWS SDK for Go v1 reached its end of support on July 31, 2025 (AWS Developer Tools Blog). For systems that run on such SDKs, check the size in CloudTrail and CloudWatch (section 5).

7. Where Things Break — The Systems That Carry the Token

This section discusses potential points of failure when tokens become large. The AWS Security Blog distinguishes between the side that is less likely to be affected and the side that should be verified.

7.1 Applications Whose SDK Handles the Token Internally

The AWS Security Blog discusses applications that obtain temporary credentials with the SDK and then use them to call AWS APIs with the SDK.

If your application uses an AWS SDK to obtain temporary credentials and make AWS API calls, the SDK handles the session token internally, so token size doesn’t affect your code.

This sentence addresses applications where both the acquisition and the API calls are handled entirely inside the SDK. If the application itself writes the token to a location, or passes it to another process or service, then those destinations fall under the scope of section 7.2.

7.2 Systems That Store or Forward Tokens

The AWS Security Blog states the side to check as follows:

Focus instead on systems that store or forward session tokens, such as load balancers, proxies, caches, and databases. These systems might have size limits that smaller tokens didn’t reach. For example, a database column defined as varchar(2048) can’t hold a 4,096-byte token. Review where you persist or pass session tokens, and identify the maximum token size each system supports.

Systems that carry tokens may have handled only small tokens so far, so they may not have encountered their limits. However, since September 15, 2026, the separate limit on the packed policy has been removed. As a result, combinations like Session Policy and tags, which previously might have been rejected with a PackedPolicyTooLarge error, may now succeed in creating larger tokens. The AWS Security Blog also notes that even users who have not previously encountered errors may see their tokens grow over time.

If you have never hit a token size error: You’re unlikely to notice a change. Your tokens stay their current size and gain headroom. Over time they could become larger than your systems have handled before.

Tokens are also carried with each request sent to AWS. The IAM User Guide's page on Create a signed AWS API request indicates that when signing requests with temporary credentials, the session token must be included in the header or query string as X-Amz-Security-Token. Proxies and load balancers along the request path are among the systems the AWS Security Blog says to check. The re:Post validation article also lists header buffer size as an example of a setting that needs adjustment.

According to the IAM User Guide, the version 2 tokens described in section 2.4 may also affect systems where tokens are temporarily stored.

7.3 Avoid Hard-Coding the Current Limit

The AWS Security Blog recommends against hard-coding a fixed value of 4,096 bytes.

The 4,096-byte limit reflects today’s needs, not a permanent ceiling. It might grow as AWS introduces new capabilities such as additional context keys for new services, richer audit metadata, and larger cryptographic signatures as the industry transitions to post-quantum algorithms. Avoid hard-coding the current maximum into your systems and revisit any fixed size assumptions if the limit changes.

The Credentials description in the STS API Reference also contains similar recommendations.

The size of the security token that AWS STS API operations return is not fixed. We strongly recommend that you make no assumptions about the maximum size.

Setting database column widths or buffer sizes precisely to 4,096 can lead to the same issues when the maximum limit is increased. Verifying whether the current maximum token limit can be accommodated, as outlined in section 6.3, and the implementation of a mechanism to detect changes in the limit are separate tasks. The SessionTokenMaxSize described in section 5.3 can be used for the latter.

8. Reviewing Workarounds

This section discusses how to handle workarounds implemented before September 15, 2026. While the AWS Security Blog recommends reviewing these workarounds, some cannot be removed for reasons other than size.

8.1 AWS's Advice

The AWS Security Blog advises users who have encountered a PackedPolicyTooLargeException as follows:

If you’ve hit PackedPolicyTooLargeException before: Some requests that previously failed now succeed under the single limit. Review any workarounds you put in place specifically to avoid token size errors and decide whether you still need them. General best practices still apply: consistent tag casing and reused tag values compress more efficiently, and concise session policies keep the assembled token smaller.

This advice has two qualifiers. The review covers workarounds put in place specifically to avoid token size errors. Furthermore, standard best practices still apply. It does not state that you should discontinue measures to keep tokens small.

8.2 Methods for Reducing Token Size and Their Purposes

The re:Post error article mentions several methods for reducing the size of the data passed, as of September 28, 2026. Rephrased in this article's words, these methods are as follows:

Target	Methods Listed in the re:Post Article
Session tags	Shorten keys and values, including only the information necessary for authorization decisions.
Session tags	Replace tags used for purposes other than ABAC (e.g., information for auditing) with references to external records.
Session tags	Use one consistent case, such as lowercase, for keys and values (this can improve compression).
Session tags	Move identification information to a separate `SourceIdentity` with its own limits.
Inline Session Policy	Remove the optional `Sid` elements.
Inline Session Policy	Use wildcards in action and resource ARNs within an appropriate scope.
Inline Session Policy	Pass the ARN of a managed policy instead of the policy document itself (this takes up less space in the token).
Inline Session Policy	Implement conditional permissions using session tags and role policies.

Some of these methods have effects beyond simply reducing token size. For example, moving identification information from session tags to SourceIdentity changes the condition key that policies inspect from aws:PrincipalTag/<key> to aws:SourceIdentity. The STS API Reference states that the value of SourceIdentity is maintained across chained role sessions. Wildcards can broaden the scope of permissions. Before removing any of these methods, verify whether the change was implemented solely to reduce token size, or if it served another purpose. The advice in the AWS Security Blog also limits the scope of review to workarounds implemented solely to avoid token size errors.

8.3 When EKS Pod Identity Session Tags Are Disabled

EKS Pod Identity includes a setting (disableSessionTags) that allows you to disable the automatically assigned session tags on a per-association basis. As of September 28, 2026, the EKS User Guide and the EKS API Reference state that the reason for this setting is as follows. The EKS console help also contains nearly identical wording.

AWS compresses inline session policies, managed policy ARNs, and session tags into a packed binary format that has a separate limit. If you receive a PackedPolicyTooLarge error indicating the packed binary format has exceeded the size limit, you can attempt to reduce the size by disabling the session tags added by EKS Pod Identity.

This explanation is based on the previous STS limit mechanism (a separate limit) that was in place before September 15, 2026. The AWS Security Blog states that this separate limit has been removed, and the current STS API Reference no longer describes it. As of the date of this article, it is unclear when and how the EKS documentation will reflect this change.

Furthermore, for associations with Session Policy, disabling tags is mandatory. The EKS API Reference describes the Session Policy (policy) that is applied to associations as follows.

Session tags: When using this policy, disableSessionTags must be set to true.

The AWS Containers Blog article, Session policies for Amazon EKS Pod Identity, explains the reason for this combination's limitations as being due to STS's limitations on the size of packed policies. Although the separate STS limit has been removed, this limitation remains in the EKS API as of September 28, 2026. The STS change alone does not make it possible to enable tags for associations with Session Policy.

To summarize, associations that have tags disabled within EKS Pod Identity fall into two categories:

Association	Reason for Disabling Tags	Review
Associations with Session Policy	This is a requirement of the EKS API.	The STS change does not make it removable.
Associations without Session Policy	This may have been to avoid size-related errors.	May be subject to recommendations in the AWS Security Blog. However, whether or not to enable tags is also a design decision based on whether you are using tags with ABAC.

Sections 7.3 and 7.4 of the Amazon EKS Pod Identity and IRSA Decision Guide discuss session tags and ABAC, and Session Policy, in EKS Pod Identity.

9. Frequently Asked Questions about Session Token Size

This section summarizes the main content in the form of questions and answers. The basis for each answer can be found in the corresponding section (indicated in parentheses).

Q1. Can the workaround that was implemented to avoid the PackedPolicyTooLarge error be removed now?

Whether you can remove the workaround depends on the specific workaround. The AWS Security Blog recommends reviewing workarounds implemented solely to avoid token size errors, while also noting that general best practices for keeping tokens small should still be followed. For EKS Pod Identity associations with a Session Policy, the STS change does not let you re-enable the disabled tags, because the EKS API requires the setting (see sections 8.1 and 8.3).

Q2. Should the monitoring system currently tracking PackedPolicySize remain unchanged?

Left as is, it measures a different quantity than before. As of September 15, 2026, PackedPolicySize returns the same value as SessionTokenUtilization. Even if the underlying content is the same, the displayed value may appear lower. If your SDK can read SessionTokenUtilization, migrate the monitoring to SessionTokenUtilization and SessionTokenSize. Otherwise, re-evaluate the threshold (see section 3.3 and section 5.4).

Q3. Is it possible to calculate the size of a token based on the number and length of the tags passed?

It's not possible to calculate it precisely. AWS documentation states that STS compresses policies and tags, and the resulting size is determined by the content rather than simply the length. Tags with the same number of characters can produce different token sizes. You learn the actual size by examining SessionTokenSize after the call (see section 2.5 and section 5.1).

Q4. Does setting MinimumSessionTokenSize change permissions or the limit?

No, it does not. The re:Post validation article states that this parameter is solely for testing purposes and does not add any new permissions or alter the security posture of the tokens. The STS API Reference states that the value must not exceed 4,096 bytes, and the token can be padded only up to that limit (see sections 6.1 and 6.2).

Q5. Are applications calling AWS through an SDK required to perform any verification?

If obtaining and calling AWS services can be completed entirely inside the SDK, the AWS Security Blog states that token size does not affect the application's code. However, if the application writes tokens to caches or databases, passes them through proxies, or forwards them to other services, those storage locations and pathways should be verified (see sections 7.1 and 7.2).

Q6. Does the error handling code need to be rewritten?

If the code branches based on exception names, no, it doesn't. The exception name, PackedPolicyTooLargeException, has not changed. However, if there is any processing that reads a percentage from the message string, it will need to be rewritten. The message now indicates the size of the token and the maximum size in bytes, rather than a percentage (see section 3.2).

Q7. What threshold should be set for CloudWatch alarms?

Base it on the maximum size your system can handle. The AWS Security Blog recommends aligning the threshold with the maximum size identified through testing, rather than the 4,096-byte maximum. Since the STS maximum is the same for every account, what matters is the maximum size your own system can support (see sections 5.3 and 6.3).

Q8. Is it safe to size database columns or buffers on the assumption of 4,096 bytes?

It's best not to. The AWS Security Blog states that 4,096 bytes is currently the maximum size, but not a permanent limit, and recommends against hard-coding the current maximum. The STS API Reference also strongly advises against assuming a maximum token size (see section 7.3).

10. Summary

As of September 15, 2026, STS consolidated the maximum size limits for session tokens to a single value. Previously, there were two limits: one for packed policies and one for the entire token. Since September 15, 2026, there is now a single maximum size limit for the entire session token (4,096 bytes as of September 28, 2026). Separate limits for the number of tags and the number of plaintext characters remain in effect (see sections 2.2 and 3.1).
The exception name remains the same, but the message has changed. The message now indicates the token size and maximum limit in bytes (see section 3.2).
The meaning of PackedPolicySize has changed, although the name remains the same. As of September 15, 2026, it returns the same value as SessionTokenUtilization and is deprecated in the STS API Reference (see section 3.3).
The actual size of a token cannot be accurately estimated based on the input length. The result of compression varies depending on the content (see section 2.5).
There is no condition key to inspect the size of a token. STS rejects a token over the limit and reports the size of a successful one in the API response, CloudTrail, and CloudWatch (see section 4.3 and section 5).
MinimumSessionTokenSize allows you to test with larger tokens. Permissions remain unchanged. You can start with 4,096 bytes and gradually decrease the size (see section 6).
The systems responsible for storing or forwarding the token are the ones that can break. For applications that handle token retrieval and calls inside the SDK, the AWS Security Blog states that token size does not affect their code (see section 7).
4,096 bytes is not a permanent maximum limit. Do not hard-code it; as a way to notice when it changes, this article suggests SessionTokenMaxSize (see section 7.3).
Before removing a workaround, check whether it was put in place only for size. For EKS Pod Identity associations with a Session Policy, the STS change does not let you re-enable the session tags (see section 8).

11. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi