Amazon DVA-C02: Amazon API Gateway とアプリケーション統合 — 学習ガイド

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Developer Associate DVA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

API Gateway (REST, HTTP, WebSocket) を使用した API の設計と統合

設計は、適切な API フレーバーの選択から始まります。REST API (API Gateway REST) は、ステージごとのキャッシュや高度なマッピングテンプレートなど、きめ細かなステージレベルの機能を提供します。HTTP API (API Gateway v2) は、一般的なプロキシパターンやネイティブの JWT/OIDC オーソライザーに対して、より低いレイテンシーと低コストを提供します。WebSocket API は、ルートキー ($connect, $disconnect, $default) を持つ永続的なクライアントサーバーチャネルを提供し、メッセージを送信するには API Gateway Management API (PostToConnection) が必要です。統合を設計する際は、単純なリクエスト/レスポンスには AWS_PROXY/Lambda プロキシを優先し (

undefined

を使用するか、v2 の場合は ApiGatewayV2Client で CreateIntegration を使用)、プライベート HTTP バックエンドには HTTP または VPC Link を選択します。高スループットのバックエンドには、NLB + VPC Link を使用します。モック統合 (

undefined

) と統合レスポンステンプレートにより、フロントエンドチームはバックエンドの準備ができていなくても作業を開始できます。API の前面に CloudFront を配置する場合、オリジンとしてリージョン API エンドポイントを使用し、Origin Protocol Policy を HTTPS-only に設定します。エッジ最適化 REST API はすでに CloudFront の背後に配置されています。よくある落とし穴には、API と Lambda 間のペイロード形式バージョンの不一致 (v1.0 対 2.0)、Lambda を呼び出すための apigateway.amazonaws.com への権限付与の忘れ (

undefined

で権限を追加)、ブラウザをブロックする CORS の設定ミスなどがあります。

セキュリティと認可のパターン (Cognito, IAM, カスタムオーソライザー)

セキュリティパターンは、クライアントのタイプとアクセスモデルに合わせる必要があります。HTTP API の場合は、Amazon Cognito ユーザープールまたは外部 OIDC プロバイダーを使用し、それらを JWT オーソライザーとして接続します (apigatewayv2 の CreateAuthorizer で identitySource を $request.header.Authorization に設定)。セッションベースのユーザーアクセスには、REST API の Cognito オーソライザーを使用します。サービス間または管理者用 API の場合は、IAM 認可 (SigV4) と、ステージおよびメソッドに対する厳密にスコープされた IAM リソースポリシーを優先します。Lambda (カスタム) オーソライザーは、独自の認証ルールを実装するための最大限の柔軟性を提供しますが、レイテンシーと障害モードを追加することを忘れないでください。コールドスタートを減らし、クライアントに 500 を返すエラーのスローを避けるために、オーソライザーのレスポンスを TTL 付きでキャッシュします。使用量プランと API キー (

undefined

と

undefined

) をスロットリングクォータと組み合わせて、不正使用から保護します。正しい IAM 権限を確認します。API Gateway に Lambda を呼び出す権限を付与し (

undefined

)、Lambda の実行ロールを最小権限に制限します。開発者の注意点には、JWT オーソライザーのトークン抽出の有効化忘れ、オーソライザーのタイムアウトが API 全体のレイテンシーに影響を与えること、CloudFront によるヘッダー/クッキーの転送が意図せずキャッシュをバイパスしたりユーザーデータを漏洩させたりする可能性があることなどがあります。

ステージ管理、バージョニング、キャッシュ、カナリアデプロイ

ステージは独立したランタイムサーフェスとして扱います。デプロイはスナップショットであり (

undefined

または

undefined

)、ステージはそれらのスナップショットにマッピングされます。バージョン間でトラフィックをルーティングするには、ステージ変数、またはできれば Lambda エイリアスを使用します。エイリアスをアトミックに切り替えるか (UpdateAlias)、API Gateway のステージカナリア設定を使用して段階的なロールアウトを行います。REST API の場合、ステージでキャッシュを有効にし (patch-operations で cacheClusterEnabled と cacheClusterSize を設定する

undefined

)、メソッド設定で TTL とキャッシュキーのパラメータを制御します。HTTP API には現在、組み込みのキャッシュ機能がないため、CloudFront またはアプリケーションレベルのキャッシュを使用します。デプロイ時または基礎となるデータが変更されたときにキャッシュを無効化します。TTL のみに依存すると、古いデータが返される可能性があります。バージョニングパターン: パス (/v1/…) でセマンティック API バージョニングを使用するか、ブルー/グリーンフローのためにステージデプロイに依存します。よくある落とし穴には、ステージ変数が安全であると想定すること (コンソールアクセス権を持つ開発者には表示されます)、キャッシュキーの設定ミス (Authorization ヘッダーやクエリパラメータの含め忘れ)、スキーマ変更のデプロイとクライアントの互換性を調整しないことなどがあります。

