Omówienie sieci dla usługi Azure Database for PostgreSQL — serwer elastyczny z dostępem prywatnym (integracja z siecią wirtualną)

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

W tym artykule opisano pojęcia dotyczące łączności i sieci dla serwera elastycznego usługi Azure Database for PostgreSQL.

Podczas tworzenia wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL należy wybrać jedną z następujących opcji sieciowych: dostęp prywatny (integracja z siecią wirtualną) lub dostęp publiczny (dozwolone adresy IP) i prywatny punkt końcowy. W tym dokumencie opisano opcję sieci prywatnej (integracja z siecią wirtualną).

Dostęp prywatny (integracja z siecią wirtualną)

Możesz wdrożyć wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL w sieci wirtualnej platformy Azure przy użyciu iniekcji sieci wirtualnej. Sieci wirtualne platformy Azure zapewniają prywatną i bezpieczną komunikację sieci. Zasoby w sieci wirtualnej mogą komunikować się za pośrednictwem prywatnych adresów IP, które zostały przypisane w tej sieci.

Wybierz tę opcję sieci, jeśli chcesz uzyskać następujące możliwości:

• Połączenie z zasobów platformy Azure w tej samej sieci wirtualnej do wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu prywatnych adresów IP.
• Użyj sieci VPN lub usługi Azure ExpressRoute, aby nawiązać połączenie z zasobów spoza platformy Azure z wystąpieniem serwera elastycznego usługi Azure Database for PostgreSQL.
• Upewnij się, że wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL nie ma publicznego punktu końcowego, który jest dostępny za pośrednictwem Internetu.

Na powyższym diagramie:

• Wystąpienia serwera elastycznego usługi Azure Databases for PostgreSQL są wstrzykiwane do podsieci 10.0.1.0/24 sieci wirtualnej VNet-1.
• Aplikacje wdrożone w różnych podsieciach w tej samej sieci wirtualnej mogą uzyskiwać bezpośredni dostęp do elastycznych wystąpień serwera usługi Azure Database for PostgreSQL.
• Aplikacje wdrożone w innej sieci wirtualnej (VNet-2) nie mają bezpośredniego dostępu do wystąpień serwera elastycznego usługi Azure Database for PostgreSQL. Przed uzyskaniem dostępu do serwera elastycznego należy wykonać komunikację równorzędną sieci wirtualnych dla prywatnej strefy DNS.

Pojęcia dotyczące sieci wirtualnej

Sieć wirtualna platformy Azure zawiera prywatną przestrzeń adresową IP skonfigurowaną do użycia. Sieć wirtualna musi znajdować się w tym samym regionie świadczenia usługi Azure Co wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL. Aby dowiedzieć się więcej o sieciach wirtualnych, zobacz Omówienie usługi Azure Virtual Network.

Poniżej przedstawiono kilka pojęć, które należy znać podczas korzystania z sieci wirtualnych, w których zasoby są zintegrowane z siecią wirtualną z elastycznymi wystąpieniami serwera usługi Azure Database for PostgreSQL:

• Podsieć delegowana. Sieć wirtualna zawiera podsieci (podsieci). Podsieci umożliwiają segmentowanie sieci wirtualnej na mniejsze przestrzenie adresowe. Zasoby platformy Azure są wdrażane w określonych podsieciach w sieci wirtualnej.

  Zintegrowane wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL w sieci wirtualnej musi znajdować się w delegowanej podsieci. Oznacza to, że tylko wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL mogą używać tej podsieci. W podsieci delegowanej nie mogą znajdować się żadne inne typy zasobów platformy Azure. Delegujesz podsieć, przypisując jej właściwość delegowania jako Microsoft.DBforPostgreSQL/flexibleServers. Najmniejszy zakres CIDR, który można określić dla podsieci to /28, który zapewnia 16 adresów IP, jednak pierwszy i ostatni adres w dowolnej sieci lub podsieci nie może być przypisany do żadnego pojedynczego hosta. Platforma Azure rezerwuje pięć adresów IP, które mają być używane wewnętrznie przez sieć platformy Azure, w tym dwa adresy IP, których nie można przypisać do hosta, wymienione powyżej. Pozostawia to 11 dostępnych adresów IP dla zakresu CIDR /28, podczas gdy pojedyncze wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL z funkcjami wysokiej dostępności korzysta z czterech adresów. W przypadku połączeń replikacji i usługi Microsoft Entra upewnij się, że tabele tras nie wpływają na ruch. Typowy wzorzec jest kierowany cały ruch wychodzący za pośrednictwem usługi Azure Firewall lub niestandardowego lokalnego urządzenia filtrowania sieci. Jeśli podsieć ma tabelę routingu skojarzona z regułą w celu kierowania całego ruchu do urządzenia wirtualnego:

  • Dodaj regułę z tagiem usługi docelowej "AzureActiveDirectory" i następnym przeskokiem "Internet"
  • Dodaj regułę z docelowym zakresem adresów IP tak samo jak zakres podsieci serwera elastycznego usługi Azure Database for PostgreSQL i następny przeskok "Sieć wirtualna"

  Ważne

  AzureFirewallSubnetNazwy , AzureFirewallManagementSubnet, AzureBastionSubneti GatewaySubnet są zarezerwowane na platformie Azure. Nie używaj żadnej z nich jako nazwy podsieci.

• Sieciowa grupa zabezpieczeń. Reguły zabezpieczeń w sieciowych grupach zabezpieczeń umożliwiają filtrowanie typu ruchu sieciowego, który może przepływać do podsieci i z podsieci sieci wirtualnej oraz interfejsów sieciowych. Aby uzyskać więcej informacji, zobacz Omówienie sieciowej grupy zabezpieczeń.

  Grupy zabezpieczeń aplikacji ułatwiają kontrolowanie zabezpieczeń warstwy 4 przy użyciu sieciowych grup zabezpieczeń dla sieci prostych. Umożliwia on szybkie wykonywanie następujących zadań:

  • Przyłącz maszyny wirtualne do usługi ASG lub usuń maszyny wirtualne z grupy asg.
  • Dynamiczne stosowanie reguł do tych maszyn wirtualnych lub usuwanie reguł z tych maszyn wirtualnych.

  Aby uzyskać więcej informacji, zobacz Omówienie usługi ASG.

  Obecnie nie obsługujemy sieciowych grup zabezpieczeń, w których grupa zabezpieczeń jest częścią reguły z elastycznym serwerem usługi Azure Database for PostgreSQL. Obecnie zalecamy używanie filtrowania źródłowego lub docelowego opartego na adresach IP w sieciowej grupie zabezpieczeń.

  Ważne

  Wysoka dostępność i inne funkcje serwera elastycznego usługi Azure Database for PostgreSQL wymagają możliwości wysyłania/odbierania ruchu do docelowego portu 5432 w podsieci sieci wirtualnej platformy Azure, w której wdrożono elastyczny serwer usługi Azure Database for PostgreSQL, a także do usługi Azure Storage na potrzeby archiwizacji dzienników. Jeśli utworzysz sieciowe grupy zabezpieczeń w celu odmowy przepływu ruchu do lub z wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL w podsieci, w której została wdrożona, upewnij się, że zezwalasz na ruch do portu docelowego 5432 w podsieci, a także do usługi Azure Storage przy użyciu tagowania usługi Azure Storage jako miejsca docelowego. Tę regułę wyjątku można dodatkowo filtrować , dodając region świadczenia usługi Azure do etykiety takiej jak us-east.storage. Ponadto jeśli zdecydujesz się używać uwierzytelniania entra firmy Microsoft do uwierzytelniania logowań w wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL, zezwól na ruch wychodzący do identyfikatora Entra firmy Microsoft przy użyciu tagu usługi Microsoft Entra. Podczas konfigurowania replik do odczytu w różnych regionach platformy Azure serwer elastyczny usługi Azure Database for PostgreSQL wymaga możliwości wysyłania/odbierania ruchu do portu docelowego 5432 dla zarówno podstawowego, jak i repliki, a także do magazynu platformy Azure w regionach podstawowych i replik zarówno z serwerów podstawowych, jak i repliki.

