Skip to main content
Cloud DevOps Solutions
Get a quote Talk to an engineer

Containers and Kubernetes

Azure Kubernetes Service Engineering for Teams Building on Azure

Azure Kubernetes Service (AKS) is Microsoft's managed Kubernetes service: Azure runs the control plane and you manage node pools and workloads. We design AKS clusters around Microsoft Entra ID, workload identity, Azure networking and upgrade channels, then operate them with monitoring and cost control.

Key takeaways

  • AKS integrates deeply with Microsoft Entra ID and Azure RBAC, which makes it the natural fit for organisations already standardised on Microsoft identity.
  • The networking model (kubenet, Azure CNI or Azure CNI Overlay) is chosen at cluster creation and shapes IP planning, so decide it deliberately.
  • Use workload identity so pods authenticate to Azure services without stored secrets.
  • Auto-upgrade channels and planned maintenance windows keep clusters current, but node image upgrades need their own policy.
  • The control plane has a free tier; paid tiers add an uptime SLA and are the usual choice for production.

What teams use Azure AKS for

Microsoft-centric organisations

Teams using Entra ID, Azure DevOps, Key Vault and Azure SQL get single sign-on and consistent governance across the stack.

Enterprise landing zones

Clusters deployed into hub-and-spoke networks with Azure Firewall, private endpoints and Azure Policy.

Windows and .NET workloads

Windows node pools run legacy .NET Framework services alongside Linux containers while modernisation continues.

Azure DevOps delivery

Pipelines build to Azure Container Registry and deploy through Helm or GitOps with managed identities instead of stored credentials.

Event-driven scaling

KEDA, available as an AKS add-on, scales workloads on queue depth in Service Bus or Storage queues.

What AKS is and who it suits

Azure Kubernetes Service is Microsoft’s managed Kubernetes offering. Azure operates the API server and etcd; you own node pools, add-ons you choose to install and everything deployed on top. Our AKS consulting is led by an engineer who holds the Microsoft Certified DevOps Engineer Expert and Azure Administrator Associate credentials as well as the CKA, which matters because most AKS problems are really Azure problems: identity, networking and policy.

For Kubernetes fundamentals see our Kubernetes page. Here we focus on what AKS does differently from EKS and GKE.

Architecture decisions to make early

Networking mode

AKS offers kubenet, Azure CNI and Azure CNI Overlay. Overlay assigns pod IPs from a private range that is not part of your VNet, which solves the IP exhaustion that hurts classic Azure CNI in large address plans. Classic CNI still suits workloads that need pod IPs routable from elsewhere on the network. Decide this alongside your hub-and-spoke design, egress path (Azure Firewall, NAT gateway or user-defined routes) and whether the API server should be a private cluster. Changing mode later is awkward, so we treat it as a day-one decision. Our cluster architecture with Terraform work shows the module layout.

Node pools

Keep a dedicated system pool for core components and separate user pools for workloads, split by purpose: general, memory-heavy, GPU, Windows, spot. Taints keep workloads where you intend.

resource "azurerm_kubernetes_cluster" "main" {
  name                = "aks-prod-weu"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "aks-prod"
  sku_tier            = "Standard"

  oidc_issuer_enabled       = true
  workload_identity_enabled = true
  local_account_disabled    = true

  azure_active_directory_role_based_access_control {
    azure_rbac_enabled = true
  }

  network_profile {
    network_plugin      = "azure"
    network_plugin_mode = "overlay"
  }

  default_node_pool {
    name       = "system"
    vm_size    = "Standard_D4s_v5"
    node_count = 3
  }

  identity {
    type = "SystemAssigned"
  }
}

Identity and security on Azure

Identity is where AKS is strongest if you are already on Microsoft.

  • Human access: integrate with Microsoft Entra ID and use Azure RBAC for Kubernetes or map Entra groups to Kubernetes roles. Disable local accounts so there is no shared admin credential.
  • Workload access: use Entra Workload ID so a service account federates with a managed identity. Pods then reach Key Vault, Storage or SQL with no secrets stored in the cluster.
  • Secrets: the Key Vault CSI driver mounts secrets or syncs them to Kubernetes Secrets when needed.
  • Policy: Azure Policy for Kubernetes enforces rules such as no privileged containers or allowed registries, giving you governance consistent with the rest of your subscription.
  • Network: combine NSGs, network policy (Azure NPM or Cilium) and a private cluster where regulation demands it. Our Kubernetes network policy implementation applies equally here.
  • Supply chain: Azure Container Registry with vulnerability scanning, and attach it to the cluster through managed identity rather than image pull secrets.

Cost and capacity

AKS control plane pricing has a free tier without an uptime SLA and paid tiers with one. Compute cost follows node pools. Our levers are the cluster autoscaler (or node auto-provisioning, which is Karpenter-based), spot node pools for stateless batch work, scheduled scale-down of non-production pools, and reservations or savings plans once baseline usage is stable. Do not forget Log Analytics ingestion: container logs at default verbosity are frequently the largest surprise on the bill. Tune data collection rules and consider Prometheus metrics with Grafana for long retention.

Day-2 operations

Upgrades

AKS separates Kubernetes version upgrades from node OS image upgrades. You can choose an auto-upgrade channel (patch, stable, rapid and so on) and a separate node OS channel, then constrain timing with planned maintenance windows. Nodes are replaced with a configurable surge. The safety net is the same as everywhere else: scan for removed APIs, set PodDisruptionBudgets and rehearse. See Kubernetes upgrade planning and execution.

