AKS Automatic管理VNetからAzure Database for PostgreSQLフレキシブルサーバーへプライベート接続する設計と制約

AKS Automatic の管理 VNet にデプロイした Airbyte から、別 VNet 上の Azure Database for PostgreSQL フレキシブルサーバーへ「完全プライベート接続」したいとき、多くの人が nrg-lockdown に阻まれて詰まります。本記事では、その理由と現実的な解決策（BYO VNet＋プライベートエンドポイント構成）を、移行ステップまで含めて詳しく解説します。

シナリオの整理：AKS Automatic と PostgreSQL フレキシブルサーバー

想定している構成は次のようなものです。

アプリケーション：Airbyte（データ連携ツール）
実行基盤：AKS Automatic クラスター（Azure CNI Overlay＋Cilium、管理 VNet）
データベース：Azure Database for PostgreSQL フレキシブルサーバー（別 VNet 上）
要件：DB をインターネットに公開せず、「プライベートのみ」で AKS から接続したい

しかし実際には、次のような操作がいずれも deny assignment（nrg-lockdown） によりブロックされます。

AKS 管理 VNet と DB VNet の VNet ピアリング作成
AKS 管理 VNet に新しいサブネットを追加
AKS 管理 VNet 内にプライベートエンドポイントを作成

この時点で「AKS Automatic のままでは無理なのでは？」という疑問が出てきます。本記事の結論から先に整理していきます。

結論：管理 VNet Automatic のままでは“完全プライベート接続”はサポート外

2025 年 9 月の Microsoft Q&A で、まさに本記事と同じシナリオ（Airbyte on AKS Automatic 管理 VNet → 別 VNet の PostgreSQL フレキシブルサーバーへプライベート接続）が相談され、公式回答として以下が明言されています。

「BYO VNet を使わない構成はサポートされない」
AKS Automatic 管理 VNet は Microsoft 管理の VNet であり、ユーザーが VNet ピアリングなどを作成することはできない
インプレースで BYO VNet に切り替える方法はなく、新しい BYO VNet クラスターを作ってアプリを移行する必要がある
BYO VNet にしても、AKS Automatic の「お任せなマネージド性」は維持される

したがって、要件「別 VNet 上の PostgreSQL に、インターネット公開無しでプライベート接続したい」を満たすには、次の構成が推奨されます。

AKS：BYO VNet（カスタム VNet）上に新しい AKS クラスター（Automatic または Standard）を構築
PostgreSQL：プライベートエンドポイント＋プライベート DNS を構成し、Public access（パブリックアクセス）はオフ
AKS VNet から DB のプライベートエンドポイントサブネットへの TCP/5432 の許可

以降では、「なぜ AKS Automatic 管理 VNet ではダメなのか」「BYO VNet でどう設計すればよいか」「移行をどう進めるか」を順番に解説します。

AKS Automatic 管理 VNet の正体：なぜいじれないのか

AKS Automatic のネットワーク構成をおさらい

AKS Automatic のネットワークは、概ね次のような特徴を持ちます。

Azure CNI Overlay＋Cilium を利用したオーバーレイネットワーク
- Pod は VNet とは別のプライベート CIDR（Pod CIDR）から IP を払い出し
- クラスターの外に出るトラフィックは、Node の IP へ SNAT されて外部へ出る
Managed Virtual Network（AKS 管理 VNet）
- AKS が自動で VNet・サブネット・ルートなどを作る
- ユーザーはこの VNet を直接編集しない前提
Outbound（インターネット向け）は、AKS 管理 NAT Gateway から出ていく

Azure CNI Overlay 自体は、「Pod の外向き通信は Node IP から出る」モデルなので、VNet レベルで Node サブネットから DB のプライベート IP へ到達できればよいというシンプルな考え方で済みます。

問題は、「その VNet 自体を触れない」という点にあります。

AKS 管理 VNet は AKS 管理リソース：ユーザー変更はサポート外

AKS のネットワークドキュメントでは、プラットフォーム側が自動作成した VNet / ルートなどのリソースは、ユーザーが直接変更しないことがサポートポリシーとして明記されています。

