カレンダー
1234567
891011121314
15161718192021
22232425262728
293031    
       
     12
3456789
10111213141516
17181920212223
24252627282930
       
  12345
6789101112
13141516171819
20212223242526
2728293031  
       
  12345
6789101112
13141516171819
20212223242526
2728     
       
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
   1234
567891011
12131415161718
19202122232425
262728293031 
       
 123456
78910111213
14151617181920
21222324252627
282930    
       
     12
3456789
10111213141516
17181920212223
24252627282930
31      

最新記事

2016.10.3

AWS NATインスタンスをNAT ゲートウェイに置き換えてみた

crown
クラウドテックブログ ★もう一度読みたい良記事賞 5月 同率1位 受賞★

プライベートサブネットのインスタンスからインターネットへ接続するためにプロキシや NAT インスタンスを利用しているケースが多いと思います。
NAT インスタンスに代わる AWS サービスとして NAT ゲートウェイがリリースされていますので、今回は すでに NAT インスタンスを利用している環境で NAT ゲートウェイへ乗り換える設定方法などを纏めたいと思います。

NAT ゲートウェイの特徴

AWS の製品紹介を見るとおおまかに以下の特徴があるようです。

  • パブリックサブネットに作成する必要がある
  • ElasticIP アドレスを指定する必要がある
  • アベイラビリティゾーン(以下 AZ)ごとに冗長性を持たせて実装される
     → AZ に依存しないようにするには、AZごとに作成する必要がある
  • 最大 10Gbps の帯域幅をサポート
  • プロトコルは TCP, UDP, ICMP をサポート
  • セキュリティグループは利用できない
  • ネットワーク ACL は利用できる

現在の環境(NAT インスタンスを利用)

ネットワーク構成

以下のようにプライベートセグメント、パブリックセグメントがあり、プライベートサブネット内のインスタンスがインターネットへアクセスするには NAT インスタンスを経由してインターネットへアクセスします。
逆にプライベートサブネット内のインスタンスにアクセスするには踏み台インスタンスを経由してログインを行うような環境となっています。

overall_before01.png

アクセス制御

セキュリティグループ

三つのセキュリティグループでアクセス制御を行っています。

グループ名 制御 紐づく対象
NAT-CLI-SG 踏み台インスタンスからの SSH のみ許可 プライベートサブネット内のインスタンス
NAT-SG プライベートサブネットからのすべてのアクセスと踏み台インスタンスからの SSH のみ許可 NAT インスタンス
NAT-Bastion-SG オフィスからの SSH のみ許可 踏み台インスタンス

ネットワーク ACL

ネットワーク ACL でのアクセス拒否設定は行っていません。(デフォルト状態)

NAT ゲートウェイへ移行

現在のアクセス経路やアクセスルールを維持したまま、利用中の NAT インスタンスを NAT ゲートウェイに置き換えてみます。

事前確認

NAT ゲートウェイの作成には、EIP が必要になります。
作成時に新しいアドレスを割り当てることはできますが、枯渇していると作成できませんので、必要であれば上限緩和申請を行ってアドレスを割り当てられる状態にしておきます。

NAT ゲートウェイの作成

今回は AWS マネジメントコンソールを利用して NAT ゲートウェイを作成します。

AWS マネジメントコンソールの VPC > NAT ゲートウェイを開き、「NAT ゲートウェイの作成」をクリックします。
create00.png

サブネットにパブリックサブネットを指定して NAT ゲートウェイを作成します。
このとき EIP も一緒に割り当てます。
create02.png

ルートテーブルの設定変更

NAT ゲートウェイを作成した際に出た以下のダイアログで、「ルートテーブルの編集」をクリックします。
ダイアログを閉じてしまった場合は、AWS マネジメントコンソールの VPC > ルートテーブルを開きます。
create03.png

プライベートサブネットを選択して、ルートを編集します。
送信先 0.0.0.0/0 を NAT インスタンスから先ほど作成した NAT ゲートウェイに変更します。
route01.png

動作確認

プライベートサブネットのインスタンスにログインして、インターネットアクセスしてみます。
プライベートサブネットのインスタンスには踏み台インスタンスを経由しないとログインできないので、.ssh/config に下記のような記載をして、踏み台経由でログインできるようにします。

Host nat-bastion
HostName 踏み台インスタンスのグローバル IP
User ubuntu
Port 22
IdentityFile ~/.ssh/秘密鍵

Host nat-cli1
HostName プライベートインスタンスのプライベート IP
User ubuntu
Port 22
IdentityFile ~/.ssh/秘密鍵
ProxyCommand ssh nat-bastion nc %h %p
$ ssh nat-cli1

でログインできます。

$ ssh nat-cli1
Warning: Permanently added '54.238.171.201' (ECDSA) to the list of known hosts.
Warning: Permanently added '172.34.74.59' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-87-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Fri Jun  3 12:01:35 JST 2016

  System load:  0.0               Processes:           97
  Usage of /:   17.3% of 7.74GB   Users logged in:     0
  Memory usage: 5%                IP address for eth0: 172.34.74.59
  Swap usage:   0%

  Graph this data and manage this system at:
    https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

0 packages can be updated.
0 updates are security updates.


Last login: Fri Jun  3 12:01:36 2016 from 172.34.64.226
ubuntu@client1:~$

踏み台インスタンスをホップしてインスタンスにログインできました。
続けて、NAT している外部 IP が NAT ゲートウェイの EIP と同じか確認してみます。

