次の方法で共有

Azure Database for PostgreSQL のプライベート アクセスを使用したネットワーク (仮想ネットワーク統合)

この記事では、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの接続とネットワークの概念について説明します。

Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成するときは、次のいずれかのネットワーク オプションを選択する必要があります。

  • プライベート アクセス (仮想ネットワーク統合)
  • パブリック アクセス (許可された IP アドレス) とプライベート エンドポイント

このドキュメントでは、プライベート アクセス (仮想ネットワーク統合) というネットワーク オプションについて説明します。

プライベート アクセス (仮想ネットワーク統合)

仮想ネットワークインジェクションを使用して、Azure Database for PostgreSQL フレキシブル サーバー インスタンスを Azure 仮想ネットワークにデプロイできます。 Azure の仮想ネットワークでは、非公開の、セキュリティで保護されたネットワーク通信が提供されます。 仮想ネットワーク内のリソースは、このネットワークで割り当てられたプライベート IP アドレスを介して通信できます。

次の機能が必要な場合は、このネットワーク オプションを選択します。

  • プライベート IP アドレスを使用して、同じ仮想ネットワーク内の Azure リソースから Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続します。
  • VPN または Azure ExpressRoute を使用して、Azure 以外のリソースから Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続します。
  • Azure Database for PostgreSQL フレキシブル サーバー インスタンスに、インターネット経由でアクセスできるパブリック エンドポイントがないことを確認します。

仮想ネットワーク間のピアリングのしくみを示す図。そのうちの 1 つに Azure Database for PostgreSQL フレキシブル サーバー インスタンスが含まれています。

前の図で:

  • Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、VNet-1 仮想ネットワークのサブネット 10.0.1.0/24 に挿入されます。
  • 同じ仮想ネットワーク内の異なるサブネットにデプロイされたアプリケーションは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに直接アクセスできます。
  • 別の仮想ネットワーク (VNet-2) にデプロイされているアプリケーションは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに直接アクセスできません。 フレキシブル サーバー インスタンスにアクセスするには 、プライベート DNS ゾーンの仮想ネットワーク ピアリング を実行する必要があります。

仮想ネットワークの概念

Azure 仮想ネットワークには、用途に合わせて構成されたプライベート IP アドレス空間が含まれます。 仮想ネットワークは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスと同じ Azure リージョンに存在する必要があります。 仮想ネットワークの詳細については、Azure Virtual Network の概要に関するページを参照してください。

