記事シリーズの背景
普段AWSを使っていて、最近初めてAzure上でシステムを構築してみたら、色んな所で違いがありすぎで最初は思ったより大変でした。このシリーズの記事は同じAWS経験者でAzureを触り始める方を対象に書いており、AWSに慣れているエンジニアの目線でAzureのサービスを紹介していこうと思います。また、自分自身もAzure歴が浅いため、情報が間違っている可能性もございますが、ご参考程度で読んでいただければと思います。
目次
サービス名称の比較
| 項目 | AWS | Azure |
|---|---|---|
| 仮想ネットワーク | VPC | VNET |
| サブネット | サブネット | サブネット |
| ルーティング | ルートテーブル | ルートテーブル |
| インターネットゲートウエイ | インターネットゲートウエイ | - |
| NATゲートウエイ | NATゲートウエイ | 既定の送信アクセス NATゲートウエイ |
| 通信制限 | セキュリティキーグループ(SG) ネットワークACL(NACL) |
ネットワークセキュリティキーグループ(NSG) アプリケーションセキュリティグループ(ASG) |
| ロードバランシング | Application Load Balancer(L7) Network Load Balancer(L4) |
Application Gateway(L7) Load Balancer(L4) |
| CDN | CloudFront | Azure Front Door Azure CDN |
| DNSサービス | Route53 パブリックホストゾーン プライベートホストゾーン |
Azure DNS DNSゾーン プライベートDNSゾーン |
仮想ネットワーク
仮想プライベートネットワークは他の多くのサービスが動作する基盤となります。AWSとAzureでは仮想プライベートネットワークの基本概念が同じで、呼び方が違います。
■AWS
Virtual Private Cloud（VPC）
■Azure
Virtual Network(VNET)
名称の違いでけではなく、色んな機能においても考え方が違います。詳細についてはこれ以降の内容で紹介していきます。
サブネット
VPCのサブネット
- 一般的にパブリックサブネットやプライベートサブネットなど、ルーティング要件でサブネットを分ける。
- サブネットはAZと紐づく。マルチAZ冗長構成にする場合、同じ種類のサブネットをAZごとに作成する必要がある
VNETのサブネット
-
AWSよりサブネットの種類が多くなりがち
Azureでは基本的にサブネットごとにNSGを設定するため、ルーティング要件の他に、セキュリティグループの設定も考慮して上でサブネットの分け方を考えないといけません。AWSでよくするパブリック、プライベートなど単純なサブネットの分け方では足りず、サーバー種類ごとにサブネットを分けることが多いようです。更にDatabase、Application Gateway、プライゲートゲートウエイ、Container Appsなど多くのAzureサービスでは専用のサブネットが必要のため、AWSに比べるとより多くのサブネット種類を設ける必要があります。 -
AzureのサブネットはすべてのAZに同時に紐づいているため、１つのサブネットでもマルチAZ冗長構成ができる
ルーティング
今はまだAzureのルートテーブルを触る機会がないため、現状は紹介することがありません。今後何かがあれば追記していきます。
インターネットゲートウエイ
VPCにおける外部通信方式
default-vpcでは インタネットゲートウェイ(IGW) がデフォルトでアタッチされており、ルートテーブルにもIGWへのルートが設定されているため、VPC内でパブリックIPを持つリソースならインターネットにアクセスできます。
自分の手でゼロからVPCを作成する場合、インタネットゲートウェイを作成、VPCにアタッチ、ルートテーブルにIGWへのルートを追加、ルートテーブルをサブネットに関連付けなど一連の構築を実施しない限り、VPC内からはインターネットにアクセスできません。
VNETにおける外部通信方式
VNETではインターネットゲートウエイという概念はないです。
VPCでいうと常にインターネットゲートウエイ、ルーティング設定と既定のSNATが用意されている状態になります。
VNETをインターネットと通信させたくない場合は、NSG、カスタムルーティングでブロックしたり、サブネットをプライベートにすることで通信を遮断する必要があります。
NATゲートウエイ
AWSのNATゲートウエイ
AWSでNAT Gatewayを使用する際の流れは以下になります。
- パブリックサブネット（
0.0.0.0/0 → igwのルートが設定されているサブネット）を指定してNATゲートウエイを作成する。すると、サブネット内にNATゲートウエイのネットワークインターフェース（ENI）が作成され、固定パブリックIPアドレスが付与される。 - プライベートサブネットのルートテーブルで
0.0.0.0/0へのルートをパブリックサブネットにあるNATゲートウエイに指定すると、NATゲートウエイを通してインターネットにアクセスできる。
AzureのNATゲートウエイ
既定の送信アクセス（既定のSNAT）
VNETはデフォルトで既定の送信アクセスが提供されております。公式のドキュメントに記載されている名前ではちょっとわかりにくいなと思いますが、つかり暗黙的なSNAT変換がデフォルトで提供されています。無効化する設定をしない限りには、VNET内のリソースがパブリックIPなしでもインターネットにアクセスできます。この場合、Azureが持っているパブリックIPの内、任意のIPが使用されるため、VNETからのアウトバウントIPアドレスを固定できません。
※プライベートモードでサブネットを作成すると既定の送信アクセスを無効化できる
※明示的な送信接続（NATゲートウエイ）が設定されているサブネットでは既定の送信アクセスを無効にできる
※リソースがパブリックIPを持っている場合、そのパブリックIPが使用される
明示的な送信アクセス
VNETからのアウトバウントIPアドレスを固定化したい場合、NAT Gateway（有料サービス）を利用します。AzureのNAT Gatewayを使用する際の流れは以下になります。
- 固定のパブリックIPを付与してNATゲートウエイを作成する
- NATゲートウエイをサブネットに関連付けるとそのサブネットでは既定の送信アクセスの代わりにNATゲートウエイが使用される
- 1つのNATゲートウエイを複数のサブネットに同時に関連付けられる
※NAT Gatewayが設定されたサブネット内にあるリソースに対してパブリックIPを付与する場合、リソースはパブリックIPで受信できるが、リソースからインターネットにアクセスする際にNAT GatewayのIPが優先に使用される。
NATゲートウエイの冗長化
AWSにおいても、Azureにおいても、１つのNATゲートウエイインスタンスは１つのAZにデプロイされます。
AWSでのマルチAZ冗長化
AWSでNATゲートウエイをマルチAZ冗長化にする場合、AZごとにNATゲートウエイを作成し、プライベートサブネットが同じAZにあるNATゲートウエイを使用するようにルートテーブルを設定する方式で実現します。
AzureでのマルチAZ冗長化
Azureの仕様上１つのサブネットに複数のNATゲートウエイを関連付けられないので、NATゲトウエイのマルチAZ冗長化はできなさそうです。そんなころあるか!?と思いながら今のところ実現方法が見つからないですね...
通信制限
AWSとAzureの共通点
AWSもAzureも、デフォルトでインバウンドに対して厳しく制限し、アウトバウンド基本的に制限していません。
AWS VPCの通信制限
セキュリティグループ（SG）
■デフォルトの通信設定 - デフォルトSG
インバウンド：同じSGからのすべての通信を許可
アウトウンド：すべて許可
■デフォルトの通信設定 - 新規作成
インバウンド：なし（すべて拒否）
アウトウンド：すべて許可
■特徴
- ネットワークインタフェース(NIC)に適用
- ルールの優先順位なし
- 許可ルールのみ記載可能（ルールなしの場合は全ブロック）
- ステートフル
- インバウンドに対してのアウトバウンド／アウトバウンドに対してのインバウンドが自動的に許可される
- 同じVPC内であれば、送信元／送信先としては他のSGを指定することが可能。つまりSG自身が通信対象を識別するタグとして役割も持っている。
■設定方式
- インバウンドルールのパラメータ
- プロトコル（L4のみ）
- ポート範囲
- ソース：CIDRブロック、セキュリティグループもしくはプレフィクスリスト
- 説明
- アウトバウンドルールのパラメータ
- プロトコル（L4のみ）
- ポート範囲
- 送信先：CIDRブロック、セキュリティグループもしくはプレフィクスリスト
- 説明
ネットワークACL
■デフォルトの通信設定 - デフォルトNACL
インバウンド：
- すべて許可（優先）
- すべて拒否
アウトウンド：
- すべて許可（優先）
- すべて拒否
■デフォルトの通信設定 - 新規作成
インバウンド：
- すべて拒否
アウトウンド：
- すべて拒否
■特徴
- サブネットに対して適用
- ルールの優先順位あり
- ルール番号小さい方から評価されていく
- 通信パッケージが1つのルールに合致したら評価が終わり、通信が合致したルールの設定によって許可／拒否される。以降のルールは無視される
- 許可、拒否ルール両方記載可能
- ステートレス
- インバウンドに対してのアウトバウンド／アウトバウンドに対してのインバウンドが自動的に許可されない
■設定方式
- インバウンドルールのパラメータ
- ルール番号（優先順位）
- プロトコル（L4のみ）
- ポート範囲
- 送信元
- 許可／拒否
- アウトバウンドルールのパラメータ
- ルール番号（優先順位）
- プロトコル（L4のみ）
- ポート範囲
- 送信元
- 許可／拒否
Azure VNETの通信制限
AWSとの大違い
AWSの通信制御方式はSG（NICレベル）とNACL（サブネットレベル）二つの手段が取られますが、AzureではNSG一つで両者の役割を果たしています。AzureのNSGはAWSの世界で言うとステートフルなNACLと言えばイメージしやすいでしょう。
また、AWSでは同じVPC内の通信をSGで制御する場合、送信先／送信元として他のSGを指定することは可能だが、AzureのNSGではこれができません。（AWSを慣れているとここが意外と不便さを感じるかもしれません）。Azureでこれと似たようなことを実現するには、Azureがアプリケーションセキュリティグループ（ASG） という機能が提供しているが、制限が多いので、個人的にはAWSのSGのほうが使いやすいと思います。
ネットワークセキュリティグループ(NSG)
■デフォルトの通信設定 - デフォルト設定（NSGなし）
インバウンド（優先順位高 → 低）：
- VNETから同じVNET内への通信をすべて許可
- AzureLoadBalancerからの通信をすべて許可
- すべての通信を拒否
アウトウンド（優先順位高 → 低）：
- VNETから同じVNET内への通信をすべて許可
- 任意のIPアドレスからインターネットへの通信を許可
- すべての通信を拒否
■特徴
- サブネット、NIC両方に対して適用可能。ベストプラクティス上ではサブネットに対しての適用が推薦されている。 ← AWSのNACLと違う
- ルールの優先順位あり ← AWSのNACLと同じ
- ルール番号小さい方から評価されていく
- 通信パッケージが1つのルールに合致したら評価が終わり、通信が合致したルールの設定によって許可／拒否される。以降のルールは無視される
- 許可、拒否ルール両方記載可能 ← AWSのNACLと同じ
- ステートフル ← AWSのNACLと違う
- インバウンドに対してのアウトバウンド／アウトバウンドに対してのインバウンドが自動的に許可される
■設定方式
- ルールのパラメータ（インバウンド／アウトバウンドが同じ）
- ルールの名前
- 優先度
- 送信元：IPアドレス、CIDRブロック、サービスタグもしくはASG
- 送信元ポート範囲
- 送信先：IPアドレス、CIDRブロック、サービスタグもしくはASG
- 送信先ポート範囲
- プロトコル
- 許可／拒否
アプリケーションセキュリティグループ(ASG)
AWSのSGルールを定義するとき、送信元／送信先を他のSGに指定できます。
ただし、AzureのNSGルールでは、送信元／送信先を他のNSGに指定することはできません。
似たようなことを実現するには、Azureではアプリケーションセキュリティグループ(ASG)という機能を提供しています。
ASGは単純のタグみたいの機能になります。リソースを作成する際にASGを指定すると、NSGルールの送信元／送信先として、ASGを指定できます。
ただし、AWSではNICを作成するほぼすべてのリソースにSGを指定できることに対して、AzureのASGはリソース作成時指定できなかったり、手動で対象NICにアタッチする運用をしたりするので、使用できるシナリオに制限が多いと感じています。
ロードバランシング
AWSのロードバランサー
L4のNetwork Load Balancer（NLB） も L7のApplication Load Balancer（ALB） もサブネット内にデプロイされます。
Azureのロードバランサー
Azure Load Balancer（L4ロードバランサー）
AWSのNLBと同じ箇所
外部のクライアントからパブリックのAzure Load Balancerにアクセスする際に、通信はバックエンドのターゲットサーバーに転送されます。バックエンドサーバーからは通信は直接クライアントから来ているように見えます。また、帰りの通信はバックエンドサーバーから直接クライアント側に送信されます。つまり、バックエンドはクライアント側のネットワークにアクセスできる必要があります。例えば、クライアントはインターネット経由してアクセスしに来た場合、バックエンドサーバーは既定のNAT変換、明示的なNAT変換、自身のパブリックIPなどなんでもよいので、インターネットにアクセスできる手段を用意必要があります。
また、AWSもAzureも、ロードバランサーを外部受けと内部向けに設定できます。
AWSのNLBと違う箇所
引用元：https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-overview
■Publicロードバランサーに設定した場合
AWSのNLBと違い、作成時サブネットを指定しません。つまり、ロードバランサーはパブリックIPのみを持ち、サブネット内にロードバランサーのNICが作成されない（＝プライベートIPは持たない） ということです。(AWSの場合、NLBのNICはパブリックIPとプライベートIP両方持ちます。)
LBはプライベートIPアドレスを持たないので、LBからバックエンドサーバへのヘルスチェック通信は外部からくるということでしょうか？と思いましたが、Azureの公式ドキュメントを見ると以下のようにLBがVNET内に描かれています。（AWSではプライベートIPを持つ = VPC内にあるということですが、Azureでの考え方が少し違うみたいです。）
サブネットのNSGを見ると、デフォルトルールの１つの65001番のルールがAzureロードバランサーからのインバウンド通信を許可しています。65001番のルールがないと、LBからバックエンドサーバーに対してのヘルスチェックが失敗し、クライアントからもアクセスできなくなります。自分のカスタムルールを作成する際に誤ってブロックしないように注意しましょう。
また、バックエンドサーバー側はクライアントから直接通信が来るように見えるので、NSGのインバウンドルールにはクライアントIPからの通信を許可する必要があります。このため、バックエンドサーバーがパブリックIPを持っていると、クライアントはNLBを無視して直接バックエンドサーバーにアクセスできてしまいます。これを防ぐには、バックエンドサーバーにはパブリックIPを持たせず、NAT Gatewayを設置してインターネットにアクセスさせるのがお勧めです。
※ 昔AWSでも同じでしたが、最近のAWSではバックエンドサーバーのSGはNLBからの通信だけ許可すれば、クライアントから正常にアクセスできるように仕様変更されました。今のAWSはNLBを使用する際に、バックエンドのSGにクライアントIPからのインバウンド許可が不要になりました。これでNLBを無視してバックエンドのサーバーにアクセスされる心配がなくなり、より安心になります。
※ Azure Container Appsをデプロイする際に自動的に作成されたAzure Load Balancerは一般のLBと違い、サブネットのNSGの制御対象外になるというちょっと特殊な動きをします。これについてはまた別の記事で説明します。
■Privateロードバランサーに設定した場合
- AWSの内部NLBを基本的に同じ
- 選択したサブネット内にNICが作成される
- 専用のサブネットは不要
Azure Application Gateway（L7ロードバランサー）
設定方式が違いますが、基本的にAWSのALBと同じ機能を持ちます。
最大の違いとしては、Azure Application Gatewayを作成するには、専用のサブネットが必要という点です。つまり、Application Gatewayサブネットがに他のリソースが存在してはいけない。
CDN
AWSでContent Delivery Network(CDN)と言えば、CloudFront一択ですが、AzureではAzure Front DoorとAzure CDN二択があります。
2つの違いについてはこのサイトで詳しく紹介されています。
上記を見た感じではAzure CDNは静的コンテンツのデリバリに特化したもので、 Front Doorはより汎用的に作られているイメージです。
また、料金面においては、Azure Front Doorは毎月の基本料金が発生しますが、ゾーンのによってAzure CDNのデータ転送料金より10%~50%くらい安くなるようです。
Azure Front Doorの料金：https://azure.microsoft.com/ja-jp/pricing/details/frontdoor/
Azure CDNの料金：https://azure.microsoft.com/ja-jp/pricing/details/cdn/
DNSサービス
AWSではRoute53というDNSサービス名で提供している機能が、AzureではDNSゾーンとプライベートDNSゾーンというサービス名で提供しております。概念や使い方がほぼ一緒なのでRoute53に慣れていればすぐに使いこなせるかと思います。