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.
Azure PaaS Services and Private Networking Integration Patterns
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.
- VNet injection is the VNet integration pattern for services whose architecture is based on dedicated resources that can be deployed (aka “injected”) into the instance owner’s VNet. VNet-injected services are usually deployed to a dedicated subnet that cannot contain any other services (such as Virtual Machines) deployed by the user. This is referred to in Azure documentation as subnet delegation, each VNet-injected service requires its own delegated subnet. VNet-injected services are exposed over IP addresses that belong to the VNet’s address space. More specifically, they can initiate connections to, and receive connections from, Virtual Machines in the same VNet (or in other VNets connected to it via VNet peering), as well as also Initiate connections to, and receive connections from, on-prem hosts over VPN tunnels or ExpressRoute;
Figure 1 below shows typical architecture of VNET injection
Figure 1. VNET Injection network architecture
- VNet service endpoints are a VNet integration pattern that can be applied to select Azure PaaS services with a shared architecture to make them accessible only from authorized VNet/subnets. Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Service Endpoints enables private IP addresses in the VNet to reach the endpoint of an Azure service without needing a public IP address on the VNet. Service Endpoints do have some limitations or downsides. It’s important to understand that traffic to a Service Endpoint is still leaving your virtual network, and the Azure PaaS resource is still being accessed on its public address. Service Endpoints by default cannot be used by traffic originating on-premises, through VPN or Express Route, only for traffic coming from your Azure Virtual Network. If you want to allow, your on-premises resources access you would need to whitelist their public IPs as well.
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
- Private Link is another integration pattern for services with a shared architecture. It addresses the limitations of VNet service endpoints by exposing select PaaS services with a shared architecture via private IP addresses belonging to a user VNet’s address space. Private Link unlike VNET Injection, does not prevent internet clients from accessing the service through its public endpoint. However, all services that support Private Link provide a firewall feature that can be configured to block all connections from the internet (or to only accept connections from known, trusted public IPs). This feature, combined with Private Link, enables users to make their PaaS service instance completely private, i.e. exclusively accessible from authorized VNets over private IP addresses belonging to the VNets’ address spaces. One important detail about Private Link to remember that Private Link currently support NSGs in preview only.
Figure 3. Private Link Networking Architecture Diagram
Virtual Network integration with Microsoft Azure Database for PostgreSQL – Flexible Server
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:
- A virtual network contains subnets (sub-networks). Subnets enable you to segment your virtual network into smaller address spaces. Azure resources are deployed into specific subnets within a virtual network. Your flexible server must be in a subnet that's delegated. That is, only Azure Database for PostgreSQL - Flexible Server instances can use that subnet. No other Azure resource types can be in the delegated subnet. You can however deploy multiple Flexible Server instances into the same delegated subnet if the subnet size supports it.
- Applications that are deployed on different subnets within the same vnet can access the Flexible servers directly. Applications that are deployed on a different VNET do not have direct access to flexible servers. You have to perform private DNS zone VNET peering before they can access the flexible server
- Plan your Flexible Server deployment carefully - after the flexible server is deployed to a virtual network and subnet, you cannot move it to another virtual network or subnet. You cannot move the virtual network into another resource group or subscription.
Figure 4. Flexible Server Azure Virtual Network Setup
Network Deployment with Hub and Spoke Model and Custom DNS Services
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:
- Workloads deployed in different environments (development, testing and production) which require access to the shared services such as DNS, IDS, Active Directory Domain Services (AD DS). Shared services will be placed in the Hub virtual network, while the various environments (development, testing and production) will be deployed in Spoke networks to maintain a high level of insolation.
- When certain workloads must not communicate with all other workloads, but only with shared services.
- Where customers desire high level of control over aspects related to network security and needing to make a segregation of the network traffic.
Using Network Security Groups and Application Security Groups to further restrict traffic within Virtual Network
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:
- Azure Database for PostgreSQL – Flexible Server Networking Documentation
- Azure Private Endpoint
- Troubleshoot NSG in Azure with Network Watcher
- Planning Azure Virtual Network
We’re always eager to get your feedback, so please reach out via email to Ask Azure DB for PostgreSQL.