Azure Kubernetes Service (AKS) Design and Deployment
Azure Kubernetes Service (AKS) Design and Deployment builds a production-grade AKS platform for teams that have outgrown Azure App Service or inherited a self-managed Kubernetes cluster nobody wants to own. The engagement covers the tier and topology decisions, node-pool sizing, Azure CNI networking powered by Cilium, Microsoft Entra ID sign-in with Azure RBAC for Kubernetes and workload identity for pods, ingress with TLS, Azure Monitor managed Prometheus and Managed Grafana observability, Azure Backup for AKS with a tested restore, an upgrade and maintenance baseline, one containerized workload onboarded through your CI/CD pipeline, and an operations handover document your team runs the cluster from. Projects are quoted after a scoping call — cluster and environment count, network topology, and Windows node requirements move the price — and a single-cluster build typically runs about 4 weeks, managed by Roman Sotnik.
What this engagement is
Two kinds of teams arrive at this page. The first has outgrown Azure App Service: several services that need to share a platform, sidecars, custom networking, background workers that do not fit a web-app model, or a vendor product that ships only as Helm charts. The second has inherited Kubernetes — a kubeadm cluster on virtual machines, or an AKS cluster a contractor built with a local admin kubeconfig, no upgrades in a year, and nobody who knows how the ingress works. Both need the same thing: a cluster designed to Microsoft's AKS baseline guidance, deployed from infrastructure as code, and documented well enough to operate. We start with an honest platform decision. If your workloads would run happily on Azure Container Apps without the Kubernetes API, we say so in the design document — it is cheaper to run and far cheaper to operate — and we scope that instead. If Kubernetes is the right answer, the next decision is AKS Automatic, Microsoft's opinionated configuration with node auto-provisioning, Deployment Safeguards, and managed system node pools enforced by default, versus AKS Standard, where we make every choice explicitly — the usual reasons to choose Standard are Windows node pools, custom node configuration, or network constraints Automatic does not accommodate yet. From there the design covers the things that are painful to change later: the pricing tier (production clusters go on the Standard tier for the financially backed API-server SLA), availability zones, network mode and IP plan (Azure CNI Overlay powered by Cilium is our default, and Microsoft's), whether the API server is private, egress, identity (Microsoft Entra ID sign-in with Azure RBAC for Kubernetes, local accounts disabled, workload identity for pods), ingress, observability, backup, and the upgrade policy — because AKS supports only the latest three Kubernetes minor versions, an upgrade cadence is a design input, not an afterthought. We then deploy it, onboard one workload through your CI/CD pipeline so the pattern is proven end to end, rehearse a restore and an upgrade, and hand over with a runbook and a recorded session. Writing or refactoring application code is out of scope — Application Containerization to Azure packages an existing application into an image, and Legacy Application Modernization to Azure re-platforms aging code — and so is 24/7 operation of the cluster after handover, which is available as a managed follow-on.
Success criteria
What you receive
How the work unfolds
Review current hosting, the workloads and their images, team skills, the Azure subscription and network you already have, and compliance constraints. Output is the design document — including the Container Apps versus AKS and Automatic versus Standard decisions — which you approve before anything is built.
Infrastructure-as-code baseline and supporting resources: virtual network or landing-zone spoke, Azure Container Registry, Key Vault, monitoring workspaces, Managed Grafana, and the Backup vault. Pipeline deployment of the foundation is validated before the cluster exists.
AKS deployed from code on the agreed tier: node pools, availability zones, Entra ID integration and Azure RBAC, private API server or authorized ranges, Azure Policy and Deployment Safeguards, maintenance windows, and autoscaling.
Ingress and TLS stood up, workload identity and Key Vault integration proven with a test pod, Prometheus metrics and Container Insights flowing, Grafana dashboards deployed, alert rules wired to your channel.
Your Helm chart or Kustomize manifests reviewed or written, resource limits and probes set, the deployment step added to your CI/CD pipeline, a smoke test run, and DNS cut over where the workload replaces an existing endpoint.
Backup policy applied and a restore tested; a Kubernetes or node-image upgrade rehearsed on the non-production cluster or pool; the build reviewed against Microsoft's AKS baseline guidance; cost estimate refreshed from real telemetry.
Operations runbook delivered, recorded walkthrough for the team that will run the cluster, open items closed, and acceptance signed.
Prerequisites
Who does what
IT Partner
- Lead discovery and produce the design document, including the honest platform recommendation and the cost estimate.
- Write the infrastructure as code and deploy the foundation, the cluster, identity integration, ingress, observability, and backup to the approved design.
- Onboard the agreed workload through your pipeline and prove ingress, identity, secrets, and monitoring end to end.
- Rehearse a restore and an upgrade and record the results.
- Deliver the operations runbook and the recorded handover session, and raise risks, scope changes, and platform constraints as soon as they are found.
Your team
- Provide subscription, Entra ID, network, and source-control access, and make design decisions when options are presented.
- Supply the workload's container image, build steps, and configuration, and the developer who knows how it runs.
- Approve the design document, the cutover window for any endpoint being replaced, and the acceptance criteria.
- Own Azure consumption and any Microsoft or third-party licensing.
- Operate the cluster after handover — upgrades, scaling, on-call — or contract managed operations separately.
What's not included
Limitations & technical notes
Frequently asked questions
What does Azure Kubernetes Service (AKS) Design and Deployment include?
A design document you approve first, then a production-grade AKS cluster deployed from infrastructure as code: node pools sized and zoned, Azure CNI Overlay with Cilium networking, Microsoft Entra ID sign-in with Azure RBAC for Kubernetes, workload identity and Key Vault integration for pods, ingress with TLS, Azure Monitor managed Prometheus and Managed Grafana with alerting, Azure Backup for AKS with a tested restore, an upgrade and maintenance baseline, one of your workloads onboarded through your CI/CD pipeline, and an operations runbook with a recorded handover.
Why is there no price on the page, and what drives the quote?
Because cluster builds range widely. The main drivers are the number of clusters and environments, whether the API server is private and how egress is routed, Windows node pools, whether you are starting clean or we are untangling an inherited cluster, and how much of the surrounding foundation — network, registry, monitoring — already exists. After one scoping call you get a written fixed quote, and per our standard terms you pay after you approve delivery.
How long does it take?
About 4 weeks for a single-cluster build with one workload onboarded: design in week one, foundation and cluster in week two, ingress, identity, monitoring, and workload in week three, backup and upgrade rehearsal plus handover in week four. Multiple environments, a private-cluster network design that waits on a change board, or a slow approval on the design document are what stretch it.
Do we actually need Kubernetes, or would Azure Container Apps do?
Often Container Apps does, and the design document says so when it is true. Container Apps runs container images on a Kubernetes-based platform Microsoft operates, with scaling, ingress, and revisions built in and no cluster to upgrade. You need AKS when you need the Kubernetes API itself — operators, custom controllers, DaemonSets, a service mesh, GPU or Windows node pools, specific node configuration, or a vendor product delivered as Helm charts that assumes a real cluster. If you do not need those things, we would rather sell you the smaller engagement.
AKS Automatic or AKS Standard — which do you deploy?
Whichever the design justifies. AKS Automatic, generally available since late 2025, is Microsoft's opinionated configuration: node auto-provisioning, managed system node pools, Azure CNI Overlay with Cilium, Entra ID integration, and Deployment Safeguards enforced by default — a strong choice for a team without a platform engineer. AKS Standard is where we make every setting explicitly, and it is the answer when you need Windows node pools, custom node configuration, or network patterns Automatic does not yet accommodate. Both are AKS; your images, manifests, and pipelines are the same either way.
Which AKS tier do we need — Free, Standard, or Premium?
Production runs on Standard: it carries Microsoft's financially backed uptime SLA for the Kubernetes API server and scales well beyond anything an SMB cluster needs. Free has no SLA and suits development and test clusters. Premium adds long-term support — Microsoft maintains a Kubernetes version for an additional year beyond the community window — which matters if your workloads or vendors cannot keep up with two upgrades a year. The tier is a per-cluster hourly fee billed by Microsoft; we recommend one in the design and you decide.
How do our engineers sign in to the cluster?
With their Microsoft Entra ID accounts. The cluster is deployed with AKS-managed Entra integration and Azure RBAC for Kubernetes authorization, so cluster-admin and namespace-level developer access are Azure role assignments on Entra security groups — governed by your conditional access policies and revoked the day an account is disabled. Local cluster accounts are turned off, so there is no shared admin kubeconfig to leak.
How do pods get access to Key Vault, storage, or a database without secrets?
Through Microsoft Entra Workload ID: a Kubernetes service account is federated with a managed identity, and the pod exchanges its projected token for an Azure access token at run time — no client secret to store or rotate. Secrets that must exist, such as third-party API keys, live in Azure Key Vault and are mounted by the Secrets Store CSI driver. The older pod-managed identity approach is deprecated and we do not deploy it.
Which ingress do you use — and what about NGINX?
For new clusters, Azure Application Gateway for Containers — an Azure-managed data plane outside the cluster with WAF support — or the Gateway API implementation of the AKS application routing add-on, depending on whether you need a WAF and how traffic reaches the cluster. We no longer design new clusters on NGINX ingress: the upstream ingress-nginx project ended maintenance in March 2026, and Microsoft supports the managed NGINX in the add-on with critical security patches only through November 2026. If you inherit a cluster that depends on it, the migration is scoped explicitly.
What monitoring do we get, and what will it cost to run?
Azure Monitor managed Prometheus collects cluster and workload metrics, Azure Managed Grafana presents them on Microsoft's AKS dashboards plus any we add, and Container Insights collects logs into Log Analytics. Alerts for node pressure, crash-looping pods, failed rollouts, certificate expiry, and backup failures route to your channel. Cost is driven by Prometheus samples ingested, log volume, and Grafana users; the design estimates it from Microsoft's published pricing and we tune collection so you are not paying to store logs nobody reads.
What does the backup actually protect?
Azure Backup for AKS snapshots cluster resources — deployments, config, secrets, custom resources — and Azure Disk persistent volumes on the agreed schedule, keeping a vaulted copy for the retention you choose, with cross-region restore available. We take a backup and restore it during the project so the procedure is proven, not assumed. It does not cover databases outside the cluster or data in Azure Files, which keep their own backup — and we recommend running stateful databases outside the cluster on managed Azure services in the first place.
Who upgrades the cluster after handover?
Your team, from the runbook — or IT Partner under a managed operations arrangement. AKS supports the latest three Kubernetes minor versions, so a cluster needs a version upgrade roughly twice a year plus regular node-image updates; we configure auto-upgrade channels and maintenance windows during the build and rehearse an upgrade before handover so the first one your team does is not the first one anyone has done.
Can you run Windows containers on the cluster?
Yes, on AKS Standard with a Windows Server node pool alongside the Linux system pool — the usual reason is a .NET Framework application that cannot move to Linux. Windows pools use the cluster autoscaler rather than node auto-provisioning and carry Windows licensing in the VM price, both of which the design spells out. If the only reason for AKS is one Windows application, we will also tell you whether App Service for Windows containers would be simpler.
Do we need an Azure landing zone first?
Not always, but a cluster deserves a governed home: a subscription with policy, a virtual network with an agreed address plan, and a monitoring workspace it can share with the rest of your estate. If you already have that, the cluster lands in a spoke. If you have nothing but a pay-as-you-go subscription with resources created by hand, the Azure Landing Zone engagement builds the foundation first, and the two can be scoped together.
We inherited a cluster built by someone who left — can you take it over instead of building new?
Sometimes. Discovery examines the existing cluster — version, tier, networking, how people authenticate, what the ingress is, whether anything is in code — and the design document either brings it to the baseline in place or recommends a clean cluster with the workloads migrated across, which is frequently faster and safer than remediating an out-of-support cluster with local admin access and an NGINX ingress nobody maintains. Either way the outcome is the same: code, identity, monitoring, backup, and a runbook.
What happens after handover — do you offer managed operations?
After handover your team owns the cluster with the runbook and the recorded session. If you would rather not run it, managed operations — monitoring, patching, upgrades, backup administration — are available as a separate recurring engagement through Azure Resource Monitoring and Maintenance, and 24/7 support is an optional extra-cost add-on through IT Partner's NOC and support partnerships. Additional workloads are quoted as small fixed-scope add-ons, and the documented pattern means each one is cheaper than the first.