I still remember the chaos of the post-CentOS 8 announcement. We were all scrambling, testing Rocky, testing Alma, testing Oracle (don’t get me started), and generally panicking about where our production workloads were going to live. For a while, spinning up these clones in the cloud felt a bit like the Wild West. You grabbed an image from the Marketplace, hoped the maintainer updated it regularly, and prayed that the Azure fabric wouldn’t freak out over some kernel module incompatibility.

That changed for me back in late 2024. When Microsoft officially added AlmaLinux to its “Endorsed Distributions” list, I initially dismissed it as marketing fluff. A logo swap. A handshake.

I was wrong.

It’s been over a year since that announcement, and looking at my dashboard today in early 2026, the difference is actually tangible. It’s not about the logo; it’s about what happens at 3 a.m. when your disk I/O hits the floor and you need to know if it’s the OS or the hypervisor.

The Support Ticket Litmus Test

Here is the reality of “Endorsed” status that nobody puts in the press release: it dictates whether a Microsoft support engineer hangs up on you or not.

Before the endorsement, running AlmaLinux on Azure was technically “supported” in the sense that the VM would boot. But if you opened a Sev A ticket because of a weird networking stack trace, you’d often get the polite brush-off: “Please reproduce this on a supported OS like RHEL or Ubuntu.”

Last month, I had a weird issue with a scale set dropping packets on specific D-series v5 instances. I opened a ticket. The engineer didn’t blink. Because Alma is endorsed, the Azure Linux team treats it as a first-class citizen. They have direct lines to the Alma devs. They have the kernel symbols. They actually debugged the hypervisor vSwitch interaction with me.

That safety net is the only reason I signed off on migrating our core API clusters from RHEL to Alma last summer. The economics are obvious—no licensing fees—but the engineering risk was the blocker. The endorsement removed the blocker.

The Technical Guts: It’s Not Just an ISO

There’s a technical distinction here too. The endorsed images aren’t just vanilla ISO installs thrown onto a VHD. They come baked with the Azure Linux Agent (waagent) pre-configured correctly, and more importantly, they are tuned for the Azure hypervisor.

We used to build our own golden images using Packer because the community images were hit-or-miss with updates. Now? I just pull the official endorsed reference. It supports Generation 2 VMs out of the box (which you absolutely should be using for the UEFI and secure boot benefits), and the update cadence aligns with Azure’s patching cycles.

If you’re still building custom images just to get basic Azure compatibility, stop. You’re wasting cycles. Here is the Terraform block I’ve been copy-pasting into every project since mid-2025:

resource "azurerm_linux_virtual_machine" "main" {
  name                = "prod-api-01"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_D4ds_v5"
  admin_username      = "adminuser"
  
  # This is the key part - using the endorsed reference
  source_image_reference {
    publisher = "AlmaLinux"
    offer     = "AlmaLinux-x86_64"
    sku       = "9-gen2" 
    version   = "latest"
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Premium_LRS"
  }

  # ... keys and networking config
}

Notice the sku = "9-gen2". If you’re running on legacy Gen1, you are leaving performance on the table. The endorsed images handle the NVMe interfaces on the newer Azure instance types much better than the generic generic kernel builds we were hacking together previously.

The “Update Manager” Integration

Another thing that surprised me was how well it plays with Azure Update Manager now. Back in the day, third-party distros would show up as “Unknown” or report patch status incorrectly in the portal.

Because of the collaboration between the Alma team and Microsoft, the repository metadata is parsed correctly by the Azure agent. I can set up a maintenance window in the Azure portal to patch my Alma fleet every Tuesday at 2 a.m., and it actually works. It respects the dnf locks, it reboots if the kernel changed, and it reports success back to the dashboard.

I didn’t have to write a custom Ansible playbook to handle patching. I just clicked buttons in the portal. I know, I know—”ClickOps” is a sin. But for basic patch management across 500 VMs? I’ll take the easy win.

Where RHEL Fits In (The Elephant in the Room)

So, does this kill RHEL on Azure? Not exactly.

We still keep RHEL for our database nodes. Why? Because the database vendor’s support contract explicitly says “Certified on Red Hat Enterprise Linux.” They get fussy if they see /etc/redhat-release saying AlmaLinux, even if the binaries are identical. It’s a lawyer thing, not a tech thing.

But for everything else—web servers, cache nodes, worker queues, CI runners—we’ve moved entirely to endorsed AlmaLinux. The cost savings are massive. We aren’t paying the RHEL premium on the compute hourly rate, but we still get the “Microsoft will help us fix it” assurance.

A Warning on Mirrors

One hiccup I ran into a few months ago: check your mirror configuration. By default, the images point to the global mirrors. In some Azure regions (looking at you, South Africa North), the latency to the default mirrors was causing dnf install to time out during cloud-init.

We fixed this by forcing the use of Azure-local repositories where available, or setting up a local Nexus proxy. It’s a small detail, but when you’re autoscaling 50 nodes at once, those extra seconds adding up can cause the scale-out to fail.

# Quick check to see what mirrors you are actually hitting
dnf repolist -v | grep "Repo-baseurl"

# If you see high latency, consider tweaking /etc/yum.repos.d/almalinux.repo
# to prioritize local mirrors or your own internal proxy.

The Boring Conclusion

Honestly? The best thing I can say about running AlmaLinux on Azure in 2026 is that it’s boring.

It boots. It patches. The monitoring works. The support tickets get answered. The drama of 2024 is gone. We aren’t fighting the platform anymore; we’re just using it. And for a sysadmin who just wants to close the laptop at 5 p.m., “boring” is the highest compliment I can give.