ubuntu@client1:~$ curl -s ifconfig.io
52.193.144.236
ubuntu@client1:~$

NAT ゲートウェイの EIP が返ってきたので、NAT ゲートウェイ経由でインターネットアクセスしていることが確認できました。

apt-get update でもリストが取得できました。

ubuntu@client1:~$ sudo apt-get update
無視 http://ap-northeast-1.ec2.archive.ubuntu.com trusty InRelease
取得:1 http://ap-northeast-1.ec2.archive.ubuntu.com trusty-updates InRelease [65.9 kB]
取得:2 http://ap-northeast-1.ec2.archive.ubuntu.com trusty-backports InRelease [65.9 kB]
ヒット http://ap-northeast-1.ec2.archive.ubuntu.com trusty Release.gpg
-- >8 -- >8 -- snip -- >8 -- >8 --
ヒット http://security.ubuntu.com trusty-security/main Translation-en
ヒット http://security.ubuntu.com trusty-security/universe Translation-en
1,843 kB を 2秒 で取得しました (724 kB/s)
パッケージリストを読み込んでいます... 完了
ubuntu@client1:~$

ping も飛びました。

ubuntu@client1:~$ ping www.yahoo.co.jp
PING www.g.yahoo.co.jp (183.79.131.212) 56(84) bytes of data.
64 bytes from f14.top.vip.kks.yahoo.co.jp (183.79.131.212): icmp_seq=1 ttl=51 time=17.8 ms
64 bytes from f14.top.vip.kks.yahoo.co.jp (183.79.131.212): icmp_seq=2 ttl=51 time=17.7 ms
^C
--- www.g.yahoo.co.jp ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 17.773/17.816/17.859/0.043 ms
ubuntu@client1:~$

NTP も同期できているようなので、UDP も NAT できたようです。

ubuntu@client1:~$ ntpq -p
-----remote-----------refid------st-t-when-poll-reach---delay---offset--jitter
 v157-7-235-92.z 103.1.106.69     2 u 1065   64    0    0.000    0.000   0.000
 chobi.paina.jp  131.113.192.40   2 u   90   64   76    4.446  -11.863  56.773
+laika.paina.jp  133.243.238.163  2 u   18   64  377    4.232  -10.446   0.972
*7c2955f3.i-revo .GPS.            1 u   19   64  377   11.435   -9.885   1.251
+juniperberry.ca 193.79.237.14    2 u   22   64  377  259.687   -9.422   0.678
ubuntu@client1:~$

サポートされている TCP, UDP, ICMP のインターネット接続が可能なことが分かりました。

試しに ubuntu の docker イメージを pull してみました。
掛かった時間は9秒ほど。

ubuntu@client1:~$ time sudo docker pull ubuntu
latest: Pulling from ubuntu
031c24a19e4b: Pull complete
84387ed57eee: Pull complete
ed3bfbcc08f7: Pull complete
81756f259b61: Pull complete
594b6e305389: Pull complete
Digest: sha256:46fb5d001b88ad904c5c732b086b596b92cfb4a4840a3abd0e35dbb6870585e4
Status: Downloaded newer image for ubuntu:latest

real    0m9.009s
user    0m0.023s
sys     0m0.007s
ubuntu@client1:~$

アクセス制御の確認

踏み台インスタンスとプライベートサブネット内のインスタンスはセキュリティグループを変更していないので、アクセス制御に変更はありません。
NAT ゲートウェイがNAT インスタンスと同様インターネットからのアクセスを拒否するか試してみます。

$ ssh ubuntu@52.193.144.236
ssh: connect to host 52.193.144.236 port 22: Connection timed out

NAT ゲートウェイへ SSH を行ってもタイムアウトしてアクセスできませんでした。
他のポートは試していませんが、NAT インスタンスを利用していた時と同様、インターネットからのアクセスは拒否されていると考えられます。

使ってみた感想

とにかく手軽。
インスタンスをデプロイメントする感覚か、それより手軽に NAT ゲートウェイを作成することができました。
NAT ゲートウェイ自体の作成は、稼働するサブネットと EIP を指定するだけなので、肝となるのはルートテーブルの変更です。
複数のプライベートサブネットがある場合は、手数が増えて面倒ですが、現在 NAT インスタンスを利用しているサイトであれば、ルートテーブルのターゲットを NAT インスタンスから NAT ゲートウェイに変更すれば OK です。

awscli を使って変更することもできます。

aws ec2 delete-route --route-table-id rtb-xxxxxxxx --destination-cidr-block 0.0.0.0/0
aws ec2 create-route --route-table-id rtb-xxxxxxxx --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-xxxxxxxxxxxxxxxxx

最後に

NAT インスタンスを利用している環境を NAT ゲートウェイを利用するように変更を行ってみましたが、AWS のサービスなので、簡単な手順で色々な運用から解放されそうです。

ただし、NAT ゲートウェイは一時的に停止することができません。
作成すると一ヶ月分丸々費用が課金されてしまいますので、利用する環境によって、NAT インスタンスが良いか NAT ゲートウェイが良いか変わることが考えられます。

ですので、次回は、どんな環境で NAT ゲートウェイが有利か、NAT ゲートウェイが生かせる環境を考察してみたいと思います。

トール ラモーンさんのプロフィール

  • ペンネーム
    トール ラモーン
  • 業務区分
    システムエンジニア

  • プロフィール
    ロックとバイクをこよなく愛する中年エンジニア
    AWS認定ソリューションアーキテクトを一回で取得