> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Azure Providers azurerm vs azapi
> Comparison of Terraform Azure providers azurerm and azapi, outlining differences in abstraction, validation, use cases, and guidance to combine them for stable and preview features
In this lesson we’ll focus on how Terraform interacts with Microsoft Azure and the two primary providers you’ll encounter: AzureRM and AzAPI. Terraform communicates with Azure through providers—these act as an abstraction layer between Terraform and the Azure platform. For Azure, you can use either or both providers in a single project. Each provider differs in abstraction level, validation, and flexibility, so choosing the right one for each use case is important.
* AzureRM: a high-level, opinionated provider that enforces schemas, performs input validation, and provides strongly typed resources. It’s jointly maintained by HashiCorp and Microsoft and is the most commonly used provider for Azure infrastructure.
* AzAPI: a lower-level provider exposing direct access to Azure Resource Manager (ARM) APIs. It’s maintained by Microsoft and supports any ARM resource type and API version with minimal abstraction—ideal for preview or newly released features not yet available in AzureRM.
A key point: these providers are complementary and can be used together in the same Terraform project.
## Quick provider summaries
| Provider | Abstraction level | Best for | Example usage |
| --------- | -------------------------------: | ------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| `azurerm` | High-level, strongly typed | Stable, common Azure services (VMs, networks, storage, managed services) | Use when you want schema validation and predictable lifecycle behavior |
| `azapi` | Low-level, direct ARM API access | New/preview features, niche or advanced configurations | Use when AzureRM doesn’t yet support a resource or API version |
You can combine AzureRM and AzAPI in the same Terraform project: use AzureRM for stable, validated resource types and AzAPI for features that are not yet supported by AzureRM.
## AzureRM (high-level) — what you get
* Official provider for public Azure cloud.
* Maintains resource lifecycle via ARM APIs.
* Strongly typed resources with schema validation and built-in lifecycle handling.
* Best choice for stable, well-supported Azure services.
* Limitation: may lag behind Azure for preview or newly released features.
## AzAPI (low-level) — characteristics & benefits
* No predefined resource schemas: you specify the ARM resource type and API version directly.
* Support for any ARM resource or API version: use new or preview APIs immediately.
* Enables preview and newly released features without waiting for AzureRM provider schema updates.
AzAPI provides flexibility but no compile-time schema validation. Mistakes in API version or property names will only surface at `terraform apply`. Use AzAPI for targeted gaps, not as a default for everything.
## AzAPI use cases and trade-offs
* When a feature is not yet supported in AzureRM (new or preview capabilities).
* Advanced or edge-case configurations and platform experimentation.
* Trade-offs: you must choose API versions manually, deal with runtime errors, and perform more detailed ARM knowledge checks during development.
## Practical examples
### 1) AzureRM-only provider (typical setup)
provider configuration:
```hcl theme={null}
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = ">= 4.55.0, != 4.59.0"
}
}
}
provider "azurerm" {
features {}
subscription_id = "1b228746-75fd-46ed-a6b-6a9066d6d3a"
}
```
Initialize the working directory:
```bash theme={null}
terraform init --upgrade
```
Example CLI confirmation:
```json theme={null}
{
"message": "Terraform has been successfully initialized!"
}
```
You can confirm your Azure subscription with Azure CLI:
```bash theme={null}
az account show
```
Example output (representative):
```json theme={null}
{
"environmentName": "AzureCloud",
"id": "1b228746-75fd-46ed-a6b-6a9066d6d3a",
"name": "PenTest Lab 2",
"isDefault": true,
"tenantId": "1e0fa212-37dc-45f5-bb0f-b60687cac64b",
"user": {
"name": "rithinskaria@kodekloud.lab.onmicrosoft.com",
"type": "user"
}
}
```
### 2) Adding AzAPI alongside AzureRM
Declare both providers under `required_providers` and configure each provider block. Terraform loads all `.tf` files in the working directory.
```hcl theme={null}
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = ">= 4.55.0, != 4.59.0"
}
azapi = {
source = "Azure/azapi"
version = "2.8.0"
}
}
}
provider "azurerm" {
features {}
subscription_id = "1b228746-75fd-46ed-a6b-6a9066d6d3a"
}
provider "azapi" {
subscription_id = "1b228746-75fd-46ed-a6b-6a9066d6d3a"
}
```
Notes on provider file naming:
* Terraform loads all `.tf` files in a directory. Many teams use `providers.tf` (or `provider.tf`) for clarity, especially when multiple providers are present.
## Creating the same resource: AzureRM vs AzAPI
AzureRM resource group (strongly typed and validated):
```hcl theme={null}
resource "azurerm_resource_group" "rg" {
name = "kodekloud-tf-rg"
location = "eastus"
tags = {
environment = "testing"
}
}
```
AzAPI equivalent (direct ARM type + API version):
```hcl theme={null}
resource "azapi_resource" "rg" {
name = "kodekloud-tf-rg-azapi"
type = "Microsoft.Resources/resourceGroups@2021-04-01"
location = "eastus"
tags = {
environment = "testing"
}
}
```
Notes on the AzAPI example:
* `type` uses the format `/@`.
* For complex resources you can pass a full ARM JSON body (use `jsonencode()`), or set specific properties as required.
* Because AzAPI lacks a typed schema, verify the API version and property names against ARM documentation—errors will appear at apply time if mismatched.
## When to use which provider
* Use AzureRM when you want:
* Schema validation
* Predictable lifecycle behavior
* Coverage for the majority of common Azure resources
* Use AzAPI when you need:
* Immediate access to new or preview ARM features
* Niche property control or resource types not exposed by AzureRM
* Common approach: use AzureRM for most resources and AzAPI selectively to fill gaps.
## Real-world scenario
If Microsoft releases a new capability for Azure Database for PostgreSQL that’s not yet available in AzureRM, you can target the correct ARM resource type and API version with AzAPI to enable that capability immediately while keeping the rest of your infrastructure managed by AzureRM.
## Wrap-up
AzureRM and AzAPI are complementary:
* AzureRM = stability, validation, conventional provider behaviors.
* AzAPI = agility, immediate ARM access, and coverage for preview/new features.
Use AzureRM as your default provider and introduce AzAPI selectively to bridge feature gaps or enable early adoption of Azure capabilities. This hybrid approach helps keep Terraform configurations maintainable while staying current with Azure’s evolving platform.