SW BBANG J

Webアプリに「サインアップ」と「サインイン」を実装しようとしたとき、AWSコンソールを開くと『Cognito User Pools』と『Cognito Identity Pools』という2つの選択肢が並んでいる。どちらを使えばいいのか迷うのは当然で、名前が似ているせいで混同しやすい。結論から言うと、ユーザーのログイン管理には User Pools を使う。Identity Poolsはまったく別の目的のサービスだ。 TL;DR — AWS Cognitoの使い分け早見表 目的 使うべきサービス 主な機能 サインアップ / サインイン / ユーザー管理 Cognito User Pools ユーザーDB、JWT発行、MFA、パスワードポリシー AWSリソース（S3, DynamoDBなど）への一時的アクセス Cognito Identity Pools フェデレーテッドID、STS一時認証情報の払い出し ログイン後にAWSリソースも直接操作させたい 両方を組み合わせる User PoolsでJWT取得 → Identity Poolsで一時認証情報に交換 AWS Cognito User Poolsの仕組みを理解する User Poolsは、アプリケーション専用のユーザーディレクトリだ。メールアドレスとパスワードでサインアップしたユーザーの情報を保持し、認証が成功するとOpenID Connect準拠のJWTトークン（IDトークン、アクセストークン、リフレッシュトークン）を発行する。バックエンドAPIはこのJWTを検証するだけでよく、セッション管理の複雑さをCognitoに委譲できる。 sequenceDiagram participant Browser as ブラウザ participant UserPool as Cognito User Pools part...

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を呼び出した瞬間に 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 -- ...