Azure Kubernetes Service is Microsoft’s managed Kubernetes offering, and for many UK development teams it has become the default answer to “where should this application run?” Kubernetes is the industry standard for container orchestration, it appears on every job advert, and it promises portability, scale and flexibility. So a team building a web application, an API and a background worker provisions a cluster, writes manifests and Helm charts, sets up ingress and certificates, and ships.
Six months later, the same team is spending a noticeable share of its time on the cluster rather than the product: upgrading Kubernetes versions before support ends, chasing node image updates, debugging ingress and certificate renewals, tuning resource requests, wiring up monitoring, and explaining to the finance director why the Azure bill includes nodes that are mostly idle. None of this work is wasted for a workload that needs Kubernetes. For one that does not, it is overhead that a simpler platform would have absorbed.
This guide starts with the operational overhead AKS actually requires, then covers what Azure App Service does well out of the box, where Azure Container Apps sits between the two, the specific scenarios where Kubernetes genuinely pays for its complexity, and a decision framework based on team size and operational maturity rather than what looks good on a CV. It is written for technical leads, CTOs and IT managers at UK businesses choosing a compute platform for a new or existing application.
What the two platforms are
Both platforms run your application code in Azure, but they sit at very different levels of abstraction.
Azure App Service
App Service is a platform as a service for web applications, APIs and background jobs. You deploy code in a supported language runtime or a container image, choose a plan that determines the size and number of instances, and Azure handles the operating system, patching, load balancing, scaling infrastructure and much of the plumbing around certificates, authentication and deployment. You think about your application and a handful of platform settings.
Azure Kubernetes Service
AKS provides a managed Kubernetes cluster. Microsoft operates the Kubernetes control plane; you are responsible for much of everything else: the node pools that run workloads, the Kubernetes version and upgrades, networking and ingress, how applications are packaged and deployed, scaling rules, security policies, observability and cost management. Kubernetes gives you enormous flexibility, and with it, responsibility for many decisions App Service makes for you.
Azure Container Apps
A third option sits between them. Container Apps runs containers on a managed platform built on Kubernetes technology, but hides the cluster. You get features such as scaling based on events, scale to zero, revisions and service-to-service communication, without managing nodes, versions or ingress controllers. For many container workloads that do not need full Kubernetes control, it is worth evaluating alongside the other two.
A useful rule: choose the least complex platform that meets your actual requirements today and in the foreseeable future, and move up only when a specific requirement forces it. Moving from App Service to containers later is a well-trodden path; recovering the months spent operating a cluster you did not need is not.
The operational overhead AKS actually requires
“Managed Kubernetes” can give the impression that Microsoft runs everything. It runs the control plane. The rest is a substantial list of ongoing work, and teams new to Kubernetes routinely underestimate it.
Version upgrades
Kubernetes releases new minor versions several times a year, and AKS supports only a limited window of recent versions. Clusters must be upgraded regularly to stay supported, and each upgrade needs testing, because APIs are deprecated and removed over time. Node operating system images also need updating for security patches. Automatic upgrade channels help, but someone still needs to understand what is changing and test workloads.
Node pools and capacity
You choose virtual machine sizes, node counts, autoscaling limits and how workloads are spread across pools. Too few nodes and applications fail to schedule; too many and you pay for idle capacity.
Networking and ingress
Choosing a networking model, configuring an ingress controller or gateway, managing DNS, handling TLS certificates and their renewal, and connecting securely to databases and other services all fall to you.
Packaging and deployment
Applications need container images, Kubernetes manifests or Helm charts, and a deployment pipeline. Many teams also adopt GitOps tooling, which is powerful and adds another system to run.
Security
Role-based access to the cluster, workload identity for accessing Azure resources, secrets management, network policies, pod security standards, image scanning and policy enforcement are all your responsibility to design and maintain.
Observability
Logs, metrics and traces need collecting and making useful, along with alerting on both application and cluster health.
Cost management
Clusters run continuously, and allocating cost to applications or teams within a shared cluster takes deliberate effort.
Skills and on-call
When something goes wrong at the cluster level, someone needs the knowledge to diagnose it. For a small team, that often means one or two people carry most of the Kubernetes expertise, which creates a key-person risk.
Microsoft has introduced more automated AKS options that take on some of this work, and they are worth considering if you choose AKS. They reduce the burden but do not remove the need to understand Kubernetes.
The operational gaps we find in SME clusters
The chart shows how often each operational gap appears in the AKS clusters we review for UK SMEs and scale-ups. Many clusters have several, so the figures add up to more than 100%.
None of these gaps reflects incompetence. They reflect small teams who adopted a platform designed for organisations with dedicated platform engineers, and who reasonably prioritised shipping features over cluster hygiene. On App Service, most of these items are either handled by the platform or simply do not arise. Our earlier overview of whether AKS is right for your business covers the platform itself; this guide focuses on the comparison and the decision.
Compute platform choices in UK teams — the numbers
The figures below are indicative, drawn from Azure architecture reviews we carry out for UK businesses. They are not a formal survey.
The last figure is telling. Portability is a legitimate reason to choose Kubernetes when there is a real requirement for it. But many teams cite it as a general hedge, paying the operational cost of portability every month for an option they are unlikely to exercise. Containers themselves provide much of the practical portability, whichever Azure service runs them.
What App Service does well out of the box
App Service is sometimes dismissed as a platform for simple websites. In practice it hosts a wide range of business applications, APIs and background processing, and it handles a great deal that teams on Kubernetes build and maintain themselves.
- Managed runtime and patching. Operating system and runtime patching are handled by the platform. There is no node image or cluster version to upgrade.
- Code or containers. Deploy code directly in supported languages, or deploy a container image if you need custom dependencies. Containerising on App Service keeps the option of moving to another container platform later.
- Deployment slots. On suitable plans, staging slots let you deploy a new version, warm it up and swap it into production with minimal disruption, and swap back if something goes wrong.
- Scaling. Scale up to larger instances or out to more instances, manually, on a schedule or automatically based on metrics, within the limits of the chosen plan.
- Certificates and custom domains. Managed certificates for custom domains and straightforward TLS configuration, without running a certificate manager.
- Built-in authentication. Integration with Microsoft Entra ID and other identity providers can be switched on with configuration rather than code.
- Networking options. Virtual network integration for outbound access to private resources, private endpoints for inbound access, and isolated environments for workloads that need dedicated infrastructure.
- Diagnostics and monitoring. Built-in log streaming, diagnostics and integration with Application Insights for application performance monitoring.
- Background work. WebJobs and the closely related Azure Functions cover scheduled and event-driven processing alongside web workloads.
For a typical business application — a web front end, an API, a few background tasks, a database and some storage — App Service usually provides everything needed, with far less to operate. Our guide to Azure App Service hosting covers plans, deployment and configuration in more detail.
App Service does have limits. Scale-out is capped per plan, fine-grained control over the runtime environment is limited compared with Kubernetes, complex service meshes and sidecar patterns are not its strength, and some specialised workloads, such as those needing GPUs or unusual networking, are better placed elsewhere. The question is whether your application actually needs what App Service does not provide.
Scoring three Azure compute platforms
The score grid compares App Service, Container Apps and AKS across the dimensions that usually decide the choice. A high badge means the platform performs well on that dimension, except for the last row, where high means high operational effort.
AKS wins clearly on orchestration, custom scaling and portability, and pays for those strengths in operational effort and time to production. App Service is the quickest and lightest to run for conventional web workloads. Container Apps often captures much of what teams want from Kubernetes — containers, event-driven scaling, multiple cooperating services — with operational effort closer to App Service, which is why it deserves a place in any comparison.
Kubernetes by default versus the simplest platform that fits
The comparison contrasts two approaches to choosing a compute platform.
Kubernetes by default
AKS chosen because it is the industry standard
Simplest platform that fits
Platform chosen from requirements, moving up only when needed
The right-hand approach does not rule out Kubernetes. It makes Kubernetes a choice driven by specific requirements rather than a default. Many teams that follow it eventually adopt AKS for some workloads, but do so with a clear reason and the operational capacity to support it.
When Kubernetes genuinely pays for its complexity
There are real scenarios where AKS is the right answer, and where its complexity buys capabilities that simpler platforms cannot provide.
Orchestrating many cooperating services
Applications made up of many services that need fine-grained control over how they communicate, are deployed, discover each other and recover from failure benefit from Kubernetes’ orchestration model. When the number of services and teams grows large, a shared platform with consistent deployment and operational patterns becomes valuable.
Custom scaling and scheduling logic
Workloads that need scaling based on custom metrics or queue depths, scheduling across specialised hardware such as GPUs, batch processing with complex dependencies, or precise control over placement and resource allocation can be expressed in Kubernetes in ways managed platforms do not allow. Container Apps covers some event-driven scaling needs; beyond that, AKS provides the control.
Genuine portability requirements
Where there is a concrete requirement to run the same workload across clouds, on-premises or at customer sites — for example, a software product deployed into customers’ own environments — Kubernetes provides a common target. That is different from a general wish to avoid lock-in, which containers alone partly address.
Specialised workloads and ecosystem tooling
Some workloads depend on tools and patterns that assume Kubernetes: certain data processing and machine learning frameworks, service meshes, operators for stateful systems, or sidecar-heavy architectures. If your workload needs these, AKS is the natural home.
A platform team to run it
Above all, Kubernetes pays when there are people whose job includes running it well. Organisations with a dedicated platform or operations function, or a development team large enough to share the load, can absorb the overhead and realise the benefits.
Where Azure Functions fits
Not every piece of compute needs a continuously running application. Azure Functions runs small units of code in response to events — an HTTP request, a message on a queue, a file arriving in storage, a timer — and charges largely for execution rather than for idle capacity on consumption-based plans. For scheduled jobs, integrations, file processing and lightweight APIs, it can be simpler and cheaper than any of the platforms above.
Functions works well alongside App Service or Container Apps: the main application runs on one, and event-driven tasks run as functions. It is less suited to long-running processes or applications with complex in-memory state, and cold starts on some plans can add latency to infrequently used functions. In a platform decision, it is worth asking which parts of the workload are really event-driven tasks that could run as functions, since that often shrinks what the main platform needs to do.
What running AKS properly involves in the first 90 days
For teams that do choose AKS, the timeline sets out the work needed to run a production cluster responsibly. It illustrates the investment involved, which should be weighed against the alternatives.
On App Service, most of these steps either do not exist or take hours rather than weeks: there is no cluster to design, ingress and certificates are platform features, deployment is built in, and scaling is configuration. That difference is the overhead the opening of this guide describes, made concrete.
What each platform really costs
The table compares indicative monthly costs for a modest business application — a web front end, an API and a background worker with moderate traffic — across the three platforms. Figures are broad ranges in pounds and depend heavily on sizing, region, reservations and usage; they include an estimate of engineering time, which is often the largest cost.
| Cost element | App Service | Container Apps | AKS |
|---|---|---|---|
| Compute | £150 to £600 for suitable plans | £50 to £500, lower with scale to zero | £300 to £1,200 for a resilient node pool |
| Control plane or platform fees | Included | Included | Free tier, or a paid tier for an uptime SLA |
| Supporting services | Minimal; certificates and deployment built in | Minimal | Load balancer, monitoring ingestion, registry, often more |
| Engineering time for platform operations | A few hours a month | A few hours a month | Two to eight days a month for a small team |
| Typical total including people time | Lowest | Low | Often two to four times the alternatives at this scale |
At small and moderate scale, the people cost of running a cluster usually dwarfs the infrastructure difference. At large scale, with many services and high utilisation, AKS can become cost-effective, because dense packing of workloads onto shared nodes and fine-grained scaling can reduce infrastructure spend. The crossover point depends on the workload, but it is typically well beyond what a single business application needs. Our guide to Azure cost management covers how to keep compute spend visible whichever platform you choose.
Container Apps: the middle ground
Many teams that reach for Kubernetes actually want a subset of what it offers: run containers, deploy several services that talk to each other, scale based on load or events, and roll out new versions safely. Azure Container Apps provides much of that without exposing a cluster.
Container Apps lets you deploy container images as apps within a shared environment, with built-in ingress, revisions for safe rollouts and traffic splitting, scaling rules based on HTTP traffic, queues and other event sources, and the option to scale to zero when idle. Services can discover and call each other within the environment, and background jobs can run on schedules or in response to events. Microsoft manages the underlying infrastructure, versions and nodes.
It suits microservice-style applications with a handful of services, event-driven processing, APIs with variable traffic and teams that want containers without cluster operations. It is less suitable when you need direct access to Kubernetes APIs, custom controllers or operators, specialised node hardware or full control over networking and scheduling.
For teams torn between App Service and AKS, Container Apps is often the answer they did not know they were looking for: containers and modern scaling patterns, with an operational burden much closer to App Service. And because the application is containerised, moving to AKS later, if a genuine need arises, is a much smaller step than starting there.
Signs you have outgrown App Service
Starting on the simplest platform only works if you recognise when to move on. The signs below suggest a workload may genuinely need Container Apps or AKS.
- The application has become many services. A growing number of independently deployed services with their own scaling needs and communication patterns is better served by a container platform with service discovery and revisions.
- Scaling needs to follow events, not just traffic. Workers that should scale with queue depth or other event sources, including down to zero, fit Container Apps or AKS more naturally.
- You are hitting plan limits. Regularly running at the maximum instance count or needing instance sizes beyond those available suggests a different platform.
- You need runtime control App Service does not offer. Custom networking, sidecars, specialised hardware or specific operating system configuration.
- Several teams need a shared platform. When many teams deploy many services, a consistent orchestration platform with a team to run it can become worthwhile.
- Portability becomes a concrete requirement. A customer or contract requires deployment into other environments.
One or two of these may point to Container Apps rather than AKS. Several together, with a team able to operate a cluster, make a stronger case for Kubernetes. None of them is a reason to start on AKS before the need is real.
How many clusters could run on something simpler
Across the AKS clusters we review in UK SMEs and scale-ups with fewer than twenty developers, the proportion running workloads that App Service or Container Apps could host without loss of required capability is substantial.
The figure is indicative rather than a formal survey, and it does not mean those teams made foolish decisions. Many chose AKS before Container Apps matured, or anticipated growth that did not materialise, or inherited the cluster from a previous team. The practical question is whether continuing to operate the cluster is the best use of the team’s time now, which a periodic review can answer.
AKS operational practices in place
The progress bars show how often each practice is in place across the AKS clusters we review in UK SMEs and scale-ups. Figures are indicative, and the gaps illustrate the ongoing work AKS demands.
AKS operational practices in place
The basics of getting software onto a cluster are well established in most teams. The practices that keep a cluster secure, supported and cost-effective over time — upgrades, resource limits, network policies, cost allocation — are in place in a minority. These are exactly the tasks that App Service and Container Apps either handle for you or make unnecessary.
Kubernetes operational maturity — where most small teams sit
Combining upgrade discipline, security, observability, capacity management, cost allocation and spread of skills gives an indication of a team’s readiness to operate AKS well. The gauge reflects a typical UK development team of five to fifteen people running AKS without a dedicated platform engineer.
A score in the mid-thirties reflects a team that can deploy to Kubernetes but struggles to keep up with everything else: upgrades slip, resource settings are guesses, security policies are partial, cost is opaque and knowledge sits with one or two people. The cluster works, but carries risk and absorbs time.
Teams in this position have two good options: invest in raising maturity, typically through more automated AKS options, platform tooling and broader skills, or move workloads that do not need Kubernetes to App Service or Container Apps and keep the cluster only for those that do. Either is better than drifting.
A decision framework based on team size and operational maturity
The most reliable predictor of whether AKS will serve a business well is not the application’s architecture but the team that will run it. The framework below combines both.
Step 1: State the requirements honestly
List what the workload actually needs: number of services, traffic patterns, scaling triggers, networking and isolation, specialised hardware, compliance constraints, and any real requirement to run outside Azure. Separate genuine requirements from “might be nice one day”.
Step 2: Assess the team
- Small team, no platform specialist (roughly under ten developers): default to App Service or Container Apps. Choose AKS only for a specific requirement that the others cannot meet, and then consider external support for cluster operations.
- Growing team with some operations capability (roughly ten to thirty): App Service or Container Apps for most workloads; AKS where several services or teams benefit from a shared orchestration platform and someone owns it.
- Larger engineering organisation with a platform team: AKS as a shared platform can make sense, with simpler services still used where they fit better.
Step 3: Match requirement to platform
- Conventional web apps and APIs, modest background work: App Service.
- Containerised services, event-driven scaling, scale to zero, a handful of cooperating services: Container Apps.
- Many services needing fine-grained orchestration, custom scheduling or hardware, Kubernetes-specific tooling, or genuine multi-environment portability: AKS.
Step 4: Check the exit route
Whatever you choose, containerising the application keeps options open. A containerised app on App Service or Container Apps can move to AKS later with modest effort if requirements change.
Step 5: Review annually
Requirements, team size and platform capabilities change. A yearly review of whether each workload is on the right platform avoids both staying on a platform that has been outgrown and operating complexity that is no longer needed.
Questions to ask before approving a Kubernetes proposal
Business leaders are often asked to approve platform decisions they cannot evaluate technically. The questions below help test whether a proposal to adopt AKS is grounded in need.
- Which specific requirement can only AKS meet? Expect a concrete answer, not “flexibility” or “industry standard”.
- Were App Service and Container Apps evaluated? Why were they rejected for this workload?
- Who will own the cluster? Who upgrades it, responds to incidents and keeps it secure, and who covers when they are away?
- How much engineering time will operations take each month? And what product work will that time displace?
- What is the full monthly cost? Including control plane tier, supporting services and people time, not just nodes.
- What is the upgrade plan? How often, how tested and who signs off?
- If portability is a reason, where would we move and when? Is there a customer or contractual driver?
- What would make us reconsider? A good proposal includes the conditions under which a simpler platform would be preferred.
Clear answers suggest a well-founded decision. Vague answers suggest the team should start simpler and revisit when a specific need emerges.
Moving between platforms
Platform decisions are not permanent, and moving in either direction is more manageable than many teams assume.
From App Service to containers
The usual first step is to containerise the application and run the container on App Service, which changes little operationally but makes the application portable. From there, moving to Container Apps or AKS is mainly a matter of configuration, networking and deployment pipeline changes.
From AKS to a simpler platform
Teams that conclude they do not need Kubernetes can often move workloads to Container Apps with relatively little change, since both run containers. Configuration held in manifests needs translating, ingress and certificates move to platform features, and secrets and identity need re-wiring, but application code usually remains the same. Moving workloads one at a time, starting with the simplest, keeps risk low.
Running both
Many organisations end up with a mix: most workloads on App Service or Container Apps, and a cluster for the few that genuinely need it. That is often the best outcome, provided each workload’s placement is deliberate. Good foundations make this easier; our guide to Azure landing zones covers the structure that lets several platforms coexist cleanly.
Common compute platform mistakes
The mistakes below account for most of the platform regret we see.
- Choosing AKS because it is the industry standard. Standard for whom? Large organisations with platform teams, not every application.
- Underestimating ongoing operations. The control plane is managed; upgrades, security, capacity and cost are not.
- Citing portability without a plan. Containers provide most practical portability on any platform.
- Dismissing App Service as too simple. It hosts a wide range of serious business applications.
- Overlooking Container Apps. Often the right answer for teams that want containers without clusters.
- Letting Kubernetes versions fall behind. Unsupported clusters carry security and support risk.
- Concentrating cluster knowledge in one person. A key-person dependency for a critical platform.
- No cost allocation. Shared clusters hide which applications drive spend.
- Over-provisioning nodes for peace of mind. Idle capacity runs continuously and adds up.
- Never revisiting the decision. The right platform two years ago may not be the right platform now.
Engineers understandably want experience with the technologies the market values, and Kubernetes is high on that list. That is a legitimate career consideration, but it is not a business requirement. Decisions about platforms should be made on the workload’s needs and the team’s capacity to run them, with professional development supported in ways that do not commit the business to unnecessary operational overhead.
Case study: from cluster operations back to product work
A UK software-as-a-service company with eight developers ran its platform — a customer-facing web application, a public API, three background workers and an admin portal — on an AKS cluster set up two years earlier by a contractor who had since left. The cluster ran three nodes continuously, with ingress, certificate management, a monitoring stack and a GitOps tool installed.
Over the previous year, the team had spent an increasing share of its time on the cluster. A Kubernetes version reached end of support and the upgrade surfaced deprecated APIs in several charts; a certificate renewal failure took the API offline for part of a morning; and only one developer understood the networking configuration well enough to troubleshoot it. Cost reviews showed the nodes were lightly used outside business hours.
A platform review concluded that none of the workloads needed Kubernetes-specific capabilities. The company moved the web application, API and admin portal to Azure Container Apps, using the existing container images, with built-in ingress and managed certificates replacing the cluster components. The background workers moved to Container Apps jobs triggered by queue messages, scaling to zero when idle. Secrets moved to a key vault with managed identities, and monitoring was simplified to Application Insights and platform metrics. The migration was done service by service over seven weeks, with the cluster decommissioned at the end.
Over the following quarter, the team estimated that time spent on platform operations fell from roughly a fifth of one developer’s month to a few hours, monthly compute costs fell noticeably, and deployments became something any developer could do with confidence. The containerised services remain portable if requirements change.
“We were running Kubernetes because that is what we were given, not because we needed it. Moving to Container Apps gave us back the time we were spending looking after the cluster, and nobody on the team misses the upgrades.” — CTO, UK software-as-a-service company
The lesson is not that Kubernetes was a mistake in principle. It was the wrong fit for an eight-person team with no platform specialist and workloads that a managed container platform could run equally well.
The 12-point compute platform checklist
The checklist covers the essentials for choosing and running an Azure compute platform.
- Write down the real requirements. Services, scaling, networking, hardware, compliance and portability.
- Assess the team honestly. Size, operations experience and who would own the platform.
- Start with the simplest platform that fits. App Service, then Container Apps, then AKS.
- Containerise to keep options open. Portability without operating a cluster.
- Choose AKS only for specific needs. And name the requirement that justifies it.
- If using AKS, plan upgrades from day one. Cadence, testing and automatic channels.
- Set resource requests and limits deliberately. Based on observed usage, not guesses.
- Secure the platform. Identity, secrets in a vault, network isolation and policy.
- Make costs visible. Allocation by application or team, whichever platform you use.
- Spread platform knowledge. Documentation and at least two people able to troubleshoot.
- Monitor applications and platform. With alerts that reach someone who can act.
- Review placement annually. Move workloads up or down as requirements change.
There is no need to put every workload on the same platform. Many well-run Azure estates use App Service for conventional web applications, Container Apps for event-driven and containerised services, Functions for small pieces of automation and AKS for the few workloads that genuinely need it. The goal is that each placement is deliberate and supportable.
Security and networking compared
Security requirements are sometimes cited as a reason to choose AKS, on the basis that Kubernetes offers more control. More control also means more to configure correctly.
On App Service and Container Apps, the platform handles operating system patching and isolates applications, and you configure a manageable set of controls: virtual network integration for outbound access, private endpoints or internal-only ingress for inbound access, managed identities for accessing other Azure services, secrets in a key vault and built-in authentication. For workloads needing dedicated, isolated infrastructure, isolated App Service environments and dedicated Container Apps workload profiles are available.
On AKS, you can achieve fine-grained isolation and control, but you must design and maintain it: cluster access through Entra ID and Kubernetes role-based access control, workload identity, network policies between pods, pod security standards, admission policies, image scanning and provenance, node patching and private cluster configuration. Each is achievable, and each is something that can be missing or misconfigured.
For most business applications, the managed platforms meet security requirements with less risk of configuration gaps. AKS earns its place where specific isolation or control requirements exceed what they provide and the team has the expertise to configure it correctly.
Deployment pipelines and developer experience
How easily developers can ship changes matters as much as runtime capability. App Service offers straightforward deployment from common CI/CD tools, deployment slots for safe releases and the ability to deploy code without building containers at all. Container Apps deploys container images with revisions and traffic splitting for gradual rollouts. AKS deployments typically involve building images, maintaining manifests or Helm charts and, often, GitOps tooling, which gives great control and requires more knowledge across the team.
For small teams, the simpler models usually mean more developers can deploy confidently, fewer pipeline components to maintain and less risk that releases depend on one person. Our guide to Azure DevOps for small teams covers building pipelines that suit a small team, whichever platform they deploy to.
Reliability, availability and resilience
All three platforms can support highly available applications, but the work involved differs.
App Service and Container Apps provide platform-level availability, with options to run multiple instances and, in supported regions and tiers, spread across availability zones. Microsoft publishes service level agreements for each service and tier; check the current terms for the configuration you use. Resilience then depends mainly on running more than one instance, designing the application to tolerate restarts, and protecting the data tier.
On AKS, availability depends on both the control plane tier and how you configure the cluster. A paid control plane tier provides a financially backed uptime commitment. Beyond that, resilience comes from node pools spread across zones, multiple replicas, pod disruption budgets, health probes and careful upgrade procedures. Done well, AKS can be extremely resilient; done hastily, upgrades and misconfigurations become a source of outages in their own right.
Whatever the platform, the database, storage and external dependencies usually determine overall resilience more than the compute layer. A highly available cluster in front of a single database instance is not a highly available application.
Data, state and the services around compute
Compute platform discussions often focus on where application code runs and overlook where data lives. In most Azure business applications, state is best kept in managed services — Azure SQL, Cosmos DB, PostgreSQL, Storage, Service Bus, Redis — rather than inside the compute platform. This applies equally to App Service, Container Apps and AKS, and it is one reason the choice of compute platform is less permanent than it can seem: if the application is stateless and its data sits in managed services, moving compute between platforms is far simpler.
Running databases or other stateful systems inside Kubernetes is possible, using persistent volumes and operators, and some organisations do it for good reasons. For most SMEs, it adds backup, upgrade and recovery responsibilities that managed data services handle better. If a proposed AKS design includes running your own database in the cluster, it is worth asking whether a managed service would serve the business better.
At a glance: AKS, App Service and Container Apps
| Factor | App Service | Container Apps | AKS |
|---|---|---|---|
| What you deploy | Code or container | Containers | Containers with Kubernetes manifests |
| What you operate | Application and plan settings | Application and scaling rules | Nodes, versions, networking, security, observability |
| Version upgrades | Handled by platform | Handled by platform | Your responsibility, several times a year |
| Scaling | Manual, scheduled or metric-based within plan limits | HTTP and event-driven, scale to zero | Fully customisable |
| Multi-service orchestration | Limited | Moderate | Extensive |
| Certificates and ingress | Built in | Built in | You configure and maintain |
| Portability | Good when containerised | Good; standard containers | Highest; Kubernetes runs anywhere |
| Typical team fit | Any size | Any size | Teams with platform capability |
| Time to production | Days | Days | Weeks to months for production readiness |
| Cost at small scale | Low | Low, often lowest with scale to zero | Higher, mainly people time |
| Best for | Conventional web apps and APIs | Containerised and event-driven services | Complex multi-service, custom scheduling, real portability needs |
How Cloudswitched approaches Azure compute decisions
We help UK businesses choose compute platforms on the basis of the workload’s requirements and the team that will run it, not on what is fashionable. That starts with a short review of the application, its services, traffic and scaling patterns, security and compliance needs, and the team’s size and operational experience.
For most business applications, that leads to App Service or Container Apps, with containerisation to keep future options open. We design the platform configuration, networking, identity, secrets and monitoring, build deployment pipelines that any developer on the team can use, and size plans to demand so costs stay predictable. Where a workload genuinely needs Kubernetes, we design and build AKS clusters with upgrades, security, observability and cost allocation planned from the start, and can provide ongoing cluster operations so your developers can focus on the product.
For teams already running AKS, we can review whether each workload still belongs on the cluster, help raise operational maturity where Kubernetes is the right choice, and migrate workloads to simpler platforms where it is not. No platform is right for every application, but a deliberate choice saves months of avoidable work.
Not sure whether you need Kubernetes?
Talk to us about an Azure compute review, designing on App Service or Container Apps, or running AKS properly where it is the right fit.
Talk to an Azure SpecialistFrequently Asked Questions
What is the difference between AKS and App Service?
App Service is a managed platform for web apps and APIs where Azure handles the infrastructure and runtime. AKS provides a managed Kubernetes control plane, with you responsible for nodes, versions, networking, security and deployment. App Service is simpler to run; AKS offers more control and flexibility.
Is Azure Kubernetes Service fully managed?
Microsoft manages the Kubernetes control plane. You remain responsible for node pools, Kubernetes version upgrades, networking and ingress, security policies, observability and cost management, although more automated options reduce some of this work.
When should a business choose AKS?
When a workload needs fine-grained orchestration of many services, custom scaling or scheduling, specialised hardware, Kubernetes-specific tooling or genuine portability across environments, and the team has the capacity to operate a cluster well.
Can App Service run containers?
Yes. App Service can run container images as well as code in supported runtimes, which keeps applications portable to other container platforms later.
What is Azure Container Apps?
A managed platform for running containers with built-in ingress, revisions, event-driven scaling and scale to zero, built on Kubernetes technology but without exposing a cluster to manage. It often suits teams that want containers without cluster operations.
Is AKS more expensive than App Service?
At small and moderate scale, usually yes once engineering time is included, because clusters run continuously and require ongoing operations. At large scale with many services and high utilisation, AKS can become cost-effective.
Does Kubernetes avoid vendor lock-in?
Kubernetes provides a common target across environments, which helps where portability is a real requirement. Containers themselves provide much practical portability on any platform, and lock-in also arises from databases and other managed services.
How often do AKS clusters need upgrading?
Kubernetes releases new minor versions several times a year, and AKS supports a limited window of recent versions, so clusters need regular upgrades. Node images also need updating for security patches. Check current AKS support policies.
Can we move from AKS to a simpler platform?
Often, yes. Containerised workloads can usually move to Container Apps with changes to configuration, ingress, secrets and pipelines rather than application code. Moving one service at a time keeps risk low.
Is AKS more secure than App Service?
Not inherently. AKS offers more security controls, but they must be configured correctly. Managed platforms handle more security for you and leave fewer opportunities for configuration gaps.
What team size justifies Kubernetes?
There is no fixed number, but teams without someone who owns platform operations, typically fewer than ten developers, are usually better served by App Service or Container Apps unless a specific requirement demands Kubernetes.
Can we use more than one platform?
Yes, and many well-run Azure estates do. Place each workload on the platform that fits it, with consistent identity, networking, monitoring and cost management across them.
Related reading
More guidance for UK businesses from the Cloudswitched blog:
- Why Microsoft 365 native retention is not a backup
- AI integration architecture: connecting LLMs without a maintenance nightmare
- Database reporting security: controlling who sees what
- VoIP integrations: connecting your phone system to CRM and helpdesk
- Cyber Essentials scope: deciding what is in and out of your certification
The right platform, not the fashionable one
Cloudswitched helps UK businesses choose and run Azure compute platforms that fit their applications and their teams, from App Service and Container Apps to well-run AKS clusters.
Talk to an Azure Specialist
Cloudswitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
