Does Azure API Management change outbound IP after reactivation? Impact on IP whitelisting and Cloudflare 530 errors

Hi @Ihor Kondratenko

Thank you for reaching out to Microsoft Q&A.

Thank you for reaching out to Microsoft Q&A.

After an Azure API Management (APIM) service is stopped due to subscription inactivation (unpaid) and later reactivated, your existing Cloudflare + IP-whitelisting design can break because the origin endpoint details you depended on may no longer be valid. In many setups, Cloudflare is configured with an A record pointing to a specific APIM public IP, and when that IP changes, Cloudflare can no longer resolve/reach the configured origin and surfaces Cloudflare 530 / 1016 (Origin DNS error). Additionally, if your downstream/backend service only allows requests from a specific APIM outbound IP, an IP change will cause the backend to reject APIM-originated traffic until the allowlist is updated. Microsoft documents that APIM has retrievable public IPs (and that IP changes are a consideration), and Cloudflare documents that 1016 is triggered when the origin cannot be resolved/reached due to DNS/origin configuration issues.

Refer below points to resolve this issue or this is the workaround

1) Fix Cloudflare origin configuration (avoid pinning APIM by A-record IP)

• Recommended: Configure Cloudflare DNS to use a CNAME to the APIM gateway hostname (example: <apim-name>.azure-api.net) instead of an A record to a single IP. This prevents outages when the underlying APIM public IP changes because the hostname remains the stable target.
• Also ensure Cloudflare is not pointing to an unresolvable/incorrect target, which is a primary cause of 1016/530.

2) Update backend IP allowlisting using APIM’s published “publicIPAddresses”

• For classic APIM tiers (Developer/Basic/Standard/Premium), retrieve the APIM public IP addresses from the Azure portal (APIM → Overview) or via ARM and allowlist the full set shown for the instance. Microsoft documents how to retrieve these addresses and that they are exposed via properties.publicIPAddresses.

ARM example:

GET https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<service-name>?api-version=<api-version>

Look for:

"properties": {
  "publicIPAddresses": ["<ip1>", "<ip2>"]
}

3) If you require truly stable outbound IPs, use a “customer-controlled egress” design (tier-dependent)

• If your requirement is “backend must only see a static IP I control,” then you should use an architecture where outbound traffic is forced through a controlled egress (for example, NAT/Firewall/proxy pattern). The right option depends on whether you are on classic tiers or v2 tiers and which networking capability is supported for your tier. Microsoft’s APIM networking options documentation explains the tier-based networking models (injection/integration/private endpoint, etc.).
• For Standard v2 scenarios, community guidance commonly highlights that a NAT gateway may not automatically give “fixed outbound IP from APIM” the way classic dedicated tiers do, and you may need to move outbound calling to a component that supports deterministic NAT egress or use a proxy-based approach.

4) Best practices for APIM + Cloudflare + IP allowlisting

• Prefer hostname-based origin mapping (CNAME) over IP pinning to reduce outages during infrastructure changes.
• If IP allowlisting is mandatory, automate drift detection: periodically read APIM publicIPAddresses and reconcile with your backend allowlist to avoid surprises after lifecycle events.
• Use the APIM networking model that matches your security needs (public gateway vs private connectivity) as per Microsoft guidance on networking options.

5) Quick incident checklist (to restore service fast)

• Update Cloudflare DNS: switch from A → old IP to CNAME → APIM gateway hostname (or update the origin target to the current APIM endpoint).
• Update backend allowlists add the current APIM publicIPAddresses to your backend firewall/allowlist.