In the ever-expanding universe of infrastructure as code, Terraform has become a starship of choice for cloud engineers. And when navigating Microsoft Azure, the journey often begins with the familiar — the azurerm provider. But what lies beyond that home planet? What other Terraform providers orbit Azure, enabling rich, interconnected, and sometimes unexpected use cases?

Watch my appearance on vBrownBag where I discuss this topic with Chris Williams.

The Home Planet: AzureRM

For most Terraform users working with Azure, the starting point is the azurerm provider. It represents the Azure Resource Manager control plane and forms the backbone of infrastructure provisioning.

One of the notable differences between AWS and Azure here is the scoping model. In AWS, resources are scoped to regions within an account. In Azure, the scope is defined by subscriptions, and within them, resource groups act as logical containers. These allow practitioners to organize related resources and manage them by lifecycle — often region-specific.

While azurerm is powerful and widely used, it doesn’t support every feature or service out of the gate. That’s where the exploration truly begins.

Entra ID (formerly Azure AD)

The AzureAD (or Entra ID) provider is often overlooked, but it’s a vital companion. It enables provisioning of identities, service principals, federated credentials, and more — all crucial for modern authentication and authorization setups.

Since Entra ID powers authentication for azurerm itself, integrating these providers is frictionless. You can declare all your security infrastructure — users, apps, permissions — right alongside your resource deployments. This also means you can define fine-grained role assignments with HCL instead of clicking around in the portal.

AZAPI: Terraform at Warp Speed

Previously, unsupported Azure features required resorting to the azurerm_template_deployment, which allowed embedding raw ARM templates in your HCL — a workaround as elegant as an airlock breach.

Enter the azapi provider: a flexible, day-0 compatible Terraform provider that can target any Azure resource type using just one resource block and a payload schema. It’s a powerful polyfill for new or obscure services not yet implemented in azurerm, though it comes with tradeoffs: less intelligent diffs, limited lifecycle behaviors, and fewer guardrails.

Still, if you want to terraform to the edge of the Azure galaxy, azapi is your ticket.

Terraforming the Hybrid Frontier

Azure’s deep investment in hybrid cloud also brings unique providers for managing on-premise assets:

  • AD provider: Manage traditional Active Directory objects on-prem via Terraform.
  • Azure Stack: Provision private cloud workloads in an Azure-consistent environment hosted within your own datacenter.

These tools are essential for enterprises bridging legacy infrastructure and cloud-native deployments.

Automating the Automation: GitHub & Azure DevOps

Modern development requires infrastructure and automation pipelines. I’ve been talking a lot about my “AT-AT” modules (yes, Star Wars fans — that’s Automate The Automation with Terraform) to define repositories, branches, and CI/CD pipelines via Terraform.

Using providers like:

  • github — rich, flexible, and even usable from within Codespaces
  • azuredevops — tailored for Microsoft’s DevOps suite

…you can bootstrap not just the cloud infrastructure, but the entire DevOps framework around it. These modules embody infrastructure and automation as code.

Blending Providers for Real-World Workloads

Terraform’s real power shines when multiple providers converge. Consider:

  • Kubernetes: Provision clusters with azurerm, then deploy workloads using the kubernetes and helm providers — all in one workflow.
  • Grafana: Use Azure to spin up a managed Grafana service, then configure dashboards via the grafana provider.
  • Datadog: Create service principals with azuread, then link Azure to your Datadog tenant using their provider. These mashups simplify complex scenarios where control planes span vendors, cloud platforms, and managed services.

Database-as-a-Service in a Multi-Cloud Universe

Third-party DBaaS providers like MongoDB Atlas or DataStax Astra support Terraform, often with cloud-specific placement. You can deploy a Mongo cluster directly into Azure’s infrastructure, ensuring low-latency private networking via VNet peering.

Other use cases include:

  • ADX (Azure Data Explorer): A community Terraform provider lets you manage Kusto clusters, schemas, and functions. It’s ideal for telemetry-heavy workloads — assuming your DBAs don’t mind learning HCL.

Terraforming Minecraft (Yes, Really)

For fun — and as a relatable enterprise metaphor — I’ve also showcased Terraforming Minecraft. Using packerto build VM images and Terraform to spin up Bedrock servers on Azure, it mimicked the classic IT automation journey: take a dusty runbook, codify it, and deploy it repeatably. Whether for your kids or your users, the automation skills are the same.

Verified Modules: Stars in the Terraform Sky

Microsoft’s Azure Verified Modules (AVM) initiative is producing vetted, SLA-backed modules built by Microsoft engineers. These modules encode best practices from the Well-Architected Framework and are production-ready out of the box.

Experimental tooling, like module telemetry (modtm) or new providers from engineers like Matt White and Jared Holgate, continues to expand the Microsoft Terraform ecosystem.

Conclusion

Terraforming Azure is more than just writing resource “azurerm_*” blocks. The broader Terraform ecosystem — from azapi to azuread, from hybrid providers to third-party mashups — opens up a galaxy of possibilities for Azure practitioners.

There’s a lot of Terraform that happens at Microsoft and Azure… and AzureRM is not the end of your Terraforming journey.

Wherever your Terraform journey takes you — from DevOps pipelines to Minecraft servers — you’re not alone. And with the ever-growing constellation of providers, your infrastructure universe is only getting bigger.