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

同一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...

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

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...