• integracja strefy Prywatna strefa DNS. Integracja prywatnej strefy DNS platformy Azure umożliwia rozpoznawanie prywatnego systemu DNS w bieżącej sieci wirtualnej lub dowolnej równorzędnej sieci wirtualnej w regionie, w której jest połączona prywatna strefa DNS.

Używanie prywatnej strefy DNS

Usługa Azure Prywatna strefa DNS zapewnia niezawodną i bezpieczną usługę DNS dla sieci wirtualnej. Usługa Azure Prywatna strefa DNS zarządza i rozpoznaje nazwy domen w sieci wirtualnej bez konieczności konfigurowania niestandardowego rozwiązania DNS.

W przypadku korzystania z dostępu do sieci prywatnej z siecią wirtualną platformy Azure zapewnienie informacji o prywatnej strefie DNS jest obowiązkowe w celu umożliwienia rozpoznawania nazw DNS. W przypadku nowego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu dostępu do sieci prywatnej należy używać prywatnych stref DNS podczas konfigurowania elastycznych wystąpień serwera usługi Azure Database for PostgreSQL z dostępem prywatnym. W przypadku nowego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu dostępu do sieci prywatnej za pomocą interfejsu API, usługi ARM lub narzędzia Terraform utwórz prywatne strefy DNS i użyj ich podczas konfigurowania elastycznych wystąpień serwera usługi Azure Database for PostgreSQL z dostępem prywatnym. Zobacz więcej informacji na temat specyfikacji interfejsu API REST dla platformy Microsoft Azure. Jeśli używasz witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure do tworzenia wystąpień serwera elastycznego usługi Azure Database for PostgreSQL, możesz podać nazwę prywatnej strefy DNS, która została wcześniej utworzona w tej samej lub innej subskrypcji albo domyślna prywatna strefa DNS zostanie automatycznie utworzona w ramach subskrypcji.

Jeśli używasz interfejsu API platformy Azure, szablonu usługi Azure Resource Manager (szablonu arm) lub narzędzia Terraform, utwórz prywatne strefy DNS, które kończą się na ..postgres.database.azure.com Użyj tych stref podczas konfigurowania elastycznych wystąpień serwera usługi Azure Database for PostgreSQL z dostępem prywatnym. Na przykład użyj formularza [name1].[name2].postgres.database.azure.com lub [name].postgres.database.azure.com. Jeśli zdecydujesz się użyć formularza [name].postgres.database.azure.com, nazwa nie może być nazwą używaną dla jednego z wystąpień serwera elastycznego usługi Azure Databases for PostgreSQL lub podczas aprowizacji zostanie wyświetlony komunikat o błędzie. Aby uzyskać więcej informacji, zobacz omówienie prywatnych stref DNS.

Korzystając z witryny Azure Portal, interfejsu API, interfejsu wiersza polecenia lub usługi ARM, można również zmienić prywatną strefę DNS z podanej podczas tworzenia wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL na inną prywatną strefę DNS, która istnieje w tej samej lub innej subskrypcji.

Ważne

Możliwość zmiany prywatnej strefy DNS z podanej podczas tworzenia wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL na inną prywatną strefę DNS jest obecnie wyłączona dla serwerów z włączoną funkcją wysokiej dostępności.

Po utworzeniu prywatnej strefy DNS na platformie Azure należy połączyć z nią sieć wirtualną. Po połączeniu zasoby hostowane w tej sieci wirtualnej mogą uzyskiwać dostęp do prywatnej strefy DNS.

Ważne

Nie weryfikujemy już obecności łącza sieci wirtualnej podczas tworzenia serwera dla serwera elastycznego usługi Azure Database for PostgreSQL z siecią prywatną. Podczas tworzenia serwera za pośrednictwem portalu udostępniamy klientowi możliwość utworzenia linku do tworzenia serwera za pomocą pola wyboru "Połącz Prywatna strefa DNS strefę sieci wirtualnej" w witrynie Azure Portal.

Strefy prywatne DNS są odporne na awarie regionalne, ponieważ dane strefy są globalnie dostępne. Rekordy zasobów w strefie prywatnej są automatycznie replikowane w różnych regionach. Azure Prywatna strefa DNS to podstawowa, strefowa usługa reduntant strefy dostępności. Aby uzyskać więcej informacji, zobacz Usługi platformy Azure z obsługą stref dostępności.

Integracja z niestandardowym serwerem DNS

Jeśli używasz niestandardowego serwera DNS, musisz użyć usługi przesyłania dalej DNS, aby rozpoznać nazwę FQDN serwera elastycznego usługi Azure Database for PostgreSQL. Adres IP usługi przesyłania dalej powinien mieć wartość 168.63.129.16.

Niestandardowy serwer DNS powinien znajdować się w sieci wirtualnej lub osiągalny za pośrednictwem ustawienia serwera DNS sieci wirtualnej. Aby dowiedzieć się więcej, zobacz Rozpoznawanie nazw używające własnego serwera DNS.

Prywatna strefa DNS strefy i komunikacji równorzędnej sieci wirtualnych

Prywatna strefa DNS ustawienia strefy i komunikacja równorzędna sieci wirtualnych są niezależne od siebie. Jeśli chcesz nawiązać połączenie z wystąpieniem serwera elastycznego usługi Azure Database for PostgreSQL z poziomu klienta, który jest aprowizowany w innej sieci wirtualnej z tego samego regionu lub innego regionu, musisz połączyć prywatną strefę DNS z siecią wirtualną. Aby uzyskać więcej informacji, zobacz Łączenie sieci wirtualnej.

Uwaga

Można połączyć tylko prywatne nazwy stref DNS kończące się ciągiem "postgres.database.azure.com". Nazwa strefy DNS nie może być taka sama jak w przypadku wystąpień serwera elastycznego usługi Azure Database for PostgreSQL. W przeciwnym razie rozpoznawanie nazw zakończy się niepowodzeniem.

Aby zamapować nazwę serwera na rekord DNS, możesz uruchomić polecenie nslookup w usłudze Azure Cloud Shell przy użyciu programu Azure PowerShell lub powłoki Bash, podstawiając nazwę serwera dla <parametru server_name> w poniższym przykładzie:

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

Korzystanie z projektu sieci prywatnej piasty i szprych

Piasta i szprycha to popularny model sieci umożliwiający efektywne zarządzanie typowymi wymaganiami dotyczącymi komunikacji lub zabezpieczeń.

Piasta to sieć wirtualna, która działa jako centralna lokalizacja do zarządzania łącznością zewnętrzną. Hostuje również usługi używane przez wiele obciążeń. Piasta koordynuje całą komunikację do i ze szprych. Reguły i procesy IT, takie jak zabezpieczenia, umożliwiają inspekcję i kierowanie ruchu oraz centralne zarządzanie ruchem. Szprychy to sieci wirtualne, które obsługują obciążenia i łączą się z centralną piastą za pomocą komunikacji równorzędnej sieci wirtualnej. Usługi udostępnione są hostowane we własnych podsieciach do udostępniania szprych. Podsieć obwodowa działa następnie jako urządzenie zabezpieczające.

Szprychy również są sieciami wirtualnymi na platformie Azure, które służą do izolowania poszczególnych obciążeń. Przepływ ruchu między siedzibą lokalną a platformą Azure jest połączony za pośrednictwem sieci VPN usługi ExpressRoute lub lokacji do lokacji połączonej z siecią wirtualną koncentratora. Sieci wirtualne ze szprych do piasty są połączone za pomocą komunikacji równorzędnej i umożliwiają komunikację z zasobami lokalnymi. Piastę i poszczególne szprychy można implementować w osobnych subskrypcjach lub grupach zasobów.

Istnieją trzy główne wzorce łączenia ze sobą sieci wirtualnych szprych:

• Szprychy bezpośrednio połączone ze sobą. Komunikacja równorzędna sieci wirtualnych lub tunele vpn są tworzone między sieciami wirtualnymi szprych w celu zapewnienia bezpośredniej łączności bez przechodzenia przez sieć wirtualną koncentratora.
• Szprychy komunikują się za pośrednictwem urządzenia sieciowego. Każda sieć wirtualna szprych ma komunikację równorzędną z usługą Virtual WAN lub z siecią wirtualną piasty. Urządzenie kieruje ruch z szprychy do szprychy. Urządzenie może być zarządzane przez firmę Microsoft (podobnie jak w przypadku usługi Virtual WAN) lub przez Ciebie.
• Brama sieci wirtualnej dołączona do sieci piasty i korzysta z tras zdefiniowanych przez użytkownika (UDR), aby umożliwić komunikację między szprychami.

Użyj usługi Azure Virtual Network Manager (AVNM), aby utworzyć nowe (i dołączyć istniejące) topologie sieci wirtualnej będącej szprychą na potrzeby centralnego zarządzania łącznością i mechanizmami kontroli zabezpieczeń.

Komunikacja z klientami sieciowymi prywatnie w różnych regionach

Często klienci muszą łączyć się z klientami w różnych regionach świadczenia usługi Azure. Mówiąc dokładniej, to pytanie zwykle sprowadza się do sposobu łączenia dwóch sieci wirtualnych (z których jedna ma usługę Azure Database for PostgreSQL — serwer elastyczny i inny klient aplikacji), które znajdują się w różnych regionach. Istnieje wiele sposobów osiągnięcia takiej łączności, z których niektóre to:

• Globalna komunikacja równorzędna sieci wirtualnych. Najbardziej typowa metodologia, ponieważ jest to najprostszy sposób łączenia sieci w różnych regionach. Globalna komunikacja równorzędna sieci wirtualnych tworzy połączenie za pośrednictwem sieci szkieletowej platformy Azure bezpośrednio między dwiema równorzędną sieciami wirtualnymi. Zapewnia to najlepszą przepływność sieci i najmniejsze opóźnienia łączności przy użyciu tej metody. Gdy sieci wirtualne są połączone równorzędnie, platforma Azure będzie również obsługiwać routing automatycznie, te sieci wirtualne mogą komunikować się ze wszystkimi zasobami w równorzędnej sieci wirtualnej ustanowionej w bramie sieci VPN.
• Połączenie między sieciami wirtualnymi. Połączenie między sieciami wirtualnymi to zasadniczo sieć VPN między dwiema różnymi lokalizacjami platformy Azure. Połączenie między sieciami wirtualnymi jest ustanawiane w bramie sieci VPN. Oznacza to, że ruch wiąże się z dwoma dodatkowymi przeskokami ruchu w porównaniu z globalną komunikacją równorzędną sieci wirtualnych. Istnieje również dodatkowe opóźnienie i niższa przepustowość w porównaniu z tą metodą.
• Komunikacja za pośrednictwem urządzenia sieciowego w architekturze piasty i szprych. Zamiast łączyć sieci wirtualne szprychy bezpośrednio ze sobą, można użyć urządzeń sieciowych do przesyłania dalej ruchu między szprychami. Urządzenia sieciowe zapewniają więcej usług sieciowych, takich jak głęboka inspekcja pakietów i segmentacja ruchu lub monitorowanie, ale mogą one wprowadzać opóźnienia i wąskie gardła wydajności, jeśli nie są prawidłowo dopasowane.

Replikacja między regionami i sieciami wirtualnymi platformy Azure przy użyciu sieci prywatnej

Replikacja bazy danych to proces kopiowania danych z serwera centralnego lub podstawowego do wielu serwerów nazywanych replikami. Serwer podstawowy akceptuje operacje odczytu i zapisu, podczas gdy repliki obsługują transakcje tylko do odczytu. Serwer podstawowy i repliki tworzą zbiorczo klaster bazy danych. Celem replikacji bazy danych jest zapewnienie nadmiarowości, spójności, wysokiej dostępności i dostępności danych, szczególnie w aplikacjach o dużym natężeniu ruchu i krytycznym znaczeniu.

