More than 3 years have passed since last update.

Azure NATゲートウェイの冗長構成を検討する

Posted at 2020-05-04

AzureのNATについて

AzureではデフォルトでSNATされる仕組みがあり、パブリックIPを持たないVMからでも外部へアクセスすることが可能です。
しかしながら、この仕組みではIPアドレスが動的に変化してしまいます。（詳細説明は省略します）

Azure上の仕組みでIPアドレスを固定する方法は何パターンか存在しますが、
NATゲートウェイが最近リリースされたようですのでこのリソースを利用したIPアドレス固定を考えます。

AWSのNATゲートウェイと同様である（と想定される）AzureのマネージドNATゲートウェイ、
その構築手順と冗長構成について簡単に纏めます。

パブリックIPを持つVMと持たないVMを作成し、そのサブネットへのNATゲートウェイ紐付け前後で変化を確認します。
※ ここではvm01を踏み台にしてvm02にsshします。

# パブリックIPを持つVM
[root@centos-vm01 ~]# curl ifconfig.me
40.81.187.139

# パブリックIPを持たないVM（SNATされる）
[root@centos-vm02 ~]# curl ifconfig.me
40.74.79.8

Azure NATゲートウェイでは、1つのNATゲートウェイを複数のサブネットに紐づけることが可能です。
※ 当然ですが、1サブネットに複数のNATゲートウェイを紐づける事は不可能です

検索バー等で検索してNATゲートウェイを作成していきます。

可用性ゾーンではゾーン指定なし、もしくはいずれかのゾーンを指定します。

紐づけるサブネットはNATゲートウェイ作成時に指定できますが、リソースの作成後でも修正可能です。

サブネットへの紐付け後、各VMから再度送信元IPアドレスを確認すると、
NATゲートウェイのパブリックIPアドレスでSNATされていることが確認できます。

# パブリックIPを持つVM
[root@centos-vm01 ~]# curl ifconfig.me
40.74.111.48

# パブリックIPを持たないVM
[root@centos-vm02 ~]# curl ifconfig.me
40.74.111.48

NATゲートウェイを作成する際に可用性ゾーンを指定していましたが、なしで指定した場合でも内部ではゾーン1,2,3のいずれかにデプロイされています。
そのため可用性ゾーンレベルでの障害が起こった場合、1/3で障害をNAT環境に影響を及ぼすことになります。（単純計算ではありますが）

AWSではAZを指定してサブネットを作成しますので、AWSでのNAT環境のAZ冗長を考えると、
AZを分けたサブネットに対して同様にAZを分けたNATゲートウェイリソースを作成することになります。

一方でAzureでは、サブネットが可用性ゾーンを跨る様に構成されています。
ここでAWSと同様にゾーンを分けて構成（ゾーン保証）することを考えます。
https://docs.microsoft.com/ja-jp/azure/virtual-network/nat-gateway-resource

ドキュメント中でも説明されていますが、ゾーンを分けてNAT環境を構築する場合は下記の方法となります。

ゾーン毎のスタックを構成することでゾーン冗長を考慮した構成になります。
上記構成では、可用性ゾーン1で障害が発生しても、az2-subnet/az3-subnet上のVMには影響がありません。
（az1-subnetに対して、可用性ゾーン2/3を指定してVMを立ち上げること自体は可能です）

AWS、AzureのNATゲートウェイはゾーン冗長を考慮しなくとも、99.9%以上のSLAで提供されています。

一般的な用途では十分とは思いますが、
アプリケーションの要件でゾーン冗長が必要な場合には、上記の様な構成も一考の余地があるかもしれません。

しかしながら、Azureではサブネットが可用性ゾーンを跨ぐように設計されていますので、
サブネットに対してデプロイするゾーンを決めてVMを立ち上げることが設計思想上正しいかどうかは不明です。。