リソースが Azure Database for PostgreSQL フレキシブル サーバー インスタンスを使用して仮想ネットワーク に統合されている仮想ネットワーク を使用する場合に理解しておく必要がある概念を次に示します。

  • 委任されたサブネット - 仮想ネットワークには、サブネット (サブネットワーク) が含まれます。 サブネットを使用すると、仮想ネットワークをより小さなアドレス空間に分割できます。 Azure リソースは、仮想ネットワーク内の特定のサブネットにデプロイされます。

    仮想ネットワークに統合されている Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、 委任されたサブネット内に存在する必要があります。 つまり、そのサブネットを使用できるのは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスだけです。 委任されたサブネットに他の Azure リソースの種類を含めることはできません。 サブネットを委任するには、その委任プロパティを Microsoft.DBforPostgreSQL/flexibleServers として割り当てます。

    指定できる CIDR 範囲は /28 です。これで 16 の IP アドレスを使用できます。 ネットワークまたはサブネットの最初と最後のアドレスを個々のホストに割り当てることはできません。 5 つの IP は Azure ネットワークの内部で利用するために予約されています。これには、前述のホストに割り当てることのできない 2 つの IP も含まれます。 これにより、/28 CIDR 範囲に 11 の使用可能な IP アドレスが残ります。 高可用性機能を備えた単一の Azure Database for PostgreSQL フレキシブル サーバー インスタンスでは、4 つのアドレスが使用されます。

    レプリケーションと Microsoft Entra 接続の場合は、ルート テーブルがトラフィックに影響しないことを確認します。 一般的なパターンは、すべての送信トラフィックを Azure Firewall またはカスタムのオンプレミス ネットワーク フィルタリング アプライアンス経由でルーティングすることです。

    サブネットに、すべてのトラフィックを仮想アプライアンスにルーティングするルールに関連付けられたルート テーブルがある場合:

    • 宛先サービス タグ AzureActiveDirectory とネクスト ホップ Internet を含むルールを追加します。
    • Azure Database for PostgreSQL フレキシブル サーバー インスタンスのサブネット範囲と同じ宛先 IP 範囲と次ホップ Virtual Networkを持つ規則を追加します。

    重要

    AzureFirewallSubnet、AzureFirewallManagementSubnet、AzureBastionSubnet、GatewaySubnet を含む名前は、Azure 内で予約されています。 これらの名前のいずれも、サブネット名として使用しないでください。 さらに、仮想ネットワークでは、リージョン間レプリカを作成するためのアドレス空間が重複しないようにする必要があります。

  • ネットワーク セキュリティ グループ (NSG): NSG のセキュリティ規則を使用して、仮想ネットワーク サブネットとネットワーク インターフェイスに出入りできるネットワーク トラフィックの種類をフィルター処理できます。 詳細については、NSG の概要に関するページを参照してください。

    アプリケーション セキュリティ グループ (ASG) を使用すると、フラットなネットワークで NSG を使用して、レイヤー 4 のセキュリティを簡単に制御できます。 以下を迅速に実行できます。

    • ASG に仮想マシンを参加させる、または ASG から仮想マシンを削除する。
    • これらの仮想マシンに対するルールを動的に適用または削除する。

    詳細については、ASG の概要に関するページを参照してください。

    現時点では、ASG が Azure Database for PostgreSQL フレキシブル サーバー インスタンスのルールの一部である NSG はサポートされていません。 現在、NSG では IP ベースのソースまたは宛先のフィルター処理を使用することをお勧めします。

    Azure Database for PostgreSQL サーバーの高可用性やその他の機能では、Azure Database for PostgreSQL フレキシブル サーバー インスタンスがデプロイされている Azure 仮想ネットワーク サブネット内の 宛先ポート 5432 と、ログ アーカイブ用の Azure Storage にトラフィックを送受信する機能が必要です。 デプロイされているサブネット内の Azure Database for PostgreSQL フレキシブル サーバー インスタンスとの間のトラフィック フローを拒否する NSG を作成する場合は、サービス タグ Storage を宛先として使用して、サブネット内の宛先ポート 5432 と Storage へのトラフィックを許可してください。 高可用性を実現するには、Microsoft.Storage サービス エンドポイントを追加することをお勧めします。これは、先書きログ (WAL) ファイルのアップロードに使用される Azure ストレージ アカウントへの正しいトラフィック ルーティングが保証されるためです。

    などのラベルに Azure リージョンを追加することで、この例外ルールをさらにus-east.storageできます。 また、 Microsoft Entra 認証 を使用して Azure Database for PostgreSQL フレキシブル サーバー インスタンスへのサインインを認証する場合は、Microsoft Entra サービス タグを使用して Microsoft Entra ID への送信トラフィックを許可します。

    Azure リージョン間で読み取りレプリカを設定する場合、Azure Database for PostgreSQL フレキシブル サーバー インスタンスでは、プライマリおよびレプリカの両方のサーバーが宛先ポート 5432にトラフィックを送受信する必要があります。また、プライマリ サーバーとレプリカ サーバーがそれぞれのプライマリ リージョンとレプリカ リージョンのAzure Storageへトラフィックを送受信できる機能が必要です。 Storage に必要な宛先 TCP ポートは 443 です。

  • プライベート DNS ゾーンの統合: Azure プライベート DNS ゾーンの統合により、現在の仮想ネットワーク、またはリージョン内でピアリングされた (プライベート DNS ゾーンがリンクされた) 仮想ネットワーク内でプライベート DNS を解決できます。

プライベート DNS ゾーンを使用する

Azure プライベート DNS は、仮想ネットワークのための信頼性が高く安全な DNS サービスとなります。 カスタムの DNS ソリューションを構成しなくても、Azure プライベート DNS によって、仮想ネットワークにおけるドメイン名の管理と解決が行われます。

Azure 仮想ネットワークでプライベート ネットワーク アクセスを使用する場合は、DNS 解決を行うためにプライベート DNS ゾーン情報の提供が必須です。 プライベート ネットワーク アクセスを使用して新しい Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成するには、プライベート アクセスを使用して Azure Database for PostgreSQL フレキシブル サーバー インスタンスを構成するときに、プライベート DNS ゾーンを使用する必要があります。

重要

別のサブスクリプションでプライベート DNS ゾーンを使用する場合、そのサブスクリプションには Microsoft.DBforPostgreSQL リソース プロバイダーも登録されている 必要があります 。そうしないと、Azure Database for PostgreSQL フレキシブル サーバー インスタンスのデプロイは完了しません。

