AWS STS でリージョナルエンドポイントの利用が推奨されるとはどういうことか

コンバンハ、千葉（幸）です。

AWS Security Token Service (STS) は、一時的な認証情報を提供するサービスです。

AWS STS に対して一時的な認証情報払い出しのリクエストを行う際、リクエスト先となる AWS サービスエンドポイントには以下の2種類があります。

• グローバルエンドポイント
• リージョナルエンドポイント

デフォルトでは前者のグローバルエンドポイントが使用されるものの、後者のリージョナルエンドポイントの利用を推奨する、という記述が各種ドキュメントにあります。

👇

デフォルトでは、AWS Security Token Service (AWS STS) は、グローバルなサービスと使用することができ、AWS STS リクエストはすべて、https://sts.amazonaws.com の単一エンドポイントに送信されます。AWS では、レイテンシーの低減、冗長性の構築、セッショントークンの有効性の強化のために、グローバルエンドポイントではなく、リージョンの AWS STS エンドポイントを使用することを推奨しています。

AWS リージョン での AWS STS の管理 - AWS Identity and Access Management

👇

By default, the AWS Security Token Service (AWS STS) is available as a global service, and all STS requests go to a single endpoint at https://sts.amazonaws.com. AWS recommends using Regional STS endpoints to reduce latency, build in redundancy, and increase session token validity.

AWS Security Token Service endpoints and quotas - AWS General Reference

👇

1. デフォルトのグローバルエンドポイントではなく、AWS STS リージョン別サービスエンドポイントを使用します。

AWS Identity and Access Management での耐障害性 - AWS Identity and Access Management

👇

レコメンデーション

リージョン STS エンドポイントを使用するように SDK と CLI の設定を更新してください。

グローバルサービス - AWS 障害分離境界

今回は、「そもそも AWS STS とは何か？」「グローバルエンドポイントとリージョナルエンドポイントは何が違うのか？」「なぜリージョナルエンドポイントの使用が推奨されるのか？」あたりを、少し整理してみます。

AWS STS とは

冒頭の繰り返しになりますが、AWS STS とは一時的な認証情報を提供するサービスです。単独のサービスとして認識されることは少なく、AWS IAM とセットで捉えられることが多いのではないでしょうか。

簡単に説明すると、以下のイメージです。

IAM ユーザー、AWS サービスなどのプリンシパル（リクエストの実行主体）は、AWS STS に対して認証情報取得のリクエストを行います。リクエストの実行先は、AWS STS のサービスエンドポイントです。

リクエストの種類（どんな認証情報を取得するか）はいくつかあります。もっとも馴染みが深いものはsts:AssumeRoleかと思います。

IAM ロールを指定し、「この IAM ロールに与えられた許可を一定期間使いたい」とリクエストを送ると、一定期間のみ有効な認証情報が返却されます。（もちろんプリンシパルに適切な許可が与えられていなければリクエストが失敗します。）

その一時的な認証情報を利用して任意の AWS サービスに対して API リクエストを実行することで、その IAM ロールを引き受けたプリンシパルとして振る舞えます。

AssumeRole以外の一時的な認証情報を取得するリクエストの種類は以下をご参照ください。

• 一時的なセキュリティ認証情報のリクエスト - AWS Identity and Access Management

AWS STS のサービスエンドポイント

リクエストの実行先となる AWS サービスエンドポイントには、以下2種類があります。

• グローバルエンドポイント：バージニアリージョンにのみ存在。レガシーな位置付け。
• リージョナルエンドポイント：各リージョンに存在

構成のイメージとしては以下です。

バージニア北部リージョンのみ、グローバルエンドポイントとリージョナルエンドポイントの2つを持ちます。それ以外のリージョンでは、そのリージョンでのリージョナルエンドポイントを持ちます。

プリンシパルはリクエストの実行先として上記のいずれも選択できます。

リージョナルエンドポイントは一部を除き個別に無効化もできます。また、香港リージョンなどの「リージョン自体の利用にオプトインが必要なリージョン」ではリージョン自体の有効化と共にリージョナルエンドポイントが有効化されます。オプトインリージョンでのリージョナルエンドポイントは無効化できません。

