はじめに
AWS STS(Security Token Service)は、一時的な認証情報(トークン)を発行するための重要なサービスです。
これまで sts.amazonaws.com
という グローバルエンドポイント が広く使われてきましたが、現在は リージョナルエンドポイント の利用が推奨されています。
本記事では、この方針変更の背景、利点、実際の対応方法について解説します。
1. グローバル vs リージョナル エンドポイントの違い
項目 | グローバルエンドポイント | リージョナルエンドポイント |
---|---|---|
エンドポイント | https://sts.amazonaws.com |
例:https://sts.ap-northeast-1.amazonaws.com
|
レイテンシ | 高くなる場合がある | 地理的に最適化される |
可用性 | us-east-1に依存(単一点) | 各リージョンに分散 |
障害時の影響範囲 | 広域(全リージョンに波及) | リージョン内で局所化 |
AWS推奨 | ❌ 非推奨へ移行中 | ✅ 推奨(今後のデフォルト) |
2. なぜリージョナルが推奨になったのか
以下のような理由から、AWSはリージョナルエンドポイントの使用を強く推奨しています。
-
レイテンシの低減
リージョン内でSTSトークンを取得することで、より高速に認証が行えるようになります。 -
可用性と耐障害性の向上
グローバルエンドポイントがダウンするとすべてのリージョンに影響するため、リスク分散の観点でもregionalが優位。 -
一部サービスでregional前提に移行
例:S3クロスリージョンレプリケーション、IAM Roles Anywhere など。 -
将来的なデフォルト移行への布石
AWS_STS_REGIONAL_ENDPOINTS=regional
がデフォルトになる流れに備える必要あり。
2025年4月18日のブログ投稿でグローバルエンドポイントを指定してもローカルに処理される機能拡張が行われたとされていますが、引き続きリージョナルエンドポイントを推奨するのは変わらないそうです。
3. リージョナルエンドポイントの設定方法
3.1 AWS CLIでの設定
~/.aws/config
に以下の設定を追加します。
[default]
region = ap-northeast-1
sts_regional_endpoints = regional
または環境変数で設定:
export AWS_STS_REGIONAL_ENDPOINTS=regional
3.2 SDK(boto3)での対応
Python(boto3)でリージョナルエンドポイントを利用する例:
import boto3
sts = boto3.client('sts', region_name='ap-northeast-1', endpoint_url='https://sts.ap-northeast-1.amazonaws.com')
print(sts.meta.endpoint_url)
Lambda Functionの場合はパラメータでendpoint_urlを指定せず、以下のように環境変数で指定してあげた方が確実です。
4. 注意点・落とし穴
- 古いAWS SDK/CLIでは regional 設定が未対応の場合があるため、常に最新バージョンを使用することが推奨されます。
- 一部マネージドサービスで、STSエンドポイントの切り替えが自動的に反映されない可能性があります。
- CloudTrailログやアクセス監査の設計にも注意し、どのエンドポイント経由で認証されたかを追跡可能にすることが望ましいです。
5 グローバルエンドポイントを使っているかどうか確認する方法
CloudTrailのログをCloudWatch Logsに転送する設定をしている場合は、こちらのブログを参考にCloudWatch Logs Insightsを活用して確認するのが良いです。
S3に出力している場合は、こちらの記事を参考にログをAthenaを利用して確認するのが良さそうです。
※こちらの記事だとap-northeast-1を指定して問題ないことを確認しているようですが、us-east-1を指定しないとグローバルエンドポイントを利用しているかどうかは確認できないと思うので、そこだけ注意してください。
6. まとめ
AWS STSのリージョナルエンドポイントへの移行は、以下の観点で非常に有効です:
- レイテンシの最適化
- 耐障害性・可用性の向上
- AWSの今後のデフォルト方針に準拠
将来のトラブル防止や運用効率の向上のためにも、早めの移行を強く推奨します。