Delivery and monitoring

For delivery, AKS pairs well with Azure DevOps or GitHub Actions building into ACR and Argo CD or the Flux-based GitOps extension reconciling the cluster (Azure DevOps consulting). For observability, Azure Monitor and Container Insights give quick coverage; Prometheus and Grafana give portable dashboards and alert rules your team controls.

Ingress, egress and governance

For ingress, teams commonly choose between the application routing add-on (managed NGINX), Application Gateway for Containers, or a self-run controller; the right answer depends on whether you need Web Application Firewall features at the edge. Egress deserves equal attention: route outbound traffic through a NAT gateway or Azure Firewall so source addresses are predictable for partners who allow-list you. Apply Azure Policy at the management group level so every new cluster inherits the same guardrails, and tag resources consistently so cost reports can be split by team.

Backup and recovery

Stateless workloads should be rebuilt from Git. For persistent volumes, use Azure Disk snapshots or a Kubernetes-aware backup tool, and rehearse restoring into a fresh cluster. That exercise also proves your infrastructure code can recreate the platform. See backup and disaster recovery.

Common AKS failure modes

  • Subnet exhaustion with classic Azure CNI in a small VNet.
  • Local admin credentials left enabled and shared in pipelines.
  • Upgrade surprises from auto-upgrade with no maintenance window or budgets.
  • Quota limits on VM families blocking scale-out during peak.
  • Log Analytics cost from unfiltered container logs.

When to choose something else

If you run a few HTTP services and do not need Kubernetes APIs, Azure Container Apps or App Service is simpler. If your estate is mostly AWS, EKS will integrate more naturally. If you want help judging fit or starting an AKS build, book a consultation.

Official documentation: learn.microsoft.com/azure/aks

How we work with Azure AKS

  1. 01

    Landing zone and network plan

    We choose subscriptions, VNet layout, CNI mode, private cluster options and egress path before creating the cluster.

  2. 02

    Provision with Terraform or Bicep

    Cluster, node pools, ACR, Key Vault and policy assignments are defined as reviewed code.

  3. 03

    Identity and RBAC

    Entra ID groups map to Kubernetes roles, local accounts are disabled and workload identity replaces stored secrets.

  4. 04

    Security baseline

    Azure Policy for Kubernetes, Defender for Containers where licensed, network policy and image scanning are enabled.

  5. 05

    Scale and monitor

    Cluster autoscaler or node auto-provisioning, Azure Monitor or Prometheus, and alerts tied to service objectives.

  6. 06

    Upgrade operations

    Channels, maintenance windows and surge settings are configured and rehearsed in a lower environment.

Azure AKS compared with the alternatives

We recommend the tool that fits your team, not the one we know best. Here is when each option makes sense.

OptionChoose it when
Azure AKSAzure Kubernetes Service (AKS) is Microsoft's managed Kubernetes service: Azure runs the control plane and you manage node pools and workloads.
Azure Container AppsChoose Container Apps for HTTP and event-driven services where you want Kubernetes-like scaling without managing a cluster.
Azure App ServiceChoose App Service for a small number of web apps and APIs where a simple PaaS deployment is enough.
Amazon EKS or Google GKEChoose these when your workloads, data and identity primarily live in AWS or Google Cloud.
Azure FunctionsChoose Functions for short-lived, event-triggered code that does not need containers or a scheduler.

Tools we use alongside Azure AKS

TerraformBicepAzure Container RegistryAzure Key VaultMicrosoft Entra IDAzure MonitorPrometheusGrafanaKEDAAzure PolicyArgo CDFluxHelm

Frequently asked questions

What is the difference between AKS and self-managed Kubernetes on Azure VMs?
AKS runs and maintains the Kubernetes control plane for you and integrates with Azure networking, identity and monitoring. With self-managed Kubernetes on VMs you operate every component. Almost all teams should use AKS unless a specific constraint forbids it.
Which AKS network plugin should we use?
Azure CNI Overlay is a good default for most new clusters because pods draw addresses from a private overlay range, which saves VNet IP space. Classic Azure CNI gives pods VNet addresses directly and suits cases needing direct pod reachability. Kubenet is the older option and is generally avoided for new builds.
How should pods authenticate to Azure services?
Use Microsoft Entra Workload ID. A Kubernetes service account is federated with a managed identity, and pods obtain short-lived tokens without secrets in the cluster. It replaces the older pod identity add-on and is the pattern Microsoft recommends.
How do AKS upgrades work?
You can upgrade manually or set an auto-upgrade channel. Control plane and node pools upgrade separately, nodes are cordoned and drained with a configurable surge, and node OS images have their own channel. Maintenance windows control timing. Always check for removed APIs and respect PodDisruptionBudgets.
How do we control AKS cost?
Right-size requests, use the cluster autoscaler, stop or scale down non-production pools out of hours, and use spot node pools for tolerant workloads. Review log analytics ingestion, which can exceed compute spend, and choose reservations or savings plans once usage is stable.
AKS or EKS?
Pick the cloud your identity, data and compliance already sit in. AKS wins on Entra ID and Azure DevOps integration. EKS wins on depth of AWS services and Karpenter. The Kubernetes layer is largely the same; the surrounding cloud differences decide it.

Talk to an engineer about Azure AKS

Book a free 30-minute call. We review your current setup and tell you honestly whether and how we can help.

Written by Saddique Khan, DevOps / SRE / Cloud Consultant Engineer. Last updated 2026-10-09.