PostgreSQL Connection Throttling Disabled on Azure: Risk and Fix

Azure Database for PostgreSQL ships with a server parameter called connection_throttling. When it is enabled, the server temporarily slows down repeated connection attempts from a host that keeps failing authentication. When it is disabled, a client can hammer the login endpoint as fast as the network allows. This Lensix check, postgresql_noconnectionthrottling, looks at the server configuration and reports any PostgreSQL server where that parameter is off.

It is a small setting with an outsized security impact, and it is one of the easiest hardening wins you can apply to a managed PostgreSQL instance.

---

What this check detects

The check inspects the server-level configuration of each Azure Database for PostgreSQL instance and verifies whether the connection_throttling parameter is set to on. If the value is off, the check fails for that server.

Connection throttling is a defensive feature specific to the Azure managed offering. It works at the gateway and server layer, not inside your application. When a single source generates a burst of failed connection attempts, the server starts injecting delays before responding to subsequent attempts from that source. The effect is to make automated password-guessing slow and impractical without affecting legitimate users who connect successfully.

---

Why it matters

A PostgreSQL server that accepts unlimited connection attempts is a soft target. Here is how that plays out in practice.

Brute-force and credential stuffing

If your server endpoint is reachable from a wide network range, or worse, from the public internet via firewall rules set to 0.0.0.0, attackers can run dictionary attacks against known or guessed usernames. The default admin account name is often predictable, and weak or reused passwords are common. Without throttling, an attacker can try thousands of passwords per minute. With throttling, those same attempts get progressively delayed, turning a feasible attack into one that would take an impractical amount of time.

Resource exhaustion

Each connection attempt consumes server resources, even failed ones. A flood of attempts can saturate the connection handler, degrade performance for legitimate traffic, and in extreme cases cause the server to reject valid clients. Throttling caps the damage a single misbehaving or malicious source can do.

Compliance and audit findings

Several benchmarks, including the CIS Microsoft Azure Foundations Benchmark, call out connection throttling as a required control for PostgreSQL servers. Leaving it off generates findings in audits and can block compliance attestations. Fixing it is cheap, so there is rarely a good reason to carry the finding.

---

How to fix it

Enabling throttling is a configuration change to the server parameter. It does not require downtime and does not interrupt existing connections.

Azure Portal

1. Open the Azure portal and navigate to your Azure Database for PostgreSQL server.
2. In the left menu, select Server parameters.
3. Search for connection_throttling.
4. Set the value to ON.
5. Click Save.

Azure CLI

For a Single Server instance:

az postgres server configuration set \
  --resource-group myResourceGroup \
  --server-name mypgserver \
  --name connection_throttling \
  --value on

For a Flexible Server instance:

az postgres flexible-server parameter set \
  --resource-group myResourceGroup \
  --server-name mypgserver \
  --name connection_throttling \
  --value on

Verify the change took effect:

az postgres server configuration show \
  --resource-group myResourceGroup \
  --server-name mypgserver \
  --name connection_throttling \
  --query "{name:name, value:value}" -o table

Terraform

Manage the parameter as code so it stays correct on every apply. For a Single Server:

resource "azurerm_postgresql_configuration" "throttling" {
  name                = "connection_throttling"
  resource_group_name = azurerm_resource_group.example.name
  server_name         = azurerm_postgresql_server.example.name
  value               = "on"
}

For a Flexible Server:

resource "azurerm_postgresql_flexible_server_configuration" "throttling" {
  name      = "connection_throttling"
  server_id = azurerm_postgresql_flexible_server.example.id
  value     = "on"
}

Bicep

resource throttling 'Microsoft.DBforPostgreSQL/servers/configurations@2017-12-01' = {
  name: '${pgServerName}/connection_throttling'
  properties: {
    value: 'on'
    source: 'user-override'
  }
}

---

How to prevent it from happening again

Fixing one server is fine, but the goal is to make sure throttling is never disabled in the first place. Bake the control into your delivery pipeline and your policy engine.

Azure Policy

Use Azure Policy to audit or enforce the setting across subscriptions. There is a built-in policy that checks for connection throttling on PostgreSQL servers. Assign it in audit mode first to find existing offenders, then switch to deny once your estate is clean so new noncompliant servers are blocked at creation.

az policy assignment create \
  --name "pg-connection-throttling" \
  --display-name "PostgreSQL connection throttling should be enabled" \
  --policy "" \
  --scope "/subscriptions/"

CI/CD gates

If you provision PostgreSQL through Terraform, add a static analysis step to your pipeline with a tool like Checkov or tfsec. Block merges when a server is defined without the throttling configuration. A simple gate stops the misconfiguration before it ever reaches Azure.

# Example: fail the build on policy violations
checkov -d ./infra --framework terraform

Continuous scanning

Policy and CI gates catch new resources, but drift happens. Someone changes a parameter by hand during an incident and forgets to revert it. Run Lensix on a schedule so the postgresql_noconnectionthrottling check flags any server that drifts back to the insecure state, regardless of how it got there.

---

Best practices

Connection throttling is one layer. Combine it with the rest of the PostgreSQL hardening checklist to actually reduce risk.

• Restrict network access. Use private endpoints or virtual network rules instead of public access. Never set a firewall rule that allows the full 0.0.0.0 to 255.255.255.255 range.
• Enforce strong authentication. Use Microsoft Entra ID authentication where possible so you can apply conditional access and central identity controls rather than relying on a static database password.
• Require SSL. Keep ssl_enforcement on so credentials and data are never sent in cleartext.
• Enable logging. Turn on log_connections and log_disconnections so failed attempts are recorded. Throttling slows an attacker down, logging tells you they tried.
• Rotate credentials and avoid shared admin accounts. Give applications scoped roles instead of the server admin login.
• Monitor for failed connection spikes. Alert on unusual volumes of failed logins so throttling buys you time to respond rather than silently absorbing an attack.

Enabling connection throttling takes a single parameter change and costs nothing. It will not stop a determined attacker on its own, but it raises the cost of brute-force attacks enough to make most automated attempts pointless. Combined with tight network rules and strong identity controls, it is a solid part of a layered defense for your managed PostgreSQL servers.