EC2からSESへの疎通に少しハマったので、解決方法とそれに付随して改めてRoute 53 Resolverについて理解したことをまとめます。
事象：EC2からSESのエンドポイントへ繋がらない
EC2から Test-NetConnection コマンドで、SESが持つSMTPエンドポイント email-smtp.ap-northeast-1.amazonaws.com へ疎通確認したところ上手くいかなかったのが始まりです。
構成は以下の図のような形でした。
EC2はアウトバウンド制限してないし、ルートテーブルは「Nat Gateway ⇒ Internet Gateway ⇒ SES」へ確保できているし、どうして通らないんだ？となっていました。
なんとなく「名前解決とVPCエンドポイント辺りが絡んでいそう」と当たりはつけていたくらいです。
調査と原因：VPCエンドポイントの存在
調査を進めたところ、やはり原因はSES用のVPCエンドポイントが存在していたためでした。
元々「オンプレ環境の端末からSESを使用したい」という要件があり、SES用のVPCエンドポイントを作っていました。
実際の構成
VPCエンドポイントを追加した後に、「EC2からもSESを使いたい」という要件が出てきて疎通確認をしたところ、上手くいかないことに気づきました。
この時はまだ「オンプレはVPCエンドポイント経由で繋がるし、EC2はVPCエンドポイントでも直接SMTPエンドポイント指定でも繋がる」と思っていました。
しかし、どうやらVPCエンドポイントを作成した時点で、EC2からの通信もVPCエンドポイント経由になるという結論にたどり着きました。
そうなると、VPCエンドポイントを作成したときはまだ「オンプレ環境からの接続」のみを想定していたため、EC2からの接続はセキュリティグループで許可していなかったわけです。
そのため、VPCエンドポイントのセキュリティグループで拒否され、EC2からSESへは接続が出来ないという状況になっていました。
なぜEC2もVPCエンドポイント経由になったのか？
前置きが長くなりましたが、「じゃあなぜVPCエンドポイントを作成した時点で、EC2はそれ経由の通信になってしまったのか」という点について調べました。
ここで登場するのが「Route 53 Resolver」です。
VPC内の名前解決をなんやかんやしてくれるイメージはありましたが、普段意識したことはありませんでした。
Route 53 Resolverについては公式ドキュメントもありますが、パッと見では少し理解が難しいかもしれません。イメージとしては、VPC内で使える専用DNSサーバーみたいなものです。
VPCのDNS設定について
VPCの設定に「DNS解決を有効化」と「DNSホスト名を有効化」という項目があります。
これらを有効化しないとVPCエンドポイントが使えないということは知っていましたが、これらが具体的になんなのかは知りませんでした。以下にまとめます。
-
DNS解決を有効化
VPC上でRoute 53 Resolverを認識させる。つまり、EC2などのリソースが名前解決出来るようになります。 -
DNSホスト名を有効化
VPC内リソースが、プライベートなドメイン名空間も名前解決できるようになる。VPCエンドポイントが持つ固有のDNS名を指定しても名前解決が出来るようになります。
参考
これらの動きについては以下のサイトがより詳しく実証してくれています。
VPCのDNS解決とDNSホスト名の関係について実機で確認してみた | サーバーワークスエンジニアブログ
名前解決の経路の違い
これらを踏まえると、VPCエンドポイントがあるとEC2からの通信がエンドポイント経由になる理由は以下の通りです。
VPCエンドポイントがない場合
EC2 ⇒ Route 53 Resolver ⇒ パブリックDNS ⇒ SESのパブリックIPが返答される ⇒ Nat Gateway経由で接続
図で示すと以下のような経路です。
+-----------------------------------------------------------------------+
| AWS VPC |
| |
| +--------------------+ |
| | EC2インスタンス | |
| | (プライベートサブ) | |
| +---------+----------+ |
| | |
| | (1) DNSクエリ: email-smtp.ap-northeast-1.amazonaws.com |
| v |
| +---------------------------------------------------+ |
| | Route 53 Resolver (VPC標準のDNSサーバー) | |
| +---------------------------------+-----------------+ |
| | |
| (VPCエンドポイントがないため | (2) インターネット上の |
| プライベートゾーンは不在) | パブリックDNSへ問い合わせ |
| v |
| +-------------------------+ |
| | パブリックDNS | |
| | (インターネット) | |
| +---------+---------------+ |
| | |
| | (3) SESのパブリックIPを返答 |
| v |
| +---------------------------------+-----------------+ |
| | EC2インスタンス (宛先: SESのパブリックIP) | |
| +---------+-----------------------------------------+ |
+-----------------------------------------------------------------------+
VPCエンドポイントがある場合
EC2 ⇒ Route 53 Resolver ⇒ プライベートホストゾーン ⇒ SESのDNS名がVPCエンドポイントのDNS名に置き換えられプライベートIPが返答される ⇒ VPCエンドポイント経由で接続
図で示すと以下のような経路です。
Plaintext
+-----------------------------------------------------------------------+
| AWS VPC |
| |
| +--------------------+ |
| | EC2インスタンス | |
| | (プライベートサブ) | |
| +---------+----------+ |
| | |
| | (1) DNSクエリ: email-smtp.ap-northeast-1.amazonaws.com |
| v |
| +---------------------------------------------------+ |
| | Route 53 Resolver (VPC標準のDNSサーバー) | |
| +---------+-------------------------------+---------+ |
| | | |
| | (2) 優先して確認 | (4) 見つからない場合のみ |
| v v |
| +--------------------+ +-------------------------+ |
| | プライベート | | パブリックDNS | |
| | ホストゾーン | | (インターネット) | |
| | (VPCエンドポイント)| | | |
| +---------+----------+ +---------+---------------+ |
| | | |
| | (3) 一致した場合 | (5) 回答 |
| | プライベートIPを返答 | パブリックIPを返答 |
| v v |
| +--------------------+ +-------------------------+ |
| | VPCエンドポイント | | NAT Gateway | |
| | (ENI) | | | |
| +--------------------+ +-------------------------+ |
+-----------------------------------------------------------------------+
VPCエンドポイントのプライベートホストゾーンが先に見つかるため、名前解決結果としてプライベートIPが返ってきてしまい、エンドポイント側のセキュリティグループに引っかかり疎通が出来なかったという結論でした。
実際にやってみる（検証）
実際にどうなるか検証しました。
まず、エンドポイントがない状態で疎通してみます。
結果としてはパブリックIPが返ってきています。
次にエンドポイントを作成した状態でどうなるか確認します。
まず、VPCエンドポイントが持つDNS名を指定してみます。
プライベートIPが返ってきました。
そして、元々疎通していたSMTPエンドポイントを指定してみます。
VPCエンドポイントが持つプライベートIPと同じ値が返ってきました。
まとめ
今回のトラブルを通して、以下の知見を得ることができました。
Private DNSを有効にしてVPCエンドポイントを作成すると、VPC内リソースからの該当サービスへの通信は、自動的にパブリックな経路からVPCエンドポイント経由（プライベートIP）に切り替わる。
これは「Route 53 Resolver」がパブリックDNSよりもプライベートホストゾーンのレコードを優先して名前解決するためである。
VPCエンドポイント経由に経路が変わるため、エンドポイント側のセキュリティグループで、新たに通信元（今回の場合はEC2）からのインバウンド通信を許可する必要がある。
サービスへの通信経路を設計する際は、ネットワークのルーティング（NAT Gateway等）だけでなく、「名前解決（Route 53 Resolver）がどのように行われるか」もセットで意識することが非常に重要だと再認識しました。
この記事が、同じような事象でハマってしまった方の解決の糸口になれば幸いです！