Azure でNetwork Routing（UDR、Firewall、Load Balancer、Application Gateway、Front Door）

# User Defined Route
- Subnet単位で指定
- 適用されたSubnetからの外部向け通信を制御する
- 詳細度が高いRouteのほうが優先される（10.0.0.0/24 > 10.0.0.0/16）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/1dc638c5-f58a-9fff-3ecc-bbc25cb5064b.png)

# Azure Firewall
Azure FirewallってStandard機能だけだと結局ルーティングがメインのリソースな気がする。NAT Rule、Network Rule、Application Ruleについてはこちら参照。

https://qiita.com/smr1/items/c57115f29b25d1d19c28#azure-firewall%E3%81%AEpolicy

かつならNSGとAzure Firewallの違いとは？と分からなくなってくるので、自分の未来のために（一度上の記事に貼っているけど）参考リンクをペタリ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/81ac6adc-75c5-ff6e-92e5-09381e16113d.png)

https://jpaztech.github.io/blog/network/difference-nsg-fw/

## Azure Firewallによる強制トンネリング
ちゃんと理解できたか微妙だが自分の理解を書くと。
強制トンネリングとはAzure上のVMから直接インターネットに出る前にオンプレのNVAなどに通信を向けて、監査用にスクリーニング、ロギング等させること。
VNetにAzure FirewallとVMがある構成で、インターネット向け通信は全てAzure Firewallを通し、Azure FirewallからDestinationとして監査用NVAに通信を向ける。
※ここではAzure Firewallの勉強の文脈で出てきたため、こちらを使っているが、オンプレのNVAに向けるのであればVPN GatewayでTunnelingしたほうがいいらしい。

ただ、以下の記事によると逆にオンプレの通信をクラウド上のNVAを通したいということもあるらしい。

https://jpaztech.github.io/blog/network/forcetunneling-azure-to-onpre-configuration/#:~:text=Azure%20%E3%81%A7%E3%81%AF%E3%80%81Azure%20%E7%92%B0%E5%A2%83%E3%81%8B%E3%82%89,%E3%81%A8%E5%91%BC%E3%82%93%E3%81%A7%E3%81%84%E3%81%BE%E3%81%99%E3%80%82

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/9354115f-5931-19a5-0a0d-7b250af07a4b.png)

- Azure Firewallの強制トンネルリングを有効化
    - 有効化のためにAzureFirewallManagementSubnetとPublic IPが必要
    - これは一般ユーザーの通信と管理の通信（Threat Intelligence等）を分離するという意味で有用
- VMをデプロイしたSubnetにRoute設定
    - Routeで0.0.0.0/0 = Internetあての通信をFirewallに向ける

自分でスクショ取りながらやっていたが、こちらにきれいにまとまっていた記事があったので、、、感謝。（こちらは1つのVNetでやっているぽいので上の図とはちょっと構成が違うが。）

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

ちなみに強制トンネリングを有効にするとAzure Firewallを通るようになるので、VMへのRDPがつながらなくなってしまう事象が発生した。テスト用にお金をケチってPublic IPに対してRDPしていたのが悪い。
Perplexityに壁打ちして気づいたのだが、強制トンネリングをするとRDPの通信もAzure Firewallに向いてしまい、RDPを許可していないのでブロックされると。Bastionなら影響されないらしいのでBastionの利用をお勧めする。

## ルーティングのトラブルシュート

VMのトラブルシュートであれば、以下が可能。
- Network WatcherのIP Flow Verifyで疎通を確認できる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/2b699072-3449-0a7c-7e4d-7b0d785d47f4.png)
どのNSGルールにより許可されたかが表示される、ここではVNetPeeringしたVM間の疎通確認。ただし、どのNSGかが書かれていない。。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/1300e5b3-0aa9-63ea-185c-be6a8e228b43.png)

- NICのEffective RouteでどのRoutingが有効化を確認できる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/05ace7b1-3588-54fe-f10f-ccc35376e349.png)

Network WatcherはVNetを作成すると自動的に作られるのでそれを使うこともできる。
- Network WatcherのNext Hop
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/2bb4c9e8-5c4c-7ddf-c4e9-6749aa286217.png)

- Network WatcherのConnection Troubleshoot
VMから外部のIPへの通信状況、レイテンシとかも出せる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/60b86595-bfa3-6bac-8e75-d62f0d4a109d.png)

