AWS の API エンドポイントはなぜリージョンごとに異なるのか - グローバルサービスとリージョナルサービスの設計
ec2.us-east-1.amazonaws.com のようなリージョナルエンドポイントと iam.amazonaws.com のようなグローバルエンドポイントが分かれている設計理由、デュアルスタックエンドポイント、FIPS エンドポイントの存在を解説します。
リージョナルエンドポイントの設計意図
AWS のほとんどのサービスは、リージョンごとに独立した API エンドポイントを持っています。EC2 なら ec2.us-east-1.amazonaws.com、ec2.ap-northeast-1.amazonaws.com のように、リージョンコードが URL に含まれます。この設計には 2 つの意図があります。第 1 に、障害の隔離です。各リージョンのエンドポイントは独立したインフラで動作しているため、us-east-1 の EC2 API が障害を起こしても、ap-northeast-1 の EC2 API は影響を受けません。もしすべてのリージョンが単一のグローバルエンドポイントを共有していたら、そのエンドポイントの障害が全リージョンに波及します。第 2 に、データの局所性です。API リクエストはそのリージョンのコントロールプレーンで処理されるため、リクエストが大陸を横断する必要がありません。東京リージョンの EC2 API を呼び出すと、リクエストは東京のコントロールプレーンで処理され、レイテンシが最小化されます。SDK はデフォルトで設定されたリージョンのエンドポイントにリクエストを送信するため、開発者がエンドポイント URL を意識することはほとんどありません。
グローバルサービスの特殊な設計
IAM、Route 53、CloudFront、WAF (CloudFront 用)、STS のグローバルエンドポイントは、リージョンコードを含まない URL (iam.amazonaws.com、route53.amazonaws.com) を使用します。これらのサービスがグローバルである理由は、その性質上、リージョンに紐づかないリソースを管理するためです。IAM ユーザーやロールは AWS アカウント全体に適用され、特定のリージョンに属しません。Route 53 のホストゾーンもグローバルなリソースです。ただし、グローバルサービスのコントロールプレーンは物理的にはどこかのリージョンで動作しています。IAM のコントロールプレーンは us-east-1 に集中しており、2021 年の us-east-1 障害時に IAM の管理操作が影響を受けました。STS は興味深い例外です。STS にはグローバルエンドポイント (sts.amazonaws.com) とリージョナルエンドポイント (sts.ap-northeast-1.amazonaws.com) の両方が存在します。AWS はリージョナル STS エンドポイントの使用を推奨しています。グローバルエンドポイントは us-east-1 で処理されるため、us-east-1 の障害時に他のリージョンからの STS 呼び出しも影響を受けるためです。
S3 のエンドポイントの複雑さ
S3 のエンドポイントは、AWS サービスの中で最も複雑です。パススタイル (s3.amazonaws.com/bucket-name/key) と仮想ホストスタイル (bucket-name.s3.amazonaws.com/key) の 2 つの URL 形式が存在します。AWS は 2020 年以降、仮想ホストスタイルを推奨しており、新しい SDK ではデフォルトで仮想ホストスタイルが使用されます。さらに、S3 にはリージョナルエンドポイント (s3.ap-northeast-1.amazonaws.com) とレガシーグローバルエンドポイント (s3.amazonaws.com) があります。レガシーグローバルエンドポイントは us-east-1 にリダイレクトされるため、他のリージョンのバケットにアクセスすると 307 リダイレクトが発生し、余分なレイテンシが加わります。S3 Transfer Acceleration を有効にすると、さらに別のエンドポイント (bucket-name.s3-accelerate.amazonaws.com) が使用されます。このエンドポイントは CloudFront のエッジロケーションを経由してデータを転送し、遠距離のアップロード速度を向上させます。S3 のデュアルスタックエンドポイント (s3.dualstack.region.amazonaws.com) は IPv4 と IPv6 の両方をサポートします。
FIPS エンドポイント - 米国政府向けの暗号化要件
AWS は多くのサービスで FIPS (Federal Information Processing Standards) 140-2 準拠のエンドポイントを提供しています。FIPS エンドポイントは、TLS 通信に FIPS 140-2 認定の暗号モジュールを使用します。URL は通常のエンドポイントに fips が付加された形式 (例: ec2-fips.us-east-1.amazonaws.com、s3-fips.us-east-1.amazonaws.com) です。FIPS エンドポイントが必要なのは、主に米国連邦政府機関とその請負業者です。FedRAMP や FISMA などの規制は、政府データの通信に FIPS 140-2 準拠の暗号化を要求しています。民間企業でも、政府との取引がある場合は FIPS エンドポイントの使用が求められることがあります。FIPS エンドポイントと通常のエンドポイントの機能的な違いはありません。違いは TLS ハンドシェイクで使用される暗号スイートだけです。FIPS エンドポイントでは、FIPS 140-2 で承認されていない暗号アルゴリズム (ChaCha20 など) が無効化されます。パフォーマンスへの影響はほとんどありません。
VPC エンドポイント - パブリックインターネットを経由しない API アクセス
通常、EC2 インスタンスから AWS API を呼び出すと、リクエストはインターネットゲートウェイまたは NAT Gateway を経由してパブリックインターネットに出て、AWS の API エンドポイントに到達します。VPC エンドポイント (PrivateLink) を使用すると、リクエストは AWS のプライベートネットワーク内で完結し、パブリックインターネットを経由しません。VPC エンドポイントには 2 種類あります。ゲートウェイエンドポイントは S3 と DynamoDB 専用で、ルートテーブルにエントリを追加する方式です。追加料金はかかりません。インターフェースエンドポイント (PrivateLink) は、VPC 内に ENI (Elastic Network Interface) を作成し、プライベート IP アドレスで API にアクセスする方式です。1 時間あたり 0.01 USD + データ処理料金がかかります。VPC エンドポイントのセキュリティ上の利点は、API リクエストがパブリックインターネットに露出しないことです。金融機関や医療機関のように、データの経路を厳密に管理する必要がある環境では、VPC エンドポイントが必須です。また、NAT Gateway のデータ処理料金 (0.045 USD/GB) を削減できるコストメリットもあります。AWS のエンドポイント設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。