Serwer elastyczny usługi Azure Database for PostgreSQL oferuje dwie metody replikacji: fizyczne (tj. przesyłanie strumieniowe) za pośrednictwem wbudowanej funkcji repliki do odczytu i replikacji logicznej. Oba są idealne dla różnych przypadków użycia, a użytkownik może wybrać jeden w zależności od celu końcowego.

Replikacja między regionami platformy Azure, z oddzielnymi sieciami wirtualnymi (VNETs) w każdym regionie, wymaga łączności między regionalnymi granicami sieci wirtualnych, które mogą być udostępniane za pośrednictwem komunikacji równorzędnej sieci wirtualnych lub architektur piasty i szprych za pośrednictwem urządzenia sieciowego.

Domyślnie rozpoznawanie nazw DNS jest ograniczone do sieci wirtualnej. Oznacza to, że każdy klient w jednej sieci wirtualnej (VNET1) nie może rozpoznać nazwy FQDN serwera elastycznego usługi Azure Database for PostgreSQL w innej sieci wirtualnej (VNET2).

Aby rozwiązać ten problem, należy upewnić się, że klienci w sieci VNET1 mogą uzyskać dostęp do serwera elastycznego usługi Azure Database for PostgreSQL Prywatna strefa DNS Zone. Można to osiągnąć, dodając link sieci wirtualnej do strefy Prywatna strefa DNS wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL.

Nieobsługiwane scenariusze sieci wirtualnej

Poniżej przedstawiono pewne ograniczenia dotyczące pracy z sieciami wirtualnymi utworzonymi za pośrednictwem integracji z siecią wirtualną:

• Po wdrożeniu wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL w sieci wirtualnej i podsieci nie można przenieść go do innej sieci wirtualnej ani podsieci. Nie można przenieść sieci wirtualnej do innej grupy zasobów lub subskrypcji.
• Nie można zwiększyć rozmiaru podsieci (przestrzeni adresowych), gdy w podsieci istnieją zasoby.
• Wstrzyknięte zasoby sieci wirtualnej nie mogą domyślnie korzystać z usługi Private Link. Jeśli chcesz użyć usługi Private Link do sieci prywatnej, zobacz Azure Database for PostgreSQL — sieć serwerów elastycznych za pomocą usługi Private Link

Ważne

Usługa Azure Resource Manager obsługuje możliwość blokowania zasobów jako kontroli zabezpieczeń. Blokady zasobów są stosowane do zasobu i są skuteczne we wszystkich użytkownikach i rolach. Istnieją dwa typy blokady zasobów: CanNotDelete i ReadOnly. Te typy blokad można zastosować do strefy Prywatna strefa DNS lub do pojedynczego zestawu rekordów. Zastosowanie blokady typu względem strefy Prywatna strefa DNS lub pojedynczego zestawu rekordów może zakłócać możliwość serwera elastycznego usługi Azure Database for PostgreSQL w celu zaktualizowania rekordów DNS i wystąpienia problemów podczas ważnych operacji w systemie DNS, takich jak przejście w tryb failover o wysokiej dostępności z podstawowej do pomocniczej. Z tych powodów upewnij się, że podczas korzystania z funkcji wysokiej dostępności z serwerem elastycznym usługi Azure Database for PostgreSQL nie używasz blokad prywatnych ani rekordów DNS.

Nazwa hosta

Niezależnie od wybranej opcji sieciowej zalecamy, aby zawsze używać nazwy FQDN jako nazwy hosta podczas nawiązywania połączenia z wystąpieniem serwera elastycznego usługi Azure Database for PostgreSQL. Adres IP serwera nie ma gwarancji, że pozostanie statyczny. Użycie nazwy FQDN pomaga uniknąć wprowadzania zmian w parametry połączenia.

Przykładem użycia nazwy FQDN jako nazwy hosta jest hostname = servername.postgres.database.azure.com. Jeśli to możliwe, unikaj używania hostname = 10.0.0.4 (adresu prywatnego) lub hostname = 40.2.45.67 (adresu publicznego).

Następne kroki

• Dowiedz się, jak utworzyć wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu opcji Dostęp prywatny (integracja z siecią wirtualną) w witrynie Azure Portal lub w interfejsie wiersza polecenia platformy Azure.