AWS STSのサービスエンドポイントの一覧については以下をご参照ください。

• AWS リージョン での AWS STS の管理 - AWS Identity and Access Management

AWS STS でリージョナルエンドポイントが推奨

冒頭で記載した通り、AWS STS ではリージョナルエンドポイントの利用が推奨されています。

観点としては、以下が挙げられています。

1. レイテンシーの低減
2. 冗長性の構築（障害影響の封じ込め）
3. セッショントークンの有用性の向上（オプトインリージョン向けの有効化が不要）

• AWS リージョン での AWS STS の管理 - AWS Identity and Access Management

これらのイメージは以下のとおりです。ここでは、東京リージョンでワークロードが稼働しており、東京リージョン内やその近郊のプリンシパルからリクエストがあるケースを想定します。

簡単に補足すると、以下のとおりです。

• ①レイテンシーの軽減
  • 単純な地理的な距離に関する話です
  • 東京リージョンもしくはその近郊からリクエストを実行することを考えると、バージニア北部リージョンにあるエンドポイントにリクエストを送るよりは東京リージョンのリージョナルエンドポイントに送る方がレイテンシーが軽減できます
• ②冗長性の構築（障害影響の封じ込め）
  • 障害発生時の影響を限定的にできます
  • 東京リージョンでワークロードが稼働していてグローバルエンドポイントを利用した場合、以下の障害が発生した場合、その影響を受けてしまいます
    • バージニア北部リージョンでの障害
    • 東京リージョン（および近郊）からバージニア部リージョンに至るまでのネットワークにおける障害
  • 東京リージョン自体で障害が起こったら、リージョナルエンドポイントを使っていても影響を受けます。ただし、東京リージョンというスコープに障害範囲がとどまることになります
    • 障害範囲が東京リージョンのリージョナルエンドポイントのみである、ということであれば別のリージョンのリージョナルエンドポイントに切り替える手段もあります
• ③セッショントークンの有用性の向上
  • グローバルエンドポイントから発行された認証情報は、デフォルトではオプトインリージョンを対象にしていません（セッショントークンが有効でない）
    • 別途、オプトインリージョンに対する互換性を変更する必要があります
  • リージョナルエンドポイントから発行される認証情報ではオプトインリージョンも含め全てのリージョンで有効です
  • （東京リージョンはオプトインリージョンではないので、今回の例ではあまり関係ありません）

なぜグローバルエンドポイントがあるの？

リージョナルエンドポイントの方がメリットが多く、利用が推奨されているということであれば、そもそもなぜグローバルエンドポイントがあるのか？というのが気になります。

そのあたりの背景は、以下のエントリを読むと伺い知れます。

https://aws.amazon.com/jp/blogs/security/how-to-use-regional-aws-sts-endpoints/

当初、AWS STSのサービスエンドポイントはグローバルエンドポイントのみが提供されていました。その後、より機能が拡充されたリージョナルエンドポイントの提供が開始されています。（具体的な開始時期は確認できませんでしたが、2015年9月にはドキュメント上で記述 がありました）

そして、AWS サービスはデフォルトでリージョナルエンドポイントを使用する、という記述があります。

By default, AWS services use Regional AWS STS endpoints.

AWS STS にリクエストを実行するプリンシパルには、AWS 利用者が関与できない AWS サービスプリンシパルも含まれます。そういった AWS サービスプリンシパルは、すでにデフォルトでリージョナルエンドポイントを利用しているということのようです。

逆に、AWS 利用者が関与できるプリンシパルからの実行においては、デフォルト動作の変更によるワークロードへの影響を避けるため、従来通りグローバルエンドポイントをデフォルトの参照先としているようです。

利用者の立場で気にする点は？

AWS 利用者である我々が AWS STS のサービスエンドポイントを意識するのは、AWS CLI や AWS SDK などによるプログラムアクセスを実行する場合です。

AWS CLI の場合

AWS CLI においては、v2では利用者側で意識しなくともリージョナルエンドポイントが利用されます。

v1ではデフォルトでグローバルエンドポイントが使用されるため、以下のようにコンフィグで指定することでリージョナルエンドポイントの使用を指定できます。

