Azure環境でVPNゲートウェイを利用していると、「スタンバイモード（Updating）」という状態に遭遇することがあります。この状態になるとオンプレミスとのVPN接続が切断され、管理ポータルからの操作も受け付けなくなります。特にBasic SKUを利用している環境では冗長性がなく、障害時に復旧が遅れることも多く報告されています。この記事では、Azure VPNゲートウェイがスタンバイモードに入った場合の原因、確認手順、対応策、そして今後の防止策を具体的に解説します。
Azure VPNゲートウェイが「スタンバイモード」になる原因と確認方法
VPNゲートウェイが「Updating」状態に入る主な原因は、Azureプラットフォーム側のメンテナンスまたは障害対応中に発生するシステム更新です。この際、ゲートウェイの「Provisioning State」がUpdatingとなり、ユーザーからのリセット操作や再接続コマンドがブロックされます。結果として、VPNトンネルが切断され、オンプレミス機器や他のAzure VNetとの通信が停止します。
確認手順
- AzureポータルでVPNゲートウェイの状態を確認し、「Provisioning State」が
Updatingであるかをチェックします。 - 「Resource Health」や「Service Health」でメンテナンスイベントや障害情報を確認します。
- アクティビティログに「Updating」や「Failed」イベントが記録されていないかを確認し、問題の発生タイミングを特定します。
多くのケースでは、Azure側のプラットフォームメンテナンス完了を待つしかなく、ユーザー操作で即時に解消することはできません。状態が「Succeeded」に戻った時点で再度リセット操作を行うのが基本的な対応です。
Basic SKU利用時の制約と推奨対策
Basic SKUのVPNゲートウェイは低コストで手軽に利用できますが、BGP非対応、ゾーン冗長性なし、アクティブ-アクティブ構成非対応といった制限があります。そのため、高可用性を求める環境ではトラブル時の影響が大きくなりやすいのが現実です。以下に、Basic SKUを使う際に取るべき具体的な対策を整理します。
1. リセット自動化と監視の導入
手動でのリセットや再接続では障害対応が遅れるため、自動化が効果的です。Azure Automation Runbookなどを用い、次のような条件で動作するスクリプトを構築すると良いでしょう。
| 監視項目 | トリガー条件 | 対応アクション |
|---|---|---|
| Provisioning State | Updating → Succeeded に変化 | 自動でリセットコマンドを実行 |
| Resource Health | 正常に戻った | 通知＋再接続処理 |
これにより、Azure側の復旧完了を自動的に検知し、早期復旧が可能になります。
2. コールドスタンバイ構成の検討
Basic SKUを使い続ける場合でも、冗長構成を組むことは可能です。具体的には、以下のような方法が有効です。
- 別リージョン、または同一リージョン内に2台目のVPNゲートウェイを設置
- オンプレミス側ファイアウォールで2本目のトンネルを設定し、手動または自動で切替
- ピアリング済みのVNetにもう1台Basicゲートウェイを設けて手動切替構成
これにより、メインゲートウェイがスタンバイ状態に入っても、バックアップ経路で通信を維持できます。
3. GatewaySubnetの適正サイズ確保
GatewaySubnetのCIDRブロックが狭すぎると、更新や再デプロイ時にIPアドレスが不足し、ゲートウェイが正常に動作できなくなる場合があります。推奨は/27以上です。/28以下では拡張に対応できない可能性があるため注意が必要です。
4. 管理用バックドアの用意
VPN障害時にリモート接続できなくなるリスクを軽減するために、Azure BastionやPoint-to-Site（P2S）VPNを管理者用の経路として併用することを推奨します。これにより、VPNゲートウェイが停止してもAzureリソースへアクセス可能な経路を確保できます。
5. 高可用性SKUへの移行
Basic SKUは2026年1月31日をもってサポート終了予定であり、可用性SLAも低いため、より高性能なSKU（VpnGw1AZ以上）への移行が推奨されます。これらのSKUでは以下の利点があります。
- ゾーン冗長構成により単一障害点の排除
- BGP対応による動的ルーティングの実現
- 高いスループットとSLA保証
ただし、Basicからの移行はインプレース変更ができず、再デプロイ（新規作成＋再構成）が必要です。移行計画時にはダウンタイム対策を考慮してください。
障害発生時の具体的な対応ステップ
実際にVPNゲートウェイがスタンバイ状態になった場合は、以下の手順で対応を進めます。
- Azureポータルで「Provisioning State」が
Updatingであることを確認 - 「Service Health」でリージョン障害・メンテナンス情報を確認
- 「Resource Health」でイベントIDを取得
- 状態が「Succeeded」に戻るまで待機（リセットは無効）
- 復旧後、
az network vnet-gateway resetコマンドなどで再リセットを実施 - オンプレミス側のIKE/IPSecセッションを再確立
もし状態が24時間以上変わらない場合や、Resource Healthにイベントが表示されない場合は、Microsoftサポートに問い合わせて「ファブリックレベル再イメージ（再作成）」を依頼してください。
緊急時の回避策と復旧戦略
状況によっては即時復旧が求められるため、以下のような手段を取ることも可能です。
| 対応手段 | 概要 | 注意点 |
|---|---|---|
| SKU変更（例：VpnGw1への変更） | 新しいSKUへの再デプロイを行い再接続 | 再作成のためダウンタイムが発生 |
| 別VNetでの新規ゲートウェイ作成 | 一時的に別経路を確保 | 設定転送が必要、DNSやルート更新に注意 |
| Azure Bastion利用 | VPN経由せず管理接続 | Bastion構築が必要 |
これらを事前にスクリプト化しておくと、緊急時でも迅速な切替が可能になります。
今後の運用・防止策
同様の問題を防止するため、日常運用では以下のポイントを押さえておきましょう。
- Azure Monitorでゲートウェイの状態変化を自動通知
- Resource HealthイベントをLog Analyticsへ転送しアラート化
- 週次でVPNトンネルの再接続テストを実施
- スクリプトによる定期的な構成バックアップ（ARMテンプレート）
また、インシデント発生時の復旧フローをドキュメント化し、関係者が迅速に対応できる体制を整えることも重要です。
まとめ
Azure VPNゲートウェイの「スタンバイモード（Updating）」は、プラットフォーム側の制御下にあるため、ユーザー操作で即時解除はできません。特にBasic SKUを利用している環境では冗長性がないため、障害発生時に長時間接続不能となるリスクがあります。復旧後はリセットや再接続を行い、今後のために監視・自動化・冗長構成の導入を検討することが重要です。将来的には高可用性SKU（VpnGw1AZ以上）への移行を進めることで、安定したVPN運用が実現できます。
コメント