パフォーマンス、オブザーバビリティ、診断

APIをエンドツーエンドで計測します。API Gatewayで実行ログとアクセスログを有効にし、構造化されたJSON（$context変数）をCloudWatch Logsに出力します。API GatewayとLambdaでX-Rayを有効にし（デプロイ/ステージでtracingEnabledを設定するか、SDKを使用: PutFunctionConcurrency/UpdateFunctionConfigurationとTracingConfig）、トレースを相関させます。CloudWatchでAPI Gatewayのメトリクス（Latency, IntegrationLatency, 4XX/5XX, CacheHitCount）とLambdaのメトリクス（Duration, Throttles, ConcurrentExecutions）を監視し、メトリクス数式を使用してレイテンシーがどこで蓄積しているかを特定します。WebSocketの場合は、接続数とAPI Gatewayの5XXの急増を追跡します。トラブルシューティングの手順には、IntegrationLatencyとLatencyを比較してバックエンドとゲートウェイのどちらがオーバーヘッドを追加しているかを確認すること、X-RayセグメントをドリルダウンしてコールドスタートやVPC ENIを調査すること、マッピングテンプレートのエラーがないかCloudWatch Logsを確認することが含まれます。非同期Lambdaの失敗にはDLQと送信先を使用し、重要な関数には予約済み同時実行数またはプロビジョニング済み同時実行数を設定します。開発者の落とし穴としては、機密性の高いPIIをトレースに記録してしまうこと（ソースで墨消しするか、それらのフローのX-Rayサンプリングを無効にする）、カスタムドメイン用のプロバイダー証明書が欠落していること（エッジの場合はACMリージョナル vs us-east-1）、パブリックAPIに対して使用量プランなしでデフォルトのアカウントスロットリングに依存することが挙げられます。

実践的な問題: ユースケースシナリオ

シナリオ: BrightCartは、S3/CloudFrontでホストされているシングルページアプリケーション上でリージョナルなeコマースフロントエンドを運用しており、API Gateway（リージョナルHTTP API）を介してチェックアウトAPIを公開しています。このAPIはVPC内のLambda関数を呼び出し、注文をDynamoDBに書き込みます。この環境では、CI/CDパイプラインを使用してLambdaのバージョンを本番エイリアスにデプロイし、本番ステージで/checkoutを公開しています。

課題: 最近の機能ロールアウト後、本番APIのレイテンシーが増加し、一部のチェックアウト要求が断続的に502/504を返すようになりました。開発者は安全なロールバックメカニズムと即時の診断を必要としています。

推奨アプローチ:

本番APIステージを以前のデプロイメントに向けることで、デプロイメントのロールバックを作成します: aws apigatewayv2 create-deployment --api-id <api> --description "rollback" を使用し、次に aws apigatewayv2 update-stage --api-id <api> --stage-name prod --deployment-id <old-deploy-id> を使用します。
Lambdaエイリアスを使用して安全にトラフィックを移行します: aws lambda update-alias --function-name CheckoutFn --name prod --function-version <previous-version> でprodのLambdaエイリアスを以前のバージョンに更新し、動作を検証します。
診断を有効にして収集します: APIとLambdaに対してX-Rayトレースを有効にし（aws apigatewayv2 update-stage --tracing-enabled true および aws lambda update-function-configuration --function-name CheckoutFn --tracing-config Mode=Active）、詳細なアクセスログ（$context.requestTime, $context.integrationErrorMessage）をCloudWatch Logsに出力するように設定します。
メトリクスとトレースを分析します: CloudWatchでAPI GatewayのIntegrationLatencyとLatencyを比較し、X-Rayセグメントを調べてVPC ENIのコールドスタートを特定し、LambdaのスロットリングやDynamoDBの条件付き書き込みを確認します。VPC ENIのレイテンシーが根本原因である場合は、プロビジョニング済み同時実行数（aws lambda put-provisioned-concurrency-config）またはVPCエンドポイント最適化を備えたLambdaへの移行を検討します。

論理的根拠: アトミックなステージの再デプロイとLambdaエイリアスの切り替えは、コードの変更なしで迅速かつ低リスクのロールバックを提供します。X-Rayと構造化アクセスログを有効にすることで、開発者はAPI Gateway、Lambdaのコールドスタート、VPCネットワーキング、または下流のDynamoDB呼び出しのいずれがエラーの原因であるかを正確に特定でき、正しい緩和策（プロビジョニング済み同時実行数、スループットの増加、または設定の修正）を導き出すことができます。

← サーバーレスと AWS Lambda · すべてのドメイン · Amazon DynamoDB と NoSQL 設計 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →