はじめに
AWSエンジニアですが、諸事情によりAzureも勉強しています。
細かい所を見ると結構違って、理解するのに苦労したのでまとめてみました。
私もまだ知識が浅いので、間違いや分りづらい点、また書いて欲しい点などありましたらコメント等頂けると幸いです。
前提知識
リージョンペア
AWSと違い、ペアとして定義されているリージョンが存在します。
ビジネス継続性とディザスター リカバリー (BCDR):Azure のペアになっているリージョン
日本の場合、東日本（東京、埼玉）/西日本（大阪）リージョンがペアです。
以下のような利点があります。
- 広域障害時、リージョンの障害復旧はペアの一方を優先するポリシーになっている。
- サービス次第だが、ペアリージョンを利用した冗長機能が備わっている。
注意点もあり、
ペアリージョンの冗長機能を使うと、フェールオーバーさせた時に初めて他方のリージョンで普通に使えるようになります（それまではReadOnlyだったり、読めもしなかったり）。
特に読めもしない機能の場合は、災対リージョンで簡単なテストを行う事すらできず、システムが稼働停止した状態でテストする事になるでしょう。
Availability Zones
AzureにもマルチAZ相当の機能があります。（西日本リージョンは対応してないので注意1）
※なお、AWSの場合はAZと呼ぶ事が多いと思いますが、Azureの日本語ドキュメントでは「可用性ゾーン」と記載されています。
AWSの場合、サブネットをAZに作成しますが、Azureの場合そのような指定はしません（リージョンにサブネットを作成します）。
※ちなみにGCPも同様です。 >サブネットはリージョン リソースです。
サブネットをAZに作成しないという事はマルチAZ構成にする際、サブネット指定によりAZを指定するという方法にはなりません。
どのような使い方をするかはサービスの実装によって異なります。
- Azure VM では、可用性オプションで有効にした上で、ゾーンを選択します。
- SQL Database では、可用性オプションで有効にするのみです。
また、サービスの実装によって異なるので、一見使えそうでも使えないという事もあるので注意が必要です。
例えば、Azure VMは対応してますが、Azure Batchは対応していません。1
可用性ゾーンは後からできた機能のようで、発展途上といった所でしょうか。
可用性セット
西日本リージョンは可用性ゾーンに対応していないと記載しましたが、可用性セットという冗長機能は使用できます。
AWSには存在しない概念ですが、DC内での冗長機能2で、更新ドメイン（メンテンスのグループ）と障害ドメイン（基盤のグループ）を分散させる事ができます。
Azure VM専用の機能という認識です。
NSG
AWSではサブネットのアクセス制御はネットワークACLを、インターフェースのアクセス制御はSGを使用しますが、AzureではどちらもNSG（Network Security Group）を使用します。
NSGはサブネットにアタッチすることも、インターフェースにアタッチすることもできます。
拒否設定もできて、優先度を設定する必要があるので、設定の仕方はACLの方に近いです。
ただ、ステートフルなので戻りのパケットを設定する必要はありません。
なお、AWSではSG同士で接続許可ができますが、NSGではIPアドレス指定になってしまいます。
Application Security Groupという拡張機能を合わせて使うことで、グループ毎にアクセス制御が可能です。
データベースがグローバルNWに存在する
AzureのマネージドDBサービスはサブネット内にインスタンスが作られるのではなく、グローバルNW上に作られます。（S3のような感じ）
プライベートに制限したい場合は後述のエンドポイントを作成した上で、各DBサービスのファイアウォール機能でパブリックアクセスをブロックします。
サービスエンドポイントとプライベートエンドポイント
AWSでグローバルNWを経由せずに各サービスに接続したい場合、VPCエンドポイントを作成しますが、Azureにも同様の機能があります。
サービスエンドポイントとプライベートエンドポイントです。
AWSと比較すると、サービスエンドポイントはゲートウェイエンドポイントに、プライベートエンドポイントはインターフェイスエンドポイントに少し近いですが、色々な差異があります。
まずそもそも、サービスエンドポイント、プライベートエンドポイントどちらを使うか選ぶ事ができます。（AWSではサービスで固定）
両者を比較すると
-
サービスエンドポイント
- Vnetとサービスを接続します。
- それ以外の制御は基本的にできません。
- Azure Storageのみ1サービスエンドポイントポリシーで対象リソースの制御が可能です。
- オンプレから直接接続できません。（AWSのゲートウェイエンドポイント同様プロキシサーバーが必要です）
※オンプレからはパブリックで繋ぐというのは可能です。 - ゲートウェイエンドポイントと同様、無料です。
-
プライベートエンドポイント
- リソースに対して作成します。（AWSのインターフェースエンドポイントはサービスに対して作成します）
- NW的に到達可能な範囲全てから接続可能になります。
- オンプレからも直接接続できます。（名前解決は別途必要です）
- エンドポイント側でアクセス制御はできません。（AWSの場合はSGで制御が可能）
- 接続元リソースの送信トラフィックで、インターフェースエンドポイントのIPに対する制御を行う形式になります。
- Application Security Groupに対応してないのでIP指定です。。
- インターフェースエンドポイントと同様、時間とトラフィックに料金が掛かります。
- AWSの場合内部DNSに登録されて見えませんが、Azureの場合プライベートDNSゾーン（Route53のプライベートホストゾーン相当）に登録されますし、レコードを確認できます。
- プライベートDNSゾーンの設定に不備があると接続できないという事になります。
細かな制御は必要ない、料金を掛けたくない場合はサービスエンドポイントを
細かな制御が必要だったり、オンプレから接続したい場合にプライベートエンドポイントを使うというのが選べるのは利点ですね。
でもサービスエンドポイントポリシーがストレージのみってのは微妙。
また、インターフェースエンドポイント側は全開放になるのもどうなんでしょうね…
もし組織が分かれていたりしたら、相手を信用するか別の牽制が必須になるかの0か100かみたいな。
（使わない場合、パブリックアクセスになるとはいえサービス側のファイアウォールでIP単位の制御が可能だし）
セキュアに使うためのサービスなのに何でガバいの？という気がしてしまいます。。