1 つのAzure Resource に複数 Private Endpoint を設定する場合の注意事項

掲載内容は個人の見解であり、所属する企業を代表するものではありません.

はじめに

最近は Azure Private Endpoint を使用して、 PaaS を使用しつつも閉域ネットワーク構成をとるアーキテクチャを多く取り扱うようになりました。 やはりオンプレミスと同様にプライベートネットワーク空間でサービスを利用したい／しなければならないという要件は非常に根強いものがあります。 ただある程度の規模の構成になってくると、Private Endpoint が 1 つでは足らず、複数の独立した仮想ネットワークから接続したいパターンが割と出てきます。 これを構成したい理由は色々あるのですが、実装しようとすると地味にハマるポイントがあり、設計段階で知っておいた方が良いかと思いますのでブログにしてみました。

Private Endpoint の構成と挙動

例えば下図のような構成で、各仮想ネットワークの仮想マシンから Private Endpoint 経由で同じストレージアカウントにアクセスしたい場合の挙動を考えてみます

multiple-private-endpoint-for-single-resource

左右の環境での差異が発生するのは２段目です。 アクセス対象リソースに対して Private Endpoint を構成した時点で、対象リソースの FQDN は privatelink を含んだ CNAME に解決されるようになります。 この privatelink を含んだ FQDN を解決するための A レコードは、各仮想ネットワークで異なる Privafte IP アドレスを返す必要があるわけですが、この IP アドレスは左右で異なります。 つまり左右の環境では同じ hoge.privatelink.blob.core.windows.net という FQDN に対して異なる名前解決の仕組みを持つ必要があることになります。 この名前解決の仕組みは基本的に以下の３択です。

２番目と３番目は独自に頑張る方法なので良いのですが、問題が発生しやすいのは1つ目のパターンです。 Private DNS Zone はそのリソース名が DNS ゾーン名に、具体的には privatelink.blob.core.windows.net になります。 つまり１つのリソースグループには Blob に対する Private DNS ゾーンは１つしか作ることができませんし、そしてそこには A レコード hoge も１つしか定義できません。 (実際に作ろうとすると hoge はなかなか使えないので、画面キャプチャ内では異なる名前 ainabastr になっています)

private-dns-zone-and-a-record

こちらのキャプチャは右側の環境になりますが、同じゾーン内には左側の環境で参照するための A レコードを登録することができません。 つまり左側の環境用に 同じ名前を持つ異なる DNS Private Zone リソース を作成する必要がありますので、リソースグループを分ける必要が出てくるわけです。

構築時のポイント

構成がわかればあとは作成するだけですが、これをポータルで作業すると割とよく間違えます。 具体的に何を間違えるかというと、2つ目の Private Endpoint を作成する際に、1つ目の Private DNS ゾーンを使用してしまい、うっかり A レコードを上書きしてしまうんですね。 つまりこんな↓構成をうっかり作ってしまうと、左側の環境からは使えるようになるのですが、右側の環境からアクセスができなくなってしまうわけです。

single-dns-zone-for-multiple-private-endpoint

構築時のポイントは Private Endpoint 作成時に選択する 統合する Private DNS Zone を選択するドロップダウン です。 下図を見ての通り、Private DNS ゾーンを選択するドロップダウンがあるのですが、接続するリソース種別が同じ（この場合は blob）であれば、全部同じゾーン名なのでリソース名も同じになり、 ドロップダウンを開いてみてリソースグループまで確認してやらないとわからないという、大変不親切な画面デザインになっています。困ったもんです。

configure-dnszone-for-private-endpoing

スクリプトやARMでやれば良いのですが、まあ試行錯誤するときはポータルが便利ですよね、ということで。 作成できたら左右の環境の DNS Private Zone を開き、A レコードの値とともに、リンクされた仮想ネットワークなどを確認しておきましょう。

private-dns-zone-and-a-record-left

補足

なお上記の問題に関しては「双方の仮想ネットワークアドレスレンジを合わせて、同一の Private IP を使用させればいいのでは？」というアイデアも考えられるわけですが、 これは以下の理由からお勧めしません。というか現実的ではありません。

具体例がないと分かりにくいかもしれませんが、例えば以下のように、左側の環境をサービス利用側、右側の環境をサービス提供側、とした構成を考えてみてください。

isolated-vnet-usecase

左側からアクセスする利用者に対しては 提供したいサービスの Private Endpoint 、ここでは Blob と Web Apps へのアクセス経路のみが提供されています。 しかし右側の環境では 一般ユーザーには提供されないサービスの Private Endpoint 、ここでは SQL Database へのアクセス経路が用意されており、保守担当者の直接アクセスや、Web Apps からバックエンドサービスとしてアクセスすることができるようになっています。 双方で共有しているリソースは Blob サービスのみで、これが本記事でトピックとしていた 分離された複数の仮想ネットワークから各々 Private Endpoint が必要になる ケースです。

この仮想ネットワークを分離するアプローチが個人的には最近のお気に入りなのですが、これは以下の理由によります。

以上、ご参考になれば幸いです。