change the name of the frontend IP of an Azure application gateway

Question

change the name of the frontend IP of an Azure application gateway

EL YACOUBI Mounir 0

Hello,

I have an Azure Application Gateway deployed using Terraform. I would like to know if it is possible to change the name of the frontend IP address. If it is feasible, could this operation potentially lead to the destruction and recreation of the Application Gateway?

Thank you in advance for your guidance.

Best regards,

0 comments

2 answers

Your answer

Answer 1

EL YACOUBI Mounir 0

Hello Fabien,

thx a lot for your quick answer. I tried your proposal, but I've always the same error:

Error: deleting Public I P Address (Subscription: "54e84914-948d-4e77-8c3f-85b62fxxxxxx" Resource Group Name: "z-ago-netdev-dv14-en1-01" Public I P Addresses Name: "zagomyAGPublicIPAddressdv01en1pip01"): performing Delete: unexpected status 400 (400 Bad Request) with error: PublicIPAddressCannotBeDeleted: Public IP address /subscriptions/54e84914-948d-4e77-8c3f-85b62f7a1327/resourceGroups/z-ago-netdev-dv14-en1-01/providers/Microsoft.Network/publicIPAddresses/zagomyAGPublicIPAddressdv01en1pip01 can not be deleted since it is still allocated to resource /subscriptions/54e84914-948d-4e77-8c3f-85b62fxxxxxx/resourceGroups/z-ago-netdev-dv14-en1-01/providers/Microsoft.Network/applicationGateways/zagoalb_default_valuedv01en1agw01/frontendIPConfigurations/zagomyAGPublicIPAddressdv01en1pip01. In order to delete the public IP, disassociate/detach the Public IP address from the resource. To learn how to do this, see aka.ms/deletepublicip.

my question; if a disassociate the public IP, th eAzure application gateway will be destroyed and recreated again?

thx,

Fabian Zankl 185 Reputation points

2026-09-07T17:56:41.26+00:00
Hi @EL YACOUBI Mounir ,

The error is not caused by the frontend IP configuration rename. Terraform is trying to delete the Public IP resource zagomyAGPublicIPAddressdv01en1pip01, so your plan replaces or removes the azurerm_public_ip itself. Renaming the frontend_ip_configuration block never issues a delete against a Public IP. Since the Public IP and the frontend IP configuration share the same name, my guess is that the frontend name is derived from the Public IP name and you changed the Public IP name; the plan should show -/+ (or -) on azurerm_public_ip.

To your question: no, the gateway is not destroyed, neither by this failed apply nor by a disassociation. Only name, location, resource_group_name and zones of azurerm_application_gateway force a replacement, and the gateway is unchanged after the failed apply. Detaching the Public IP manually is not a way forward either: Application Gateway v2 requires a public frontend unless the subscription is enabled for private-only deployment.

name on azurerm_public_ip is ForceNew in the provider source, so a new name means destroy and recreate, and the recreated Public IP gets a new address. Terraform destroys before it creates by default, and the gateway update that would drop the old Public IP cannot run before the new one exists, hence PublicIPAddressCannotBeDeleted.

If you only want the frontend IP configuration renamed, leave azurerm_public_ip untouched, give frontend_ip_configuration.name a literal value, change every frontend_ip_configuration_name in your listeners to match, and check that the plan shows no change on the Public IP and ~ update in-place on the gateway. The rename itself is the case from the earlier answer, the old frontend IP configuration replaced by the new one in a single request: the gateway keeps its IP address, and if Azure rejects the request, the gateway is left unchanged. Azure does not document this combination, so run it on your dv gateway first and check the result.

If you paste the plan lines for azurerm_public_ip and azurerm_application_gateway, I can confirm which case you are in.

References

terraform-provider-azurerm: public_ip_resource.go

Terraform lifecycle meta-argument reference

Private Application Gateway deployment

Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against the azurerm provider source, the Terraform documentation and Microsoft Learn.

Answer 2

Hi @EL YACOUBI Mounir ,