- NSGの通信ログであるFlow LogをLog Analyticsに蓄積・分析してNSGのネットワークトラフィックをTraffic Managerから傾向を分析できる。

https://qiita.com/hisnakad/items/15185eccb13a2fb2858b

# 負荷分散リソース
Azure PortalでLoad balancerで検索すると以下のように選択するための情報が出てくる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/24a1392e-4f11-5315-745b-c91d4a6a27e9.png)

https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview

# Load Balancer
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/216b4c0c-650c-b4de-d669-e23c258ad2ab.png)

https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-overview#pricing-and-sla

- エンタープライスユースだと（AZ分散、NSGによるセキュリティ等）Standardが必須
- PublicとPrivateの分散が可能
- OSI レイヤー4による分散
    - ソースIP、ソースポート
    - 目的IP、目的ポート
    - プロトコル

Regionまたぎの分散も可能。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/98b33a02-cd50-e394-a0e8-cfdc65ea1d31.png)

https://learn.microsoft.com/ja-jp/azure/load-balancer/cross-region-overview

汎用的な負荷分散なので、バックエンドはVMでもDBでもなんでも可能。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/7f447345-3362-83af-6815-724bd1360ac5.png)

# Application Gateway
- Webアプリ用
- Layer 7の負荷分散、HTTP、HTTPS用、パスベースルーティングが可能
- Auto Scalingやゾーン冗長がある
- Internal、Publicの設定が可能
- WAFとの統合が可能
- TLS終端が可能（バックエンドがHTTPを受け付けるので、CPU不可軽くなり、証明書設定も不要）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/41cb348b-300d-a817-b1bb-e33a2d543dcc.png)

https://learn.microsoft.com/ja-jp/azure/application-gateway/overview

メインどころの設定を書くと、
- FrontendとしてPublic IP、Private IPを持てるが、Private IPだけというのはできない
→と思ったらプレビューだがPrivateのみのApplication Gatewayも設定できるぽい

https://learn.microsoft.com/ja-jp/azure/application-gateway/application-gateway-private-deployment?tabs=portal

- Listenerは複数に複数ドメインホスト用にマルチサイトとすることも可能（contoso.com、fabrikam.com等）

https://jpaztech.github.io/blog/archive/about-application-gateway/

