outputAmazon API Gateway入門｜REST APIの作成からLambda連携・認証設定まで現場で使える実践ガイド

「APIサーバーをクラウドで動かしたいけど、NginxやApacheと何が違うんだろう」「Lambdaと組み合わせるとよく聞くけど、実際の設定手順がわからない」——そんな疑問を持ちながらも、なかなか手を動かせていないインフラエンジニアは多いはずです。

オンプレミスではリバースプロキシとWebサーバーを自前で管理してAPIを公開するのが当たり前でした。しかしAWSではその役割をAmazon API Gatewayが担います。インフラの運用管理から解放され、APIのルーティングや認証、スロットリングをマネージドサービスとして利用できます。

この記事では、Amazon API Gatewayの基本概念から、REST APIとHTTP APIの違い、Lambda連携の具体的な設定手順、認証・認可の選び方、料金の仕組みまでを体系的に解説します。

なぜAPI Gatewayなのか？オンプレとの根本的な違い

オンプレミスでAPIを公開する場合、典型的な構成はこうです。物理サーバーにNginxを置いてリバースプロキシとし、バックエンドのアプリケーションサーバーへリクエストを転送する。サーバーの増設、SSL証明書の更新、アクセスログの管理、DDoS対策——これらをすべて自分たちで担います。

Amazon API Gatewayはその役割を丸ごとAWSに委ねるサービスです。

・ルーティング管理: URLパスとHTTPメソッドに応じたバックエンドへの振り分けをGUIまたはCLIで定義できます
・SSL終端: ACMと連携することでHTTPS対応が数クリックで完了します
・スロットリング: リクエスト数の上限設定が組み込み機能として提供されています
・認証・認可: APIキー、IAM認証、Cognitoオーソライザーなど複数の認証方式を選択できます
・モニタリング: CloudWatchと標準統合されており、レイテンシやエラー率を即座に可視化できます

オンプレで当たり前に運用していたこれらの仕組みが、すべてマネージドで提供されます。「サーバーを管理しないでAPIを公開する」という感覚は最初は少し戸惑いますが、慣れると手放せません。

API Gatewayの3種類：何が違うのか

Amazon API Gatewayには現在3種類のAPIタイプが存在します。選択を誤るとコストや機能面で後悔するため、最初に整理しておきます。

**新規で作るならHTTP APIを第一候補にする**のが現在のベストプラクティスです。REST APIが必要になるのは、使用量プランやAPIキーによる細かいアクセス制御、APIキャッシュ、Lambda Authorizerの高度な設定が必要な場合に限られます。

基本的な使い方：HTTP APIを作ってLambdaと連携する

ここではHTTP APIを作成し、Lambda関数と統合する手順を解説します。事前にLambda関数が作成済みであることを前提とします。

1. API Gatewayコンソールでの作成

AWSコンソールの「API Gateway」サービスを開き、「APIを作成」をクリックします。「HTTP API」の「構築」を選択します。

「統合を追加」でLambdaを選択し、連携させるLambda関数をリージョンと合わせて指定します。「APIの名前」に任意の名前を入力し、次の画面でルートを設定します。

デフォルトでは `$default` ステージが作成され、すべてのリクエストがLambdaに転送されます。特定のパスのみをLambdaに転送したい場合は「ルートを設定」でパスとメソッドを指定します。

ステージの設定でデプロイ設定を確認し、「作成」をクリックすれば完了です。エンドポイントURLが発行されます。

2. カスタムドメインの設定

発行されたデフォルトのURLは `https://{api-id}.execute-api.ap-northeast-1.amazonaws.com` という形式です。本番環境では独自ドメインを設定します。

API Gatewayの「カスタムドメイン名」メニューから独自ドメインを追加し、ACMで発行した証明書を紐付けます。Route 53でCNAMEレコードを設定すると、独自ドメインでAPIにアクセスできるようになります。

3. CLIでのデプロイ確認

# AWS CLI: 作成したHTTP APIの一覧確認
aws apigatewayv2 get-apis --region ap-northeast-1

# 特定APIのルート一覧確認
aws apigatewayv2 get-routes --api-id {YOUR_API_ID} --region ap-northeast-1

# curlでAPIの動作確認
curl -X GET "https://{api-id}.execute-api.ap-northeast-1.amazonaws.com/hello"

REST APIとHTTP APIの違いを具体的に理解する

「HTTP APIで始めたけど、あとからREST APIに変えたくなった」というケースは少なくありません。移行は容易ではないため、最初に要件を確認しておくことが重要です。

REST APIにしかない機能：

・APIキャッシュ: レスポンスをキャッシュしてバックエンドへのリクエストを削減できます（ステージ単位で有効化）
・使用量プラン: APIキー単位でリクエスト数やスロットリングの上限を細かく制御できます
・リソースポリシー: IPアドレスやVPCエンドポイントからのアクセス制限を設定できます
・Lambda Authorizer（リクエスト型）: カスタム認証ロジックをリクエストの全パラメータを使って実装できます
・AWS WAFとの統合: WAFを適用してSQLインジェクションやXSS対策を追加できます

HTTP APIで対応できる機能：

・JWTオーソライザー（OIDC/OAuth2）: CognitoやAuth0などのIDプロバイダーとの統合
・Lambda統合: Lambdaとのシンプルな連携
・HTTP統合: 任意のHTTPエンドポイントへのプロキシ
・CORS設定: クロスオリジンリソース共有の設定

社内向けのシンプルなAPIや、Lambdaとの連携がメインであればHTTP APIで十分です。外部公開APIでアクセス制御を細かく設定したい場合はREST APIを選択します。

認証・認可の設定：3つの方式と使い分け

API Gatewayの認証設定はオンプレと発想が異なります。オンプレではアプリケーション層で認証を実装することが多いですが、API Gatewayではインフラ層での認証をサービスとして設定できます。

1. APIキー（シンプルなアクセス制御）

最もシンプルな認証方式です。APIキーを発行し、クライアントにはHTTPヘッダー `x-api-key` に付けてリクエストを送ってもらいます。REST APIのみ使用可能で、使用量プランと組み合わせることで外部パートナーへのAPIアクセス管理に使われます。

注意点は「認証」ではなく「識別」に近い機能だという点です。APIキーは暗号化されていないため、セキュリティの観点ではIAM認証やJWTオーソライザーを優先すべきです。

2. IAM認証（AWS内部での連携）

リクエストをAWS Signature Version 4で署名し、IAMポリシーで権限を制御する方式です。AWS内部サービス間の連携（例：EC2上のアプリケーションからAPI Gatewayを呼び出す）に適しています。

# AWS CLI: IAM認証を使ったAPIリクエスト例
aws apigateway test-invoke-method \
  --rest-api-id {YOUR_API_ID} \
  --resource-id {RESOURCE_ID} \
  --http-method GET \
  --region ap-northeast-1

3. JWTオーソライザー（Cognito連携）

Amazon CognitoやAuth0などのIDプロバイダーが発行するJWTトークンを検証する方式です。モバイルアプリやWebアプリのユーザー認証に最適です。HTTP APIで設定できます。

CognitoユーザープールのIDを指定するだけで設定でき、クライアントはCognitoから取得したIDトークンをAuthorizationヘッダーに付けてリクエストを送ります。

料金の仕組みとコスト試算

API Gatewayの料金は主に以下の3軸で構成されます（東京リージョン、2026年3月時点）。

具体的なコスト試算をしてみます。月間100万リクエスト、平均レスポンスサイズ1KB、HTTP APIを使用した場合：

・リクエスト料金: $1.00
・データ転送（1KB × 100万 = 約1GB）: $0.114
・月額合計: 約$1.11（約160円）

中規模サービスでも月間10億リクエストを超えない限り、API Gateway自体のコストは比較的小さいです。コストの大半はバックエンドのLambda実行料金や、データ転送量によるものになります。

【重要】スロットリングのデフォルト値に注意

API Gatewayにはアカウントレベルのデフォルトスロットリング上限があります。

・デフォルト上限: 10,000 リクエスト/秒（リージョン単位）
・バースト上限: 5,000 リクエスト（同時リクエストの瞬間最大値）

上限に達すると「429 Too Many Requests」が返されます。本番環境でトラフィックが増加する前にAWSサポートに上限引き上げをリクエストしておくことを強く推奨します。

応用・実務Tips

現場でよく使われるパターンをいくつか紹介します。

Lambda Proxyの活用でバックエンドを柔軟に

