Azure ネットワーク についての まとめ

# はじめに
Azure Network について、全体像をまとめてみました。
AZ-700 の資格試験にも役立てられる内容になっています。

各要素の詳細な記事は、今後 検証結果や手順とともに投稿していこうと思っています。

<img width="250" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/888122dc-25c5-d435-4212-c47948d132b0.png">
<br>
<img width="350" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/eea13baa-af1a-9637-e9f0-aaa8d5f8820e.png">

今回の記事の内容に近い公開情報は、以下となりますが、章の順序や内容は 一致していません。記事の方は、私なりに判りやすいと思う形にしています。

**公開情報：Azure ネットワーク サービスの概要**

https://learn.microsoft.com/ja-jp/azure/networking/fundamentals/networking-overview?wt.mc_id=mvp_407731

# 1. Microsoft グローバルネットワーク
インターネット 上の通信の宛先は、グローバル IP アドレス が使われています。
Microsoft では、この グローバル IP アドレス の事を パブリック IP と呼んでいます。
以降の表記は、パブリック IP に統一していますが、同じ意味を持っていると認識ください。

下図のとおり、世界中のユーザーが Azure の日本リージョンへアクセスする場合は、ユーザーの近隣のエッジルーターから、日本のリージョンの パブリック IP アドレスまで  Microsoft グローバルネットワーク を介して接続されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/1d5b4426-afb8-7b56-90a5-aa13aae8f086.png)

**パブリックインターネット ＋ Microsoft グローバルネットワーク ＝ インターネット**
上記の式が成り立つ事を覚えておきましょう。
Microsoft グローバルネットワーク を理解するために、以下の図と TraceRoute の結果を参照ください。

:::note info
**イメージ図**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/d8836a8d-4ebf-53a2-0e29-eecd86d547a1.png)
上記の図は、以下の公開情報の図に、説明を付け加えています。
https://learn.microsoft.com/ja-jp/azure/virtual-network/ip-services/routing-preference-overview?wt.mc_id=mvp_407731

**TraceRoute**
日本にある私の自宅から、ロンドンリージョンの VM (172.167.216.128) への TraceRoute 結果
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/77b02e74-599d-bb49-a5c5-4db513f90e63.png)
※tyo=東京 , sin=シンガポール , mrs=マレーシア , par=パリ , lon=ロンドン と推測してます。
:::

利用者の視点で、PC から、Azure サービスに到達するまでの全体が 一般に 広義の インターネット と呼ばれている部分です。

これを、Microsoft 側の視点でみると、Microsoft が管理していない部分を「パブリックインターネット（緑色）」と呼び、Microsoft が管理している部分を「Microsoft グローバルネットワーク（紫色）」と呼び分けています。

**公開情報：Microsoft グローバルネットワーク**

https://learn.microsoft.com/ja-jp/azure/networking/microsoft-global-network?wt.mc_id=mvp_407731

（上記より抜粋）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/47fa554e-676e-f093-21ee-58588a78821c.png)

上記の記載では、ロンドンにある PC から、東京の Azure が提供するサービスへ接続する場合の説明になっています。

（緑下線）
ロンドン PC から、より近い場所にある Microsoft の エッジルーター までは、利用者が契約しているプロバイダなどを介して、パブリックなインターネット回線が使われます。
エッジルーターから先の部分が、Microsoft グローバルネットワーク と呼ばれるエリアになります。

（紫下線）
ロンドンエッジに入ったトラフィックは、フランスを介して、ヨーロッパ～インド洋横断経路を経由して、Azure 日本リージョンまでルーティングされます。

（橙下線）
戻りのトラフィックは、ロンドン PC のパブリック IP アドレス に向かって返されますが、東京から すぐにパブリックインターネットに出る事は無く、来た時の逆の経路をたどって、ロンドンエッジから インターネットを介して、ロンドン PC に返されます。

（赤下線）
Azure VM , Microsoft 365 , Xbox , SQL DB , Storage , Azure 仮想ネットワーク などの、Microsoft が提供するサービスは、すべて この Microsoft グローバルネットワークが使われていて、他社のネットワーク回線を経由する事が無く、最適化されていることが明言されています。