- ルーティングは ベーシック（constoso.com/*）にするか、パスベースにするか選択、これによりどのBackend Poolに流すかを決める
- Backend PoolはFQDNやIPアドレスにすることも可能

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/fd64faae-98b9-a335-fc60-872f2df55617.png)

https://learn.microsoft.com/ja-jp/azure/application-gateway/application-gateway-components

## Deploy
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/87397c95-3ba9-9dc9-f7a5-1c2c1ba3f9f4.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/0510b096-b746-81ed-6bc6-8957c0dabc5a.png)

色々選べる。VM立てるのも面倒なので、適当なサイトを宛先にしてみる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/05731594-ca65-93c7-7d12-d04c2afabac6.png)

RuleでListenerを設定。
これはApplication Gatewayの受け取り側のルール。
502や403のエラーに対してSooryページ等が表示できる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/e5aac2de-f52f-d2d6-caed-617f364e2ec1.png)

今度はタブをBackend targetsに切り替え、Application Gatewayから流す通信の詳細を決定する。IPではなくCookieベースセッションアフィニティもできる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/45f194f0-8dd5-a8ed-5777-cbf6a8d6846b.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/de019202-a441-2857-0482-b45a27641efd.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/fc5c1008-f49f-db0a-fba5-1911e02a197c.png)

## SSL オフロード
ちなみにSSLオフロードをするには、RuleのListenerでHTTPSにしてKeyVaultに証明書を格納しBackend targetsでHttpで流すようにすればよいらしい。これによりバックエンドには未暗号の通信になる（未検証）。ただしAzure バックボーン通信になるのでそれが危険というわけではない。

https://zenn.dev/microsoft/articles/793b43673a7a32

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/7936ba56-e8d7-eaf5-b4ec-5882ef53f0a1.png)

https://learn.microsoft.com/ja-jp/azure/application-gateway/ssl-overview

## Application Gatewayカスタムドメイン

Application Gatwayにカスタムドメインを構成するにはこちらを参照。App GWとWebApp両方にカスタムドメイン設定してしまうのがきれいポイ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/44198199-b9c4-56c4-289f-453aeaf4ebe9.png)

https://learn.microsoft.com/ja-jp/azure/application-gateway/configure-web-app?tabs=customdomain%2Cazure-portal

https://jpaztech.github.io/blog/network/appgw-appservice-redirectissue/

試してみた手順はこちら。

https://qiita.com/smr1/items/77099256878bb35c1dab

## RedirectとRewrite
- AppGWでRedirect
    以下のようなパターン
    - HttpをHttpsにRedirectさせる
    - 外部サイトへのRedirect

https://zenn.dev/microsoft/articles/793b43673a7a32

- Rewriteは
    - RequestやResponseヘッダの編集
    - クエリストリングをURLパスからクエリストリングへの変換等
    f.ex. /article/123を/article?id=123にする
こんな感じのRewriteルールが設定可能。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/fc3aeed4-3cfa-f3be-5359-b48e78f0108c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/68984f52-f205-9b32-6396-09b1b0d365ed.png)

https://jpaztech.github.io/blog/network/appgw-rewrite/

## Health Probe
シングルサイトの場合は宛先を127.0.0.1にできる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/d61b409f-dfd0-bd54-9404-7c11a4a1af39.png)
テストもできる。GoogleはhealthがあるのでOK。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/4fee42ce-2c0b-1156-657a-c5b123516bd4.png)


# Front Door
- Globalリソース
- レイテンシに基づいたルーティング
- Layer 7の負荷分散
- Auto Scalingやゾーン冗長がある
- キャッシング
- WAFとの統合が可能

複数リソースの機能（Traffic Manager、Application Gateway、WAF、CDN）を統合しているので、リソースをシンプル化できる可能性がある。


以下のようなマルチリージョンアプリに向いている。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/6cba294e-c26a-d36a-9250-5ca41bcae75e.png)

https://learn.microsoft.com/ja-jp/azure/architecture/web-apps/app-service/architectures/multi-region

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/73b0016f-ff31-d4af-c83c-357fbc9d47c3.png)

https://zenn.dev/headwaters/articles/7ed3a8aecbba57

Standardは配信機能に特化しており、Premium SKUはPrivate Endpoint、WAF、Threat Intelligence等追加でセキュリティ機能が追加される。

## Deploy
GlobalリソースなのでRegionを選ぶ必要がない。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/7736912d-f0f5-fecb-fff0-48f6df3578dd.png)

カスタムドメインを設定する場合はKey Vaultを設定。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/6fb8a05c-7c59-e76d-9c97-288ecbd66125.png)

エンドポイントを作成。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/74aabc01-1b68-de1c-430c-cc26a866a17c.png)

エンドポイントに複数のルーティングを入れられ、個別のWAF Policyを設定できる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/6aa8f856-a759-f450-33a0-9652d8388488.png)

Origin -> 実際のバックエンド（URL、IP、Web Apps、Container等を設定する、接続先ポート等もここで）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/bacf70f6-7ae1-7cda-4ff1-3ba6671a7806.png)
接続先は選択可能なものがたくさん。CustomにすればFQDNやIPベースもOK。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/09d64100-f40b-6a46-aadb-f6986fcafa3c.png)
ルーティングの優先度
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/ecfebabc-6201-8111-6186-8b80feff4f48.png)

OriginGroup -> 複数のOriginを設定する（Health ProbeやLoad Balancing Optionなどを設定）
> The latency sensitivity with value zero (0) means always send it to the fastest available backend, else Front Door will round robin traffic between the fastest and the next fastest backends within the configured latency sensitivity

Load Balancingで通常は一番早いのと2番目に早いエンドポイントでラウンドロビンする。Latency sensitivityを0にすると1番早いところにずっとつなぎ続ける。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/7646b5ab-1eac-e880-6ae8-97dd9c969192.png)

Route -> パスベースルーティングの設定（受信プロトコル、キャッシング等）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/8cda86de-7a14-3604-6d1b-e26e576838cf.png)

## カスタムドメイン

https://www.tama-negi.com/2024/03/23/azure-front-door-custom-domain/

## Rules Engine
ルールベースで処理が可能。App GWのRewriteみたいな感じ。
GlobalサービスなのでGeoのルールが使える。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/ef11f8f4-740f-422c-7ca4-62f548066ec4.png)