As you deploy your PostgreSQL Flexible Server in Azure as a part of enterprise cloud environment it becomes important to understand how this service fits into Azure networking paradigm. Many people heard of different Azure VNET integration patterns, including Azure Private Link and VNET Injection, and are looking to understand how Azure Database for PostgreSQL – Flexible Server works with them.
In this blog we will delve into Flexible Server network architecture and discuss how it may fit into your organization cloud environment setup.
PaaS (Platform as Service) services, such as Azure Database for PostgreSQL – Flexible Server, democratized access to advanced it capabilities that, with more traditional computing paradigms, would be affordable only for very large organizations with enough resources (financial and technical) to acquire and manage the underlying infrastructure. However, the public nature of some PaaS services emerged as a challenge to their adoption in many security-sensitive scenarios. Microsoft azure supports three virtual network (VNET) integration patterns to make PaaS services only accessible from clients deployed within Azure VNETs and not accessible from the internet. Multiple patterns are required because of the architectural differences that exist among different public PaaS services.
Figure 1. VNET Injection network architecture
On Figure 2, below, the virtual machine has the private IP address 10.1.1.4 but can access the storage account over a service endpoint. On-premises traffic cannot use service endpoints and must go over the internet to access the storage account.
Figure 2. Architecture of Azure network service endpoints
Figure 3. Private Link Networking Architecture Diagram
As a service with dedicated resources and to fit architecture that strives for the highest level of network isolation and security, Azure Database for PostgreSQL – Flexible Server utilizes VNET Injection as its integration pattern with Azure networking.
VNET Injection was chosen as a network integration pattern as it offered highest network isolation by design, without having to configure firewalls or IP whitelists as other patterns listed above. This technology also worked well with well-known advanced database service on Azure that utilizes dedicated resources – Azure SQL Database Managed Instance, as well other popular Azure offerings such as App Service Environments and Redis Cache. Since adoption, we have heard very positive remarks from many large customers that value network security and isolation that this solution brings “out of the box” and work well with these customers enterprise cloud designs.
The limitation of this pattern for some customers was a need to create separate delegated subnet for hosting Azure Flexible Server. The smallest range you can specify for a subnet is /28, which provides fourteen IP addresses, of which five will be utilized by Azure internally, whereas a single Flexible Server with HA features utilizes 4 addresses. You can work around this issue and increased management overhead of delegated subnet by hosting multiple PostgreSQL servers in a single subnet and if necessary, peering other VNETs where clients connecting to Postgres reside.
Based on that architecture diagram in Figure 4 below here are some important points to remember about networking deployment basics with Flexible Server:
Figure 4. Flexible Server Azure Virtual Network Setup
Hub and Spoke is increasingly popular network topology used by larger enterprise customers in Azure. In a Hub-Spoke network architecture, the Hub is a virtual network on Azure that serves as the point of connectivity to the on-premises network. This connectivity can be done through VPN Site to site or through ExpressRoute. The Spokes are virtual networks running the peering with the Hub and can be used to isolate workloads. We often see a custom DNS server is deployed in the Hub VNET which is linked to the on-premises DNS server. Since spoke virtual networks are connected through the Hub virtual network clients can directly connect with your Flexible Server instance. For DNS to work you must add a conditional forwarder for DNS domain postgres.database.azure.com domain. This conditional forwarder must point to the Azure DNS IP address: 168.63.129
This network architecture is typically used in scenarios where these characteristics are required in terms of connectivity:
A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. A NSG can be applied to a network interface and to a Subnet. Applying an NSG to a Subnet simplifies the rule management if all VMs in the subnet requires the same security rules. For each rule, you can specify source and destination, port, and protocol. Microsoft recommends applying an NSG to either interface or subnet, but not to both.
Defining and maintaining NSGs and UDRs for subnets that host injected services can be a complex task. To reduce complexity for NSGs, service tags have been introduced in the platform. A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules. Full list of service tags available can be found here.
High availability Features of Azure Database for PostgreSQL - Flexible Server require ability to send\receive traffic to destination ports 5432, 6432 within Azure virtual network subnet where Azure Database for PostgreSQL - Flexible Server is deployed, as well as to Azure storage for log archival. If you create Network Security Groups (NSG) to deny traffic flow to or from your Azure Database for PostgreSQL - Flexible Server within the subnet where its deployed, please make sure to allow traffic to destination ports 5432 and 6432 within the subnet, and to Azure storage by using service tag Azure Storage as a destination.
Application Security Groups (ASG) are used within a NSG to apply a network security rule to a specific workload or group of VMs – defined by ASG worked as being the “network object” and explicit IP addresses are added to this object. This provides the capability to group VMs into associated groups or workloads, simplifying the NSG rule definition process.
As you can see all three constructs (NSGs, ASGs and service tags) can be used together to minimize number security rules you need and avoid IP address hardcoding.
We hope that you find this blog article helpful and are always interested how you plan to use Flexible Server offering within your enterprise cloud environment. Additional information on topics discussed above can be found in following documents:
We’re always eager to get your feedback, so please reach out via email to Ask Azure DB for PostgreSQL.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.