これまでAWSでシステムを設計することは多々ありましたが、Azureに触れる機会も出てきたため、AWS経験者目線でAWSとAzureのネットワークの違いについてまとめて書いてみます。
Azureの公式ページには丁寧にAWS経験者向けの説明ページもあって、今回のNW以外のことはこちらから参照するとわかりやすいです。
AWS プロフェッショナルのための Azure
Virtual Network（VNet）
AWSでプライベートな仮想ネットワークを作成する場合はVPCを作成しますが、Azureの場合はVirtual Network（VNet）。
AWSではVPC内の仮想マシン（EC2）からインターネットにアクセス出来るようにするには、Internet GatewayかNAT Gatewayをアタッチする必要がありますが、Azureの場合はPublic IPが付与されていない仮想マシン（VM）もデフォルトでインターネットにつながります。
Subnet
AWSは高可用性を考慮してAZを指定したサブネットを設計する必要がありますが、Azureは意識する必要がありません。
なぜならサブネットはAZを跨いで作成されます。
もちろん仮想マシン（VM）を作成するときにはAZを指定することが可能です。
Network Security Group（NSG）
VPCでネットワークトラフィックを制御するには、ネットワークACLとセキュリティグループになりますが、AzureはNetwork Security Group（NSG）で管理できます。
AWS
・Network ACL：ルールの許可と拒否をサポート
・Security Group：ルールの許可のみ
Azure
・Network Security Group：ルールの許可と拒否をサポート
AWSだとNetwork ACLでサブネット単位のルールを設計し、Security Groupで仮想マシン（NIC）レベルのルールを設計することが一般的ですが、NSGは仮想マシン（NIC）レベルに適用することもできれば、サブネットレベルで適用することも可能です。
デフォルトのNSGルール
また、注意すべきはNSGにはインバウンド（受信）とアウトバウンド（送信）にデフォルトのルールが適用されることです。
インバウンドはVNet内、AzureLBからのアクセスがデフォルトで許可されています。
アウトバウンドはVNet内、インターネットへのアクセスがデフォルトで許可されています。
サービスタグ
AWSのSecurity Groupではルールの指定にIPやSecurity Groupを設定出来ますが、Azureの場合はIPやNSG以外にサービスタグで対象のAzureサービスに限定することが出来ます。
NSGの管理
サービスタグ
システムルート
Azureの場合、サブネットを作成すると自動的にシステムルートが割り当てられ、これらを変更する場合はカスタムルート（ユーザ定義ルート）でオーバーライドする必要があります。
デフォルトの状態で仮想マシン（VM）にPublicIPがアタッチされていなくても、VNetからインターネットに接続できるのはこのシステムルートにインターネットが許可されており、AzureデフォルトのSNATで変換して接続できるためです。
仮想マシン（VM）からインターネットに接続するパターンはたくさんあって複雑なのですが、以下の記事がわかりやすいです。
参考
Azure VM の外部接続 (SNAT) オプション まとめ
Firewall
Azure FirewallはNSGよりも上位のレイヤーでネットワークポリシーを制限することができます。
NSGでは実現できないFQDNレベルでの制御や、オンプレミス、複数のVNetのネットワーク制御を実現できます。
IPアドレス、サブネット、VNet単位でルールを作成できるので便利です。
AWSだと別途Proxyサーバ等を立てる必要がありましたが、先日のAWS re:Invent 2020で発表された「AWS Network Firewall」を使うことでFQDNレベルの制御が出来るようになったようですね。
Firewallを作成するには専用のサブネットを作成する必要があります。
1つのVNet内でFirewallを作成するのは簡単ですが、複数のVNetを1つのFirewallで管理する場合は専用のルートテーブルを作成して紐付ける必要があるのでやや複雑です。
ハイブリットNWでFirewallをデプロイ
便利ですが、従量課金なので1ヶ月で日本円で約10万くらいかかりますので要注意。
Azure Firewall 価格
Service Endpoints
AWSでVPCからVPC外のS3とかRDS等のサービスに対してセキュアに接続する場合は、エンドポイント作って承認してサブネットに紐付。。。といろいろやることがありますが、AzureにはService Endpointsという考えがあり、接続先のサービス（Azure Storage、SQL DB等）のファイアウォールメニューで対象のVNet（Subnet）を許可し、NSG（VNet）のアウトバウンドを許可するだけでOKです。
利用者はService Endpoint自体を意識する必要はなく、しかも無料です。
AWSのPrivate Linkで設計してきた人は、Azureだとこちらの選択肢があることをお忘れなく。
さらにPrivate Linkとの違いはこちらが参考になります。
Azure のサービスエンドポイント vs プライベートエンドポイント
Private Link
Azure Private LinkでもService Endpointsと同様にVNet->VNet外のサービスとセキュアな通信を実現することはできます。
VNetからVNet外のサービスとセキュアに通信する場合は、ほとんどService Endpointsで事足りますが、オンプレミスからVNet外のサービスに対してセキュアにプライベート通信する場合には、いよいよPrivate Linkが必要です。
こちらは従量課金で料金発生しますのでご注意ください。
Azure Private Link料金
DNS
AWSだとRoute53でドメインの購入、DNSレコードの設定ができますが、Azure DNSはDNSレコードの設定のみでドメイン購入はAzure App Service内でしかできません。
TLS/SSL証明書
AWSの場合、ACM（AWS Certificate Manager）を利用してELB、API Gateway、CloudFrontに無償でTLS/SSL証明書を発行できたりしますが、AzureはApp Serviceという固有のサービス内でのみサポートします。
App Serviceのドメインと証明書を使って、App Service以外のサービスのSSL化を実現することも可能です。
負荷分散
アプリケーションの負荷分散を実現するにはAWSもたくさんありますが、Azureも全部揃ってます。
AWSはWAFが単体のサービスとして存在しますが、AzureはサービスにWAF機能が紐付いています。
| Azureサービス | 説明 |
|---|---|
| Azure Load Balancer | AWS ELB（Network Load Balancer/Classic Load Balancer）と同様のL4ロードバランサー |
| Application Gateway | AWS ALB（Application Load Balancer）と同様のアプリケーションレベルのL7ロードバランサー、WAF |
| Traffic Manager | Route53と同様のDNSレベルのトラフィックルーティング |
| Front Door | グローバル負荷分散、L7ロードバランサー、WAF |
まとめ
以上が私がAzureを触れる上で、AWSとの違いを理解するのに苦労したところです。
あまり深い内容ではないですが、やはり実際に動かしてみないと理解できない部分も多々ありました。
ご利用は計画的に。