🧑‍🏫

AzureのVNet、プライベートエンドポイントなどのネットワークのイメージを掴む!

2023/12/07に公開1

初めに

仕事でAzure OpenAIに絡んだことをやっているため、閉域化などAzureのネットワークについて考えることがありました。閉域化するためのVNetやリソース同士を繋げるプライベートエンドポイントなどについて、Microsoftのドキュメントなどを色々読み、ようやくイメージが掴めてきたので、「これ初めに教えて欲しかった」と自分が思った内容を記事にしていこうと思います。この記事では各リソース等の細かい仕組みなどには言及せず、ざっくりとAzureのネットワークへのイメージを掴むことで、Azureのドキュメントを理解して読み進めやすくする!を目標にします。

VNet(仮想ネットワーク)

VNet(仮想ネットワーク)とは

まずVNet(Virtual Network)とはAzure内でプライベートなネットワークの空間を提供するものです(イメージは下図)。VNetの中にAzureのリソースを配置することで、そのリソースはインターネットや他のVNetからアクセスできなくなります。一方、同一VNet内のリソース同士は通信を行うことができます。VNetの外から中のリソースにアクセスしたいなら、アクセスするための通り道を用意する必要があります。

図1
VNet作成時にはアドレス空間を割り当てる必要があります。このアドレス空間というのはプライベートIPのどこからどこまでがこのVNetですよという意味になります。プライベートIPをたくさん範囲に含んでいる方がサイズの大きいVNetになります。

図2
↓VNetに関して詳しくはこちらを参照
https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-overview

サブネット

サブネットとはVNetの中のプライベートIPを区切ってグループ化するようなものです。AzureのリソースをVNet内に作成する場合は、VNetを作る→サブネットを作る→サブネットの中にリソースを作成するという流れになり、サブネットは不可欠な存在です。イメージとしてはVNetという箱があってその中にさらに細かく分けたサブネットという箱があるといった感じです。

図3
このサブネット単位でNSG(ネットワークセキュリティグループ)が設定できたり、リソースの中にはサブネットにそのリソース以外を含められないといった制約があるものもあります(※注意!)。実際にVNetやサブネットのサイズを決める際には、どのようなリソースを配置する必要があり、どれくらいプライベートIPを使用する見込みがあるかを考える必要があります。

VNet内にデプロイできるリソース、デプロイできないリソースがある

では、Azureのリソース同士を通信させたい場合、まずは同一VNet内に入れてしまう(デプロイする)という方法が考えられます。VNet内にリソースをデプロイすることをVNet内部デプロイやVNet統合と言います。しかしリソース自体をVNet内にデプロイできるリソースとデプロイできないリソースがあります。
【デプロイできるリソース例】

  • AppService
  • Functions
  • API Management

【デプロイできないリソース例】

  • cosmosDB
  • Blob Storage
  • AzureOpenAI

詳しくは以下リンクにVNet内にデプロイできるリソースが記載されているので見てみてください。
https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-for-azure-services

厳密には違うかもですが、内部デプロイできる・できないのイメージは下図のような感じです!下図のApp Serviceが内部デプロイできる例として記載しています。

図4

VNetに内部デプロイできないリソースとの通信

方法としては主に以下の3つになります。

  • リソースをパブリックにする
  • プライベートエンドポイント
  • サービスエンドポイント

リソースをパブリックにする

1つ目の方法としては、VNetに内部デプロイできないリソースをパブリックな状態にしておくことです。これはインターネット上で誰でもアクセスできるように公開してしまうという意味です。なので、APIキーなど認証に必要な情報さえあればリソースを利用できてしまい。セキュリティ的にはよろしくありません。
イメージは下図のような感じです。

図5
この時、VNet内部のリソースからパブリックな外のリソースにアクセスすることは可能です(セキュリティの設定で禁止することも可能だと思いますが)。

プライベートエンドポイント

これから話すプライベートエンドポイントとサービスエンドポイントについては以下ドキュメントが参考になります。この2つの違いが難しいのですが、ドキュメント内に比較表もあるので正確な情報はドキュメントを参照してください。
https://learn.microsoft.com/ja-jp/azure/virtual-network/vnet-integration-for-azure-services
まず、リソースのネットワークを無効にします。そうすると、そのリソースは外部からアクセスできなくなります。ただこれではアクセスしたいリソースからもアクセスできないということになります。そのため、アクセスしたいリソースに繋がる通り道を作成する必要があり、これがプライベートエンドポイントとなります。
下図がその際のイメージです。

図6
この場合AppServiceからcosmosDBにアクセスさせたいので、同一のVNet内にプライベートエンドポイントを作成します。プライベートエンドポイントを作成すると、PrivateLinkが構成され、プライベートエンドポイントとネットワークが無効になったcosmosDBとの通り道ができます。そして、プライベートエンドポイントとAppServiceは同じVNetなので通信可能となり、結果的にAppServiceからcosmosDBにアクセス可能になります。

サービスエンドポイント

サービスエンドポイントもプライベートエンドポイントと同様に外部からのアクセスは遮断し、アクセスさせたいリソースからはアクセス可能にすることができます。イメージは下図です。

図7
サービスエンドポイントはプライベートエンドポイントのように設置するというよりも、このIPからのアクセスは許可するけど他のIPはアクセスできないよって感じのイメージです。ただ、Azureのリソース間の通信であれば、Azureのバックボーンネットワークというものが使用されるらしく、閉域化された状態で通信が行えるという意味ではセキュリティ的に問題がないように思えます。リソースによって異なるようですが、アクセス許可の設定の際にIPでの指定だけしかできないリソースもあれば、サブネットを指定してアクセス許可できるリソースもあるようです。

