NATとIGW

このレッスンでできるようになること。「プライベートサブネットの EC2 から外へ出たいが、外からは入らせたくない」という要件文を、ルートテーブルの形に翻訳できるようになります。

要件の文から入る

ある企業が、プライベートサブネットの EC2 で夜間バッチを動かしています。バッチは外部 API を呼び、OS のパッチも取得します。セキュリティ部門からは「インターネットからこの EC2 へ着信させてはならない」と言われています。どう作りますか。

答えは パブリックサブネットに NAT ゲートウェイを置き、プライベートサブネットのルートテーブルの 0.0.0.0/0 を NAT ゲートウェイに向けるです。ここで押さえる性質は 1 つだけです。NAT は内から外への通信と、その戻りしか通しません。外から始まる接続は通せません。だから「外向きだけ許す」という要件文にそのまま対応します。

IGW と NAT の線引き

表の最後の行は、コスト要件のシナリオでよく効きます。NAT ゲートウェイは置くだけで課金され、通したデータ量にも課金されます。「S3 への大量転送のコストを下げたい」という要件文が来たら、NAT を経由させない道 (次のレッスンの VPC エンドポイント) を探すのが正解になります。

NAT ゲートウェイを AZ ごとに置く理由

ここが実務でも試験でも落としやすい点です。NAT ゲートウェイは特定のサブネット、つまり特定の AZ の中にあるリソースです。AZ をまたいで冗長化されているわけではありません。

AZ-a にだけ NAT を置き、AZ-a と AZ-c のプライベートサブネットの両方をそこに向けた構成を考えます。AZ-a が落ちると何が起きるでしょうか。AZ-c の EC2 は生きているのに、外向きの経路だけが消えます。バッチは失敗し、パッチも取れません。AZ-c は無傷なのに AZ-a の障害に巻き添えを食うわけです。これはマルチAZ にした意味を打ち消す典型的な設計ミスです。

ですから、要件文に可用性の語がある場合の正解は次の形になります。

• AZ-a パブリックサブネット に NAT ゲートウェイ a
  • AZ-a プライベートサブネットのルートテーブル 0.0.0.0/0 を NAT a へ
• AZ-c パブリックサブネット に NAT ゲートウェイ c
  • AZ-c プライベートサブネットのルートテーブル 0.0.0.0/0 を NAT c へ

ルートテーブルを AZ ごとに分けるのが要点です。1 枚のルートテーブルを両 AZ で共有していると、NAT を 2 台置いても片方しか使われません。

要件語から構成への対応表

よくある引っ掛け

1 つめは、NAT ゲートウェイをプライベートサブネットに置く選択肢です。NAT 自身が外へ出られなければ意味がないので、必ずパブリックサブネットに置きます。

2 つめは、NAT インスタンス (EC2 で自作) を選ばせるものです。動きはしますが、パッチ当てとスケールとフェイルオーバーを自分で持つことになります。「運用の手間を最小に」と書かれていたら NAT ゲートウェイです。逆に極端なコスト最小が要件で小規模なら NAT インスタンスが答えになることもあり、要件語で分かれます。

まとめ

• IGW は双方向、NAT は内から外への発信と戻りだけを通します
• NAT ゲートウェイはパブリックサブネットに置き、プライベート側のルートを向けます
• NAT は AZ 単位のリソースなので、AZ ごとに置いてルートテーブルも分けます
• NAT は時間課金と処理データ量課金がかかるので、コスト要件では経路そのものを疑います
• 運用の手間を最小にという語が出たら NAT インスタンスではなく NAT ゲートウェイです