Instead, engineers would be expected to use the az command or ClickOps their way to success outside of the normal Terraform lifecycle, which creates tons of friction in getting new services stood up.

Luckily, a sweet new resource was just released in the azurerm Terraform provider to right this wrong!

Enter azurerm_resource_provider_feature_registration

With the 4.67 release of the azurerm provider, we get a new resource: azurerm_resource_provider_feature_registration 🎉

Now you may be thinking "but I can already automate provider registrations since azurerm 4.0! What is the meaning of this, Cody"? Look closely, as this resource is specifically for feature registration. As it turns out there are certain parts of Azure which cannot be enabled via provider registrations alone: they require feature registrations which are enabled under a provider's registration.

Let's take a look at the example here for our handy dandy AKS resource which should help clarify:

resource "azurerm_resource_provider_feature_registration" "encryption_at_host" {
  name          = "EncryptionAtHost"
  provider_name = "Microsoft.Compute"
}

As we can see here we have the name of the feature in addition to the provider_name it belongs to. So naturally we can interpret that a feature lives under a specific provider.

Pretty straightforward & simple, right? Two thumbs up!

Now if you've never gone through this pain, you may be wondering what this even serves as a replacement for?

Just imagine your Terraform applies failing each time, having to conjure up this command and... waiting/polling for the feature registration to complete before returning to Terraform to apply a new plan and continue where you left off...

If the text doesn't do it justice, a picture is worth 1000 words!

For the adventurous, this was the previous command you needed to remember to run (hopefully) outside of Terraform:

az feature register --namespace Microsoft.Compute --name EncryptionAtHost

This created a jarring experience which in unscalable and command-wise easy to forget (100% guilty).

I'm ecstatic to report through this post we can now do our own feature registrations all in Terraform! Let's put at least this single esoteric command behind us that kept failing our runs, and keep our future deployments running smoothly 🫡.

To see a full example of provisioning an AKS cluster with disk encryption, check out the repo here: https://github.com/codycodescloud/terraform-aks-host-encryption

Takeaways, Thoughts, Miscellany

While it's awesome to see this newly Terraform-able resource which enables encrypted AKS clusters to provision without any clever outside hacks, I'm actually curious to know:

1. More about the why for features and this feature in particular continuing to exist in 2026, and...

2. What this means for feature registrations with regards to the typical Terraform CRUD lifecycle?

For 1. Most times, I've seen features come up as "in preview" which are then GA'd and are no longer available to register. I'm curious to know if there are plans to GA this feature for AKS?

And this brings up a good point for 2., which is for the future IaC maintainer to ask: "what happens when Terraform is unable to register that provider on new AKS clusters because it may no longer exist?" From my perspective it's something that should be handled at the module level and using count or for_each with a depends_on that forces the dependency (but only if it exists!) This means we can easily configure whether or not we need the registration and use defaults to control its behavior, thus minimizing deployment errors going forward.

Well, I'd love to hear your thoughts about this and what else might be bouncing around in the noggin' of yours with regards to Terraform, Azure, and this slick new resource! Feel free to post in the comments or send me a message directly on channels in my profile. I can't wait to hear about your thoughts here!

Until next time, IaC cowboy 🤠