自動作成された VNet に対して、ユーザー定義ルートやサービスエンドポイントなどを勝手に追加するのはサポート外
代わりに、自分で作った VNet（BYO VNet）にクラスターを乗せる場合のみ、UDR や NSG を自由に構成できる

さらに、AKS Automatic では node resource group lockdown（nrg-lockdown） がデフォルトで有効になっており、ノードリソースグループに対して deny assignment が設定されます。

実際の Microsoft Q&A でも、Airbyte をのせた AKS Automatic 管理 VNet に対して PostgreSQL VNet からピアリングを張ろうとしたところ、次のようなエラーが出ています。

Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write が deny assignment によって拒否
AKS 管理 VNet にサブネットを追加しようとすると、Microsoft.Network/virtualNetworks/subnets/write が拒否

つまり、AKS Automatic 管理 VNet は「AKS の一部」であり、ユーザーが VNet ピアリングやサブネット追加などの操作を行うことは設計上想定されていないということです。

プライベートエンドポイントの仕組みと、管理 VNetの壁

Azure Private Endpoint は、指定した VNet のアドレス空間からプライベート IP を持つ NIC を作成し、その NIC 経由で Azure PaaS（PostgreSQL など）へプライベート接続する仕組みです。

プライベートエンドポイント NIC は 「アクセスする側の VNet」 に作る
その VNet に紐づくプライベート DNS ゾーンで FQDN → プライベート IP への解決を行う

ところが、AKS Automatic の管理 VNet は前述の通り ユーザーがリソースを作成できない VNet です。

そのため、

AKS 管理 VNet 内に PostgreSQL 用のプライベートエンドポイントを作る

という、最もシンプルな構成が実現不可能になります。

Automatic 管理 VNet で「やってはいけない」構成と妥協案

まずは、「Automatic 管理 VNet のままなんとかできないか？」という観点で、よく検討されるパターンを整理します。

試したい構成／アイデア	Automatic 管理 VNet での可否	理由
AKS 管理 VNet ↔ DB VNet の VNet ピアリング	不可（サポート外）	管理 VNet の `virtualNetworkPeerings/write` が nrg-lockdown の deny assignment により拒否される。
AKS 管理 VNet に DB 接続専用サブネットを追加	不可（サポート外）	`/subnets/write` も node resource group lockdown により拒否。VNet 自体が AKS 管理リソース。
AKS 管理 VNet に PostgreSQL のプライベートエンドポイント NIC を作成	実質不可	そもそも管理 VNet 内でユーザーがリソース作成できず、サポートポリシー的にも非推奨。
DB をパブリックにして、AKS の送信 IP（NAT Gateway）だけ許可	可能だが要件を満たさない	PostgreSQL ファイアウォールで特定 IP のみ許可することはできるが、エンドポイント自体はインターネット公開となるため、「完全プライベート接続」の要件に反する。
別 VNet に中継用の VM / Firewall を立てて踏み台にする	構成としては可能だが複雑	結局どこかで AKS 管理 VNet と中継 VNet をつなぐ必要があり、ピアリングや UDR など「VNet をいじる」ことが避けられない。

つまり、「Automatic 管理 VNetのままやりくりする」アプローチは、セキュリティ要件を満たしつつシンプルに運用できる案がない、というのが実情です。

BYO VNet 構成の全体像：AKS 自体は引き続き “お任せ” で良い

Automatic でも BYO VNet が使える

AKS Automatic と AKS Standard の機能比較ドキュメントでは、Automatic でも Custom virtual network（BYO VNet） がオプションとしてサポートされることが明記されています。

デフォルト：Managed Virtual Network（Azure CNI Overlay＋Cilium）
オプション：Custom virtual network（BYO VNet）
クラスターのマネージド性（自動スケーリング、node auto-provisioning など）は Automatic のまま維持

また、「AKS Automatic をカスタム VNet にデプロイする」公式クイックスタートも用意されており、ユーザー自身が VNet／サブネットを作成した上で、Automatic クラスターをその VNet に配置する手順が公開されています。

API Server 用サブネット（delegation：Microsoft.ContainerService/managedClusters）を作成
ノード用サブネット（cluster subnet）を作成
ユーザー管理の VNet に対して、AKS のマネージド ID に Network Contributor を付与
その VNet のサブネット ID を指定して、--sku automatic で AKS クラスターを作成

つまり、「Automatic だから管理 VNet を使うしかない」というわけではなく、Automatic のお任せ感はそのままに、VNet だけ自分で設計できるということです。

構成タイプ別の違いを比較

構成タイプ	VNet の所有者	VNet の自由度（ピアリング／PE／NSG）	AKS のマネージド性
AKS Automatic（管理 VNet）	AKS（Microsoft 側が管理）	ユーザーによる変更はサポート外（ピアリング／サブネット追加／UDR など不可）	最大（node auto-provisioning、Managed NAT、Managed NGINX などフル自動）
AKS Automatic（BYO VNet）	ユーザー（自サブスクリプションの VNet）	ピアリング／プライベートエンドポイント／NSG／UDR などを自由に設計可能（ただし NSG 要件は満たす必要あり）	Automatic の機能はそのまま（クラスター運用は AKS にお任せ）
AKS Standard（BYO VNet）	ユーザー	ネットワーク自由度は Automatic BYO VNet と同等	ノードプールやスケーリングなどを自分で細かく設計可能（より DIY 志向）

今回の PostgreSQL フレキシブルサーバーへのプライベート接続要件だけなら、「AKS Automatic（BYO VNet）」で十分です。AKS Standard に切り替える必要はありません。

PostgreSQL フレキシブルサーバー側の前提：Private access と Private Link

Azure Database for PostgreSQL フレキシブルサーバーには、大きく分けて 2 つのネットワークモードがあります。

Private access（VNet integration）
- DB サーバーが特定の VNet/Subnet に直接注入される（VNet injection）
- VNet 統合モードのサーバーは、基本的に Private Endpoint と併用できない制限がある
Public access＋Private Link（プライベートエンドポイント）
- サーバー自体は「Public access モード」で作成
- Azure Private Endpoint を使って特定 VNet からのみプライベート IP で接続
- Public access をオフにすれば、実質的にプライベートエンドポイント経由のみアクセス可能

Private Link 方式では、

プライベート DNS ゾーン privatelink.postgres.database.azure.com を使い、DB の FQDN をプライベート IP に解決
プライベートエンドポイントが存在し、Public access やサービスエンドポイントを設定していなければ、その DB にはプライベートエンドポイント経由でのみアクセス可能

といった設計が推奨されています。

既に VNet integration モードで作成された DB は、Private Endpoint の制限があるため、必要に応じて Private Link モードで新サーバーを作り直す、あるいは構成の見直しが必要になる点にも注意してください。

推奨構成：BYO VNet 上の AKS＋PostgreSQL Private Endpoint

ここからは、具体的なターゲットアーキテクチャを整理します。

全体像（論理構成）

VNet：vnet-app
- Subnet：subnet-aks-cluster（AKS ノード用）
- Subnet：subnet-db-pe（PostgreSQL プライベートエンドポイント用）
AKS クラスター
- SKU：Automatic
- ネットワーク：Azure CNI Overlay（Pod はオーバーレイ、ノードは subnet-aks-cluster）
PostgreSQL フレキシブルサーバー
- Private Link 対応
- Public access：Disabled（パブリックエンドポイント無効）
- プライベートエンドポイント：subnet-db-pe に NIC を作成
- プライベート DNS ゾーン：privatelink.postgres.database.azure.com を vnet-app にリンク

この構成であれば、

AKS ノードから DB のプライベート IP（プライベートエンドポイントの IP）に直接 TCP/5432 で接続可能
DB はインターネットから直接到達できない（Private Link 経由のみ）
AKS 側は Automatic のマネージド性を維持しつつ、VNet を自由に設計できる

という要件を満たせます。

実装ステップの詳細

1. VNet／サブネットの設計と作成

まず、将来のスケールも踏まえた アドレス計画 を行います。

