Azure と Google Cloud（GCP）をまたいで固定 IP を使う場面は、主に「両クラウドの Web サーバーを DNS で切り替える」「外部サービスに送信元 IP を許可してもらう」「クラウド間を VPN でつなぐ」の三つです。この記事では、Azure Public IP と GCP の静的外部 IP アドレスそれぞれの性質を整理したうえで、場面ごとの設定手順と注意点を説明します。WordPress を両クラウドで運用する例を想定していますが、考え方は他の Web システムでも同じです。
両クラウドの固定 IP の性質
名前は似ていても、両者は仕様が違います。最初に違いを押さえておくと、設計の判断がしやすくなります。
Azure Public IP
Azure Public IP はリソースとして作成し、VM のネットワークインターフェース、ロードバランサー、NAT Gateway、VPN Gateway などに関連付けます。SKU には Standard と Basic がありましたが、Basic SKU の Public IP は 2025年9月30日で提供終了が告知されていたため、新しく作るなら Standard を前提にしてください（2026年10月現在）。Standard SKU は割り当て方法が静的のみで、既定では受信を遮断する設計のため、NSG で許可したポートだけが通ります。可用性ゾーンをまたぐゾーン冗長の指定もできます。
Public IP はリージョンに属し、別リージョンへそのまま移すことはできません。連続したアドレス範囲を確保したい場合は Public IP Prefix を使います。
GCP の静的外部 IP アドレス
GCP では、VM に割り当てた外部 IP は既定ではエフェメラル（一時的）で、VM を停止・削除すると変わる可能性があります。固定したい場合は静的外部 IP アドレスとして予約します。種類は二つあり、VM やリージョン内のロードバランサーで使う「リージョン」アドレスと、グローバル外部アプリケーションロードバランサーなどで使う「グローバル」アドレスです。どちらを予約するかは、関連付けるリソースで決まります。
予約したまま使っていない静的 IP にも料金がかかる点は、両クラウドに共通する注意点です。料金の詳細は各社の公式ページで確認してください。
固定 IP を作成する
Azure CLI での作成
az network public-ip create \
--resource-group rg-wp \
--name pip-wp-web \
--sku Standard \
--allocation-method Static \
--version IPv4 \
--zone 1 2 3
# 割り当てられたアドレスを確認
az network public-ip show \
--resource-group rg-wp \
--name pip-wp-web \
--query ipAddress -o tsv--zone 1 2 3 はゾーン冗長の指定で、ゾーンに対応したリージョンでのみ使えます。ゾーン指定は作成後に変更できないため、最初に決めておきます。
gcloud での予約
# リージョンの静的外部 IP（VM 用）
gcloud compute addresses create wp-web-ip --region=asia-northeast1
# グローバルの静的外部 IP（グローバル外部アプリケーション LB 用）
gcloud compute addresses create wp-lb-ip --global --ip-version=IPV4
# アドレスの確認
gcloud compute addresses describe wp-web-ip \
--region=asia-northeast1 --format="value(address)"すでに稼働中の VM のエフェメラル IP をそのまま固定したい場合は、gcloud compute addresses create wp-web-ip --addresses=現在のIP --region=asia-northeast1 のように、使用中のアドレスを指定して静的に昇格できます。DNS を書き換えずに済むので、運用中のサイトではこちらが便利です。
場面1：両クラウドの Web サーバーを DNS で切り替える
Azure と GCP にそれぞれ WordPress を置き、片方が止まったらもう片方へ切り替える構成では、固定 IP を DNS の A レコードの値として使います。固定にしておかないと、再起動のたびに DNS を直す必要が出るためです。
切り替えの方法は二通りあります。手動で A レコードを書き換える方法は単純ですが、TTL の間は古い IP にアクセスが残ります。切り替えの可能性があるレコードは、事前に TTL を短くしておくと影響時間を抑えられます。自動で切り替えたい場合は、ヘルスチェック付きの DNS サービスを使います。たとえば Azure Traffic Manager は Azure 外の宛先も「外部エンドポイント」として登録でき、GCP 側の静的 IP にヘルスチェックをかけて優先順位で切り替えられます。Amazon Route 53 や DNS 事業者のフェイルオーバー機能を使う選択肢もあります。各サービスの対応範囲は変わることがあるので、公式ドキュメントで確認してください。
ここで強調しておきたいのは、固定 IP と DNS だけでは WordPress の冗長化は成立しないことです。データベースとアップロードファイル（wp-content/uploads）を両クラウドでどう同期するか、切り替え後に古いデータで書き込みが起きないかが本当の難所です。片方を読み取り専用の待機系にする、データベースのレプリケーションを組むなど、データの扱いを先に設計してください。
場面2：外部サービスに送信元 IP を固定して許可してもらう
決済代行や社内システムの API などで、接続元 IP の登録を求められることがあります。この場合に必要なのは、受信用の IP ではなく「送信元として外に出ていく IP」の固定です。
Azure では、NAT Gateway に Public IP を関連付け、サブネットに NAT Gateway を設定すると、そのサブネットからの送信が指定した IP から出ていきます。
az network nat gateway create \
--resource-group rg-wp \
--name natgw-wp \
--public-ip-addresses pip-wp-nat \
--idle-timeout 4
az network vnet subnet update \
--resource-group rg-wp \
--vnet-name vnet-wp \
--name snet-web \
--nat-gateway natgw-wpAzure では VM の「既定の送信アクセス」を廃止する方向の変更が進められており、新しい VNet ではサブネットが既定でプライベートになるなど、明示的な送信手段（NAT Gateway など）が求められる流れです。適用時期や条件は公式の告知で確認してください。
GCP では Cloud NAT で、予約した静的 IP を手動で割り当てます。
gcloud compute addresses create wp-nat-ip --region=asia-northeast1
gcloud compute routers create rt-wp \
--network=vpc-wp --region=asia-northeast1
gcloud compute routers nats create nat-wp \
--router=rt-wp --region=asia-northeast1 \
--nat-all-subnet-ip-ranges \
--nat-external-ip-pool=wp-nat-ip自動割り当てのままだと、Cloud NAT の IP は必要に応じて増減するため、相手に登録した IP と変わってしまうことがあります。許可リストに登録するなら手動割り当てにしてください。設定後は、各クラウドの VM から curl https://ifconfig.me のような外部の確認サービスを使い、実際に出ていく IP が想定どおりかを確認します。外部サービスに IP を伝えるときは、両クラウド分のアドレスをまとめて登録してもらうと、切り替え時に連絡し直す手間が省けます。
場面3：Azure と GCP を VPN で直接つなぐ
両クラウドのプライベートネットワーク同士をつなぐ場合は、Azure VPN Gateway と GCP の HA VPN を IPsec で接続し、BGP で経路を交換する構成が一般的です。Azure VPN Gateway は Public IP を関連付けて使い、アクティブ/アクティブ構成では二つの Public IP を使います。GCP の HA VPN ゲートウェイは、作成時に二つのインターフェースそれぞれへ外部 IP が自動で割り当てられ、ユーザーが予約した静的 IP を指定する方式ではありません。
構成手順は両社の公式ドキュメントに、Azure と GCP の組み合わせを想定した手順が用意されているので、それに沿って進めるのが安全です。CIDR の重複がないこと、BGP の ASN とトンネル内のリンクアドレスを双方でそろえることが、つまずきやすい点です。
運用上の注意
固定 IP を削除すると、同じアドレスを取り戻すことは基本的にできません。DNS や外部サービスの許可リストに登録している IP は、Azure ならリソースロック、GCP なら削除権限の絞り込みなどで誤削除を防いでください。変更作業の前には、現在の関連付け（どのリソースにどの IP が付いているか）を一覧で控えておきます。
まとめ
- Azure Public IP は Standard SKU を前提にし、ゾーン指定は作成時に決める。
- GCP の外部 IP は既定でエフェメラルなので、固定したいものは静的として予約する。運用中の IP は昇格できる。
- DNS 切り替えは TTL とヘルスチェックを設計し、データベースとファイルの同期を先に決める。
- 送信元 IP の固定は Azure NAT Gateway と GCP Cloud NAT の手動割り当てで行う。
- 登録済みの固定 IP は削除すると戻らないため、ロックや権限で保護する。