API、Azure Resource Manager テンプレート (ARM テンプレート)、Bicep、または Terraform でプライベート ネットワーク アクセスを使用して新しい Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成する場合は、プライベート DNS ゾーンを作成します。 その後、プライベート アクセスを使用して Azure Database for PostgreSQL フレキシブル サーバー インスタンスを構成するときに使用します。 詳細については、「Azure の REST API 仕様」を参照してください。

Azure portal または Azure CLI を使用して Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成する場合は、以前に同じサブスクリプションまたは別のサブスクリプションで作成したプライベート DNS ゾーン名を指定するか、既定のプライベート DNS ゾーンがサブスクリプションに自動的に作成されます。

Azure API、ARM テンプレート、Bicep、または Terraform を使用する場合は、末尾が .postgres.database.azure.com のプライベート DNS ゾーンを作成します。 プライベート アクセスを使用して Azure Database for PostgreSQL フレキシブル サーバー インスタンスを構成するときに、これらのゾーンを使用します。 たとえば、[name1].[name2].postgres.database.azure.com または [name].postgres.database.azure.com の形式を使います。 フォーム [name].postgres.database.azure.comを使用する場合、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの 1 つに使用する名前を指定 することはできません 。または、プロビジョニング中にエラー メッセージが表示されます。 詳細については、「プライベート DNS ゾーンの概要」を参照してください。

Azure portal、API、Azure CLI、または ARM テンプレートを使用する場合は、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの作成時に指定したプライベート DNS ゾーンから、同じサブスクリプションまたは異なるサブスクリプションに存在する別のプライベート DNS ゾーンに変更することもできます。

重要

Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成したときに指定したプライベート DNS ゾーンから別のプライベート DNS ゾーンに変更する機能は、現在、高可用性機能が有効になっているサーバーでは無効になっています。

Azure でプライベート DNS ゾーンを作成した後、仮想ネットワークをそれにリンクさせる必要があります。 リンクされた仮想ネットワークでホストされているリソースは、プライベート DNS ゾーンにアクセスできるようになります。

重要

プライベート ネットワークを使用する Azure Database for PostgreSQL フレキシブル サーバー インスタンスのサーバー作成時に仮想ネットワーク リンクが存在することを検証しなくなりました。 ポータルを通じてサーバーを作成する場合は、Azure portal の[プライベート DNS ゾーンを仮想ネットワークにリンクする] チェック ボックスを使用して、サーバー作成時にリンクを作成するかどうかを選択できます。

ゾーン データはグローバルに利用できるため、DNS プライベート ゾーンは、リージョンの障害に対して回復性があります。 プライベート ゾーン内のリソース レコードは、リージョン間で自動的にレプリケートされます。 Azure プライベート DNS は、可用性ゾーンの基本的なゾーン冗長サービスです。 詳細については、「可用性ゾーンをサポートする Azure サービス」をご覧ください。

カスタム DNS サーバーとの統合

カスタム DNS サーバーを使用している場合は、DNS フォワーダーを使用して、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの FQDN を解決する必要があります。 フォワーダーの IP アドレスは、168.63.129.16 である必要があります。

カスタム DNS サーバーは、仮想ネットワーク内にあるか、仮想ネットワークの DNS サーバー設定を使用して到達可能である必要があります。 詳細については、「独自の DNS サーバーを使用する名前解決」を参照してください。

プライベート DNS ゾーンと仮想ネットワーク ピアリング

プライベート DNS ゾーンの設定と、仮想ネットワーク ピアリングはそれぞれ独立しています。 同じリージョンまたは別のリージョンの別の仮想ネットワークにプロビジョニングされているクライアントから Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する場合は、プライベート DNS ゾーンを仮想ネットワークに リンク する必要があります。 詳細については、「仮想ネットワークのリンク」を参照してください。

Note

リンクできるのは、名前が postgres.database.azure.com で終わるプライベート DNS ゾーンのみです。 DNS ゾーン名を Azure Database for PostgreSQL フレキシブル サーバー インスタンスと同じにすることはできません。 同じにすると、名前解決は失敗します。

サーバー名を DNS レコードにマップするには、Azure PowerShell または Bash を使用して、nslookup で コマンドを実行します。 次の例では、サーバー名を <server_name> パラメーターに置き換えます。

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