You have an Application Gateway managed by Terraform (azurerm_application_gateway) and want to rename its frontend IP configuration without the gateway being destroyed and recreated. I am reading "Application Gateway" as the classic Application Gateway resource with a frontend_ip_configuration block; if you mean Application Gateway for Containers, whose frontend is a separate resource without an IP address, the answer is different, so please say so and I will add it.

Short answer: renaming the frontend IP configuration does not force a replacement in Terraform. The name inside the frontend_ip_configuration block is not a ForceNew attribute (the provider flag that makes a change require replacement), so terraform plan shows an in-place update of the gateway. On the Azure side, however, a rename is not a rename: Azure Resource Manager identifies the frontend IP configuration by its name, so the new name is a new sub-resource and the old one is removed in the same request. Both halves of that operation are supported individually, but I found no documentation of the combined case, so verify it once on a non-production gateway before applying it in production.

What Terraform does with the rename

In the azurerm provider source, only the gateway name, location, resource_group_name and zones are ForceNew. The frontend_ip_configuration block and its name are plain Required attributes. On update, the provider reads the existing gateway, replaces the changed collections in that model, and sends one CreateOrUpdate (PUT) for the whole gateway. Nothing in this path deletes the gateway resource.

Two consequences follow from how the provider builds that request:

Listeners reference the frontend IP configuration by name. frontend_ip_configuration_name in every http_listener block (and in listener blocks for TCP/TLS listeners) is required and is turned into the sub-resource ID .../frontendIPConfigurations/NAME. If you rename the frontend IP configuration but leave the listeners pointing at the old name, the provider still sends those listeners unchanged, so the PUT carries references to a sub-resource that is no longer in the payload. I have not provoked this error deliberately, but there is nothing for Azure to resolve that reference against, so expect the apply to fail rather than succeed. Change both in the same apply.
Private Link, if you use it, keys on the same name. The Private Endpoint's group ID (target sub-resource) must match the frontend IP configuration name, as described in Configure Azure Application Gateway Private Link. Renaming the frontend IP configuration therefore also changes the value in subresource_names of any azurerm_private_endpoint pointing at the gateway, and that attribute is ForceNew in the provider source, so the Private Endpoint is replaced. If the gateway has no Private Link configuration, this point does not apply to you.

What Azure allows on an existing gateway

Azure lets you add and remove frontend IP configurations on a running gateway: the Add-AzApplicationGatewayFrontendIPConfig and Remove-AzApplicationGatewayFrontendIPConfig cmdlets and az network application-gateway frontend-ip create/delete exist for exactly that. What Azure does not allow is changing the IP address bound to an existing frontend IP configuration in place: the API answers with ApplicationGatewayFrontendIpPublicIpAddressCannotBeChanged for a public IP (see terraform-provider-azurerm issue #3883) and ApplicationGatewayFrontendIPPrivateIPCannotBeChanged for a private IP (issue #7063). Those errors concern the address of a configuration that keeps its name; they are why a same-name change to public_ip_address_id or private_ip_address fails in Terraform.

A rename in a single PUT is the remove-and-add case with the same public IP (or the same static private IP) moving to the new sub-resource. I have not found documentation that covers this combination explicitly, and I have not reproduced it, so treat the following as the expected outcome rather than a guarantee: the plan shows ~ update in-place, the apply succeeds, and the gateway keeps its IP addresses. The DNS name label, if you use one, is a property of the Public IP resource (Application Gateway FAQ), and the rename does not touch that resource, so the FQDN and any CNAME pointing at it stay valid. If Azure rejects the request up front, as it does for the address changes above, terraform apply fails with a 400 and the gateway is left as it was; a rejected update does not destroy anything.

Suggested procedure

Change frontend_ip_configuration.name and every frontend_ip_configuration_name that references it together, so that both land in the same plan and apply.
Run terraform plan and confirm the resource shows ~ update in-place and no -/+ replacement.
Apply on a non-production gateway first if you have one; the frontend IP address of the gateway should be the same before and after.
If the gateway has a Private Link configuration, plan the Private Endpoint change as a separate step, since its group ID has to follow the new name.

If the name is purely cosmetic and the gateway is in production, keeping the existing name is the zero-risk option.

References

Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against the azurerm provider source, the Terraform Registry documentation, Microsoft Learn, and the linked GitHub issues.