CIDR が重複しない 2 つの VPC を作成し、VPC ピアリング接続とルート設定で EC2 同士のプライベート通信(ping)を確立します。
このラボでは、CIDR が重複しない 2 つの VPC(10.10.0.0/16 と 10.20.0.0/16)を一から手作業で構築し、それぞれにサブネットと EC2 を 1 台ずつ配置します。各 VPC にはインターネットゲートウェイ(IGW)を作成・アタッチし、メインルートテーブルに 0.0.0.0/0 → IGW のデフォルトルートを追加します。さらにサブネットの「パブリック IPv4 アドレスの自動割り当て」を有効化し、EC2 起動時にもパブリック IP を有効化することで、SSM エージェントがインターネット経由で Systems Manager に到達できる(=セッションマネージャーで接続できる)状態を作ります。そのうえで VPC ピアリング接続を作成・承認し、両 VPC のルートテーブルに「相手側の CIDR をピアリング接続へ向ける」ルートを追加します。最後にセッションマネージャーで EC2 にログインし、ping でインターネットを経由しない VPC 間プライベート通信が成立することを実機で確認します。
VPC ピアリングは「ルート(経路)」と「セキュリティグループ(許可)」が両方そろって初めて通信できる点が肝です。本ラボはその両方を自分の手で設定し、片方が欠けると通らないことを体感できる構成になっています。
セッションマネージャーで接続できる状態は「パブリック IP が実際に付与されている+IGW+0.0.0.0/0 → IGW ルート+DNS 解決(enableDnsSupport)」の 4 つがすべて揃って初めて成立します。本ラボはパブリック DNS 名(enableDnsHostnames)は使わずプライベート IP で疎通確認まで完結するため、enableDnsHostnames は無効のままで問題ありません。
なお東京リージョンには既存の VPC(デフォルト VPC など)が複数存在し、それぞれにメインルートテーブルがあります。ルートテーブルを操作する手順では、必ず検索バーの属性「VPC」で対象 VPC を選んでから編集することで、別の VPC のルートテーブルを誤って書き換える事故を防ぎます。
cloud_user ロールでサインイン済みであることlab-peer-ssm-role)を新規作成し、それを EC2 にインスタンスプロファイルとして割り当てます。サンドボックスの cloud_user には iam:CreateRole / iam:AttachRolePolicy / iam:PassRole(lab-peer-* ロールおよび SSM 用ロールを EC2 に渡すために必須)が許可されている前提です。もし手順 5 や手順 6 でロール作成・割り当てが権限エラーになる場合は、サンドボックスに用意済みの既存 SSM ロールがあればそれを選択してください(その場合は手順 5 をスキップできます)enableDnsSupport)は「VPC のみ」で作成した VPC では既定で有効なため、通常そのままで問題ありません