techblog

AWS NatゲートウェイでAZを跨がないようルートテーブルに定義することが推奨されている件について

NATゲートウェイとサブネットのAZ設定の違いがPING値に与える影響を実際に検証。AZ内とAZ間で大きな差が生じる結果となり、同じAZ内の通信が推奨される理由が明らかになりました。

目次

概要

AWS Certified Advanced Networking – Specialty(ANS-C01)の資格勉強をおこなっていたところ、ある書籍にて「インスタンスからNATゲートウェイへの通信はAZをまたがないよう、ルートテーブルにルートを定義します。」と記載がありました。

私は、当初、NatゲートウェイってAZまたがないと使えないのでは?と思っていましたが、サブネット作成時にAZ選べれたので恥ずかしかったです。

今回は、AZまたぐ場合とまたがない場合の差違について簡単に試してみましたので備忘録として記録します。

検証

サブネット作成時のAZ選択画面

サブネット作成画面で、1a、1cなど選択できることが分かりますね。

private subnet 1a(apne1-az4)に所属したEC2インスタンスからpublic subnet 1a(apne1-az4)に所属したnatインスタンスを経由した時のping値とprivate subnet 1a(apne1-az4)に所属したEC2インスタンスからpublic subnet 1c(apne1-az1)に所属したnatインスタンスを経由した時のping値を計測してみます。

subnet create

ping検証

  • natおよびsubnetともに1a private subnet 1a(apne1-az4)に所属したEC2インスタンスからpublic subnet 1a(apne1-az4)に所属したnatインスタンスを経由した時のping値
[root@nat-test ~]# ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 バイト応答 送信元 8.8.8.8: icmp_seq=1 ttl=103 時間=2.77ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=2 ttl=103 時間=2.39ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=3 ttl=103 時間=2.34ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=4 ttl=103 時間=2.35ミリ秒

--- 8.8.8.8 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.341/2.460/2.770/0.179 ms
  • nat 1c、subnet 1a private subnet 1a(apne1-az4)に所属したEC2インスタンスからpublic subnet 1c(apne1-az1)に所属したnatインスタンスを経由した時のping値
[root@nat-test ~]# ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 バイト応答 送信元 8.8.8.8: icmp_seq=1 ttl=103 時間=6.29ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=2 ttl=103 時間=4.92ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=3 ttl=103 時間=4.94ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=4 ttl=103 時間=4.95ミリ秒

--- 8.8.8.8 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.918/5.274/6.292/0.587 ms

感想

結果、同じAZに属している方が、同じデータセンター内からの接続の為、ping値が早いことが分かりました。

ドキュメントにも以下の様に記載がありました。

NAT ゲートウェイの基本

アベイラビリティーゾーン別に NAT ゲートウェイを作成し、同じアベイラビリティーゾーンに属する NAT ゲートウェイをリソースで使用するようにルーティングを設定します。

普段、気にしないところだったので勉強になりました。