AKS and Azure Container Apps both run containers on Azure, but they target different needs and offer vastly different operational models.
Let’s see what happens when we deploy a simple web application to each.
First, AKS. Imagine you have a Kubernetes cluster already running.
# Create a deployment
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
EOF
# Create a service to expose it
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
name: my-nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer
EOF
Now, Azure Container Apps. This is a managed service, so we don’t manage nodes or Kubernetes itself.
# First, create a resource group and a container app environment
az group create --name my-container-apps-rg --location eastus
az containerapp env create --name my-container-app-env --resource-group my-container-apps-rg --location eastus
# Then, create the container app
az containerapp create \
--name my-nginx-app \
--resource-group my-container-apps-rg \
--environment my-container-app-env \
--image nginx:latest \
--target-port 80 \
--ingress external \
--query configuration.ingress.fqdn -o tsv
The core problem AKS solves is orchestrating containerized applications at scale, providing immense flexibility and control over your environment. It’s a powerful platform for complex, distributed systems where you need fine-grained control over networking, storage, scheduling, and more. You’re essentially managing a small cloud of Kubernetes nodes. This gives you the power to run stateful workloads, advanced networking policies, and custom scheduling.
Azure Container Apps, on the other hand, is built on Kubernetes but abstracts away most of that complexity. It’s designed for microservices and event-driven applications where you want to focus on your code, not infrastructure. It provides built-in capabilities like HTTP ingress, TCP ingress, scheduled jobs, and event-driven scaling (from zero to many replicas) without you needing to configure Kubernetes resources like Ingress controllers, Horizontal Pod Autoscalers, or KEDA. It’s a serverless container platform.
Here’s the mental model:
- AKS: You own and manage the Kubernetes cluster. This means you’re responsible for node scaling, OS patching, Kubernetes version upgrades, and configuring all the add-ons (like ingress controllers, cert-managers, etc.). You get maximum control and can run anything Kubernetes can run. Think of it as renting a data center and installing your own operating system and middleware.
- Azure Container Apps: Azure manages the underlying Kubernetes infrastructure for you. You deploy container apps, and Azure handles the scaling, networking, and platform updates. You focus on your application’s containers and their scaling rules. Think of it as a managed Kubernetes service where the "managed" part is significantly deeper, offering higher-level abstractions.
The key difference lies in the operational burden and the level of abstraction. With AKS, you’re a Kubernetes administrator. With Container Apps, you’re an application developer who happens to be using containers.
Container Apps’ event-driven scaling is a significant differentiator. You can configure an app to scale down to zero replicas when there’s no traffic and scale up automatically based on incoming events from sources like Azure Service Bus, Kafka, or even HTTP requests. This "scale to zero" capability is crucial for cost savings and efficient resource utilization for applications that have intermittent traffic.
The one thing most people don’t fully grasp is how Container Apps handles networking internally. While AKS exposes raw Kubernetes networking primitives (Services, Ingress, Network Policies), Container Apps uses a managed Envoy-based ingress controller and a custom networking layer that provides features like traffic splitting for blue-green deployments or A/B testing out-of-the-box, managed by Azure. You don’t see Kubernetes Ingress resources directly; you configure these capabilities through the Container Apps API or portal.
Next, you’ll likely explore how to integrate Container Apps with other Azure services for more complex event-driven architectures.