投稿

ラベル(サーバーレス)が付いた投稿を表示しています

API Gateway Lambda プロキシ統合とは?標準統合との違いとイベントオブジェクトへの影響を徹底解説

API Gateway で Lambda 関数を呼び出す方法を調べると、必ず『プロキシ統合』と『標準統合(非プロキシ統合)』という2つの選択肢に行き当たる。設定画面でチェックボックスひとつの違いに見えるが、Lambda 関数が受け取る event オブジェクトの構造、そしてレスポンスの返し方が根本的に変わる。どちらを選ぶかを誤ると、関数側でリクエストヘッダーが取れない、ステータスコードが固定されてしまうといった問題が本番環境で表面化する。 TL;DR — Lambda プロキシ統合 vs 標準統合 観点 Lambda プロキシ統合 標準統合(非プロキシ) マッピングテンプレート 不要(API Gateway が自動生成) 必須(VTL で自分で定義) event オブジェクト 固定スキーマ(headers, pathParameters, body など) テンプレートで自由に成形 HTTP ステータスコード制御 関数の戻り値で指定 API Gateway のメソッドレスポンスで設定 レスポンス変換 関数が JSON 構造を返す責務を持つ API Gateway 側でマッピング可能 向いているユースケース REST API の新規開発、マイクロサービス 既存バックエンドとの統合、レガシー変換 Lambda プロキシ統合の仕組みを理解する プロキシ統合を有効にすると、API Gateway は受信した HTTP リクエストをほぼそのまま Lambda に転送する。『ほぼそのまま』というのがポイントで、実際には API Gateway が決められたスキーマの JSON オブジェクトに変換して Lambda を呼び出す。このスキーマが Lambda プロキシ統合イベント と呼ばれる構造だ。 逆方向も同様で、Lambda 関数は API Gateway が期待する特定の JSON 構造をレスポンスとして返さなければならない。この構造を満たさない場合、API Gateway はクライアントに 502 Bad Gateway を返す。 graph LR Client[...

API Gateway CORSエラーの完全解決ガイド:コンソール設定とLambdaレスポンスヘッダーの両方が必要な理由

フロントエンドからAPI Gatewayを呼び出した瞬間に Access-Control-Allow-Origin エラーが出る。コンソールで「CORS を有効化」をクリックしたのに、まだ失敗する。この状況は、API GatewayのCORS設定が「2箇所に分散している」という構造を理解していないと、何度設定し直しても同じ結果になる。 TL;DR:API Gateway CORSエラーの全体像 レイヤー 担当する処理 設定箇所 プリフライトリクエスト (OPTIONS) ブラウザが事前確認するリクエストへの応答 API Gatewayコンソール「CORS を有効化」 実際のAPIレスポンス (GET/POST等) Lambda関数が返すレスポンスヘッダー Lambda関数のコード内 認証付きリクエスト Cookieや認証ヘッダーを含む場合の追加設定 両方に credentials 関連の設定が必要 CORSがAPI Gatewayでどう機能するか ブラウザはクロスオリジンのAPIリクエストを送る前に、 プリフライトリクエスト と呼ばれるOPTIONSメソッドのHTTPリクエストを自動的に送信する。このプリフライトに対してAPI Gatewayが適切なCORSヘッダーを返さないと、ブラウザは実際のリクエストをブロックする。 問題の核心は、API Gatewayには2種類のエンドポイントタイプがあり、それぞれCORSの設定方法が異なる点にある。 REST API (v1) :OPTIONSメソッドをAPI Gatewayレベルで処理し、Lambdaレスポンスにも別途ヘッダーが必要 HTTP API (v2) :API Gatewayが組み込みのCORSサポートを持ち、設定がシンプル sequenceDiagram participant B as ブラウザ participant AG as API Gateway participant L as Lambda B->>AG: OPTIONSリクエスト (プリフライト) AG...

Lambda タイムアウト設定を変更する方法:上限・注意点・実運用パターン

Lambda 関数が 3 秒で強制終了されるのに、処理には 10 秒必要——このギャップに気づくのは大抵、本番で初めてタイムアウトエラーを踏んだときだ。デフォルトの 3 秒という設定は「軽量な同期処理」を想定したものであり、外部 API 呼び出しやデータ変換処理を含む関数には最初から合っていない。この記事では Lambda タイムアウトの変更手順、上限値、そして設定ミスが引き起こす実運用上の問題を具体的に解説する。 TL;DR:Lambda タイムアウト設定の要点 項目 内容 デフォルト値 3 秒 最大値 900 秒(15 分) 変更スコープ 関数レベル(バージョン・エイリアス単位ではない) 変更方法 AWS コンソール / AWS CLI / IaC(CloudFormation・Terraform) 課金への影響 タイムアウト値ではなく実際の実行時間で課金される 関連する上流サービスの制限 API Gateway の統合タイムアウトは最大 29 秒(変更不可) Lambda タイムアウトの仕組みを理解する Lambda のタイムアウトは「関数が起動してから強制終了されるまでの最大壁時計時間」だ。CPU 時間でも I/O 待機時間でもなく、呼び出しから終了までの経過時間で計測される。設定値に達した瞬間、Lambda ランタイムはハンドラーを問答無用で終了させ、呼び出し元には Task timed out after X.XX seconds というエラーを返す。 重要なのは、タイムアウトは関数設定に紐づくという点だ。同一コードを使う複数の関数があれば、それぞれ独立して設定できる。また、Lambda レイヤーや VPC 設定はタイムアウト値に影響しないが、コールドスタートの初期化時間はタイムアウトのカウントに含まれる。 graph LR A["呼び出し開始 タイマースタート"] --> B["関数処理中"] B --> C{"タイムアウト 到達?"} C -- ...

Lambda環境変数の使い方とKMS暗号化:DBエンドポイントをコードから切り離す実践ガイド

Lambdaのコードにデータベースエンドポイントをハードコードしたまま本番デプロイしてしまった経験は、エンジニアなら一度はある。設定値が変わるたびにデプロイが必要になり、最悪の場合は認証情報がリポジトリに残る。Lambda環境変数とKMS暗号化を組み合わせることで、この問題を構造的に解決できる。 TL;DR:Lambda環境変数とKMS暗号化の要点 項目 内容 環境変数の設定方法 コンソール・CLI・CloudFormation/CDKで設定可能 デフォルト暗号化 保存時はAWS管理キー(aws/lambda)で自動暗号化 カスタムKMS暗号化 顧客管理キー(CMK)を指定して追加保護が可能 コード側の取得方法 process.env / os.environ など言語標準の環境変数APIで取得 注意点 環境変数の値はLambdaコンソールで平文表示される(CMK指定時はコンソール上で暗号化テキストとして表示可能) Lambda環境変数の仕組みを理解する Lambda環境変数は、関数コードから分離された設定値をランタイム起動時に注入する仕組みだ。コンテナイメージで言えば、 docker run -e KEY=VALUE に相当する。関数が実行されると、設定した環境変数はOSレベルの環境変数としてランタイムプロセスに渡され、コードからは通常の環境変数として読み取れる。 暗号化の層は2段階ある。まず、すべての環境変数はAWSのインフラ側でAWS管理キー( aws/lambda )を使って保存時に暗号化される。これはデフォルト動作で、追加設定は不要だ。次に、顧客管理キー(CMK)を指定すると、そのキーで追加の暗号化レイヤーが適用される。CMKを使う場合、コンソール上での値の表示が暗号化テキストになり、復号にはKMSへのアクセス権限が必要になる。 graph TD Dev["開発者 / CI"] -->|update-function-configuration| LambdaService["Lambdaサービス"] ...

LambdaとS3の無限ループを止める:再帰トリガーの原因と3つの対策

S3バケットへのアップロードをトリガーにLambdaが起動し、処理結果を同じバケットに書き戻す——この構成は一見シンプルだが、Lambda無限ループという本番障害の定番パターンだ。気づいたときにはLambdaの同時実行数が上限に張り付き、コストが爆発している。 TL;DR:Lambda S3再帰トリガー対策まとめ 対策 難易度 確実性 適用場面 プレフィックス/サフィックスフィルタ 低 中 入出力パスが明確に分離できる場合 出力バケットを完全分離 低 高 新規設計・構成変更が可能な場合 オブジェクトメタデータで処理済みフラグ 中 中 同一バケット・同一パスが必須の場合 なぜLambda S3再帰トリガーが発生するのか S3のイベント通知は、バケット上で発生したオブジェクト操作イベント( s3:ObjectCreated:* など)をLambdaに配信する仕組みだ。Lambdaが処理結果を同じバケットに PutObject すると、それ自体が新たな ObjectCreated イベントを発生させる。S3はそのイベントを再びLambdaに送り、Lambdaはまた書き込み、以降これが繰り返される。 graph LR User["ユーザー"] -->|"PutObject"| S3["S3バケット"] S3 -->|"ObjectCreated イベント"| Lambda["Lambda関数"] Lambda -->|"処理結果をPutObject"| S3 S3 -->|"再びObjectCreated"| Lambda Lambda -->|"また書き込み..."| S3 style S3 fill:#FF9900,color:#fff style Lambda fill:#FF6B6B,color:#fff Upload :ユーザーがオブジェクトを...