英語で読む

次の方法で共有

Azure Database for PostgreSQL - フレキシブル サーバー用にプライベート アクセス (仮想ネットワーク統合) を使用するネットワーク

  • [アーティクル]

適用対象: 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 を含むルールを追加します。
    • 宛先 IP 範囲が Azure Database for PostgreSQL フレキシブル サーバーのサブネット範囲と同じで、ネクスト ホップが Virtual Network であるルールを追加します。

    重要

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

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

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

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

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

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

    Azure Database for PostgreSQL - フレキシブル サーバーの高可用性とその他の機能を使用する場合、Azure Database for PostgreSQL - フレキシブル サーバーがデプロイされている Azure 仮想ネットワーク サブネット内の宛先ポート 5432 と、ログ アーカイブ用の Azure Storage に対して、トラフィックを送受信できる必要があります。 デプロイ先のサブネット内で Azure Database for PostgreSQL フレキシブル サーバーとの間のトラフィック フローを拒否する NSG を作成する場合は、サービス タグ Storage を宛先として使用し、Storage へのトラフィックとサブネット内の宛先ポート 5432 へのトラフィックを許可します。

    us-east.storage などのラベルに Azure リージョンを追加することで、この例外ルールをさらにフィルター処理できます。 また、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 Database for PostgreSQL フレキシブル サーバーの作成に Azure portal または Azure CLI を使用する場合は、同じ、または異なるサブスクリプションで以前に作成したプライベート 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 フレキシブル サーバーのいずれかに使用している名前にすることはできません。使用している名前にすると、プロビジョニング時にエラー メッセージが表示されます。 詳細については、「プライベート DNS ゾーンの概要」を参照してください。

Azure Database for PostgreSQL - フレキシブル サーバーの作成時に指定したプライベート DNS ゾーンは、Azure Portal、API、Azure CLI、または ARM テンプレートを使用して、同じまたは異なるサブスクリプションに存在する別のプライベート 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 ゾーンと仮想ネットワークをリンクさせる必要があります。 詳細については、「仮想ネットワークのリンク」を参照してください。

注意

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

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

Bash 
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 を使用する 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 (パブリック アドレス) の使用は避けてください。

関連するコンテンツ