SAA / ドメイン2 レジリエントなアーキテクチャの設計
重要な内容
Amazon API Gateway
は、、、 を作成、公開、保護、監視するです。SAA では、 やの前段に置き、認証、、、バージョン管理を集約する場合に選びます。
概要
クライアントからのリクエストを受け、、AWSサービス、内サービスなどのバックエンドへ転送します。サーバーを管理せず、需要に応じてスケールするの入口を作れます。
主要技術
①APIタイプ ⚠️ 頻出
| タイプ | 主な用途 | 判断ポイント |
|---|---|---|
| 高度な変換、APIキー、使用量プラン等 | 多機能なAPI管理が必要です。 | |
| API | シンプルなHTTP API | 低コスト・低遅延を優先します。 |
| API | 双方向リアルタイム通信 | 接続を維持するチャット等に使います。 |
②統合方式
プロキシ統合、統合、AWSサービス統合、 Linkを利用できます。VPC Linkでは、公開せずにVPC内の経由でバックエンドへ接続できます。
AWSサービス統合は、受け取ったリクエストをから他のAWSサービスのへ直接渡す方式です。間にLambdaやを置かずに済むため、コードもサーバーも持たずに取り込み口を作れます。
| 統合方式 | つなぐ先 | 判断ポイント |
|---|---|---|
| Lambdaプロキシ統合 | Lambda関数 | リクエストをそのまま渡し、処理をコードで書きます。 |
| AWSサービス統合 | 、、、など | 受け取ったデータを転送するだけなら、コードを書かずに済みます。 |
| HTTP統合 | 公開されたHTTP | 既存のWebサービスをAPI Gatewayの背後に置きます。 |
| VPC Link | VPC内のロードバランサー | バックエンドを公開せずに接続します。 |
⚠️ 頻出: 「外部からデータを受け取ってそのまま蓄積したい」「運用負荷を最小にしたい」という要件では、Lambdaを挟まずAWSサービス統合でData FirehoseやSQSへ直接渡す構成を検討します。
③認証と保護
、ユーザープール、オーソライザーを使い分けます。、、で過剰アクセスや一般的なWeb攻撃から保護します。
どのオーソライザーを選ぶかは、認証の判断を誰が持っているかで決まります。
| 認可方式 | 検証するもの | 選ぶ場面 |
|---|---|---|
| IAM認証 | 呼び出し元の署名と | 呼び出し元がAWSの利用者やサービスの場合に使います。 |
| Cognitoユーザープールオーソライザー | ユーザープールが発行したトークン | 利用者をCognitoで管理している場合に使います。 |
| Lambdaオーソライザー | Lambda関数へ書いた独自のロジック | 自社の認証基盤、独自トークン、取引先ごとの判定など、既製の方式に当てはまらない場合に使います。 |
| キーと使用量プラン | 配布したキーと利用量 | 認証ではなく、利用量の管理と識別に使います。 |
Lambdaオーソライザーは、検証の結果としてIAMポリシーを返し、がそれを見て通すか拒むかを決めます。検証結果はできるため、毎回関数を呼ぶわけではありません。Application Load Balancerにも認証機能がありますが、OpenID ConnectとCognitoに限られ、任意の判定ロジックを書くことはできません。
の内側からだけ呼ばせたいAPIは、タイプをプライベートにした APIで作ります。プライベートAPIはインターフェイスVPCエンドポイント(execute-api)経由でだけ呼び出せ、リソースポリシーにaws:SourceVpceやaws:SourceVpcの条件を書いて、呼び出せるエンドポイントやVPCを絞ります。プライベートの種類はREST APIだけで、 APIにはありません。
契約プランや取引先ごとに呼び出せる量を変えたい場合は、REST APIの使用量プランを使います。使用量プランは、APIキーで呼び出し元を識別し、キーごとにスロットリング(毎秒のリクエスト数とバースト)とクォータ(日・週・月あたりの上限件数)を設定します。ステージやメソッドに設定するスロットリングはすべての呼び出し元に共通で、取引先ごとに上限を変えることはできません。使用量プランの上限はベストエフォートで適用されるため、費用を厳密に止める仕組みとしては使わず、費用の監視にはを組み合わせます。
⚠️ 頻出: 「独自の認証ロジックが必要」はLambdaオーソライザー、「利用者をCognitoで管理済み」はユーザープールオーソライザー、「呼び出し元がAWSの利用者」はIAM認証です。
④レジリエンスと制限
はマネージドにスケールしますが、バックエンドの、タイムアウト、再試行、も設計します。非同期でよい処理はやへ渡し、同期処理を短くします。
バックエンドを守る入口の仕組みは2つあります。スロットリングは、ステージやメソッドに1秒あたりのレートとバーストの上限を設定し、超えた要求に 429を返します。キーと使用量プランを使うと、利用者 (キー) ごとのレートと月間などの呼び出し回数の上限 () を設けられます。ステージのは、指定した (既定300秒、最大3600秒) の間、同じキャッシュキーの要求にバックエンドを呼ばずに応答します。使用量プラン、APIキー、キャッシュ、の関連付けは APIだけの機能で、HTTP APIでは使えません。
統合のタイムアウトは既定で29秒です (Regionalとプライベートの REST API はクォータの引き上げで延長できます)。数分かかる処理を同期で待たせず、依頼を受け付けたらSQSやへ渡して受付IDをすぐ返し、結果は後から問い合わせさせる非同期の形にします。
試験対策
| 要件 | 選ぶサービス |
|---|---|
| を として公開 | |
| GraphQL APIとリアルタイム更新 | AppSync |
| 長時間処理を | API Gateway + |
| 以外の静的コンテンツ配信 | |
| 独自ロジックでリクエストを検証 | Lambdaオーソライザー |
| 受け取ったデータをコードなしでへ蓄積 | AWSサービス統合 + |
「APIの入口をフルマネージド化」「認証とを集約」が判断軸です。