vnet-app：例えば 10.50.0.0/16
subnet-aks-cluster：10.50.1.0/24
subnet-db-pe：10.50.2.0/24

Azure CLI 例：

az network vnet create \
  --resource-group rg-app \
  --name vnet-app \
  --address-prefixes 10.50.0.0/16

az network vnet subnet create \
  --resource-group rg-app \
  --vnet-name vnet-app \
  --name subnet-aks-cluster \
  --address-prefixes 10.50.1.0/24

az network vnet subnet create \
  --resource-group rg-app \
  --vnet-name vnet-app \
  --name subnet-db-pe \
  --address-prefixes 10.50.2.0/24

2. AKS Automatic クラスターを BYO VNet に作成

公式クイックスタート同様、AKS 用のマネージド ID を作成し、VNet に Network Contributor を付与した上で、Automatic クラスターを作成します。

IDENTITY_NAME=aks-auto-uami
VNET_NAME=vnet-app
AKS_SUBNET_ID=$(az network vnet subnet show \
  --resource-group rg-app \
  --vnet-name ${VNET_NAME} \
  --name subnet-aks-cluster \
  --query id -o tsv)

# UAMI 作成
az identity create \
  --resource-group rg-app \
  --name ${IDENTITY_NAME}

IDENTITY_PRINCIPAL_ID=$(az identity show \
  --resource-group rg-app \
  --name ${IDENTITY_NAME} \
  --query principalId -o tsv)

# VNet への権限付与（Network Contributor）
SUBSCRIPTION_ID=$(az account show --query id -o tsv)
az role assignment create \
  --scope "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/rg-app/providers/Microsoft.Network/virtualNetworks/${VNET_NAME}" \
  --role "Network Contributor" \
  --assignee ${IDENTITY_PRINCIPAL_ID}

# AKS Automatic クラスター作成（BYO VNet）
az aks create \
  --resource-group rg-app \
  --name aks-auto-byo \
  --location japaneast \
  --vnet-subnet-id ${AKS_SUBNET_ID} \
  --assign-identity "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/rg-app/providers/Microsoft.ManagedIdentity/userAssignedIdentities/${IDENTITY_NAME}" \
  --sku automatic \
  --no-ssh-key

3. PostgreSQL フレキシブルサーバーのプライベートエンドポイント構成

PostgreSQL フレキシブルサーバー側では、次を実施します。

Public access を無効化（Public ネットワークからの接続禁止）
subnet-db-pe に対してプライベートエンドポイントを作成
プライベート DNS ゾーン privatelink.postgres.database.azure.com を作成し、vnet-app をリンク

Private Link ドキュメントにあるように、FQDN は通常 <server-name>.postgres.database.azure.com であり、プライベートエンドポイント有効時には <server-name>.privatelink.postgres.database.azure.com の A レコードに解決されます。

4. NSG／UDR の最小設定

クラスター用サブネットに NSG を適用している場合、少なくとも次を許可する必要があります。

送信：subnet-aks-cluster → subnet-db-pe への TCP/5432（PostgreSQL）
戻り通信：subnet-db-pe → subnet-aks-cluster（ステートフル NSG なので、通常は自動許可）

UDR を使っている場合は、PostgreSQL フレキシブルサーバーのプライベートエンドポイント IP へのルートが正しく引けるようにルートテーブルを確認します。

5. 接続確認（Node / Pod から）

AKS ノードから、次のように確認します。

# DNS 解決確認
nslookup &lt;server-name&gt;.postgres.database.azure.com

# 5432/TCP の疎通確認
nc -vz &lt;server-name&gt;.postgres.database.azure.com 5432

DNS がプライベート IP を返し、TCP/5432 への接続が成功すれば、ネットワーク的な準備は完了です。Private Link ＋ Private DNS の組み合わせが正しく動いていることを意味します。

Airbyte 側の設定ポイント

PostgreSQL コネクションのホスト名は 必ず FQDN（例：<server-name>.postgres.database.azure.com）で指定
IP 直書き（プライベート IP や過去のパブリック IP）は避ける
- フェイルオーバーやプライベートエンドポイント再作成で IP が変わることがあるため
接続文字列に sslmode=require を指定し、TLS 接続を強制
もし Airbyte 側でプロキシや sidecar（Envoy など）を使っている場合は、そのコンテナからも同様に DNS／疎通テストを実施