プライベートエンドポイントとサービスエンドポイントの違い

私もこの使い分けについては理解しきれていないので、詳しくはMSドキュメントを読んでほしいと思います。MSとしては、サービスエンドポイントよりもプライベートエンドポイントを使用する方がセキュリティ的に安全等の理由でプライベートエンドポイントの使用を推奨しているようです。ただプライベートエンドポイントを使用すると以下のデメリットもあります。

  • 料金がかかる(サービスエンドポイントは無料)
  • プライベートエンドポイント用のプライベートIPが必要になる

なので私の理解としては、MS推奨に則りプライベートエンドポイントを使用するのがベストだが、値段やサービスの要件も考えサービスエンドポイントを使用するでも問題はなさそうかなといった感じです。

リソースのネットワーク設定画面

Azureのリソースのネットワークの設定画面はリソースによって微妙にUIなど違って困惑する場合があります。
参考に以下リンクはcosmosDBのネットワーク設定に関する1例のドキュメントです。
https://learn.microsoft.com/ja-jp/azure/cosmos-db/how-to-configure-vnet-service-endpoint
下図は上記リンクから拝借したネットワーク設定画面の画像です。

図8
詳しくは説明しませんが、ラジオボタンの部分とこれまで解説した内容は以下のように関連付けられます。

  • All networks(全てのネットワーク)→パブリック
  • Selected networks(選択されたネットワーク)→サービスエンドポイント
  • Disabled(無効)→ネットワーク無効

※括弧内は日本語表記の場合
わかりづらいのはこれまで話したサービスエンドポイントはネットワーク設定画面でサービスエンドポイントとは記載されていないという点ですね。
また、ネットワーク無効は無効にするとどこからもアクセスできなくなるだけなので、先ほど述べたようにプライベートエンドポイントを画面の「Private access」あたりをクリックして作成していくような流れになります。

VNetピアリング

VNetピアリングを行うことで異なるVNet同士のリソース間で通信することができます。
下図のようなイメージとなります。

図9
Vnetピアリングする際は以下3つについて注意しましょう。この後ざっくりとですが説明していきます。

  • VNetのアドレス空間が重複してはいけない
  • 原則として方向ごとのピアリングの設定が必要
  • ピアリングの設定は推移しない

また、VNetピアリングはサブスクリプションやリージョンが異なっても可能ですが、リージョンが異なる場合はVNetを跨いだ通信の際にかかる料金も変わってくるようです(参照:Virtual Nerworkの価格)。

VNetピアリングの詳細についてもっと知りたい方は、以下リンクのMSドキュメントなどを参照してください。
https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-peering-overview

VNetのアドレス空間が重複してはいけない

VNet作成時にアドレス空間を指定する必要があると記載しました。このアドレス空間が重複したVNetを作成することも可能ですが、重複したVNet同士をピアリングすることはできません。ピアリングした後もピアリング前のプライベートIPを基にどのリソースにアクセスするかが決定されるので、プライベートIPが重複した状態でピアリングできるとするなら、同じネットワークの中にプライベートIPが同じリソースが存在して、どちらのリソースにアクセスすれば良いかがわからなくなるから、ピアリングはできないといったイメージになるかと思います。AzureポータルでVNet作成時にアドレス空間が重複するVNetが存在したら、重複してますよという表示は出してくれます。

原則として方向ごとのピアリングの設定が必要

下図のようにVNet1とVNet2を接続したい場合、「VNet1からVNet2に接続するための設定」と「VNet2からVNet1に接続するための設定」の両方が必要です。現在のAzureポータルでは1つの画面操作によって各方向のピアリング設定を作成できるようです。

図10

ピアリングの設定は推移しない

「ピアリングの設定は推移しない」とは「接続させたいVNet同士は明確にピアリングの設定を行う必要がある」とも言い換えられます。下図の具体例を見てもらえればすぐに理解できると思います。

図11
図のように「VNet1とVNet2が接続している」かつ「VNet2とVNet3が接続している」場合でも、VNet1とVNet3は通信できる訳ではありません。VNet1とVNet3で通信したければ、VNet1とVNet3で接続のピアリング設定を行う必要があります。

VPNゲートウェイとExpressRoute

この記事も長くなってきたので、ここに関してはこんなものあるんだくらいの紹介です。VPNゲートウェイやExpressRouteというものを用いることで、オンプレミスのネットワークとVNet内の通信が可能になります。オンプレミスの社内環境と安全に通信を行いたい場合には、この辺りを調べると良いでしょう。
一応参考になりそうなMSドキュメントのリンクを以下に貼っておきます。
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpngateways
https://learn.microsoft.com/ja-jp/azure/expressroute/expressroute-introduction

最後に

細かい仕組みや設定方法の部分などは記載していませんが、ざっくりとAzureのネットワークに関して理解できたでしょうか?ざっくりとしたイメージを持った上でドキュメントを読むと理解が早まると思うので、皆さんのAzure学習の助けになっていれば幸いです。私もAzure触り始めの初学者には違いないので、間違いなどあればご指摘いただけると嬉しいです!

参考となる本(補足)

MSドキュメントを参考として色々貼りましたが、こちらの本もAzure学ぶのに役立ってます。
https://www.amazon.co.jp/模擬問題付き-Microsoft-Azure-Administrator教科書-AZ-104/dp/4295013692

Discussion

YasunaCoffeeYasunaCoffee

Vnetはリソース配置するときに注意が必要だと始めて知りました!
AWSとはまた違った側面があって新しい発見でした。図解とても分かりやすく助かりました!