この Microsoft グローバルネットワーク を利用して Microsoft のクラウドサービス が提供されています。

**関連情報**

https://jpaztech.github.io/blog/archive/azure-datacenter-infrastructure-1/

# 2. Azure PaaS / SaaS サービスの通信
Microsoft 社 が提供する Azure PaaS や SaaS サービスは、URL へ向けたアクセスとなります。URL が インターネット上の DNS で名前解決された結果、パブリック IP アドレス が返されて、その IP に対して通信されています。

**公開情報：Azure PaaS サービスへの接続**

https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/ready/azure-best-practices/connectivity-to-azure-paas-services?wt.mc_id=mvp_407731

PaaS や SaaS サービス同士（下図は、App Service が SQL Database や ストレージを参照する場合）がアクセスする場合も、URL（名前解決の結果 パブリック IP アドレス）が使われており、たとえ リージョン間の通信であっても、Microsoft グローバルネットワーク から 外に出る事は無く通信されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/a4620565-1347-c33f-2b14-4bc5409762bd.png)

インターネット上のデバイスからの通信を受け付ける場合は、名前解決が行われてから、通信は パブリックインターネットから、エッジルーターを経由して、Microsoft グローバルネットワークに入り、Azure PaaS サービス に到達します。なお、Microsoft 365 や Dynamics 365、PowerPlatform などの SaaS サービスへのアクセスも考え方は同じです。

:::note warn
Azure VM が Azure PaaS や SaaS サービスへアクセスする場合は、3-2.章で説明している **送信接続 (SNAT)** が利用されることを意識しておく必要があります。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/3a00f7a8-e2d9-8c1e-616b-49379347c9c6.png)

## 2-1. 送信接続 (SNAT) を使用せずに VM から PaaS に接続する方法
**サービスエンドポイント** または **プライベートエンドポイント** を活用することで、送信接続 (SNAT) を介すことなく、通信が可能になります。

両サービスの差異を私なりにまとめてみました。

| # |サービスエンドポイント|プライベートエンドポイント|
|:-:|:-:|:-:|
|構成の難度|簡単|高い|
|アクセスの範囲|サブネット = 〇<br>仮想ネットワーク = ✖<br>外部ネットワーク = ✖|サブネット = 〇<br>仮想ネットワーク = 〇<br>外部ネットワーク = 〇|
|コスト|無料|少し発生|
|セキュリティ|ゆるい|厳格|
|対象リソース|**※１：下記参照**|ストレージアカウント<br>SQL Database<br>Cosmos DB<br>Private Link サービス|

**※１：サービスエンドポイントの対象リソース**
Azure Storage (Microsoft.Storage)
Azure SQL Database (Microsoft.Sql)
Azure Synapse Analytics (Microsoft.Sql)
Azure Database for PostgreSQL サーバー (Microsoft.Sql)
Azure Database for MySQL サーバー (Microsoft.Sql)
Azure Database for MariaDB (Microsoft.Sql)
Azure Cosmos DB (Microsoft.AzureCosmosDB)
Azure Key Vault (Microsoft.KeyVault)
Azure Service Bus (Microsoft.ServiceBus)
Azure Event Hubs (Microsoft.EventHub)
Azure App Service (Microsoft.Web)
Azure Cognitive Services (Microsoft.CognitiveServices)

詳細な違いについて、公開情報 では 以下のように説明されています。

**Support Blog：サービスエンドポイントとプライベートエンドポイントの違い**
https://jpaztech.github.io/blog/network/pe-difference-se/

**公開情報：プライベート エンドポイントとサービス エンドポイントの比較**
https://learn.microsoft.com/ja-jp/azure/virtual-network/vnet-integration-for-azure-services?wt.mc_id=mvp_407731#compare-private-endpoints-and-service-endpoints

**公開情報：サービス エンドポイントとプライベート エンドポイントの違いは何ですか。**
https://learn.microsoft.com/ja-jp/azure/private-link/private-link-faq?source=recommendations#------------------------------------

**公開情報：Azure プライベート エンドポイントおよび Private Link サービスとは何ですか。**
https://learn.microsoft.com/ja-jp/azure/private-link/private-link-faq?source=recommendations#azure-------------------private-link------------