インプレース移行は不可：新クラスターへの段階移行戦略

Microsoft Q&A の回答でも、「BYO VNet へのインプレース移行パスは存在しない」ことが明言されています。

したがって、現実的な移行戦略は次のようになります。

フェーズ	主な作業	ポイント
計画・設計	VNet／サブネット設計、PostgreSQL 側の Private Link 切り替え方針の決定	既存 DB が VNet integration の場合、新規サーバーを立てるかどうかを検討。
新クラスター構築	BYO VNet 上に AKS Automatic クラスターを構築し、Private Endpoint を設定	移行前に `nslookup`／`nc` で接続確認しておく。
アプリ／Airbyte 移行	Helm Chart やマニフェストを新クラスターに適用し、Airbyte の設定を FQDN 向けに変更	ステートフルなコンポーネント（PVC、シークレット、Key Vault 参照など）は事前に移行プランを作る。
並行稼働・検証	旧クラスターと新クラスターを並行稼働し、Airbyte のジョブや同期結果を比較	一部コネクタだけ新クラスターで動かし、段階的に切り替えるとリスク低減。
本番切り替え	DNS／トラフィックを新クラスター側に寄せ、旧クラスターを段階的に停止	ロールバックパス（旧クラスターへの戻し方）をあらかじめ決めておく。

実装チェックリスト：BYO VNet で進めるときに確認すべきこと

カテゴリ	チェック項目	具体的な観点
アドレス設計	VNet／サブネットのサイズ	将来のノード数・Pod 数を見込んだ CIDR を確保（Azure CNI Overlay の最大 Pod 数などを考慮）。
NSG	ノードサブネットから DB への 5432/TCP 許可	他のサブネット間のトラフィック制御ルールで DB 接続を誤ってブロックしていないかを確認。
プライベート DNS	`privatelink.postgres.database.azure.com` のリンク	ハブ＆スポーク構成の場合、ハブ VNet の Private DNS ゾーンにスポーク VNet（AKS VNet）を正しくリンクする。
Airbyte 設定	接続先ホスト名は FQDN 指定	IP 直書きをやめ、常に `<server-name>.postgres.database.azure.com` を使う。
監視	接続失敗時のトラブルシュート	DNS 解決・TCP コネクション・NSG・ルート・Private Endpoint 状態を分解して確認する運用手順を用意。

やむを得ない場合の妥協案：パブリック＋IP 制限

どうしても短期的に BYO VNet 構成を組めない場合、暫定策として次のような妥協案があります。

PostgreSQL フレキシブルサーバーを Public access（許可 IP 制御）モードにする
AKS Automatic 管理 VNet に紐づく Managed NAT Gateway のパブリック IP を確認し、その IP のみを DB の許可リストに追加する

この場合、

DB への接続は「特定グローバル IP からのみ」に制限される
しかし、DB のエンドポイントは依然として インターネット上に公開 されている

ため、完全なプライベート接続（Private Link 経由のみ）という要件は満たせません。セキュリティ・コンプライアンスの観点からも、本番構成としてはおすすめできず、あくまで BYO VNet 構成が完成するまでのつなぎ と考えるべきです。

1分まとめ：Automatic 管理 VNet でハマったときの結論

AKS Automatic の 管理 VNet は AKS 管理リソースであり、VNet ピアリングやサブネット追加などの変更は deny assignment（nrg-lockdown）でブロックされる。
そのため、Automatic 管理 VNet のまま、別 VNet の PostgreSQL フレキシブルサーバーに「プライベートのみ」で接続するサポートされた方法は存在しない。
解決策は、BYO VNet 上に新しい AKS クラスター（できれば Automatic のまま）を構築し、PostgreSQL にプライベートエンドポイント＋プライベート DNS を設定すること。
BYO VNet にしても、AKS Automatic のマネージド性は維持される。失われるのは「管理 VNet 強制」という制約だけで、代わりにネットワークの自由度を得られる。
インプレース移行はできないため、新クラスターを別途構築し、アプリ／Airbyte を段階的に移行する戦略が必須となる。

