Amazon Web Services ブログ
AWS STS のセッショントークンのサイズ制限を簡素化、サイズのモニタリングにも対応
本ブログは 2026 年 9 月 15 日に公開された AWS Blog “AWS STS simplifies session token size limits and adds session token size monitoring” を翻訳したものです。
AWS Security Token Service (AWS STS) でセッショントークンのサイズ制限が簡素化され、セッションポリシーとセッションタグに使用できる容量が拡大しました。STS は、パックされたポリシー (packed policy) のサイズ制限とセッショントークン全体のサイズ制限を廃止し、4,096 バイトという単一のトークンサイズの制限に置き換えました。また、セッショントークンのサイズが API レスポンス、Amazon CloudWatch メトリクス、AWS CloudTrail イベントで報告されるようになりました。さらに、STS でさまざまなサイズのセッショントークンを生成できるため、インフラストラクチャがサポートできるトークンの最大サイズを確認できます。
4,096 バイトという制限は現時点での上限であり、恒久的なものではありません。セッショントークンにより多くの情報を含める必要がある新機能が追加されるのに伴い、AWS がこの制限を引き上げる可能性があります。
この記事では、変更点、この変更による影響、次に行うべきことについて説明します。
変更点
AWS STS のセッション発行 API (session-vending API) である AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity、GetSessionToken、GetFederationToken などは、一時的なセキュリティ認証情報 (アクセスキー ID、シークレットアクセスキー、セッショントークン) を返します。今回の変更の対象はセッショントークンです。セッショントークンとは、渡されたセッションポリシーとタグ、および AWS が追加するコンテキストを基に STS が作成する不透明な文字列です。
変更点は次の 3 つです。
- 単一の制限: 以前の STS は、セッショントークンに 2 つのサイズ制限を適用していました。STS はセッションポリシーとタグをシリアル化および圧縮して、パックされたポリシーと呼ばれる形式に変換しており、これに独自の制限がありました。さらに、パックされたポリシーを含む組み立て後のトークンには、全体に対する別の制限がありました。リクエストはどちらの制限でも失敗する可能性があり、いずれの場合も同じ
PackedPolicyTooLargeExceptionが返されるため、どちらの制限を超えたのかを判断できませんでした。現在は単一の制限のみが適用され、組み立て後のセッショントークンを 4,096 バイト以内に収める必要があります。パックされたポリシーに対する個別の制限は、失敗の予測を難しくしていましたが、廃止されました。組み立て後のセッショントークンが制限を超えると、STS はPackedPolicyTooLargeExceptionを返します。STS は引き続き同じ例外を使用するため、既存のエラー処理コードは SDK を更新しなくてもそのまま動作します。 - セッショントークンサイズの報告: STS のセッション発行 API から返されるすべての成功レスポンスに、
SessionTokenSize(セッショントークンのサイズをバイト単位で報告) とSessionTokenUtilization(4,096 バイトの制限に対する使用率を報告) が含まれるようになりました。また、STS は下位互換性のために、すべての成功レスポンスでPackedPolicySizeも返します。PackedPolicySizeは現在SessionTokenUtilizationと同じ値を報告するため、古いバージョンの AWS SDK を使用するアプリケーションでも、このフィールドで使用率をモニタリングできます。これらのレスポンスフィールドは CloudTrail イベントにも記録されます。CloudWatch では、SessionTokenSizeとSessionTokenMaxSize(適用される制限) が AWS/STS 名前空間に発行されます。 - テストの簡素化:
MinimumSessionTokenSizeは、STS のセッション発行 API に新しく追加されたオプションのパラメータです。このパラメータを使用すると、セッショントークンを指定したサイズ以上 (最大 4,096 バイト) に増やすことができます。インフラストラクチャが処理できるトークンの最大サイズを確認する際に使用してください。
| 動作 | 以前 | 現在 |
| 適用される制限 | 2 つ: パックされたポリシーのサイズと組み立て後のトークンのサイズ | 1 つ: 組み立て後のセッショントークンのサイズ (4,096 バイト) |
| 失敗時のエラー | PackedPolicyTooLargeException: エラーメッセージには、2 つの制限のうちどちらを超えたのかが示されませんでした。 |
PackedPolicyTooLargeException: 更新されたメッセージには、セッショントークンのサイズと許容される最大サイズがバイト単位で示されます。 |
| セッショントークンサイズの可視性 | 報告なし |
API レスポンスと AWS CloudTrail
Amazon CloudWatch
|
| インフラストラクチャのテスト | 仕組みなし | MinimumSessionTokenSize: セッション発行 API のパラメータ |
この変更による影響
影響はお客様の状況によって異なります。代表的なケースは次のとおりです。
- トークンサイズのエラーが発生したことがない場合: 変化に気付くことはほとんどないでしょう。トークンのサイズは現在のままで、制限までの余裕が広がります。ただし、時間の経過とともに、トークンがこれまでシステムで処理してきたサイズよりも大きくなる可能性があります。
MinimumSessionTokenSizeを使用して、システムで処理できるトークンの最大サイズを確認することをお勧めします。詳細については、「次に行うべきこと」セクションを参照してください。 - 以前に
PackedPolicyTooLargeExceptionが発生したことがある場合: 制限が一本化されたことで、以前は失敗していた一部のリクエストが成功するようになります。トークンサイズのエラーを避ける目的で導入した回避策を見直し、引き続き必要かどうかを判断してください。一般的なベストプラクティスは引き続き有効です。タグの大文字と小文字を統一し、タグ値を再利用すると圧縮効率が高まります。また、セッションポリシーを簡潔にすると、組み立て後のトークンを小さく抑えられます。エラー処理のためのコード変更は不要です。組み立て後のセッショントークンが制限を超えた場合、AWS STS は引き続きPackedPolicyTooLargeExceptionを返します。これは、今回の変更前に STS が返していたものと同じ例外です。 - 独自に認証情報のサイズ制限を適用しているシステムがある場合: アプリケーションが AWS SDK を使用して一時的な認証情報を取得し、AWS の API コールを行う場合は、SDK がセッショントークンを内部で処理するため、トークンサイズがコードに影響することはありません。注意が必要なのは、ロードバランサー、プロキシ、キャッシュ、データベースなど、セッショントークンを保存または転送するシステムです。これらのシステムには、これまでの小さなトークンでは抵触しなかったサイズ制限が設けられている可能性があります。例えば、
varchar(2048)として定義されたデータベース列には、4,096 バイトのトークンを格納できません。セッショントークンを永続化または受け渡ししている箇所を確認し、各システムがサポートするトークンの最大サイズを特定してください。テスト方法については次のセクションで説明します。
次に行うべきこと
この変更に向けてシステムを準備するために、次の 3 つのステップを実施することをお勧めします。
- システムで処理できるトークンの最大サイズを検証する。
MinimumSessionTokenSizeを使用して、インフラストラクチャ内の各システムで処理できるセッショントークンの最大サイズを確認します。これらの制限を把握しておくと、大きなトークンを拒否したり切り捨てたりする可能性のあるシステムを特定できます。4,096 バイトという制限は現在のニーズを反映したものであり、恒久的な上限ではありません。新しいサービス向けの追加のコンテキストキー、より充実した監査メタデータ、業界のポスト量子アルゴリズムへの移行に伴うより大きな暗号署名など、AWS が新機能を導入するにつれて、この制限が引き上げられる可能性があります。現在の最大値をシステムにハードコーディングすることは避け、制限が変更された場合は、固定サイズを前提としている箇所を見直してください。
ヒント: AWS STS はトークンを組み立てる際に、セッションポリシーとタグをシリアル化および圧縮します。圧縮結果は、長さだけでなく実際の内容によって変わります。文字数が同じ 2 つのタグセットでも、生成されるトークンのサイズが異なる場合があります。そのため、入力の長さから推定するよりも、
MinimumSessionTokenSizeを使用する方がインフラストラクチャを確実にテストできます。まずは、最大サイズのトークンでテストできるように 4,096 バイトを指定します。システムがトークンを切り捨てたり拒否したりする場合は、値を下げてインフラストラクチャがサポートするサイズを特定し、可能であればそのシステムの制限を引き上げます。
MinimumSessionTokenSizeは、AWS SDK、AWS コマンドラインインターフェイス (AWS CLI)、Tools for PowerShell の最新バージョンで利用できます。詳細については、「STS API リファレンス」を参照してください。使用中の AWS SDK または AWS CLI がこのパラメータに対応していない場合は、更新してからこの機能を使用してください。 - セッショントークンのサイズをモニタリングする (推奨)。インフラストラクチャにサイズの制約がある場合は、モニタリングによってその制限に近づいているトークンを把握し、リクエストが失敗する前に対処できます。AWS STS は 3 つのチャネルでサイズを報告しており、それぞれ異なる用途に適しています。
- API レスポンス: レスポンスから
SessionTokenUtilizationとSessionTokenSizeを読み取るには、最新バージョンの AWS SDK が必要です。なお、CloudWatch と CloudTrail を使用すれば、SDK を更新しなくてもトークンサイズをモニタリングできます。
- CloudWatch: STS は、
SessionTokenSizeとSessionTokenMaxSizeをAWS/STS名前空間に発行します。これらのメトリクスを使用して、ダッシュボードを作成したり、アラームを設定したりできます。アラームのしきい値は、4,096 バイトの最大値ではなく、テストで特定したサイズ制限に基づいて設定してください。最大値はすべてのアカウントで共通のため、重要なのはお客様のインフラストラクチャ固有の制限です。
次の図は、CloudWatch コンソールで
SessionTokenMaxSizeとSessionTokenSizeのメトリクスをグラフ表示した例です。
図 1: CloudWatch コンソールの SessionTokenMaxSize および SessionTokenSize メトリクス
- CloudTrail: STS の各セッション発行イベントには、成功したコールについて
SessionTokenUtilizationとSessionTokenSizeが記録されます。
- API レスポンス: レスポンスから
- セッショントークンの使用率のモニタリングに適切なフィールドを使用する。AWS STS は下位互換性のために、セッション発行 API のレスポンスと CloudTrail のレコードで引き続き
PackedPolicySizeを返します。このフィールドは現在、SessionTokenUtilizationと同じ値 (4,096 バイトのセッショントークンサイズの制限に対してトークンが占める割合) を報告します。そのため、トークンの内容が変わっていなくても、PackedPolicySizeの値が以前より低く表示される場合があります。SDK で
SessionTokenUtilizationが公開されている場合は、フィールド名が値の現在の意味と一致しているため、こちらを使用してください。古い SDK でSessionTokenUtilizationが公開されていない場合は、PackedPolicySizeを使用すれば、SDK を更新せずに同じ使用率をモニタリングできます。バイト単位のトークンサイズについては、SessionTokenSizeをモニタリングすることをお勧めします。
まとめ
AWS のセッションで、セッションタグ、タグ値、セッションポリシーに使用できる容量が拡大しました。AWS STS は 4,096 バイトという単一のセッショントークンの制限を適用し、トークンが制限を超えた場合にはよりわかりやすいエラーメッセージを返します。また、トークンサイズが報告されるため、サイズの増加を早い段階で把握できます。MinimumSessionTokenSize でトークンを処理するシステムを検証し、SessionTokenUtilization と SessionTokenSize をモニタリングして、継続的に状況を把握してください。
参考資料
本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。