AKS and Near-Bare-Metal Workloads: What Platform Teams Can Responsibly Plan For
Every few months a team shows up with a workload that has opinions about hardware. GPU inference, high-frequency packet processing, latency-sensitive financial systems — something that makes a shared-tenant VM feel like a traffic jam. The conversation usually ends up at "can we get bare-metal nodes on AKS?"
The honest answer right now: partially, with caveats, and you should not trust anyone who gives you a confident full answer without pointing at current documentation. This post is about what you can design around today, what requires validation before you commit to it, and where the gaps are that will bite you if you skip due diligence.
A note on sources: The AKS core concepts and product overview documentation available at time of writing covers cluster and workload fundamentals12 but does not address bare-metal or near-bare-metal node pool specifics. Claims in that category are marked NEEDS_VALIDATION throughout. Everything else is grounded in general AKS behavior that is broadly consistent across the platform.
Why "Bare-Metal on AKS" Is Complicated Terminology
