この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft LifecycleとAzure VPN Gatewayの公式ドキュメントを確認し、旧本文の固定的なSKU・性能・費用表現を整理しました。検証ステータス：✅ Microsoft公式情報確認済み
Windows Server 2016は固定ライフサイクルポリシーの対象で、日本語版Microsoft Lifecycleでは延長サポート終了が2027年1月12日と案内されています。移行計画では「Azureへ移す」こと自体より、どのワークロードを、どの順番で、どの接続を維持しながら移すかを決めることが重要です。
S2S VPNは「移行ツール」ではなく接続基盤
Azure VPN GatewayのSite-to-Site（S2S）VPNは、オンプレミスネットワークとAzure Virtual NetworkをIPsec/IKEで接続します。Azure Migrateなどの移行サービスそのものとは役割が異なり、移行期間中にオンプレミスとAzureの通信を成立させるためのネットワーク基盤として使います。
基本構成は次の4要素です。
- Azure Virtual Network：移行先のネットワーク。
- VPN Gateway：Azure側のVPN終端。
- Local Network Gateway：オンプレミス側のアドレス範囲やVPN装置をAzureに定義するリソース。
- オンプレミスVPNデバイス：外部向けパブリックIPv4アドレスを持つ対応機器。
移行前に先に決めること
| 確認項目 | 理由 |
|---|---|
| Azureとオンプレミスのアドレス範囲 | 重複すると通常のルーティングが成立しにくい |
| DNS / AD DS依存 | 移行後も名前解決やドメイン認証が必要か確認する |
| 通信量と可用性 | 必要なGateway SKUや冗長構成の判断材料になる |
| 切替・戻し手順 | 障害時にオンプレミスへ戻せるようにする |
| 移行単位 | サーバー単位ではなく、依存する業務システム単位で考える |
可用性が必要ならactive-activeを検討する
MicrosoftのS2S VPNチュートリアルでは、高可用性を重視する構成としてactive-active VPN Gatewayが推奨されています。active-activeでは両方のGatewayインスタンスからトンネルを張ります。ただし、オンプレミス側VPN機器もこの構成に対応している必要があります。
Availability Zone対応リージョンでは、AZ対応SKUによるゾーン冗長も選択肢です。どのSKUが適切かは、必要帯域、接続数、可用性要件、リージョン、現在の料金を確認して決めます。旧記事のように「VpnGw2以上を固定で選ぶ」と決め打ちする必要はありません。
段階移行のイメージ
- 現行サーバー、通信先、AD/DNS、データ同期の依存関係を棚卸しする。
- Azure側VNetとオンプレミス側アドレスが重複しないことを確認する。
- S2S VPNを構成し、疎通・DNS・認証をテストする。
- 検証対象のワークロードからAzureへ移す。
- 監視しながら段階的に切り替え、問題時の戻し手順を維持する。
- 移行完了後、不要になった旧接続・サーバー・一時リソースを整理する。
VPNがつながっただけでは移行完了ではありません。アプリケーション、データ、ID、名前解決、監視、バックアップを一つの移行単位として検証することが重要です。
公式情報
- Microsoft Lifecycle ― Windows Server 2016
- Microsoft Learn ― Create a site-to-site VPN connection
- Microsoft Learn ― Azure VPN Gateway topologies and design
この記事の更新履歴
- 2026-09-14 追加：Windows Server 2016の公式サポート終了日と段階移行の確認項目を追加。
- 2026-09-14 変更：VPN Gatewayを移行そのものではなく接続基盤として位置付け直し、active-activeの条件を整理。
- 2026-09-14 削除：内部style_prompt、本文H1、未検証ドラフト表記、固定的なSKU・スループット・割引率の断定を削除。
