こんちには。船田です。
風邪で寝ている間にマネージドな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を外部に登録していた場合など、再登録不要でスムーズに移行ができそうです。