1

I am trying to enable ZoneRedundant High Availability on our Azure PostgreSQL Flexible server.

The Azure documentation mentions the following important step:

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 also to Azure storage by using service tag Azure Storage as a destination.

I'm finding it hard to get my head around this from the way it is written and can't find many details about it elsewhere.

From what I understand, the first requirement is to add an inbound NSG rule as follows:

Source IP: [CIDR of the database subnet]
Source Port Range: *
Destination IP addresses: [CIDR of the database subnet]
Destination Port Ranges: 5432,6432
Action: Allow
Priority: [Any number before the default inbound DENY rules]

Have I read this correctly? We are effectively allowing traffic between the instance and the replication instance within the subnet, so the source IP and the destination IP should both be the database subnet CIDR.

I know that NSGs are stateful. So am I right in saying I don't need any Outbound rule for this case?

The second requirement to allow traffic 'to Azure storage by using service tag Azure storage as a destination' is confusing me. From the way this is written I don't know if it should be an inbound or an outbound rule. My first guess was outbound as logs would be moving FROM the database to Azure storage. Is that correct?

Kartik Bhiwapurkar
  • 4,550
  • 2
  • 4
  • 9
x3nr0s
  • 1,946
  • 4
  • 26
  • 46
  • Hi @x3nr0s, did the suggested solution work for you? Do let me know if it solved your problem else share more details so I can troubleshoot or else do accept it for helping other community members. – Kartik Bhiwapurkar Aug 05 '22 at 04:13

1 Answers1

1

• As per the statement from the Microsoft documentation, it is imminent that all the resources dealing with or related to the Azure PostgreSQL Database – Flexible Server should be deployed within the same virtual network. The statement accordingly states that for Azure PostgreSQL Database – Flexible server, the incoming as well as outgoing traffic over the ports 5432 and 6432 should be allowed within the same subnet.

It is because the PostgreSQL Database Server listens to the localhost IP, i.e., ‘127.0.0.1’ through these ports only, i.e., 5432 and 6432. Also, since these ports are by default not open and thus, are secure in these scenarios, the related Microsoft documentation text states accordingly.

Thus, based on that, the NSG rule that you have created is clearly sufficient and correct to allow the traffic on these ports for the PostgreSQL database server. And yes, the traffic rule needs to be created to the Azure storage from the Azure PostgreSQL database subnet and from the trusted network ranges/subnets to the Azure storage with the destination as Azure Storage as a service tag if only logs are to be transferred to that storage account. If it is provisioned for some other purpose other than this, then you will have to create rules accordingly.

Ensure to create an outbound NSG rule for the Azure storage account which will suffice the requirement from the Azure PostgreSQL DB Server subnet.

Kartik Bhiwapurkar
  • 4,550
  • 2
  • 4
  • 9
  • Hello, thanks for your reply. I wanted to verify what you mean by your answer. In my question, I state that in relation to the Database NSG, I only have an inbound rule for 5432 and 6432. I do not have an outbound rule. Is this sufficient? – x3nr0s Aug 05 '22 at 12:31
  • Yes, it is sufficient but would suggets you to please configure this rule at a higher priority than other rules so that they are effectively applied. – Kartik Bhiwapurkar Aug 05 '22 at 17:31