API Gateway＋Lambda＋DynamoDBで作るサーバーレスAPI構成【SAA対策】
「サーバーの管理をしたくない」「アクセスが不定期でコストを抑えたい」——こうした要件に対する AWS の定番解が、API Gateway ＋ Lambda ＋ DynamoDB のサーバーレス構成です。どの部品もリクエスト量に応じて自動でスケールし、使った分だけ課金されます。
リクエストの流れ
- クライアントが API Gateway にリクエストを送る（必要なら Cognito のトークンで認証）
- API Gateway が Lambda 関数を呼び出す
- Lambda が DynamoDB を読み書きして結果を返す
- ログは自動的に CloudWatch Logs に出力される
なぜこの組み合わせなのか
- サーバー管理が不要：OSのパッチ当てや台数調整を AWS に任せられる
- ゼロからスケール：アクセスがないときはほぼ課金されず、急増しても自動で追従する
- DynamoDB は接続数の問題が起きにくい：HTTPベースのAPIで呼び出すため、Lambda が大量に同時実行されても RDB のようなコネクション枯渇が起きにくい
補足：Lambda から RDS を使う場合は、同時実行で接続が増えすぎないよう RDS Proxy を挟むのが定番です。試験でも「Lambda ＋ RDS で接続数エラー」→「RDS Proxy」がよく出ます。
押さえておきたい制限
| 項目 | 内容 | 試験での使われ方 |
|---|---|---|
| Lambda の最大実行時間 | 15分 | 「1時間かかるバッチ」は Lambda 単体では不可 → ECS/Fargate や Step Functions で分割 |
| API Gateway の統合タイムアウト | 既定で約30秒 | 長時間処理は非同期化（SQS に積んで後で処理） |
| Lambda の同時実行数 | リージョンごとの上限あり（引き上げ可能） | 重要な関数には予約済み同時実行数を設定 |
| コールドスタート | 初回起動の遅延 | 遅延を避けたい → プロビジョニング済み同時実行 |
DynamoDB のキャパシティモード
- オンデマンド：リクエスト数に応じた課金。アクセスが予測できない、急増する場合に向く
- プロビジョンド：読み書きの容量を事前に指定（Auto Scaling も可）。アクセスが安定していればコストを抑えやすい
よくあるひっかけ：「予測できないトラフィック」「運用負荷を最小に」とあればオンデマンド。「安定したトラフィックでコスト最適化」ならプロビジョンド（＋リザーブドキャパシティ）です。
最小権限の IAM ロール
Lambda には実行ロールを付け、必要な操作だけを許可します。たとえばテーブルの読み書きだけなら、dynamodb:GetItem・dynamodb:PutItem などをそのテーブルのARNに限定して許可します。ArchiCraft のサンドボックスで上の構成を CloudFormation に書き出すと、この最小権限ポリシーが自動で組み立てられるので、中身を確認してみてください。
理解度チェック：API の応答を速くするため、同じリクエストへの応答をキャッシュしたい。手軽な方法は？
API Gateway（REST API）のステージキャッシュを有効にする、または CloudFront を前段に置く。DynamoDB の読み取り自体を速くしたい場合は DAX を使います。
まとめ
- サーバー管理不要・従量課金・自動スケールがサーバーレスの強み
- Lambda は15分、API Gateway は約30秒という時間制限に注意
- Lambda ＋ RDB なら RDS Proxy、Lambda ＋ DynamoDB なら接続問題は起きにくい