**公開情報：Private Link サービスとプライベート エンドポイントの関係はどのようなものですか。**
https://learn.microsoft.com/ja-jp/azure/private-link/private-link-faq?source=recommendations#private-link-----------------------------------

## 2-2. サービスエンドポイント
プライベートエンドポイントよりも、簡単に構成する事ができます。
名前解決 を考慮する必要がないため、難易度が下がります。

半面、サブネット単位で許可する必要があり、仮想ネットワーク以外（つまり外部）からのアクセスを受け付ける事はできません。

名前解決の際は、パブリック IP アドレスが 応答されます。
しかし、パブリック IP アドレス への通信が サービスエンドポイント経由でアクセスされるため、**送信接続 SNAT** を経由しません。

PaaS サービス側のファイアウォールで、インターネットからのアクセスをブロックしたり、アクセス可能な 仮想ネットワーク を選択することが可能なため、簡単に PaaS サービスのセキュリティを高められます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/b71c55f9-48a5-a368-6cdd-3db58acaf7d9.png)

**公開情報：仮想ネットワーク サービス エンドポイント**

https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-service-endpoints-overview?wt.mc_id=mvp_407731

## 2-3. プライベートエンドポイント
サービスエンドポイントよりも、難度は高めですが、ピアリングや VPN などで接続された 外部のネットワークからのアクセスも可能な点が特長です。

**公開情報**

https://learn.microsoft.com/ja-jp/azure/private-link/private-endpoint-overview?wt.mc_id=mvp_407731

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/05bbc80b-7c0f-55e0-4e28-555f9b4751fb.png)


プライベートエンドポイントについての詳細は、以下の記事にまとめました。
さらに深く掘り下げて記載したつもりなので、こちらも ぜひ 参照ください。

**私の記事の紹介**

https://qiita.com/carol0226/items/ecf769b91a4a7e03dd03

:::note info
**ポイント**
Azure では、Azure 以外（つまりオンプレミス）から、Azure プライベート DNS ゾーン (168.63.129.16) を直接参照することが出来ない仕組みになっています。そのため、プライベートエンドポイント のための名前解決 を ダイレクトに オンプレミスに提供することができません。
そのため、以下の いずれかの方法で、名前解決をフォワード（転送）してあげる必要があります。
① オンプレミスホスト -> **Azure プライベートリゾルバー** -> Azure Private DNS ゾーン
② オンプレミスホスト -> **Azure VM で DNS を用意** -> Azure Private DNS ゾーン
:::

# 3. Azure VM の通信
## 3-1. 内部の通信 (Azure VM 同士)
Azure VM は、仮想ネットワーク を介して 相互に通信されます。
仮想ネットワーク は、閉鎖された プライベートアドレス空間 が利用され、プライベート IP アドレス を使って通信を行います。

**公開情報：Azure リソース間の通信**
https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-overview#communicate-between-azure-resources?wt.mc_id=mvp_407731

仮想ネットワーク は、複数作成する事ができますが、仮想ネットワークに接続された VM 同士のみが通信できます。下図の場合は、（VM #1 と #2）または（VM #3 と #4）は相互に通信できますが、vNet A と vNetB 間は通信することができません。 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/e806d333-540c-d3d7-7da2-ba25e85362e4.png)

vNet A と vNet B を接続する場合には、ピアリング を使用します。
ピアリングは、仮想ネットワーク同士を連結して、１つの仮想ネットワークであるかのように動作をさせることができます。通常のピアリングは、同一リージョン内で利用できますが、グローバル VNET ピアリング を利用すると、リージョン間 の 仮想ネットワーク を相互に接続する事ができます。

下図の場合は、VM #1 ～ #4 の全ての VM が相互に通信が可能になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/dac2e07a-0a71-f854-15f3-fe043c8b40aa.png)

**公開情報：仮想ネットワーク ピアリング**

https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-peering-overview?wt.mc_id=mvp_407731

## 3-2. Azure VM からの インターネットへの送信接続
基本的には、以下の記事をよく読んでいただけば大丈夫です。

**Support Blog：Azure VM の送信接続 (SNAT) オプション まとめ**

https://jpaztech.github.io/blog/network/snat-options-for-azure-vm/

**公開情報：送信接続での送信元ネットワーク アドレス変換 (SNAT)を使用する**

https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-outbound-connections?wt.mc_id=mvp_407731

上記を踏まえて、私なりの説明に落とし込んだものを 以下の ①～⑤ で説明しています。
① 既定の SNAT
② パブリック IP アドレス を 直接 Azure VM の NIC に割り当てる
③ NAT ゲートウェイ
④ Azure Firewall
⑤ パブリックロードバランサー の送信規則

下図では、送信接続 (SNAT) の箇所を ①～⑤ のいずれかの方式を選択できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/8ff8bb11-98d4-4bdc-f2d0-9de70097e774.png)

① の 既定の SNAT は、廃止される予定もありますし、ポート枯渇 のリスクも発生します。
サービスの本稼働を行う前に、②～⑤ のサービス利用を検討してください。

特に ③ NAT ゲートウェイ と ④ Azure Firewall は、リソースに 複数の パブリック IP アドレス を割り当てる事が可能となっており、ポート枯渇 の対策も万全になっています。

以下の 構成の比較表 も参考にしてください。

**公開情報：構成の比較**
https://jpaztech.github.io/blog/network/snat-options-for-azure-vm/#構成の比較

### ① 既定の SNAT について
**(2025/10/1 以降に作成する VM は廃止予定)**

Azure VM は、パブリック IP アドレスを付与しなくても、既定で インターネットとの接続が許可された状態になっています。これを **既定の送信アクセス** と呼ばれます。

**公開情報：Azure での既定の送信アクセス**

https://learn.microsoft.com/ja-jp/azure/virtual-network/ip-services/default-outbound-access?wt.mc_id=mvp_407731

:::note alert
この **既定の送信アクセス** は、2025 年 10 月 1 日以降に作成される VM では 利用できなくなることがアナウンスされています。
https://jpaztech.github.io/blog/network/default-outbound-access-for-vms-will-be-retired/
:::

Azure VM に **パブリック IP アドレス** を割り当てなかった場合は、**既定の SNAT** という仕組みが自動的に適用されていて、VM から インターネットへのアクセスが可能になっています。

既定の SNAT があるおかげで、Azure VM は、何も考えなくても インターネット にアクセスすることが可能ですが、本運用を開始する前に、考慮しておかなければならない事があります。

仮想ネットワーク上に存在する VM が、インターネットにアクセスしようとすると、この **既定の SNAT** が使っている IP アドレス を介して、1 対 多 の NAT 変換（ポートアドレス変換）が行われます。

そのため、既定の SNAT を使っていると、PoC 検証 している時には問題無くても、運用サービスとして 本稼働させると、ポートの枯渇 問題が生じて、通信ができなくなる事象が発生する可能性があります。

例えば、Azure Virtual Desktop を利用する場合、複数のユーザーの各セッション から、ストレージのファイル共有へのアクセスや、インターネットのサイトにアクセスされます。

これらの大量のアクセスは、既定の SNAT では耐えられずに、ポート枯渇 発生の可能性が高くなります。

:::note info
AWS や Oracle Cloud などの他社クラウドサービスには、このような概念は無い為、VM が インターネット にアクセスできるようにするためには、インターネットゲートウェイや、NAT ゲートウェイ などのサービスを意識的に組み合わせる必要があるようです。Azure も **既定の送信アクセス** が無くなると、他社クラウドと同じような考え方をしていくことになります。
:::

### ② パブリック IP アドレス を 直接 Azure VM の NIC に割り当てる
VM の NIC に パブリック IP アドレス を割り当てると、その VM 専用に アドレスが割り当てられるため、既定の SNAT よりもポート枯渇は起こりにくくなります。

ですが、１つの VM には、１つの パブリック IP しか割り当てができないため、それ以上の拡張性は望めませんし、制御を集中管理する事もできません。

**公開情報：パブリック IP アドレス**

https://learn.microsoft.com/ja-jp/azure/virtual-network/ip-services/public-ip-addresses?wt.mc_id=mvp_407731

**公開情報：仮想マシンへのパブリック IP の割り当て**
https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-outbound-connections?wt.mc_id=mvp_407731#3-assign-a-public-ip-to-the-virtual-machine