sts_regional_endpoints = regional

（2024/08/30現在 AWSドキュメントにsts_regional_endpointsの設定項目の記述が無くなっているのは気になります。v2ではすでに設定する必要がないから、ということでしょうか。）

AWS SDK の場合

各種 AWS SDKにおけるリージョナルエンドポイントの指定可否などについて、以下にまとまっています。

• AWS STS Regionalized endpoints - AWS SDKs and Tools

Note
All new SDK major versions releasing after July 2022 will default to regional. New SDK major versions might remove this setting and use regional behavior. To reduce future impact regarding this change, we recommend you start using regional in your application when possible.

2022年7月以降に発行されるメジャーバージョンにおいては、リージョナルエンドポイントを向かせる設定項目自体がなくなり、デフォルトでリージョナルエンドポイントを向く、ということのようです。

2024/09/02時点の各種 AWS SDKのメジャーバージョンのリリース状況は以下の通りです。

• AWS SDKs and Tools version support - AWS SDKs and Toolsより

AWS SDK を利用したプログラムでリージョナルエンドポイントを利用する設定を行なっている例は以下です。前者の環境変数で指定するパターンの方が手軽ではありそうです。

https://dev.classmethod.jp/articles/aws-sts-using-reginal-endpoint-envvar-boto3/

https://dev.classmethod.jp/articles/python-boto3-sts-regional-endpoint/

実際に発生した事象から考える

2024/08/29に、AWS Health Dashboardに記録されたイベントがありました。

• タイトル：運用上の問題 - AWS Identity and Access Management (Global)
• サービス：AWS Identity and Access Management

第一報がこちら。AWS STS への接続での問題が生じているようである、という旨です。

8月 29 2:31 午前 PDT We are investigating connectivity issues, impacting requests made to AWS STS (Security Token Service). Other AWS Services are also seeing impact due to this issue. We are actively investigating this issue and will provide more information within the next 30 minutes.

20分ほど後の第二報がこちら。回復の兆しが見えているという内容。

8月 29 2:52 午前 PDT We are beginning to see signs of recovery for the connectivity issues. We will provide additional information within the next 30 minutes.

そこから30分ほどの後の最終報がこちらです。

8月 29 3:21 午前 PDT Between 1:32 AM and 2:58 AM PDT we experienced network connectivity issues for multiple AWS Services. While we initially believed the issue was specific to IAM and STS, we determined the root cause to be a networking issue. We have mitigated the issue and are confident the issue will not reoccur.

During this time, customers may have experienced general connectivity issues contacting AWS service endpoints in US-EAST-1 from AP-NORTHEAST-1, US-WEST-2, AP-SOUTHEAST-1, AP-SOUTHEAST-3, US-GOV-WEST-1, AP-SOUTHEAST-5, and AP-EAST-1. Customers may also have received error messages when contacting the global STS (Security Token Service) endpoint from the affected regions. Connectivity to the local STS endpoint in each Region was not affected by this issue. The issue has been resolved, and all services are now operating normally. While services are now operating normally, there may be a backlog, including logs and event delivery, that will be processed over the next few hours.

以降、以下を「影響を受けたリージョン」と呼びます。

• ap-northeast-1 (東京)
• us-west-2 (オレゴン)
• ap-southeast-1 (シンガポール)
• ap-southeast-3 (ジャカルタ)
• us-gov-west-1 (米国政府西部)
• ap-southeast-5 (マレーシア)
• ap-east-1 (香港)

最終報の内容をサマリしてみました。

1. 「影響を受けたリージョン」からバージニア北部リージョンの AWS サービスエンドポイントへの接続で問題が生じた
2. 「影響を受けたリージョン」からAWS STS のグローバルエンドポイントへの接続でもエラーが発生した可能性がある
3. 「影響を受けたリージョン」内のプリンシパルから、同一リージョンのAWS STS リージョナルエンドポイントへの接続は影響を受けていなかった

まさに、リージョナルエンドポイントの利用が推奨される理由である「冗長性の構築（障害影響の封じ込め）」と一致する内容に見受けます。

今回と同じ事象が発生した際に影響を避けるには？

