はじめに
こんにちは。はじめまして、katoです。
今回はAmazon VPC Reachability Analyzerを使用してEC2間の通信を確認してみます。
Amazon VPC Reachability Analyzerとは、送信元から送信先までのネットワーク到達可能性を実際のパケットを送信せずに静的な設定情報から分析、検証ができる構成分析ツールです。
検証構成
今回は以下のような構成で検証していきます。
今回はVPC内に２つの異なるサブネットを作成し、それぞれに、インスタンスを１台ずつ配置しました。
EC2-Aを送信元、EC2-Bを送信先としReachability Analyzerでネットワーク設定上の到達可能性と通信経路を分析します。
VPC ├── Subnet-A │ └── EC2-A（送信元） └── Subnet-B └── EC2-B（送信先）
Reachability Analyzerの設定をします。
送信元タイプと送信先タイプにインスタンスを選択します。
送信元にEC2-A、送信先にEC2-Bを設定します。
正常時の検証
まずは正常時の検証をしていきます。
EC2-Bに関連付けたセキュリティグループには、EC2-AのセキュリティグループからのTCP/80を許可するインバウンドルールを設定しました。
設定後パスの分析を実行したところ「到達可能」と表示されました。
これにより、このネットワーク設定ではEC2-AからEC2-BへのTCP/80が到達可能であることが確認できました。
異常時の検証
次に異常時の検証をしていきます。
正常時に記載した、EC2-Bに関連付けたセキュリティグループを削除し到達できない状態を作ります。
| 状態 | EC2-Bのインバウンドルール |
|---|---|
| 正常時 | EC2-AからのTCP/80の通信を許可 |
| 異常時 | TCP/80のルールなし |
設定していない状態でパスの分析をすると以下のように到達不可能と表示されます。
分析結果に確認すると”ENI_SG_RULES_MISMATCH”と表示されました。
調べてみると宛先となるネットワークインターフェースに設定されているセキュリティグループが、対象の通信を許可していない状態を指していることがわかりました。
まとめ
Amazon VPC Reachability Analyzerを使ってEC2間の通信経路を確認することができました。
今回の検証では、EC2-Bのセキュリティグループにインバウンドルールを設定し忘れていたため、最初は「到達不可」と表示されました。
しかし、Reachability Analyzerの分析結果からセキュリティグループに原因があることを確認し、設定漏れに気づくことができました。
意図的に作成した異常だけでなく、実際の設定ミスの原因特定にも活用できたことで、Reachability Analyzerの便利さを実感しました。
