はじめに
Azure Monitor にプライベート接続するための機能である Azure Monitor Private Link Scope (AMPLS) ですが、通常の Private Link とは異なり、かなり考慮ポイントが多い印象です。今回はこちらの実装方法と考慮ポイントを検証しつつ整理します。
AMPLS とは？
詳細は公式ドキュメントを参照いただければと思いますが、ポイントとしては以下になるかと思います。
- Azure Monitor リソース (Log Analytics ワークスペースや Application Insights など) にプライベートでアクセス
- プライベート エンドポイント経由でアクセスできる Azure Monitor リソースを制限し、指定以外の Azure Monitor リソースへのアクセスを制限
- ExpressRoute を使用して、オンプレミスのプライベート ネットワークを Azure Monitor に安全にアクセス
構成イメージ
構成イメージはこちらです。
他の PaaS のプライベート エンドポイントは各 PaaS リソースと紐づいていますが、AMPLS の場合は AMPLS が Azure Monitor リソースを集約して、AMPLS がプライベート エンドポイントと紐づく構成になっています。そのため、AMPLS に集約した Azure Monitor リソースにアクセスする場合は共通の プライベート エンドポイントを使用することになります。
設計上の注意点
AMPLS には、特に注意すべき制限があります。
DNS 構成
通常、プライベート エンドポイントに紐づくプライベート DNS レコード はリソース個別の A レコードになるため、他のプライベート エンドポイントには影響を与えません。一方で、AMPLS の場合、リソース個別のプライベート DNS レコードだけではなく、リソース共通のプライベート DNS レコードも作成されます。
以下が AMPLS を設定したときのプライベート DNS ゾーンですが、api.privatelink.monitor.azure.com や global.in.ai.privatelink.monitor.azure.com などリソースに依存しない A レコードが登録されていることが分かります。
そのため、同一のプライベート DNS ゾーンに対して、複数の AMPLS のプライベート エンドポイントを紐づけるとプライベート IP が上書きされ、前に設定したプライベート エンドポイントへアクセス不可となる可能性があります。そのため、DNS 構成と AMPLS は 1 対 1 とすることが原則になります。
AMPLS の接続制限
AMPLS には以下の制限があります。
- VNET に接続できる AMPLS は 1 つのみ (=その VNET からアクセスする必要のある Azure Monitor リソースはすべて AMPLS に含める必要がある)
- 1 つの AMPLS には 300 のLog Analytics ワークスペースと 1,000 の Application Insights コンポーネントに接続可能
- 1 つの AMPLS には最大 10 個のプライベート エンドポイントが接続可能
- 1 つの Azure Monitor リソース (Log Analytics ワークスペース、Application Insights コンポーネント、またはデータ収集エンドポイント) を最大 5 つの AMPLS に接続可能
公式ドキュメントにイメージの記載がありましたので、そちらを転記しておきます。
- 各仮想ネットワークは 1 つの AMPLS オブジェクトにのみ接続します。
- AMPLS A は、接続可能な 300 の Log Analytics ワークスペースのうちの 2 つと、接続可能な 1,000 の Application Insights コンポーネントのうちの 1 つを使用して、2 つのワークスペースと 1 つの Application Insight コンポーネントに接続します。
- ワークスペース 2 は、使用可能な 5 つの AMPLS 接続のうち 2 つを使用して、AMPLS A と AMPLS B に接続します。
- AMPLS B は、使用可能な 10 個のプライベート エンドポイント接続のうち 2 つを使用して、2 つの仮想ネットワーク (VNet2 と VNet3) のプライベート エンドポイントに接続します。
上記の通り、接続数の上限が結構厳しいため、基本的にはハブ & スポーク構成でのハブへの配置や AMPLS 接続用の VNET を準備など、できるだけ集約して使用することが推奨となります。
その他制限
その他、様々な制限がありますので、こちらを確認することをお勧めします。
デプロイ
ここから、AMPLS をデプロイしてみます。Private Link から [Azure Monitor プライベート リンク スコープ] を開き、[+作成] をクリックします。
リソース グループや名前を設定します。後ほど検証しますが、アクセスモードは [オープン] のままにしておきます。[確認および作成] をクリックします。
作成されたら、関連づける Azure Monitor リソースを指定します。
次にプライベート エンドポイントを作成します。
リソースの種類は Microsoft.Insights/privateLinkScopes を選択します。
プライベート DNS 統合を有効にします。無効で自身でレコード管理することも可能ですが、かなり個数が多いため、有効とすることをお勧めします。
Azure Monitor エージェントを使用している場合、データ収集ルールの仮想マシンにデータ収集エンドポイントを紐づける必要があります。
また、データ収集エンドポイントで AMPLS 以外からのアクセスを拒否したい場合は、データ収集エンドポイントの [ネットワークの分離] から設定することが可能です。
検証
プライベート アクセス
上記で基本的な設定は完了しましたので、動作確認していきます。VNET 内の仮想マシンからのログ転送やクエリがプライベートアクセスになっていることを確認します。
まず VM からデータ収集エンドポイントへのアクセスがプライベート IP になっていることが確認できます。
Heartbeat テーブルを確認します。こちらを見ると、IP アドレスが IPv6 になっています。調べるとユニーク ローカル アドレスっぽいので、プライベートではあるのですが、なぜ IPv6 になるのかは分かりませんでした。(NIC 設定も OS としても IPv6 は OFF にしている)
設定後に切り替わっているため、プライベート アクセスとなっているのではと思います。
アクセス モード
AMPLS にはアクセス モードという機能があり、紐づけた VNET から AMPLS に属さない Azure Monitor リソースへはアクセスさせない、ということが可能になります。インジェストとクエリそれぞれで設定が可能となるので、こちらを確認していきます。
AMPLS の設定画面から [アクセス モード] を開き、インジェスト・クエリともに [プライベートのみ] に設定します。
まずクエリから試します。VNET 内にいる VM で AMPLS 内の Log Analytics ワークスペースでログ検索すると、問題なく実行できます。
AMPLS 外の Log Analytics ワークスペースでログ検索します。すると、以下のようにアクセス拒否されます。
ちなみに上記の制限はあくまで VNET の中からアクセス制限になるので、VNET 外からアクセスした場合はアクセスはいずれも可能です。
次にインジェストを確認します。AMPLS 外の Log Analytics ワークスペースで Heartbeat を検索します。すると、ログが継続して記録されていることが確認できました。
よく確認してみると、公式ドキュメントに注意事項があり、Log Analytics のインジェストはリソース固有のエンドポイント (アクセス URL) が使用されるため、AMPLS のアクセス モードは効かず、ファイアウォールや NSG などでネットワークとしてブロックする必要があるようです。
Log Analytics のネットワーク分離
最後に Log Analytics でのネットワーク分離を試します。現時点の設定では、VNET 内からのアクセスは制限できていますが、VNET 外からの Log Analytics へのアクセスは制限できていません。こちらは Log Analytics ワークスペースで設定します。
設定後、以下のように VNET 外からはアクセス不可となります。
まとめ
AMPLS について Azure Monitor プライベート化の確認・検証をしていきました。構成や制約で考慮ポイントが多く、事前によく検討する必要がありそうです。また、プライベート化についても VNET 内外やインジェスト・クエリごとなど、いくつか段階があります。単純に VNET からのログ転送をプライベート化したいのであれば、AMPLS のアクセス モードはオープン、Log Analytics ワークスペースやデータ収集エンドポイントはパブリックアクセスを許可としておいたほうが、運用上支障がなさそうです。
Discussion