NATインスタンスから、フルマネージドのVPC NAT gatewayに変更することにしました。
理由はたくさんありますが、一番大きいのはフルマネージドになることです。
NATインスタンスとNATゲートウェイの比較については公式文書が分かりやすいです。
NAT インスタンスと NAT ゲートウェイの比較 – Amazon Virtual Private Cloud
AWS構成図
赤枠のNATインスタンスをやめて、青枠のNATゲートウェイに変更することがゴールとなります。
わたしの構成は貧乏構成なので、Publicサブネットは一つしか用意していません。
冗長化するのであれば、Availability Zone 1cにもPublicサブネットを追加しNATゲートウェイを追加することで構成できます。
VPN NAT Gatewayの追加
こちらの手順から実際にAWSマネージメントコンソールでの作業となります。
まずはNATゲートウェイの作成となります。
VPCを選択して、左メニューより「NAT ゲートウェイ」を選択します。
「NAT ゲートウェイの作成」ボタンをクリックします。
サブネットは「Public subnet 1a」のものを選択します。
VPC用のEIPを作成するために、「新しいEIPの作成」をクリックします。
モザイクの場所に実際に割り当てられたEIP（グローバルIPアドレス）が表示されます。
「NAT ゲートウェイの作成」ボタンをクリックします。
NAT ゲートウェイが作成されました。
続いてルートテーブルの編集を行いますので、「ルートテーブルの編集」をクリックします。
変更前のルートです。
0.0.0.0/0（デフォルトゲートウェイ）のターゲットが、igw-xxxxになっています。
「編集」をクリックします。
igw-xxxxをクリアすると、選択画面が表示されるので、nat-xxxxを選択します。
「保存」をクリックします。
最後にpingやtracerouteコマンドなどでテストして疎通確認がとれれば完了です。
NATインスタンスのEC2を終了させます。
まとめ
NATインスタンスを利用されていて、特別な理由がない人は機会を見てNAT ゲートウェイに変更しましょう。
わたしが今回変更しようと思ったのは、AppStream2.0をテストしたくなり、設定の途中でNATゲートウェイへの対応が必要になったからです。
新しいサービスでもNATゲートウェイがないとダメっていうことが増えてくる可能性もあります。
そのままでも使えますが、新しいサービスにいち早く対応するためにも、新しいサービスへは変更していくことをオススメします。
