こんちには。船田です。
風邪で寝ている間にマネージドなNATゲートウェイがリリースされていましたので試してみました。
前提となる構成
踏み台サーバ経由でプライベートサブネット配下のサーバにSSHできるようになっています。
プライベートサブネットからはインターネットに出て行くことができませんので、WindowsUpdateやyum updateなどが行えない状態です。
今までであればCDP:High Availability NATパターンで対応していましたが、今回はNATゲートウェイを使ってみます。
NATゲートウェイの作成
マネジメントコンソールのVPCのところに「NATゲートウェイ」という項目が増えています。こちらをクリックします。
「NATゲートウェイの作成」を押下します。
「サブネット」ではNATゲートウェイを配置するサブネットを指定します。
EIPは既存のものを指定することも、新規に取得して指定することも可能です。
作成して少し待つと「利用可能」になります。
続いてプライベートサブネットに割り当てられているルートテーブルのルートを変更します。
localをターゲットとしたVPC内部への経路に加えて、NATゲートウェイへ向けたデフォルトルートを登録します。
これで作成完了です。
NATゲートウェイの動作確認
踏み台サーバ経由でプライベートサブネット配下のサーバにSSHでログインし、インターネットに向けてpingを実行してみます。
[root@ip-10-0-2-138 ~]# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=3.54 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=3.50 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=3.20 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2509ms rtt min/avg/max/mdev = 3.206/3.419/3.547/0.166 ms
問題なく疎通できました。
今度はtracerouteしてみます。
[root@ip-10-0-2-138 ~]# traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 * 10.0.0.9 (10.0.0.9) 0.614 ms * 2 ec2-175-41-192-132.ap-northeast-1.compute.amazonaws.com (175.41.192.132) 1.139 ms ec2-175-41-192-128.ap-northeast-1.compute.amazonaws.com (175.41.192.128) 1.748 ms ec2-175-41-192-134.ap-northeast-1.compute.amazonaws.com (175.41.192.134) 1.267 ms 3 27.0.0.172 (27.0.0.172) 2.498 ms 2.927 ms 27.0.0.154 (27.0.0.154) 2.518 ms 4 27.0.0.154 (27.0.0.154) 2.652 ms 2.755 ms 2.752 ms 5 15169.tyo.equinix.com (203.190.230.31) 4.504 ms 15.033 ms 27.0.0.136 (27.0.0.136) 4.088 ms 6 216.239.54.11 (216.239.54.11) 4.388 ms 15169.tyo.equinix.com (203.190.230.31) 14.512 ms 4.422 ms 7 72.14.235.155 (72.14.235.155) 3.645 ms 64.233.174.193 (64.233.174.193) 4.518 ms 209.85.255.147 (209.85.255.147) 4.475 ms 8 216.239.54.21 (216.239.54.21) 3.634 ms google-public-dns-a.google.com (8.8.8.8) 3.282 ms 209.85.246.75 (209.85.246.75) 4.181 ms
1hop目がNATゲートウェイのプライベートIPアドレスになっています。
続いて、グローバルIPを確認してみます。
[root@ip-10-0-2-138 ~]# curl httpbin.org/ip { "origin": "52.192.225.244" }
NATゲートウェイのEIPになっていることが確認できます。
金額は?
東京リージョンでは1時間あたり$0.062に加えて、データ転送費用が発生します。
EC2でいうと、t2.smallとt2.mediumの間くらいの料金です。最大10Gbpsまでのトラフィックに対応しているということなので、妥当なところだと思います。
なお、EIPの費用については、NATゲートウェイに関連付けて使用している間は発生せず、NATゲートウェイを削除するなどして関連付けが外れると1時間あたり$0.005が発生します。EC2と同じ扱いですね。
まとめ
非常に簡単に作成できてとても良い感じです。
CDP:High Availability NATパターンの時はいずれかのAZで障害が発生した場合にルートを書き換えて片寄せしたりと手間がかかっていましたが、NATゲートウェイを使うことでそのあたりの手間をなくすことができます。
なお、「ゲートウェイは高可用性のための冗長機能が備わっています。」とありますが、これはあくまでシングルAZ内での冗長性ですので、AZ単位での障害に備えた構成にするには、AZごとに1インスタンスずつNATゲートウェイを作成する必要があります。
また、良いなと思った点として、NATインスタンスのEIPが指定ができることがあります。
既存のNATインスタンスから移行する場合、そこで使っていたEIPをそのまま流用できますので、外部連携のあるシステムなどでNATインスタンスのEIPを外部に登録していた場合など、再登録不要でスムーズに移行ができそうです。