ハブ アンド スポーク プライベートネットワーク設計を使用する

ハブ アンド スポークは、一般的な通信またはセキュリティ要件を効率的に管理するためのよく使われるネットワーク モデルです。

ハブは、外部接続を管理するための中心的な場所として機能する仮想ネットワークです。 また、複数のワークロードで使用されるサービスをホストします。 ハブでスポーク間のすべての通信が調整されます。 セキュリティのような IT のルールまたはプロセスによって、トラフィックを検査、ルーティング、集中管理できます。 スポークは、ワークロードをホストし、仮想ネットワーク ピアリングを介して中央のハブに接続する仮想ネットワークです。 共有サービスは、スポークと共有するための独自のサブネットでホストされます。 境界サブネットが次に、セキュリティ アプライアンスとして機能します。

スポークは、個々のワークロードを分離するために使用される Azure の仮想ネットワークでもあります。 オンプレミスの本社と Azure の間のトラフィック フローは、ハブ仮想ネットワークに接続されている Azure ExpressRoute またはサイト間 VPN を介して接続されます。 スポークからハブへの仮想ネットワークがピアリングされ、オンプレミス リソースへの通信が可能になります。 ハブと各スポークは、別々のサブスクリプションまたはリソース グループに実装できます。

スポーク仮想ネットワークの相互接続には、次の 3 つの主なパターンがあります。

  • スポークは相互に直接接続されます: 仮想ネットワーク ピアリングまたは VPN トンネルがスポーク仮想ネットワーク間に作成され、ハブ仮想ネットワークを通過することなく直接接続されます。
  • スポークはネットワーク アプライアンスを介して通信します: 各スポーク仮想ネットワークには、Virtual WAN またはハブ仮想ネットワークへのピアリングがあります。 アプライアンスは、スポークからスポークへのトラフィックをルーティングします。 アプライアンスは、(Virtual WAN と同様に) マイクロソフトが管理するか、ユーザーが管理することができます。
  • 仮想ネットワーク ゲートウェイはハブ ネットワークに接続され、ユーザー定義のルートを使用します: これにより、スポーク間の通信が有効になります。

Express Hub 経由のハイブリッド接続を使用した基本的なハブ アンド スポーク アーキテクチャを示すダイアグラム。

Azure Virtual Network Manager を使用すると、ハブ アンド スポーク仮想ネットワーク トポロジを新規に作成して (または既存のものをオンボードして)、接続とセキュリティ制御を一元管理することができます。

異なるリージョンのプライベート ネットワーク クライアントとの通信

お客様は、しばしばクライアントの、異なる Azure リージョンに接続する必要が生じます。 具体的には、この質問は通常、異なるリージョンにある 2 つの仮想ネットワーク (そのうちの 1 つは Azure Database for PostgreSQL フレキシブル サーバー インスタンスを持ち、もう 1 つはアプリケーション クライアントを持つ) を接続する方法を示しています。

そのような接続を実現するには、次のように複数の方法があります。

  • グローバル仮想ネットワーク ピアリング これは、異なるリージョンのネットワークを接続する最も簡単かつ最も一般的な手法です。 グローバル仮想ネットワーク ピアリングでは、ピアリングされた 2 つの仮想ネットワーク間に、Azure バックボーン経由の直接接続が作成されます。 この手法で接続すると、最高のネットワーク スループットと最短の待機時間が実現します。 仮想ネットワークがピアリングされると、Azure によってルーティングも自動的に処理されます。 これらの仮想ネットワークは、VPN ゲートウェイで確立されている、ピアリングされた仮想ネットワーク内のすべてのリソースと通信できます。
  • ネットワーク間接続 基本的に、仮想ネットワークの間の接続 (ネットワーク間接続) は、2 つの異なる Azure の場所の間の VPN です。 ネットワーク間接続は、VPN ゲートウェイで確立されます。 つまり、トラフィックには、グローバル仮想ネットワーク ピアリングと比較して、2 つ多くのトラフィック ホップが発生します。 また、グローバル仮想ネットワーク ピアリングと比較して、待機時間は長くなり、帯域幅は低くなります。
  • ハブ アンド スポーク アーキテクチャのネットワーク アプライアンスを介した通信。 スポーク仮想ネットワークを相互に直接接続する代わりに、ネットワーク アプライアンスを使用してスポーク間でトラフィックを転送できます。 ネットワーク アプライアンスでは、ディープ パケット インスペクションやトラフィックのセグメント化または監視などのネットワーク サービスがさらに提供されますが、適切なサイズに設定しないと、待ち時間とパフォーマンスのボトルネックが発生する可能性があります。