### ③ NAT ゲートウェイ
外部からの受信アクセスが不要で、外部への送信アクセスが大量に発生する場合には、NAT ゲートウェイ が適しています。なお、通信の可否を制御する機能は備わっていないため、可否を制御するためには、ネットワークセキュリティグループ (NSG) を利用するか Azure Firewall と組み合わせて利用します。

**公開情報：Azure NAT Gateway とは**

https://learn.microsoft.com/ja-jp/azure/nat-gateway/nat-overview?wt.mc_id=mvp_407731

**公開情報：サブネットへの NAT ゲートウェイの関連付け**
https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-outbound-connections?wt.mc_id=mvp_407731#2-associate-a-nat-gateway-to-the-subnet

以下の記事の手順で、NAT ゲートウェイ に 複数の パブリック IP を割り当てることができます。
**公開情報：パブリック IP アドレスを変更または削除する**
https://learn.microsoft.com/ja-jp/azure/virtual-network/ip-services/configure-public-ip-nat-gateway?wt.mc_id=mvp_407731#change-or-remove-public-ip-address

### ④ Azure Firewall
外部からの受信、外部への送信 の両方に対応し、URL や サイトのカテゴリ、Azure サービスタグ などの単位で制御が行えます。

Azure Firewall を使うと、最高レベルの脅威保護を実現しつつ、パケットのさまざまな制御が可能になります。
URL 単位、サイトのカテゴリ単位、サービスタグ単位、FQDN タグ単位 など・・・
他にも、アクセスログを記録して監視をしたり、脅威からの保護などを行えます。

**公開情報：Azure Firewall とは**
https://learn.microsoft.com/ja-jp/azure/firewall/overview?wt.mc_id=mvp_407731

Azure Firewall は、高度なセキュリティを実現できますが、単体では 負荷分散の機能を持ちません。
ロードバランサーと組み合わせることで、VM の可用性を高められます。

**公開情報：Azure Firewall と Azure Standard Load Balancer を統合する**
https://learn.microsoft.com/ja-jp/azure/firewall/integrate-lb?wt.mc_id=mvp_407731


Azure Firewall に複数の パブリック IP アドレスを 割り当てることも、NAT ゲートウェイ と組み合わせて構成することもできます。

**公開情報：複数のパブリック IP アドレス**
https://learn.microsoft.com/ja-jp/azure/firewall/features?wt.mc_id=mvp_407731#multiple-public-ip-addresses

**公開情報：送信 SNAT サポート** （NAT ゲートウェイとの統合）
https://learn.microsoft.com/ja-jp/azure/firewall/features?wt.mc_id=mvp_407731#outbound-snat-support

**私の記事の紹介**
Azure Firewall については、私の方で 構築手順や ログの取得、Azure Virtual Desktop と組み合わせる方法などのノウハウを記事化していますので、合わせて参照ください。

https://qiita.com/carol0226/items/c40de99f11fb1593f26b

https://qiita.com/carol0226/items/b626d67a74c27b4a224b

https://qiita.com/carol0226/items/894f506d3f7aa8e1a77e

### ⑤ パブリックロードバランサー の送信規則
冗長化された Web サービスを外部に公開していて、外部からの受信アクセスをメインに利用する場合に推奨されます。あくまで 受信アクセスがメインの場合の選択肢かなと思います。
その際に、送信規則を定義することで、仮想ネットワーク内の通信を パブリック ロードバランサーに割り当てられた パブリック IP を介して送信させることが可能です。

https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-overview?wt.mc_id=mvp_407731

**公開情報：送信規則による送信には、ロード バランサーのフロントエンド IP アドレスが使用される**
https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-outbound-connections?wt.mc_id=mvp_407731#outboundrules

ポート枯渇の対策としては、パブリックロードバランサーと、NAT ゲートウェイ を組み合わせて利用することも可能です。

## 3-3. インターネットから Azure VM への受信接続
インターネットからのアクセスを受け付けるためには、必ず パブリック IP アドレス のリソースが必要です。

**公開情報：パブリック IP アドレス**

https://learn.microsoft.com/ja-jp/azure/virtual-network/ip-services/public-ip-addresses?wt.mc_id=mvp_407731

