Was there any platform maintenance or frontend IP rotation affecting Azure Database for PostgreSQL Flexible Server in region Central India recently?”

Question

We are using Azure Database for PostgreSQL – Flexible Server with Public access (allowed IP addresses) enabled.

Recently, we observed that the public IP resolved from the server FQDN changed:

Previous resolution: x.x.x.x

Current resolution: x.x.x.x

The connection endpoint remains the same:

There were no configuration changes made from our side (no networking changes, no server updates, no scaling operations).

We would like to understand:

Does Azure rotate frontend/public IPs for PostgreSQL Flexible Server as part of platform maintenance?

Is there any way to verify if a backend maintenance or infrastructure update occurred in the region?

Is this behavior expected for servers configured with Public access?

Is there any mechanism to obtain a static public IP for Flexible Server, or is DNS abstraction the only supported model?

We are evaluating the impact on firewall whitelisting and want to confirm the expected design behavior.

Answer 1

Hello **Swaroop Gowda D
**This is expected behavior for Flexible Server’s public‐access model. Azure doesn’t give you a customer-assigned “permanent” public IP; instead, your server’s FQDN is a DNS CNAME that points at Microsoft-managed front-end IPs, and those IPs can change whenever we perform platform updates or a planned failover during maintenance. Here’s how it works and what you can do:

1. Front-end IP rotation during maintenance
   • Flexible Server applies OS and platform patches (and in HA setups, updates the standby first and then fails over). As part of that, the underlying compute node (and its public IP) may change, so your DNS A record updates automatically.
     • Because of this, you’ll see the FQDN resolve to a different x.x.x.x after maintenance or failover.
2. How to confirm a maintenance event
   • Azure Service Health: you should have received a “Maintenance scheduled” notification about your Flexible Server 5 days in advance.
     • Activity log & Resource Health: in the portal, check Resource Health for any “Platform initiated failover” or “Maintenance” events.
       • Built-in diagnostics: run the OrcasPostgresFailOverAppUpgradeInsightV2TroubleShooter diagnostic in the Flexible Server blade to see if an instance upgrade failover happened.
3. Is this expected?
   • Yes—public-access Flexible Servers rely on DNS for IP flexibility. You should always connect via the server-name.postgres.database.azure.com FQDN and respect its low DNS TTL (~30 seconds).
4. Getting a static IP

• Currently there is no way to pin a dedicated public IP to a Flexible Server. The supported pattern is DNS-based abstraction.
  • If static IP whitelisting is a hard requirement, consider: • Using Azure Firewall or NAT Gateway with service tags (e.g. “AzureDatabaseForPostgreSQL”) so you don’t have to track IP changes yourself • Moving to a Private Endpoint (Private Link), which gives you a fixed private IP on your VNet

1. Impact on firewall whitelisting and expected design behavior:
   Because a public IP address can change, any external system that restricts access to the database server by IP must be ready to update its firewall rules accordingly. A more reliable solution is to adopt private access through VNet integration or private endpoints, ensuring that connectivity is managed via private networking rather than a shifting public IP.****

https://learn.microsoft.com/en-us/azure/postgresql/configure-maintain/how-to-configure-scheduled-maintenance?tabs=portal-maintenance-settings

Hope this clarifies your queries. If not, please share your insights for more troubleshooting.

Answer 2

Azure Database for PostgreSQL – Flexible Server with public access uses a public endpoint whose underlying IP address is not guaranteed to be static. The behavior observed (change in IP while the FQDN remains the same) is expected and by design.

Addressing the specific points:

1. Does Azure rotate frontend/public IPs for PostgreSQL Flexible Server as part of platform maintenance?
   Yes. For Flexible Server with public access, the public IP assigned to the server can change during maintenance, updates, or other operational events. The documentation explicitly states that the public IP address is not static and can change, and recommends always using the FQDN rather than the IP.
2. Is there any way to verify if a backend maintenance or infrastructure update occurred in the region?
   The provided context does not expose a direct mechanism (API/portal view) to see per-server maintenance history for Flexible Server. It only notes that IP changes can occur during maintenance or operational events. For confirmation of a specific maintenance event, the supported path is to open an Azure support request.
3. Is this behavior expected for servers configured with Public access?
   Yes. For public access (allowed IP addresses):

• The server is reached via a public endpoint.
• The FQDN is the stable connection endpoint.
• The public IP backing that FQDN can change and is not guaranteed to remain static.
  The guidance is to always use the FQDN in connection strings and not rely on the IP address.

4. Is there any mechanism to obtain a static public IP for Flexible Server, or is DNS abstraction the only supported model?
   From the context, there is no supported mechanism to pin a static public IP on the Flexible Server public endpoint. The supported model is:

• Use the FQDN (servername.postgres.database.azure.com) as the hostname.
• For outbound firewall whitelisting on external services, either:
  • Regularly resolve the FQDN and update rules as needed, or
  • Allow the Azure datacenter IP ranges for the region, or
  • Use Azure Service Tags when the external service is also in Azure.

For more stable connectivity and to avoid reliance on public IPs, the documentation recommends using private access (virtual network integration) and/or private endpoints instead of public access.

5. Impact on firewall whitelisting and expected design behavior
   Given that the public IP can change:

• External systems that whitelist the database server by IP must be prepared to update their firewall rules when the IP changes.
• A more robust approach is to:
  • Use Azure regional IP ranges or Service Tags where possible, or
  • Move to private access with VNet integration/private endpoints so that access is controlled via private networking rather than a changing public IP.

This aligns with the documented, expected behavior for Azure Database for PostgreSQL Flexible Server with public access.

---

References:

• Networking overview for Azure Database for PostgreSQL with public access (allowed IP addresses)
• Firewall rules in Azure Database for PostgreSQL
• Network with private access (virtual network integration) for Azure Database for PostgreSQL
• Troubleshoot connection issues to Azure Database for PostgreSQL