プライベート ネットワークを使用した Azure リージョンと仮想ネットワーク間のレプリケーション

データベース レプリケーションは、中央またはプライマリ サーバーからレプリカと呼ばれる複数のサーバーにデータをコピーするプロセスです。 プライマリ サーバーは読み取りおよび書き込み操作を受け入れますが、レプリカは読み取り専用トランザクションを処理します。 プライマリ サーバーとレプリカを合わせてデータベース クラスターが形成されます。 データベース レプリケーションの目的は、特にトラフィックの多いミッション クリティカルなアプリケーションにおいて、データの冗長性、一貫性、高可用性、アクセシビリティを確保することです。

Azure Database for PostgreSQL には、 組み込みの読み取りレプリカ機能 を使用した物理 (つまりストリーミング) と 論理レプリケーションの 2 つのレプリケーション方法が用意されています。 どちらも異なるユース ケースに最適であり、ユーザーは最終目標に応じてどちらか一方を選択できます。

各リージョンに個別の仮想ネットワークがある Azure リージョン間のレプリケーションでは、仮想ネットワーク ピアリングを介して、またはネットワーク アプライアンス経由のハブ アンド スポーク アーキテクチャで提供できる、リージョンの仮想ネットワーク境界を越えた接続が必要です。

既定では、DNS 名前解決のスコープは仮想ネットワークです。 ある仮想ネットワーク (VNET1) 内のクライアントは、別の仮想ネットワーク (VNET2) 内の Azure Database for PostgreSQL フレキシブル サーバー インスタンス FQDN を解決できません。

この問題を解決するには、VNET1 のクライアントが Azure Database for PostgreSQL フレキシブル サーバー インスタンスのプライベート DNS ゾーンにアクセスできることを確認する必要があります。 Azure Database for PostgreSQL フレキシブル サーバー インスタンスのプライベート DNS ゾーンに 仮想ネットワーク リンク を追加します。

サポートされない仮想ネットワークのシナリオ

仮想ネットワーク統合で作成される仮想ネットワークで作業する場合の制限事項を次に示します。

  • Azure Database for PostgreSQL フレキシブル サーバー インスタンスを仮想ネットワークとサブネットにデプロイした後、別の仮想ネットワークまたはサブネットに移動することはできません。 仮想ネットワークを別のリソース グループまたはサブスクリプションに移動することはできません。
  • サブネットにリソースを配置した後、そのサブネットのサイズ (アドレス空間) を増やすことはできません。
  • 仮想ネットワーク インジェクションされたリソースは、既定では Private Link と対話できません。 プライベート ネットワークに Private Link を使用する場合は、Private Link を使用した Azure Database for PostgreSQL ネットワークに関するページを参照してください。

重要

Azure Resource Manager は、セキュリティ制御としてリソースをロックする機能をサポートしています。 リソース ロックはリソースに適用され、すべてのユーザーおよびロールが対象になります。 リソース ロックには、CanNotDelete と ReadOnly の 2 種類があります｡ これらのロック タイプは、プライベート DNS ゾーンまたは個別のレコード セットのいずれかに適用できます。

プライベート DNS ゾーンまたは個々のレコード セットに対していずれかの種類のロックを適用すると、Azure Database for PostgreSQL フレキシブル サーバー インスタンスが DNS レコードを更新できなくなる可能性があります。 また、プライマリからセカンダリへの高可用性フェールオーバーなど、DNS に対する重要な操作中に問題が発生する可能性もあります。 これらの理由から、Azure Database for PostgreSQL フレキシブル サーバー インスタンスで高可用性機能を使用する場合は、DNS プライベート ゾーンまたはレコード ロックを使用 していないことを 確認してください。

ホスト名

選択したネットワーク オプションに関係なく、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続するときは、ホスト名として常に FQDN を使用することをお勧めします。 サーバーの IP アドレスが静的のままであることは保証されません。 FQDN を使うと、接続文字列を変更する必要がなくなります。

ホスト名として FQDN を使用する例は、hostname = servername.postgres.database.azure.com です。 可能であれば、hostname = 10.0.0.4 (プライベート アドレス) または hostname = 40.2.45.67 (パブリック アドレス) の使用は避けてください。

関連するコンテンツ

  • Last updated on