上記の公開情報にも記載されていますが、パブリック IP アドレス の リソースは、以下の リソース と組み合わせて利用します。

① 仮想マシン ネットワーク インターフェイス
② Virtual Machine Scale Sets
③ 負荷分散オプション
　Front Door、Traffic Manager。Application Gateway、パブリックロードバランサー
④ Virtual Network ゲートウェイ (VPN または ER)
⑤ Azure Firewall
⑥ Bastion ホスト
⑦ NAT ゲートウェイ（送信接続のみ対応）
⑧ ルート サーバー（受信接続用では無い、BGP の橋渡し）
⑨ API Management（VM 接続用ではない）

上記のうち、①～⑥ が 下図の **受信接続リソース** を介して、Azure VM にアクセスする際に利用できます。⑦～⑨は、VM 接続用ではないため、この記事では割愛します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/52d3c0c7-3e1c-5132-3a5e-f0ffef72d9d3.png)

## ① 仮想マシン ネットワークインターフェイス
Azure では、VM を作成する際に、同時に パブリック IP アドレス を自動作成して 割り当てる事が可能です。

この場合は、VM (NIC) と パブリック IP アドレス が１対１で割り当てられます。
インターネットから パブリック IP アドレス にアクセスされたトラフィックは、直接 VM に転送されます。

VM 作成時に未割当の場合は、後から パブリック IP アドレス を割り当て可能です。
以下の公開情報を参照してください。

**公開情報：パブリック IP の割り当て方法**
https://learn.microsoft.com/ja-jp/azure/virtual-network/ip-services/virtual-network-network-interface-addresses?tabs=nic-address-portal?wt.mc_id=mvp_407731#public

通常、外部から VM に対して RDP 接続を行うと思いますが、その際に使われているのが、この受信接続のパターンになります。

シンプルなところでは、VM で、以下の記事のように VPN サーバー や IIS (Web) サーバーを構築して、外部からアクセスする・・・という事に利用できます。

**私の記事の紹介**
(VPN サーバー 1)

https://qiita.com/carol0226/items/9e4efc903a8802a60cfd

(VPN サーバー 2)

https://qiita.com/carol0226/items/7a9160b298b736aa187e

(Web サーバー)

https://qiita.com/carol0226/items/4357e773efdbb08b5c52

## ② Virtual Machine Scale Sets
Virtual Machine Scale Sets (VMSS) は、同一イメージの VM を多数 自動デプロイすることができる仕組みです。

同一構成の Web サーバーを VMSS で大量にデプロイする事で 管理負荷 を権限できます。
さらに、サーバーへのアクセス負荷に応じて、動的に VM をデプロイしたり 削除することもできます。

**公開情報：Virtual Machine Scale Sets とは何ですか?**

https://learn.microsoft.com/ja-jp/azure/virtual-machine-scale-sets/overview?wt.mc_id=mvp_407731

こういった用途となるため、VMSS の VM に １つずつ パブリック IP アドレス を付与するのは、レアケース です。通常は、パブリックロードバランサーと VMSS をセットで利用することが殆どですので、この記事での解説は割愛します。

レアケースの場合は、以下の公開情報を参照してください。

**公開情報：仮想マシンごとのパブリック IPv4**
https://learn.microsoft.com/ja-jp/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-networking?tabs=portal1#public-ipv4-per-virtual-machine

## ③ 負荷分散オプション
Azure では、負荷分散を行うための、４つのソリューションが提供されています。
それぞれの特性を活かして、使い分ける事ができます。

**公開情報：負荷分散のオプション**

https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview?wt.mc_id=mvp_407731

（上記の公開情報より抜粋）
|　　　機能 ▶<br>▼ サービス|グローバル<br>or<br>リージョン内|L7<br>or<br>L4|HTTP<br>or<br>TCP|VM への接続|
|:-:|:-:|:-:|:-:|:-:|
|Application Gateway|リージョン内|L7|HTTP(S)|VM 直接|
|パブリック<br>ロードバランサー|グローバル<br>リージョン内|L4|TCP 全般|VM 直接|
|Front Door|グローバル|L7|HTTP(S)|パブリック IP 経由|
|Traffic Manager|グローバル|L4|TCP 全般|パブリック IP 経由|

