トップ > AWS > NAT ゲートウェイを簡単セットアップ

NAT ゲートウェイを簡単セットアップ

AWS NAT ゲートウェイ
記事タイトルとURLをコピーする

サーバーワークスブログをご覧の皆さん、初めまして！

2月1日に入社した、技術１課の多田です。

私はこの技術ブログを通じてサーバーワークスを知ったこともあり、初めてのブログ投稿になるため緊張しますが、張り切って書いていこうと思います！

そんな初めての投稿では、VPCの「NAT ゲートウェイ」について書いていきます。

NAT ゲートウェイの詳細については、こちらをご覧下さい。

以下、記事の目次です。

  1. NATゲートウェイの特徴
  2. NATインスタンスとの置き換え
  3. まとめ

1.　NATゲートウェイの特徴

昨年末にVPCのアップデートとしてアナウンスされた、NAT ゲートウェイの特徴には以下のものがあります

  • フルマネージドのNATのため、従来のようなユーザーがNATインスタンスを構築・運用の負荷軽減
  • NAT ゲートウェイは、Elastic IPを紐付けて使用
  • サポートしているプロトコルは、TCP、UDP、ICMP
  • バーストが最大10Gbpsの帯域幅をサポート
  • NATゲートウェイがあるサブネットのトラフィック制御は、ネットワークACLで行う
  • 対象のリージョンは米国東部(北バージニア）、米国西部(オレゴン)、米国西部(北カリフォルニア)、欧州(アイルランド)、アジアパシフィック(東京)、アジアパシフィック(シンガポール)、アジアパシフィック(シドニー)
  • 料金は、１時間当たりの利用料金とデータ通信料で構成される
  • 東京リージョンでは、１時間当たり$0.062と、転送料として1GB毎に$0.062がかかる(EC2のt2.smallとt2.mediumの間の利用料というイメージ)

2.　NATインスタンスとの置き換え

それでは、外部との通信をNATインスタンス経由からNATゲートウェイ経由に変更するにはどう操作するかを見ていきます。

構成としては以下の図のイメージです。

Public Subunet 1a/Public Subnet 1cのNATサーバ2台でインターネットと疎通しています。

片方のサーバーが障害で停止してもルートテーブルの経路を、もう一方のサーバーに変更することで冗長性を保つ設計にしていたとします。

NAT環境変更前

変更後のイメージは、こちらです。

NATサーバーの他に、NAT ゲートウェイが追加されます。

NAT環境変更後

それでは、実際に上記の環境を構成していきます。

まずは、NATゲートウェイを作成します。

マネージメントコンソールよりVPCを選択して、左メニューより「NAT ゲートウェイ」を選択します。

VPC画面

その後、NAT ゲートウェイの作成ボタンをクリックします。

NATゲートウェイ作成ボタン

次に、実際にNAT ゲートウェイを配置するサブネットと紐付けるElastic IPを指定します。

サブネットは、Public Subnet 1a のものを指定しています。

「新しいEIPを作成」ボタンよりElastic IPを自動生成と紐付けをしてくれるので、今回は自動で生成しました。

NAT ゲートウェイ作成画面

そして、「NAT ゲートウェイの作成」ボタンをクリックすれば、NATゲートウェイができました。

簡単ですね。。

NAT ゲートウェイ作成後

次に、ルートテーブルの経路を変更します。

元々、外部との通信経路にはNATサーバーを指定していたのをNAT ゲートウェイに変更します。

変更前の状態がこちらです。

route table変更前

では、変更していきます。

ターゲットには、NAT ゲートウェイのIDを指定します。

route table変更

変更後は、以下のようになります。

route table変更後

以上で作業は完了となりますので、Private Subnet 1a 内のサーバーからtracerouteで動作確認をしてみます。

[ec2-user@ip-10-0-2-166 ~]$ traceroute www.google.com

traceroute to www.google.com (216.58.221.4), 30 hops max, 60 byte packets

 1  10.0.1.112 (10.0.1.112)  0.536 ms  0.531 ms  0.526 ms

 2  ec2-175-41-192-132.ap-northeast-1.compute.amazonaws.com (175.41.192.132)  0.942 ms ec2-175-41-192-128.ap-northeast-1.compute.amazonaws.com (175.41.192.128)  1.097 ms  1.109 ms

 3  27.0.0.154 (27.0.0.154)  2.077 ms 27.0.0.172 (27.0.0.172)  2.202 ms  2.264 ms

 4  27.0.0.154 (27.0.0.154)  2.202 ms 52.95.30.123 (52.95.30.123)  6.252 ms  6.274 ms

 5  52.95.30.186 (52.95.30.186)  2.342 ms 52.95.30.123 (52.95.30.123)  6.298 ms 52.95.30.129 (52.95.30.129)  6.710 ms

 6  52.95.30.196 (52.95.30.196)  2.296 ms 15169.tyo.equinix.com (203.190.230.31)  1.787 ms 52.95.30.194 (52.95.30.194)  1.922 ms

 7  72.14.239.202 (72.14.239.202)  2.129 ms  2.361 ms  2.327 ms

 8  209.85.143.39 (209.85.143.39)  2.142 ms  2.309 ms  2.131 ms

 9  nrt13s38-in-f4.1e100.net (216.58.221.4)  2.086 ms  2.199 ms  2.318 ms

[ec2-user@ip-10-0-2-166 ~]$

 

１番初めの「10.0.1.112」がNAT ゲートウェイのプライベートIPなので、NATゲートウェイを経由して宛先へ到達していることを確認できました。

同様の手順でNAT ゲートウェイを作り、もう一方のAZに配置することで従来通り冗長性を持った状態を構成できます。

3.　まとめ

簡単にですが、NAT ゲートウェイの特徴とNAT ゲートウェイを実際に使ってみた結果を書いてみました。

これまでNATインスタンスを使われていて、NAT ゲートウェイへの置き換えを検討されている方にとってもその敷居は低いと思われたのではないでしょうか？

私自身も数クリックでNAT ゲートウェイを作成して置き換えが簡単だなと実感しましたし、フルマネージドなので運用負担も減らせます。