SW BBANG J

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

SNSトピックを作成してメールアドレスを登録したのに、アラートが一切届かない——本番環境の監視を設定した直後にこの状況に陥ると、「SNSが壊れているのか、IAMが間違っているのか」と疑い始めてしまう。ほとんどの場合、原因はずっとシンプルだ。 サブスクリプション確認メールのリンクをクリックしていない 、それだけである。 TL;DR：SNSメール通知が届かない場合の確認ポイント 確認順序 確認内容 期待される状態 1 サブスクリプションのステータス confirmed （ PendingConfirmation は未確認） 2 確認メールの受信（迷惑メールフォルダ含む） 件名「AWS Notification - Subscription Confirmation」 3 SNSトピックのアクセスポリシー パブリッシュ権限が正しく設定されている 4 送信元サービスのIAMロール SNSトピックへの sns:Publish 権限を保持 5 CloudWatchアラームのアクション設定 正しいSNSトピックARNが指定されている SNSメール通知の仕組み：なぜ確認が必要なのか Amazon SNSのEmailサブスクリプションは、スパム防止のためにダブルオプトイン方式を採用している。エンドポイント（メールアドレス）を登録した時点では、サブスクリプションは PendingConfirmation 状態になる。この状態では、トピックにメッセージがパブリッシュされても、そのエンドポイントには配信されない。確認リンクをクリックして初めて confirmed 状態に遷移し、通知が届くようになる。 graph TD A["sns:Subscribe 呼び出し"] --> B["PendingConfirmation 確認メール送信"] B --> C{"確認リンクを クリックしたか？"} C -- "No（期限切れ含む）" --> D["メッセージ配信されない 再サブ...

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

「インスタンスは起動しているのに、ASGが勝手に終了させる」——この現象に直面したとき、最初に疑うべきはヘルスチェックの設定だ。EC2タイプのヘルスチェックはインスタンスの 存在 しか見ていない。アプリケーションがクラッシュしていても、OSが起動していれば「正常」と判断される。Auto Scaling Groupのヘルスチェック設定を正しく理解することは、不要なインスタンス終了を防ぐだけでなく、本当に異常なインスタンスを確実に置き換えるためにも不可欠だ。 TL;DR — ヘルスチェックタイプの選択基準 状況 推奨タイプ 理由 ELBを使用していない EC2 ELBタイプはロードバランサーなしでは機能しない ELBを使用、アプリ死活監視が必要 ELB アプリレイヤーの応答をヘルスチェックに反映できる ELBを使用、インスタンス起動直後に終了される ELB + ウォームアップ期間の確認 ヘルスチェックグレースピリオドの設定ミスが原因のことが多い カスタムアプリ監視が必要 EC2 + カスタムスクリプト ASGのカスタムヘルスチェックAPIで外部から不健全マークを付与 Auto Scaling Groupのヘルスチェックの仕組み ASGのヘルスチェックを理解するには、 誰が ヘルス状態を判定するのかを明確にする必要がある。ASG自身がインスタンスをポーリングするわけではない。ASGは複数のソースからヘルス情報を受け取り、それを元に終了・置換の判断を行う。 graph LR EC2SVC["EC2サービス システムステータス監視"] -->|"Impaired / Stopped"| ASG["Auto Scaling Group ヘルス判定エンジン"] TG["ターゲットグループ アプリHTTPチェック"] -->|"Unhealthy"| ASG CUSTOM["外部スクリプト SetInstanceHealth API"] --...

ターゲットグループのヘルスチェックは全台 Healthy なのに、ALB が 502 を返し続ける。このパターンは本番障害の中でも特に混乱しやすい。ヘルスチェックが通っているという事実が「アプリは正常」という誤った確信を生み、実際の原因であるHTTPプロトコル違反やコネクション管理の問題を見落とさせる。 TL;DR — ALB 502 の主要原因と対処 原因カテゴリ 具体的な症状 対処の方向性 不正な HTTP レスポンス ステータス行・ヘッダーの形式違反 アプリのレスポンス形式を修正 Keep-Alive タイムアウトのミスアライン 断続的な 502、ピーク時に増加 アプリ側の idle timeout を ALB より短く設定 接続リセット (RST) ALB がレスポンス受信前に RST を受け取る アプリのクラッシュ・OOM を調査 プロトコルミスマッチ HTTPS ターゲットに HTTP で応答、またはその逆 ターゲットグループのプロトコル設定を確認 レスポンスヘッダーサイズ超過 特定リクエストのみ 502 レスポンスヘッダーを削減 ALB 502 の仕組み — なぜ Healthy でも発生するか ALB のヘルスチェックとリクエスト転送は独立したコネクションで動作する。ヘルスチェックは設定したパス（例: /health ）に対して単純な HTTP GET を発行し、期待するステータスコードが返れば Healthy と判定する。これはアプリが 生きているか を確認するだけで、任意のリクエストに対して正しい HTTP レスポンスを返せるかは検証しない。 502 は ALB がバックエンドから有効な HTTP レスポンスを受け取れなかったことを意味する。具体的には以下のいずれかが発生している。 バックエンドが接続を確立したが、整形式の HTTP レスポンスを返さなかった バックエンドがレスポンスを返す前に接続をリセット (TCP RST) した ALB がレスポンスを受信する前にバックエンドが接続を閉じた sequenceDiagram ...

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

カスタムVPCを作成してパブリックサブネットにEC2インスタンスを起動したのに、 ping google.com が通らない。この問題はVPC構築時に最もよく遭遇するトラブルで、原因はほぼ必ずInternet GatewayのアタッチかRoute Tableのルート設定の抜け漏れにある。デフォルトVPCと違い、カスタムVPCはこれらのリソースを明示的に構成しなければインターネット疎通は一切得られない。 TL;DR — EC2インターネット接続不可の原因と対処 確認レイヤー よくある原因 対処 Internet Gateway 作成済みだがVPCにアタッチされていない IGWをVPCにアタッチ Route Table 0.0.0.0/0のルートが存在しない IGWへのデフォルトルートを追加 サブネット関連付け パブリックサブネットがカスタムRoute Tableに関連付けられていない サブネットをRoute Tableに明示的に関連付け パブリックIPアドレス インスタンスにパブリックIPが割り当てられていない サブネットの自動割り当て設定を有効化、またはElastic IPを割り当て Security Group アウトバウンドルールが制限されている アウトバウンド0.0.0.0/0を許可 Network ACL サブネットレベルのACLがトラフィックを拒否している インバウンド/アウトバウンドルールを確認 カスタムVPCのインターネット接続がどのように機能するか デフォルトVPCはAWSが自動的にIGWのアタッチとRoute Tableの設定を済ませた状態で提供される。カスタムVPCにはそれがない。EC2インスタンスがインターネットに到達するには、パケットが通過しなければならないレイヤーが複数存在する。 graph LR EC2["EC2インスタンス パブリックIP必須"] --> SG["Security Group ステートフル"] SG --> NACL["Network ACL ...