**Application Gateway** と **パブリックロードバランサー** は、下図のように 受信接続リソース から、複数の Azure VM を死活監視して、稼働中の VM にトラフィックを分散するサービスです。 
両サービスは、以下のような構成のイメージとなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/48259957-99d8-e521-0e4b-1d29de9e39b2.png)

**Front Door** と、**Traffic Manager** は、複数拠点を跨いで パブリック IP ごとのサービスを死活監視して、グローバルレベルで振り分けを行います。振り分けは、トラフィックが パブリック IP に到達する前の段階で、CDN や DNS の機能を使って制御しています。
そのため、災害対策 や 地域に応じたサービス内容への振り分け などに活用することができます。

**参考：Support Blog の 記事**

https://jpaztech.github.io/blog/archive/lb_appgw_traffic_different/

#### ③-1 Application Gateway
**Application Gateway** は、L7 に特化しており、HTTP(S) のトラフィックしか制御できませんが、SSL オフロードや、URL に応じた振り分けなどに対応し、アプリケーションレイヤのセキュリティの向上も期待できる高度な Web サービス専用の負荷分散装置として利用できます。

**公開情報：Azure Application Gateway とは**

https://learn.microsoft.com/ja-jp/azure/application-gateway/overview?wt.mc_id=mvp_407731

#### ③-2 パブリック ロード バランサー
**パブリックロードバランサー** は、L4 に特化しているため、あらゆる TCP トラフィック を負荷分散させることができますが、SSL オフロードや URL 振り分けには対応できません。

パブリックロードバランサーを使うと、配下に 同一構成の VM を複数台配置しておき、サービス（アクセスポート）が活性化されている VM に対して、負荷分散 を実施することができます。

Azure VM にシステムを構築して、外部公開するような場合に、多く利用されます。

**公開情報：Azure portal を使用して、VM の負荷分散を行うパブリック ロード バランサーを作成する**

https://learn.microsoft.com/ja-jp/azure/load-balancer/quickstart-load-balancer-standard-public-portal?wt.mc_id=mvp_407731

#### ③-3 Front Door
Front Door は、CDN ライクな動作をするようです。
L7 に特化したソリューションであり、HTTP(S) のみ制御することが可能です。
たとえば、動画配信コンテンツを 利用者により近い場所から配信させるなどが行えるようです。

今回、私が記事化した中で、唯一 この機能だけ 検証したことがありません。
これ以上の詳細は、公開情報を参照してください。

**公開情報：Azure Front Door とは**

https://learn.microsoft.com/ja-jp/azure/frontdoor/front-door-overview?wt.mc_id=mvp_407731

**Support Blog**

https://jpaztech.github.io/blog/network/AzureFrontDoor-LockDown/

#### ③-4 Traffic Manager
Traffic Manager は、DNS として動作しています。
バックエンドプールに割り当てられている URL を死活監視して、正常動作しているアドレスに対して、優先制御 を考慮した名前解決を行います。

優先制御は、優先順位、重みづけ、パフォーマンス、地理的、複数値、サブネット などがあります。

この優先制御の構成に応じて、利用者が DNS 参照を行った際に、適切な URL が応答されるため、様々なシナリオに応じたソリューションを提供可能です。

下図は、地理的 な優先制御を行い、地域のユーザーを 該当地域のリージョンに接続させつつ、リージョンダウン時には、別のリージョンに振り分ける構成をした際のイメージ図です。リージョンのデータセンター全体がダウンしても、Traffic Manager は 稼働しているため、稼働中のリージョンに振り分ける事が可能です。そのため、災害対策 としても利用できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/a0d656b1-41fa-88f4-723e-d23402e46b5f.png)

各優先制御の詳細は、以下の公開情報を参照してください。

**公開情報：Traffic Manager のルーティング方法**

https://learn.microsoft.com/ja-jp/azure/traffic-manager/traffic-manager-routing-methods?wt.mc_id=mvp_407731

## ④ Virtual Network ゲートウェイ (VPN または ER)
仮想ネットワークゲートウェイには、VPN ゲートウェイ と ER ゲートウェイ の２種類があります。

VPN ゲートウェイ は、インターネット を VPN プロトコルで暗号化して通信を行います。
ER ゲートウェイは、インターネットを使わずに、WAN 回線事業者から Express Route 回線を経由して Azure に直接接続します。

通常は、VPN を利用すれば 十分ですが、業務要件 や システム要件 で、インターネット回線を利用できないようば場合に ER ゲートウェイ (Express Route 回線) が選択肢となります。

### ④-1. VPN ゲートウェイ
VPN ゲートウェイ を構成すると、下図の 黄色線 の部分が VPN プロトコルで暗号化 した通信となります。
VPN の接続が確立していると、利用者は PC から、直接 Azure VM のプライベート IP アドレスに対して、通信を行う事ができます。

VPN ゲートウェイ については、さらに 以下の記事で詳しく説明しています。ぜひ 参照ください。

**私の記事の紹介**

https://qiita.com/carol0226/items/f28f381e3dcf43590d7b

**S2S と P2S 接続の場合**
S2S の場合は、VPN ルーターを経由した通信、 P2S の場合は VPN クライアントを構成した PC から接続をすることができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/08a7ccb6-a441-881a-2e48-4f5e7474fa53.png)

**V2V 接続 の場合**
vNet 対 vNet 接続 (V2V) の場合は、以下のように VPN ゲートウェイ 同士を接続します。
VPN の通信は、Microsoft グローバルネットワーク を経由することになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/7a862754-1b7e-9551-3eb7-a159fee7490d.png)

### ④-2. ER ゲートウェイ
ER ゲートウェイは、Express Route 回線 を契約することで、インターネット を一切使わずに WAN 回線事業者を介して、直接 Azure に接続することが可能になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/38cd8e8c-f693-7b72-7a66-1c3c1b3d138a.png)

**公開情報：Azure ExpressRoute とは**

https://learn.microsoft.com/ja-jp/azure/expressroute/expressroute-introduction?wt.mc_id=mvp_407731

なお、ER ゲートウェイにも パブリック IP アドレス は存在しますが、通信には使われません。Azure 側が ゲートウェイの制御や正常性監視のために利用しており、削除することはできません。
**FAQ：仮想ネットワークで ExpressRoute ゲートウェイに関連付けられているパブリック IP アドレスが存在するのはなぜですか**
https://learn.microsoft.com/ja-jp/azure/expressroute/expressroute-faqs?wt.mc_id=mvp_407731#why-is-there-a-public-ip-address-associated-with-the-expressroute-gateway-on-a-virtual-network

## ⑤ Azure Firewall
**3-2. Azure VM からの インターネットへの送信接続** の章の **④ Azure Firewall** を参照ください。

## ⑥ Bastion ホスト
Bastion の語源は、"要塞" です。
つまり、VM へのアクセスを 要塞化 するための機能となります。

パブリック IP が個別に付与された VM の場合、個々の VM のパブリック IP を事前に把握しておき、クライアントから １対１で接続する必要があります。

それに対して、Bastion では、まず、要塞化された 1 箇所へのアクセス（認証）を行ってから、接続が可能なホストを選択して、接続する形となり、リモートセッションの集中管理が可能になります。
このとき、アクセスログを記録したり、権限にしたがって、画面キャプチャや、ファイル転送、クリップボードのコピー、印刷 などの機能を、ユーザーごとに 許可／拒否 を制御することも可能です。

**公開情報：SKU**
SKU によって、制限できる機能が異なるため、注意が必要です。
https://learn.microsoft.com/ja-jp/azure/bastion/bastion-overview?wt.mc_id=mvp_407731#sku

さらに、Bastion を使うと、VM への接続に HTTPS を利用できるようになります。
VM へのリモート接続は、通常は、RDP を使用しますが、多くの企業では 社内から外部へのアクセスが制限されて、RDP を利用できない場合があります。
HTTPS であれば、多くのシーンで、アクセスが許可されている事が多く、上記の課題を解決する事ができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/e7d471fd-6cdc-98b5-e003-493c8b2cccb4.png)

**公開情報：Azure Bastion とは**

https://learn.microsoft.com/ja-jp/azure/bastion/bastion-overview?wt.mc_id=mvp_407731