Lambda統合では「プロキシ統合」を有効にすることを推奨します。プロキシ統合を使うと、API GatewayはリクエストをそのままLambdaに渡し、LambdaのレスポンスをそのままクライアントへHTTPレスポンスとして返します。

HTTPステータスコードやレスポンスヘッダーをAPI Gateway側で変換する「カスタム統合」より保守が楽で、バックエンドの変更に強い構成になります。

CORSの設定を忘れずに

フロントエンドからAPI Gatewayを直接呼び出す場合、CORS（Cross-Origin Resource Sharing）の設定が必要です。HTTP APIでは「CORS」設定から許可するオリジン、ヘッダー、メソッドを指定できます。開発中は `*` を許可しがちですが、本番環境では特定のオリジンのみに絞ることがセキュリティの基本です。

ステージ変数で環境切り替え

REST APIのステージ変数を使うと、環境（dev/stg/prod）ごとに異なるLambda関数やエンドポイントへルーティングを切り替えられます。Lambda関数のエイリアスと組み合わせることで、コードを変更せずに環境切り替えができる構成が実現できます。

# ステージ変数を使ったLambda ARN指定例
# 統合のLambdaARN設定でステージ変数を参照
arn:aws:lambda:ap-northeast-1:{account-id}:function:my-function:${stageVariables.lambdaAlias}

# devステージでlambdaAlias=devを設定
aws apigateway create-stage \
  --rest-api-id {API_ID} \
  --stage-name dev \
  --variables lambdaAlias=dev \
  --region ap-northeast-1

よくあるトラブルと対処法

「502 Bad Gateway」が返される

最もよく遭遇するエラーです。原因のほとんどはLambda関数の問題です。

・Lambda関数が例外をスローしている → CloudWatch Logsで関数のエラーログを確認します
・Lambdaのタイムアウト → API Gatewayのタイムアウトは29秒固定（変更不可）。Lambdaの処理が29秒を超えると502になります
・Lambda関数がJSON形式でレスポンスを返していない → プロキシ統合の場合、`statusCode` と `body` を含むオブジェクトを返す必要があります

「403 Forbidden」が返される

認証・認可の設定ミスが大半です。確認ポイントは以下の通りです。

・APIキー認証: `x-api-key` ヘッダーが正しく付いているか、使用量プランにAPIキーが紐付いているか
・IAM認証: 呼び出し元のIAMロールに `execute-api:Invoke` 権限が付与されているか
・リソースポリシー（REST API）: 送信元IPが許可されているか

CORSエラーが解消されない

HTTP APIではCORS設定をGUIで行った後、**必ずデプロイを再実行**する必要があります。設定変更後にデプロイが走っていないとCORSエラーが継続します。また、Lambdaのレスポンスに含まれるCORSヘッダーとAPI GatewayのCORS設定が競合するケースも多いです。プロキシ統合を使用している場合、LambdaのレスポンスからCORSヘッダーを削除し、API Gateway側に一元管理させることで解消できます。

コールドスタートによるレイテンシスパイク

API Gateway + Lambdaの構成ではLambdaのコールドスタートがレイテンシに影響します。

・Lambdaにプロビジョニング済み同時実行（Provisioned Concurrency）を設定することでコールドスタートを排除できます
・API Gatewayのキャッシュ（REST APIのみ）を有効にして、頻繁なリクエストをキャッシュから返す構成も有効です

コールドスタートの詳細については、「AWS Lambda コスト最適化入門」の記事で解説しています。

LinuxサーバーとAPI Gatewayの接続

既存のオンプレLinuxサーバーや、EC2上のAPIサーバーをAPI Gateway経由で公開するユースケースもあります。この場合、HTTP統合を使ってAPI GatewayからEC2のプライベートエンドポイントやApplication Load Balancer（ALB）へプロキシする構成を取ります。

Linuxサーバーのネットワーク設定については、姉妹サイトLinuxMaster.JPでEC2のネットワーク設計も含めて詳しく解説しています。

本記事のまとめ

Amazon API Gatewayについて、オンプレとの違いから実践的な設定手順まで解説しました。

オンプレでNginxとアプリサーバーの組み合わせで実装していた「APIの公開」という作業が、API Gatewayを使うことでインフラ管理の手間なく実現できます。まずはHTTP APIでLambdaとシンプルに連携する構成から試してみてください。