SW BBANG J

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[...

「Lambda関数からRDSに接続しようとしたら、タイムアウトが返ってくる。セキュリティグループは開いているはずなのに」——この症状で詰まるエンジニアは多い。原因の大半はVPC設定の誤解にある。LambdaをプライベートサブネットのRDSに接続するには、Lambda自身もVPC内に配置する必要があり、その設定には正確なサブネットとセキュリティグループの指定が必要だ。 TL;DR — Lambda × プライベートRDS 接続チェックリスト 確認項目 正しい状態 LambdaのVPC設定 VPC・サブネット・セキュリティグループが明示的に指定されている Lambdaのサブネット RDSと同じVPC内のプライベートサブネット（複数AZ推奨） RDSのセキュリティグループ LambdaのSGからのインバウンドを許可するルールが存在する LambdaのIAMロール VPC ENI作成権限（AWSLambdaVPCAccessExecutionRole）が付与されている インターネットアクセス（必要な場合） NATゲートウェイ経由でのルーティングが設定されている なぜLambdaにVPC設定が必要なのか — 接続の仕組み デフォルト状態のLambda関数はAWSが管理するVPC内で動作しており、ユーザーのVPCリソース（RDS、ElastiCacheなど）には直接到達できない。プライベートサブネットに置かれたRDSはパブリックインターネットからアクセス不可能なため、Lambda側もそのVPCに参加する必要がある。 Lambda関数にVPC設定を行うと、AWSはHyperplane ENI（Elastic Network Interface）をユーザー指定のサブネットに作成し、Lambda実行環境をそのVPCに論理的に接続する。この仕組みにより、Lambda関数はRDSと同じネットワークセグメントから通信できるようになる。 graph LR subgraph AWSManaged["AWSマネージドVPC"] LambdaDefault[...

フロントエンドから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 関数が 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 -- ...

SQSキューから取得したメッセージが複数のコンシューマーに重複処理される——この問題はVisibility Timeoutの設定ミスが原因であることがほとんどだ。処理時間がタイムアウト値を超えた瞬間、SQSはそのメッセージを「未処理」と判断して再度可視化し、別のワーカーが同じメッセージを拾ってしまう。 TL;DR：Visibility Timeoutとは何か 項目 内容 定義 コンシューマーがメッセージを受信してから、他のコンシューマーに見えなくなる時間 デフォルト値 30秒 設定範囲 0秒〜43,200秒（12時間） 二重処理の原因 処理時間がVisibility Timeoutを超えるとメッセージが再可視化される 対策 処理時間に余裕を持たせた値を設定、または処理中に延長APIを呼ぶ 削除タイミング 処理完了後に明示的に DeleteMessage を呼ぶ必要がある Visibility Timeoutの仕組みを理解する SQSはメッセージを受信した時点でそのメッセージを一時的に「不可視」にする。これはキューからメッセージを削除するわけではなく、他のコンシューマーから見えなくするだけだ。コンシューマーが処理を完了して DeleteMessage を呼べばメッセージは消える。しかしVisibility Timeoutが切れる前に削除されなければ、メッセージはキューに戻り、再度取得可能になる。 この設計は意図的なものだ。コンシューマーがクラッシュしたり応答しなくなった場合に、メッセージが失われないようにするためのフェイルセーフとして機能している。問題は、正常に動作しているコンシューマーの処理時間がタイムアウトを超えたときに、同じフェイルセーフが誤発動することだ。 sequenceDiagram participant CA as コンシューマーA participant SQS as SQS キュー participant CB as コンシューマーB CA->>SQS: ReceiveMessage SQS...

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サービス"] ...

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 ：ユーザーがオブジェクトを...