投稿

ラベル(ネットワーク)が付いた投稿を表示しています

LambdaからプライベートサブネットのRDSに接続できない — VPC設定の正しい理解と診断手順

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

VPCピアリング接続の設定:同一アカウント・同一リージョンの2つのVPCをプライベートIPで通信させる

同一AWSアカウント・同一リージョンに2つのVPCがあり、EC2インスタンス間をプライベートIPで通信させたい場面は頻繁に起きる。マイクロサービスの分割、共有サービスVPCとの接続、レガシーVPCからの段階移行など、理由は様々だ。VPCピアリングはその最もシンプルな解決策だが、接続リクエストの承認とルートテーブルの更新という2段階の操作を両方のVPCに対して行わないと通信は一切成立しない。片方だけ設定して「なぜ繋がらないのか」と悩むケースが多い。 TL;DR:VPCピアリング設定の全体像 ステップ 操作対象 内容 1 VPC-A(リクエスター) ピアリング接続リクエストを作成 2 VPC-B(アクセプター) ピアリング接続リクエストを承認 3 VPC-Aのルートテーブル VPC-BのCIDRへのルートを追加 4 VPC-Bのルートテーブル VPC-AのCIDRへのルートを追加 5 両VPCのセキュリティグループ 相手VPCのCIDRからのインバウンドを許可 VPCピアリングの仕組みを理解する VPCピアリングは、2つのVPC間にAWSのバックボーンネットワークを経由したプライベートルーティングパスを確立する機能だ。インターネットゲートウェイ、VPNゲートウェイ、NAT装置は一切介在しない。トラフィックはAWSネットワーク内に留まる。 重要な制約として、VPCピアリングは推移的ルーティング(Transitive Routing)をサポートしない。VPC-AがVPC-Bとピアリングし、VPC-BがVPC-Cとピアリングしていても、VPC-AからVPC-Cへは直接通信できない。A-C間の通信が必要なら、別途A-C間のピアリングが必要になる。 また、ピアリングするVPC同士のCIDRブロックが重複していると接続は作成できない。事前にCIDRの重複がないことを確認すること。 graph LR A["VPC-A 10.0.0.0/16"] -->|"1. ピアリングリクエスト作成"| PCX["VPCピアリング接続 pc...

Route 53 AliasレコードとCNAMEレコードの違い — ALBへのドメイン接続で迷ったときの判断基準

ALBをデプロイしてドメインを向けようとしたとき、多くのエンジニアが最初にCNAMEレコードを設定しようとする。しかし example.com のようなゾーンの頂点(Zone Apex)でCNAMEを設定しようとすると、Route 53のコンソールがそれを拒否する。これはDNS仕様の制約であり、Route 53の Aliasレコード がその解決策として設計されている。 TL;DR — AliasとCNAMEの比較 比較軸 CNAMEレコード Route 53 Aliasレコード ゾーンの頂点(example.com)での使用 ❌ 不可(RFC 1034制約) ✅ 可能 DNSクエリ料金 通常のクエリ料金が発生 Route 53リソースへのクエリは無料 TTL制御 任意に設定可能 Route 53が自動管理(設定不可) ヘルスチェック統合 制限あり ターゲットリソースのヘルスチェックと統合可能 IPアドレスの自動追従 不可(CNAMEが指すホスト名のAレコードに依存) ALBのIPが変わっても自動的に追従 対応ターゲット 任意のホスト名 ALB、CloudFront、S3、API Gatewayなど特定AWSリソース Route 53 AliasレコードとCNAMEレコードの仕組み CNAMEレコードはDNSの標準機能で、あるホスト名を別のホスト名に対応付ける。クライアントがCNAMEを解決するとき、DNSリゾルバーは最終的なAレコード(IPアドレス)に到達するまで複数回のクエリを実行する。この仕組み自体は問題ないが、RFC 1034の規定により、ゾーンの頂点(ネイキッドドメイン)にはCNAMEを設定できない。ゾーンの頂点にはSOAレコードとNSレコードが必ず存在しなければならず、CNAMEは他のレコードと共存できないためだ。 Route 53のAliasレコードはAWSが独自に実装したDNS拡張機能で、外部から見るとAレコード(またはAAAAレコード)として振る舞う。Route 53の権威DNSサーバーがAliasを解決するとき、ターゲットリソース(ALBなど)の現在...

ALB が 502 Bad Gateway を返す原因と診断手順 — ターゲットが Healthy でも発生するケース

ターゲットグループのヘルスチェックは全台 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 ...

カスタムVPCのEC2インターネット接続不可を解決する — Internet GatewayとRoute Tableの設定手順

カスタム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 ...