Azure Container Apps and KEDA

Azure Container Apps is a fully managed serverless container platform that runs on top of Azure Kubernetes Service (AKS) but abstracts away the Kubernetes control plane. You define containers, ingress, and scaling rules declaratively, and Azure handles the underlying infrastructure. It is designed for microservices, API endpoints, and event-driven workloads. Unlike AKS, you do not manage nodes, pods, or the Kubernetes API directly. Container Apps is ideal for scenarios where you want container orchestration without operational overhead.

KEDA (Kubernetes Event-Driven Autoscaling) is an open-source project that extends Kubernetes to scale workloads based on events from external sources like Azure Service Bus, Event Hubs, Kafka, Redis, and many more. KEDA works with both Kubernetes Horizontal Pod Autoscaler (HPA) and Azure Container Apps. In Container Apps, KEDA is built-in and allows you to scale your container app replicas based on metrics like queue length, message count, or custom Prometheus metrics. KEDA consists of two components: - Scaler: A component that connects to an external source (e.g., Service Bus) and retrieves metrics. - Operator: A component that activates or deactivates the HPA based on scaler metrics.

KEDA operates in a pull-based model. Here is the step-by-step mechanism:

To configure KEDA in Azure Container Apps, you define a scale rule in the Container Apps resource. Example ARM template snippet:

{
  "properties": {
    "template": {
      "scale": {
        "minReplicas": 0,
        "maxReplicas": 10,
        "rules": [
          {
            "name": "servicebus-queue",
            "custom": {
              "type": "azure-servicebus",
              "metadata": {
                "queueName": "myqueue",
                "namespace": "mynamespace",
                "messageCount": "10"
              },
              "auth": [
                {
                  "secretRef": "servicebus-connection-string",
                  "triggerParameter": "connection"
                }
              ]
            }
          }
        ]
      }
    }
  }
}

To verify scaling behavior, use Azure Monitor metrics:

az monitor metrics list --resource <container-app-id> --metric "ReplicaCount" --interval 5m

A large e-commerce company processes millions of orders daily. Orders are placed via web and mobile apps, then pushed to an Azure Service Bus queue. A containerized order processor runs on Azure Container Apps. The processor must scale from zero during low traffic (e.g., 2 AM) to hundreds of instances during Black Friday. Using KEDA with the Service Bus scaler, the team sets target message count to 10 per replica. During peak, the queue depth reaches 50,000, so KEDA scales to 5,000 replicas (max set to 10,000). The cooldown is set to 5 minutes to avoid scaling down during brief lulls. A common mistake is forgetting to assign a managed identity to the Container App for accessing Service Bus; without it, KEDA fails to authenticate and scales to zero. The team uses Azure Monitor to track ReplicaCount and QueueDepth metrics. They also set up alerts if the queue depth exceeds 100,000 for more than 5 minutes.

A financial services firm ingests stock market data from multiple exchanges into Azure Event Hubs. Each partition of the Event Hub corresponds to a stock symbol. They deploy a containerized analytics app on Container Apps that processes each event. With KEDA's Event Hubs scaler, the app scales based on the number of unprocessed events per partition. The scaler uses the Event Hubs checkpoint store (Azure Blob Storage) to track progress. The team sets the polling interval to 10 seconds for near-real-time scaling. A common issue is that the checkpoint store is in a different region, causing latency and stale metrics. They mitigate this by colocating the storage account in the same region as the Container Apps environment. They also configure maxReplicas to 200 to avoid overwhelming downstream databases.

A media company transcodes videos uploaded by users. Uploads are placed in a RabbitMQ queue. They run a containerized transcoder on Container Apps with KEDA's RabbitMQ scaler. The scaler queries the RabbitMQ management API for queue length. The team sets target to 1 message per replica because transcoding is CPU-intensive. They also set a cooldown of 10 minutes to avoid scaling down during a batch upload. A pitfall is that the RabbitMQ scaler requires the management plugin to be enabled; without it, KEDA cannot retrieve metrics. They also discovered that if the queue has many unacknowledged messages, the scaler counts them as well, leading to over-scaling. They mitigated by using a separate queue for dead letters.