以下の対策をとっておくと、同様の事象が発生した際の影響を回避できそうです。

• ワークロードがグローバルエンドポイントを利用するようになっていた場合、リージョナルエンドポイントを利用するように変更する

加えて、「特定のリージョナルエンドポイントへのリクエストが失敗したら別のリージョンのリージョナルエンドポイントにスイッチする機構を入れる」という対策も場合によっては有効かもしれません。

ただ、先ほど引用した AWS ブログではリージョナルエンドポイントへの接続障害があった場合について以下の記述があります。

If a Regional AWS STS endpoint becomes unreachable, your workloads shouldn’t call AWS STS endpoints outside of the operating Region.

👆「（ワークロードから同一リージョン内の AWS STS リージョナルエンドポイントへのリクエストを行う場合、）不通でも外のリージョンのリージョナルエンドポイントにリクエストを送るべきではない」

If your workload has a multi-Region resiliency requirement, build failover logic for AWS STS calls to other Regions in the event that Regional AWS STS endpoints become unreachable.

👆「（AWS 外から AWS STSエンドポイントにリクエストを送る場合）、ワークロードがマルチリージョンのレジリエンスを持つ必要があるのであれば、別のリージョンのリージョナルエンドポイントへの切り替えの仕組みを持て」

このあたりは、「AWS STS へのリクエストを行うプリンシパルがどこに位置するか」「ワークロードとしてどの程度の可用性を持たせるか」「どういった障害を想定するか」によって取りうる選択肢が変わりそうです。

IAMのレジリエンスのページでは、以下記述があります。

You can request new temporary credentials with the AWS STS Regional service endpoint for at least 24 hours. The following API operations generate temporary credentials.

AWS リージョン間の通信で中断があったとしても、AWS STS リージョナルエンドポイントを通じた一時的な認証情報の払出しは少なくとも24時間行える、という記述に見えます。

リージョナルエンドポイントが利用できなくなる、というケースの発生確率が低いものとして捉え、マルチリージョン構成をとっていないワークロードではエンドポイントの切り替えは実装しない、という選択肢もあるかと考えます。

まとめ

• AWS STS のサービスエンドポイントにはグローバルなものとリージョナルなものがある
• グローバルエンドポイントはレガシーな位置付けであり、リージョナルエンドポイントの利用が推奨される
• AWS サービスによる AWS STS へのリクエストはリージョナルエンドポイントが使用されている
• 利用者が関与する AWS CLI、AWS SDK等によるプログラムアクセスは利用者が制御可能な部分が大きい
  • 新しいバージョンではデフォルトがリージョナルになりつつあるが、過去経緯からグローバルをデフォルトとするツールもある
  • 将来的にデフォルトがリージョナルへ移行することを想定し、現段階から明示的にリージョナルを指定することが望ましい

終わりに

AWS STS でリージョナルエンドポイントの利用が推奨される理由について確認してみました。

ベストプラクティス、とされるものを机上で確認するだけでは腹落ちしないこともありますが、実際の事象と関連付けて確認すると理解が深まります。

このブログが、普段裏方に回ることが多い AWS STS を皆さんが意識するきっかけになっていれば幸いです。

以上、チバユキ (@batchicchi)がお送りしました。

参考

• AWS の障害分離境界について学べるホワイトペーパー AWS Fault Isolation Boundaries を読んでみた | DevelopersIO
• AWS再入門ブログリレー2022 AWS IAM編 | DevelopersIO
• AWS入門ブログリレー2024〜AWS IAM編〜 | DevelopersIO
• AWS IAM で障害が起こったらどうなるの？ AWS IAM のレジリエンス（復元力）に関する記述がドキュメントに追記されていた | DevelopersIO
• 香港などのオプトインリージョンにスイッチロールしてCLIコマンドを実行したらAuthFailureになった件について | DevelopersIO
• Boto3でAssumeRoleする際にSTSのリージョナルエンドポイントを使用する | DevelopersIO
• AWS Tools for PowerShell の AWS STS リクエストでハマった話 | DevelopersIO
• [Python] boto3で耐障害性を備えたAssume Roleの方法を考える | DevelopersIO