AKS Automatic 管理 VNet の「触れない」特性さえ理解してしまえば、解はシンプルです。クラスターそのもののマネージド性を諦める必要はなく、ネットワークだけ BYO VNet に切り替えて、PostgreSQL を Private Link で引き寄せる——これが、長期的に安全かつサポートされる構成になります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

AKS Automatic管理VNetからAzure Database for PostgreSQLフレキシブルサーバーへプライベート接続する設計と制約

シナリオの整理：AKS Automatic と PostgreSQL フレキシブルサーバー

結論：管理 VNet Automatic のままでは“完全プライベート接続”はサポート外

AKS Automatic 管理 VNet の正体：なぜいじれないのか

AKS Automatic のネットワーク構成をおさらい

AKS 管理 VNet は AKS 管理リソース：ユーザー変更はサポート外

プライベートエンドポイントの仕組みと、管理 VNetの壁

Automatic 管理 VNet で「やってはいけない」構成と妥協案

BYO VNet 構成の全体像：AKS 自体は引き続き “お任せ” で良い

Automatic でも BYO VNet が使える

構成タイプ別の違いを比較

PostgreSQL フレキシブルサーバー側の前提：Private access と Private Link

推奨構成：BYO VNet 上の AKS＋PostgreSQL Private Endpoint

全体像（論理構成）

実装ステップの詳細

1. VNet／サブネットの設計と作成

2. AKS Automatic クラスターを BYO VNet に作成

3. PostgreSQL フレキシブルサーバーのプライベートエンドポイント構成

4. NSG／UDR の最小設定

5. 接続確認（Node / Pod から）

Airbyte 側の設定ポイント

インプレース移行は不可：新クラスターへの段階移行戦略

実装チェックリスト：BYO VNet で進めるときに確認すべきこと

やむを得ない場合の妥協案：パブリック＋IP 制限

1分まとめ：Automatic 管理 VNet でハマったときの結論

この記事を書いた人

コメント

コメントするコメントをキャンセル

AKS Automatic管理VNetからAzure Database for PostgreSQLフレキシブルサーバーへプライベート接続する設計と制約

シナリオの整理：AKS Automatic と PostgreSQL フレキシブル サーバー

結論：管理 VNet Automatic のままでは“完全プライベート接続”はサポート外

AKS Automatic 管理 VNet の正体：なぜいじれないのか

AKS Automatic のネットワーク構成をおさらい

AKS 管理 VNet は AKS 管理リソース：ユーザー変更はサポート外

プライベート エンドポイントの仕組みと、管理 VNetの壁

Automatic 管理 VNet で「やってはいけない」構成と妥協案

BYO VNet 構成の全体像：AKS 自体は引き続き “お任せ” で良い

Automatic でも BYO VNet が使える

構成タイプ別の違いを比較

PostgreSQL フレキシブル サーバー側の前提：Private access と Private Link

推奨構成：BYO VNet 上の AKS＋PostgreSQL Private Endpoint

全体像（論理構成）

実装ステップの詳細

1. VNet／サブネットの設計と作成

2. AKS Automatic クラスターを BYO VNet に作成

3. PostgreSQL フレキシブル サーバーのプライベート エンドポイント構成

4. NSG／UDR の最小設定

5. 接続確認（Node / Pod から）

Airbyte 側の設定ポイント

インプレース移行は不可：新クラスターへの段階移行戦略

実装チェックリスト：BYO VNet で進めるときに確認すべきこと

やむを得ない場合の妥協案：パブリック＋IP 制限

1分まとめ：Automatic 管理 VNet でハマったときの結論

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

シナリオの整理：AKS Automatic と PostgreSQL フレキシブルサーバー

プライベートエンドポイントの仕組みと、管理 VNetの壁

PostgreSQL フレキシブルサーバー側の前提：Private access と Private Link

3. PostgreSQL フレキシブルサーバーのプライベートエンドポイント構成

コメントするコメントをキャンセル