Private setup for Azure Flexible Server

When Cloudera creates an Azure Database for PostgreSQL - Flexible Server instance, you must choose one of the following networking options: Private access (VNet integration or Private Link) or Public access (allowed IP addresses). Public access is used by default.

For more general information, see Networking overview for Azure Database for PostgreSQL - Flexible Server with private access (VNET Integration) and Networking overview for Azure Database for PostgreSQL - Flexible Server with public access (allowed IP addresses).

Delegated subnet

You have two options to deploy Flexible Server instances in private service mode (without public endpoints): using Private Link or without Private Link. Flexible Server with Private Link is the recommended option. If Private Link is not used, Flexible Server instances need to be deployed in a “delegated subnet” within the VNet. The Flexible Server with delegated subnet option, although still available on the UI, is deprecated and it is recommended to use Flexible Server with Private Link instead.

Delegated subnets are no longer a requirement as you can use Azure Private Link instead. However, when private endpoints are not used, it is a prerequisite to delegate a subnet to Microsoft.DBforPostgreSQL/flexibleServers as mentioned in Azure documentation. This delegation means that only Azure Database for PostgreSQL Flexible Servers can use that subnet. No other Azure resource types can be in the delegated subnet.

You need to create such a delegated subnet and provide it to Cloudera during environment registration. This delegated subnet will be used by Azure Database for PostgreSQL instances. The delegated subnet provided during environment registration will be used by default for all Azure Database for PostgreSQL instances used in Cloudera.

Creating a delegated subnet

For a step-by-step official guide on how to perform the delegation, see Delegate a subnet to an Azure service. For considerations on the delegated subnet’s sizing, see Virtual network concepts.

Here is a screenshot from Azure Portal showing the desired setting:

The Microsoft.Storage service endpoint is set automatically during deployment by Azure.

After the subnet has successfully been delegated, don’t forget to record the full subnet ID or the name of the subnet for later use as an input (referred to as <delegated-subnet-id>). For example: /subscriptions/3ddda1c7-d1f5-4e7b-ac81-abcdefgh/resourceGroups/rg/providers/Microsoft.Network/virtualNetworks/vnet/subnets/subnet

For background information, see Using Azure Database for PostgreSQL Flexible Server.

Private DNS options

Cloudera supports using VNet integration based private setup with an existing Private DNS zone that can be either pre-created and provided by you, or created by Cloudera.

When using a private setup for Azure Postgres, an Azure private DNS zone is used for the DNS service resolving the FQDN to the private IP. Cloudera offers two options. The DNS zone can be:

Created and managed entirely by Cloudera (You select “Create new private DNS zone” during environment registration), or
Created by you before registering an environment (You pre-create the DNS zone and select it during environment registration). You need to provide access for discovery, validation, and adding and removing DNS A records.

Private setup (with either of the two DNS options) can only be used with a single customer-provided resource group. They cannot be used with Cloudera-created multiple resource groups.

Depending on whether you prefer to bring your own DNS or have Cloudera create and manage it, refer to the following documentation: