そう感じているエンジニアは多い。Azureは世界有数のクラウドプラットフォームだが、azure network outageは過去に複数回発生しており、VNetの設計次第でサービスへの影響を最小化できる。
この記事では、RHEL 9系～Ubuntu 22.04 LTSを想定環境として、azure network outageを想定したVNet冗長設計の考え方と、az cliによる実装手順を解説する。Availability Zoneをまたいだゾーン冗長化・NAT Gateway設定・User Defined Routeによるバイパス経路の構成から、障害発生時の初動診断・接続が戻らないときのトラブルシューティングまでを手順書形式で説明する。
この記事のポイント
・azure network outageはゾーン冗長設計で影響を最小化できる
・Standard LBとNAT GatewayでOutage耐性を大幅に上げられる
・az cliで経路・接続性を障害時に即座に診断できる
・復旧後に繋がらない主因はNSG・SNAT・DNSキャッシュ
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Azure Network Outageで何が起きるか｜VNetの障害パターンを理解する
「障害が起きた」と一言で言っても、azure network outageが発生する場所はいくつかのレイヤーに分かれている。どのレイヤーで何が起きているかを把握しないと、設計の方向性も対処方法も変わってしまう。・コントロールプレーン障害: リソース管理API（ARM）への接続が失われる。新規VMの起動や設定変更ができなくなるが、すでに動いているVMの通信はしばらく継続することが多い
・データプレーン障害: VNet内の実際のパケット転送に影響する。VM間通信やインターネット向けアウトバウンドが断絶し、稼働中のサービスに直接の影響が出る
・ネットワークリソース障害: Load Balancer・NAT Gateway・VPN Gatewayなど、Azureが管理するネットワークリソース自体がダウンする。特にBasic SKUのLoad Balancerを使っている環境では、ゾーン障害時にトラフィックが全断になりやすい
データプレーン障害の場合、アウトバウンドトラフィックが特定のリージョン内でドロップするケースが典型的だ。VNet内のプライベートDNSが応答しなくなる障害も起きることがあるため、Linuxサーバー側のDNS設定（Linux DNS 設定の基本）を把握しておくと、原因の切り分けが速くなる。
障害を想定したVNet設計の考え方｜ゾーン冗長とリージョン分散
1. Availability Zoneをまたいだサブネット設計
Azure Availability Zone（AZ）は、同一リージョン内の物理的に独立したデータセンター群だ。1つのAZが停止しても、他のAZのVMは影響を受けない。設計のポイントは次の3つ：
・サブネットはAZ非依存にする（サブネットを特定のAZに縛らない）
・VMはAZをまたいで分散配置する（zone=1, zone=2, zone=3）
・Standard SKUのLoad Balancerを使う（ゾーン冗長対応。Basic SKUは非対応）
この設計でゾーン単位の障害は吸収できる。リージョン全体がダウンするケースには、クロスリージョン構成が必要になる。
2. クロスリージョン構成でフェイルオーバーを準備する
東日本リージョン（Japan East）で障害が発生した場合に備え、西日本（Japan West）にセカンダリ環境を持つ構成が有効だ。ただしコストが実質倍増するため、RPO（目標復旧時点）とRTO（目標復旧時間）の要件と照らして判断する。コストを抑えたい場合は「Warm Standby」——リソースは確保しておくがVMを停止状態にする——が現実的な選択肢になる。セカンダリ側のVMを停止しておけば、コンピューティングコストを最小限に抑えながらフェイルオーバー準備を維持できる。
AzureのVNetを使ったLinuxインフラを体系的に学びたい場合は、Azure Linux 実践講座も参考にしてほしい。ゾーン設計からNSG・障害対応まで一通りカバーしている。
az cliで冗長構成を実装する実践手順
1. ゾーン冗長のStandard Load Balancerを作成する
Standard SKUのLoad Balancerはゾーン冗長に対応しており、フロントエンドIPを3つのAZ全てに分散させることができる。Basic SKUではゾーン冗長が使えないため、新規構築では必ずStandardを選ぶこと。# Standard SKUのLoad Balancerを作成する az network lb create --resource-group myRG --name myLB --sku Standard --public-ip-address myPublicIP --public-ip-sku Standard --frontend-ip-name myFrontEnd --backend-pool-name myBackEndPool # フロントエンドIPにゾーン冗長を設定する（3つのAZに分散） az network lb frontend-ip update --resource-group myRG --lb-name myLB --name myFrontEnd --zones 1 2 3 # 出力例（環境により異なります） # { # "name": "myFrontEnd", # "zones": [ # "1", # "2", # "3" # ] # }
2. NAT GatewayとPublic IP Prefixで安定したアウトバウンドを確保する
NAT GatewayはAzure Network Outage時でも比較的安定したアウトバウンド経路を提供するリソースだ。Basic LBのデフォルトSNAT（SNATポート枯渇問題が起きやすい）からNAT Gatewayに移行することで、アウトバウンド接続の信頼性が上がる。# Public IP Prefixを作成する（固定プレフィックスでアウトバウンドIPを安定させる） az network public-ip prefix create --resource-group myRG --name myIPPrefix --length 31 --sku Standard # NAT Gatewayを作成する az network nat gateway create --resource-group myRG --name myNATGateway --public-ip-prefixes myIPPrefix --idle-timeout 10 # サブネットにNAT Gatewayを関連付ける az network vnet subnet update --resource-group myRG --vnet-name myVNet --name mySubnet --nat-gateway myNATGateway # 出力例（環境により異なります） # { # "natGateway": { # "id": "/subscriptions/.../natGateways/myNATGateway" # } # }
3. User Defined Route（UDR）でバイパス経路を設定する
特定のNVA（Network Virtual Appliance）を経由したバイパス経路を設定しておくと、メイン経路がダウンしてもトラフィックを迂回させられる。# Route Tableを作成する az network route-table create --resource-group myRG --name myRouteTable # バイパス経路を追加する（NVAを経由する経路の例） az network route-table route create --resource-group myRG --route-table-name myRouteTable --name bypassRoute --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.1.4 # サブネットにRoute Tableを適用する az network vnet subnet update --resource-group myRG --vnet-name myVNet --name mySubnet --route-table myRouteTable # 適用後の確認 az network vnet subnet show --resource-group myRG --vnet-name myVNet --name mySubnet --query "routeTable" # 出力例（環境により異なります） # { # "id": "/subscriptions/.../routeTables/myRouteTable" # }
Azure Network Outage発生時の検出と初動対応
1. Azure Status / Resource Healthを確認する
障害が疑われるときは、まず公式ステータスページで状況を把握する。自分の環境の問題か、Azure全体の障害かを切り分けるための最初の一手だ。・Azure Status（https://status.azure.com/）: リージョン・サービス単位の障害情報を確認できる
・Resource Health: Azureポータルで各リソースの「リソース正常性」を開くと、自分のリソースへの影響を直接確認できる
・Activity Log: リソースグループ単位で直近のイベントを確認できる。いつから障害が始まったか特定しやすい
az cliでVMの稼働状態を確認するには次のコマンドを使う：
# VMのインスタンスビューから稼働状態を確認する az vm get-instance-view --resource-group myRG --name myVM --query "instanceView.statuses[].displayStatus" # 出力例（環境により異なります） # [ # "ProvisioningState/succeeded", # "PowerState/running" # ]
2. az コマンドで経路・接続性を診断する
Network Watcherを使うと、VM間の通信経路やNSGのブロック有無をazコマンドから確認できる。# Network Watcherが有効かどうか確認する az network watcher list --output table # 2つのVM間の接続チェック（IPフロー確認） az network watcher test-ip-flow --direction Inbound --local 10.0.0.4:80 --remote 10.0.1.5:12345 --protocol TCP --vm myVM --resource-group myRG # 出力例（環境により異なります） # { # "access": "Allow", # "ruleName": "AllowAzureLoadBalancerInBound" # }
トラブルシュート｜Outage後に接続が戻らないときの対処
Azure Network Outageの復旧後も接続が戻らないケースは、主に次の3つの原因が多い。1. NSGのセッション状態が残っている
Outage中に確立されたTCPセッションが中途半端な状態のまま残り、接続が戻っても古いセッションがNSGに引っかかるケースがある。VMのネットワークインターフェースをNSGから一時的にデタッチして再アタッチすると解消することが多い。# NSGをデタッチする az network nic update --resource-group myRG --name myNIC --network-security-group "" # 数秒待ってから再アタッチする az network nic update --resource-group myRG --name myNIC --network-security-group myNSG
2. NAT GatewayのSNATポートが枯渇している
障害復旧直後に大量のコネクションが一斉に張られると、NAT GatewayのSNATポートが一時的に枯渇することがある。Azure MonitorでNAT Gatewayメトリクスの「SNATポートの使用率」を確認する。枯渇が続く場合は、Public IP Prefixの/31（2IPアドレス）を/30（4IPアドレス）に拡張するか、アプリケーション側でコネクションプールを設定してコネクション数を制限する。3. DNSキャッシュに古い情報が残っている
VNet内のAzure Private DNSが障害から復旧しても、LinuxサーバーのDNSキャッシュに古い情報が残っている場合がある。# systemd-resolvedを使っている場合はキャッシュをフラッシュする sudo systemd-resolve --flush-caches # nscdを使っている場合 sudo systemctl restart nscd # AzureのマジックIP（168.63.129.16）に直接問い合わせて確認する dig @168.63.129.16 myvm.internal.cloudapp.net # 出力例（環境により異なります） # ;; ANSWER SECTION: # myvm.internal.cloudapp.net. 10 IN A 10.0.0.4
本記事のまとめ
| やること | azコマンド・対処方法 |
|---|---|
| ゾーン冗長LBを作成する | az network lb create --sku Standard |
| LBフロントエンドをゾーン冗長にする | az network lb frontend-ip update --zones 1 2 3 |
| NAT Gatewayをサブネットに設定する | az network vnet subnet update --nat-gateway |
| UDRでバイパス経路を設定する | az network route-table route create |
| VMの稼働状態を確認する | az vm get-instance-view --query instanceView.statuses |
| VM間接続をIPフロー確認する | az network watcher test-ip-flow |
| NSGをデタッチして再アタッチする | az network nic update --network-security-group "" |
| DNSキャッシュをフラッシュする | sudo systemd-resolve --flush-caches |
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AzureでのLinuxインフラ設計を実践形式で学べる講座を用意しています。VNet冗長設計・NAT Gateway・障害対応まで、ハンズオン形式でお伝えしています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：azure Basic SKUロードバランサーをTerraformで構築する手順｜Standard移行との比較
- この記事の属するカテゴリ：Azureへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます