AWSサービス解説
Amazon API Gatewayとは？HTTP APIを初心者向けに解説
API Gatewayの役割、HTTP API、Lambda連携、CORSの注意点をAWS初学者向けに整理します。
Amazon API Gatewayは、Web APIの入口を作るサービスです。Lambdaと組み合わせることで、サーバーレスAPIを構築できます。
結論
API Gatewayは、ブラウザやフロントエンドからのHTTPリクエストを受け、Lambdaなどのバックエンドへつなぐ入口です。
API Gatewayの役割
フロントエンドは、直接Lambdaを呼び出すのではなく、API GatewayのエンドポイントへHTTPリクエストを送ります。API Gatewayがリクエストを受け、設定されたLambdaを呼び出します。
このプロジェクトでは、問い合わせフォームからPOST /contactを呼び、API Gatewayがcontact-submit Lambdaを起動します。
HTTP APIとREST API
API GatewayにはHTTP APIとREST APIがあります。MVPでは、シンプルで低コストにしやすいHTTP APIを優先します。
REST APIの方が機能は豊富ですが、小規模な問い合わせAPIではHTTP APIで十分なケースが多いです。
CORSの注意点
ブラウザからAPIを呼ぶ場合、CORS設定が必要です。本番では許可Originを独自ドメインやCloudFrontドメインに限定します。
* を本番前提で許可すると、外部サイトからAPIを使われるリスクが上がります。MVPでも本番Originに絞る設計にします。
レート制限とスパム対策
問い合わせAPIはスパム投稿の対象になりやすいです。最初はhoneypotと入力値制限を入れ、アクセスが増えたらAPI Gateway側の制限や追加対策を検討します。
試験で問われるポイント
- API GatewayはAPIの入口
- Lambdaと組み合わせてサーバーレスAPIを作れる
- HTTP APIはシンプルなAPIに向く
- CORS設定が必要になる場合がある
- 認証が必要な場合はCognito JWT Authorizerなどを使う
API Gatewayが必要になる場面
ブラウザ、モバイルアプリ、外部連携先からHTTPでバックエンド機能を呼び出したいとき、API Gatewayは入口を一元化できます。URLのパスとHTTPメソッドを処理へ対応付け、リクエスト形式、認証、CORSなどを入口側で管理しやすくなります。フロントエンドがLambdaの呼び出し権限を直接持つ構成より、公開境界を明確にできます。Amazon API Gateway とはも最初に確認しておくと、統合先との違いを整理できます。
常駐するWebアプリケーションへの単純な負荷分散が目的ならALBが合うことがあります。API Gatewayを使う理由はLambdaを使っているからだけではありません。外部へHTTP APIを提供する契約、認証、リクエスト単位の観測をどう扱うかで判断します。
HTTP APIとREST APIの選び方
HTTP APIは比較的シンプルなHTTP APIを構築する選択肢です。REST APIにはより広い機能があり、既存の要件や必要な制御によって選択肢になります。どちらが常に安価・高機能と固定して覚えるのではなく、現在の要件と公式仕様を照らして決めます。HTTP APIの基本的な作り方はHTTP API の使用で確認できます。
小さな問い合わせAPIで必要なのは、ルート、統合、CORS、エラーの扱いを明確にすることです。将来の要件を想像して使わない機能まで増やすより、必要な認証や観測を満たす構成から始め、要件が変わったときに見直します。
Lambda proxy統合のリクエストフロー
利用者がPOST /contactを送信すると、API Gatewayがルートに一致する統合先のLambdaを呼び出します。Lambdaはイベントからメソッド、パス、ヘッダー、本文を読み、入力値を検証してからDynamoDBなどへ処理を渡します。結果をHTTPレスポンスの形式にしてAPI Gateway経由で返すのが基本です。
API Gatewayがあるから入力検証は不要、とはなりません。必須項目、文字数、形式、想定外のJSONを関数で検証し、失敗時にはクライアントが扱えるステータスと本文を返します。全体像はLambdaとAPI Gatewayを初心者向けに解説で補えます。
CORSの事前確認を理解する
別オリジンのブラウザアプリは、実際のPOSTの前にOPTIONSリクエストを送ることがあります。これはpreflightと呼ばれ、許可するOrigin、メソッド、ヘッダーをAPI側が返せなければ、Lambdaが正常でもブラウザからは失敗に見えます。開発時だけ通る*設定を本番の前提にしないことが大切です。
本番では実際に公開するサイトのOriginを許可対象にし、必要なメソッドとヘッダーに絞ります。Cookieなどの認証情報を伴う場合は特に、ワイルドカード指定との組み合わせを避け、ブラウザのCORS仕様とAPI Gatewayの設定を合わせて確認します。
認証と認可の境界
認証は誰が呼び出しているか、認可はその人に何を許可するかです。公開問い合わせフォームのように匿名送信を許すAPIでも、管理用APIまで同じように公開してはいけません。CognitoのJWT AuthorizerやIAM認証を使う場合は、API Gatewayでトークンを確認し、Lambdaでは認証済みの主体に基づいて処理を分けます。
認証済みであっても、本文のuserIdをそのまま信頼するのは危険です。トークンのクレームやサーバー側で決めた権限を基準にし、他人のデータを読み書きできない条件をLambdaとデータストアの両方で考えます。
スロットリングとログの運用
アクセス集中や誤ったクライアントからの連続呼び出しには、API Gateway側のスロットリングやWAFなどを含めて対策を検討します。具体的な上限値や料金はアカウント、リージョン、設定によって確認すべきため、固定値として設計書に埋め込まないようにします。
ログでは、API Gatewayがリクエストを受けたか、統合先で失敗したか、Lambdaがどのエラーを返したかを対応付けます。ただしアクセストークン、メールアドレス、本文をログへ無造作に出してはいけません。監視に必要な識別子だけを残し、調査と情報保護を両立させます。
試験で混同しやすい点
API GatewayはHTTP APIの公開入口であり、コードを実行するサービスではありません。処理はLambda、コンテナ、HTTPエンドポイントなどの統合先が担います。またCORSはAPIを守る認証機能ではなく、ブラウザが別オリジンへアクセスする際の制約です。不正利用を防ぐには認証、認可、入力検証、レート制御を別々に考えます。
「サーバーを管理せずにHTTPエンドポイントを作り、Lambdaを呼びたい」ならAPI GatewayとLambdaの組み合わせを検討します。アプリ内部のサービス間通信やデータベース保存まで、API Gateway単体で行う選択肢ではない点も押さえます。
よくある失敗と次の学習
CORSを全許可のままにする、エラー時のレスポンス形式を決めない、認証済みの利用者IDより本文のIDを優先する、ログへ機密情報を出すことがよくある失敗です。まずPOST /contactで正常系、入力不正、認証失敗、バックエンド失敗をそれぞれ確認してください。
API Gateway + Lambda + DynamoDBで問い合わせAPIを作る流れを読み、リクエストが保存まで到達する境界を追うと理解が深まります。公開APIを増やす前に、ルートごとの認証とCORSを表にして見直す習慣も有効です。
公開前に確認する順序
まずステージのURLへ正常なリクエストと不正なリクエストを送り、期待したステータスコードが返るかを確認します。次に実際のフロントエンドのOriginから呼び出し、preflightを含むCORSが通るかを確認します。最後に認証が必要なルートで、トークンなし、期限切れ、権限不足の各ケースを試します。この順序にすると、ブラウザ、API Gateway、Lambdaのどこで問題が起きたかを切り分けやすくなります。
APIのURLを公開した後も、ルートの追加が認可漏れを作らないかをレビューします。バックエンドの処理が正しくても、想定外のメソッドやOriginを受け付ける設定では公開境界が崩れます。設定とコードを別々のものとして扱わず、リリースごとにまとめて確認してください。
APIの契約を小さく保つ
リクエストとレスポンスの項目、必須か任意か、失敗時の形式を先に決めると、フロントエンドとLambdaの変更を同期しやすくなります。仕様にない項目を受け取った場合や、同じ送信が繰り返された場合の扱いも契約の一部です。バージョンを増やす必要が出たときは、既存利用者を急に壊さない移行手順を考えます。
API Gatewayはサービス間の境界を見える形にします。ルート名を業務の意図に合わせ、管理用と公開用を分け、ドキュメントと実際の設定を継続して一致させることが、後からの保守に効きます。
問い合わせのような公開エンドポイントでは、成功回数だけではなく、拒否したリクエストと失敗理由の傾向も見ます。突然の4xx増加はフロントエンドの変更、CORS設定、ボットアクセスのいずれかを示すことがあります。メトリクスの異常を見つけたときに、API Gateway、Lambda、ブラウザのどのログを見るかを先に決めておくと、障害対応が速くなります。
APIの入力値は、画面側で検証していてもサーバー側で再度検証します。直接HTTPリクエストを送れば画面の制約を回避できるためです。本文のサイズ、文字列の形式、許可しないフィールド、メソッドの組み合わせを明確にし、エラー時は内部のスタックトレースや設定値を返さないようにします。
外部サービスを統合先にする場合は、相手側が遅い、失敗する、同じリクエストを二度受け取る可能性を考慮します。API Gatewayの再試行だけに期待せず、処理の冪等性と利用者へ返すメッセージを設計します。公開URLを増やすほど攻撃面も増えるため、不要になったルートを残さず、認証方式とログ保持を定期的に確認してください。
リリース後には、実際の利用者が送るリクエストの形式と仕様書の差分を確認します。予期しない利用方法が見つかったら、入力検証、エラーメッセージ、ドキュメントを合わせて更新し、曖昧な契約を残さないことが重要です。
開発用の許可設定を本番へ持ち込まないために、環境ごとのOrigin、認証設定、ログ出力先をレビュー対象にします。URLが動くことと、安全に公開できることは別の確認項目です。
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。