The Terraform AzAPI Provider has become a powerful companion to the more traditional AzureRM provider, especially for users needing access to the day zero Azure features. With the release of AzAPI 2.0, Microsoft has introduced many enhancements that make Infrastructure-as-Code (IaC) on Azure more powerful, flexible, and user-friendly than its previous version.
In this post, I'll explain the features and my thoughts on using this provider in the future.
AzAPI 2.0: Features
Seamless Direct Azure API Access
AzAPI has always been about giving Terraform users direct access to Azure Resource Manager (ARM) templates and APIs. However, in v2, that capability is more robust and easier to work with. You now get faster access to new Azure resources and features as soon as they're available—no waiting on provider updates.
This is crucial for users working with preview services or trying to keep up with newly released Azure functionality.
Resource Versioning
One of the standout features in AzAPI 2.0 is the ability to explicitly specify and manage resource API versions. In the previous version, resource versioning was more implicit and could sometimes lead to surprises if the defaults changed.
AzAPI 2.0 gives you more fine-grained control over how your infrastructure is defined and maintained.
resource "azapi_resource" "key_vault" {
type = "Microsoft.KeyVault/vaults@2023-07-01"
name = "example-keyvault"
parent_id = azurerm_resource_group.example.id
location = azurerm_resource_group.example.location
Retry block
AzAPI v2 introduces user-defined retriable errors, significantly improving complex deployment scenarios. You can now specify which errors should trigger a retry, making your automation workflows more resilient and reducing failed deployments caused by transient issues. This feature is called retry block and becomes a welcome addition to robust IaC in Azure.
resource "azapi_resource" "app_service" {
type = "Microsoft.Web/sites@2022-09-01"
name = "example-app-service"
parent_id = azurerm_resource_group.example.id
location = azurerm_resource_group.example.location
body = jsonencode({
properties = {
siteConfig = {
appSettings = [
{
name = "WEBSITE_NODE_DEFAULT_VERSION"
value = "~18"
}
]
}
httpsOnly = true
}
})
# Retry block for handling transient failures
retry {
error_message_regex = [
".*Internal Server Error.*",
".*Gateway Timeout.*",
".*Service Unavailable.*",
".*retriable error occurred.*"
]
interval_seconds = 10
max_interval_seconds = 180
multiplier = 1.5
randomization_factor = 0.5
}
}
Preflight Validations
In AzAPI v2, preflight validation checks allow you to catch issues before deployment begins, saving hours of debugging time.
To enable this, all you need to do is add the following to the provider block:
provider "azapi" {
enable_preflight = true
}
Resource Discovery
A new data source, azapi_resource_list, makes locating existing Azure resources across subscriptions, virtual networks, and resource groups easier. It improves visibility and facilitates working with multiple resources outside of the Terraform state you are working with.
My thoughts on the AzAPI 2.0
I believe this will be the way to go with Azure IaC. These new additions make the support of Azure resources very powerful. Before the 2.0 release, the team moved away from JSON and embraced HCL, allowing more people familiar with HCL from using AzureRM to be more confident to adopt. But now, the question is, should we continue using AzureRM and AzAPI, or since the release of AzAPI 2.0, should we primarily use AzAPI? Let me know in the comments.
External Resources
Check out these official resources to dive deeper:
