Skip to content
Notifications
Clear all

Why does AKS feel so much slower to provision than EKS?

2 Posts
2 Users
0 Reactions
3 Views
(@sre_barbarian)
Active Member
Joined: 4 months ago
Posts: 11
Topic starter   [#549]

Anyone else notice that provisioning an AKS cluster feels like watching paint dry compared to EKS? I spin up an EKS cluster, go make a coffee, and it's usually ready. With AKS, I can brew a pot, drink it, and still see "Creating..." in the portal.

I'm not talking about a few seconds. We're talking minutes turning into tens of minutes, especially with anything beyond the most basic config. It's not just the control plane. The whole flowβ€”node pool readiness, networking finalizing, system pods settlingβ€”feels like it's running on under-provisioned hardware.

Is this the infamous "Azure tax" on API call latency? Or is it just the architectural overhead of their deeply integrated platform?
* More layers of abstraction and "managed" services that actually add orchestration steps?
* Default CNI (kubenet vs. VPC CNI) adding complexity?
* Or maybe they're just more conservative with resource allocation to keep their own costs down?

I get that "managed" means they handle the control plane, but when the management plane itself is sluggish, it defeats the purpose. For rapid iteration or disaster recovery, this wait time is a real operational cost.

Or am I just doing it wrong? 🧐

rawr


Keep it simple, stupid


   
Quote
(@integration_ian_2)
Reputable Member
Joined: 2 months ago
Posts: 159
 

You're spot on about the layers of orchestration. From what I've pieced together building automations around both, it's less about raw compute speed and more about the sequential gate checks in Azure's resource manager. Every component - the control plane, node pools, networking - is a separate ARM resource with its own validation cycle, and they often don't proceed in parallel as efficiently as in AWS.

The CNI point is a big one, especially if you're using Azure CNI with subnet IP pre-allocation. That step adds a significant reconciliation delay while it talks to the virtual network provider. A basic kubenet cluster should be quicker, but then you lose features.

For rapid iteration, I've had to script around this by using Terraform to create the cluster in a "bare" config first, then immediately apply a second configuration to scale and add node pools. It's a hack, but it gets the API response back faster so the rest of your pipeline can start.


api first


   
ReplyQuote