2.2 KEDA Event-Driven Scaling in Container Apps

Event-driven scale on Container Apps

Once you can deploy revisions (§2.1), AI-200 expects you to scale them correctly. Azure Container Apps integrates KEDA—Kubernetes Event-driven Autoscaling—so a Container App can add or remove replicas based on events and external metrics, not merely “CPU went above 70%.” That model fits AI backends perfectly: HTTP inference APIs scale on concurrency; queue consumers scale on Service Bus depth; stream processors scale on Event Hubs partition lag; batch jobs scale up on a cron window and back down afterward.

You do not install KEDA yourself on ACA the way you would on a raw AKS cluster. You declare scale rules on the Container App; the platform wires KEDA-style scalers for you. Exam answers should talk about scale rules, replica limits, and scaler types, not about manually deploying the KEDA operator YAML.

Replicas, min, and max

Scale to zero is a hallmark of Container Apps + KEDA for asynchronous work. A document-ingestion worker can sit at 0 replicas overnight, then scale out when Service Bus messages arrive. For customer-facing HTTP APIs, min=0 can add cold-start latency; many teams set min=1 (or higher) for interactive endpoints and reserve min=0 for queue consumers.

Always set a max. Unbounded scale-out during a retry storm can exhaust budgets or overwhelm Cosmos/PostgreSQL connection pools. AI-200 scenarios that mention cost control or dependency protection are often hinting at max replicas (and sometimes queue prefetch/batch settings in the app code).

What a scale rule is

A scale rule tells Container Apps which signal to watch and how that signal maps to replica count. Conceptually each rule includes:

• A scaler type (HTTP, Azure Service Bus, Azure Event Hubs, cron, CPU/memory, custom/event sources, and others)
• Metadata (queue name, namespace, lag threshold, cron expression, concurrent requests target, etc.)
• Authentication references when the scaler must read Azure metrics or queue lengths (managed identity or secrets)

Multiple rules can exist on one app. The platform scales out based on the rule that demands the most replicas (the “highest wins” mental model). That means a cron rule requesting 5 replicas and a queue rule requesting 12 replicas yields at least 12 (subject to max).

HTTP scaling

For apps with ingress enabled, HTTP scale rules are the default story for APIs. Container Apps can scale based on the number of concurrent HTTP requests (and related HTTP load signals) per replica. If concurrency rises, KEDA adds replicas; when traffic falls, replicas drain after cooldown.

Exam contrast: HTTP scaling needs a request path. A pure Service Bus worker with ingress disabled should use a queue/stream scaler, not an HTTP concurrent-requests rule.

Azure Service Bus scaler

The Azure Service Bus scaler watches queue or subscription backlog. As messages accumulate, replica count rises so consumers drain the queue faster; as the queue empties, scale-in begins.

Typical metadata you should recognize conceptually:

• Queue name or topic/subscription identity
• Message count threshold that triggers additional replicas
• Connection via connection-string secret or identity-based access patterns supported by the platform

This scaler is ideal for AI pipeline stages: embed documents, generate summaries, fan out evaluations—each stage can be a Container App scaled by its queue depth.

Azure Event Hubs scaler

The Azure Event Hubs scaler targets streaming ingestion. Instead of “queue length,” think partition lag / unprocessed events. When producers write faster than consumers, lag grows and KEDA adds consumers (replicas). This fits telemetry, clickstream, or prompt-log processing where Event Hubs is the buffer.

Cron scaler

The cron scaler sets replica counts on a schedule (for example, maintain at least 8 replicas from 08:00–18:00 weekdays, then allow scale-down). Use cron when load is calendar-driven and you want capacity ready before the traffic spike—not only after queues grow.

Cron pairs well with event scalers: cron guarantees a morning floor; Service Bus still burst-scales if a backlog appears at noon. Remember max replicas still caps both.

Cooldown and scale-in behavior

Cooldown (scale-down delay) is the waiting period after load drops before replicas are removed. Without cooldown, a brief quiet second between bursts would shrink the app, then the next burst pays cold-start or ramp-up penalties—flapping.

On exam questions about “replicas keep oscillating” or “too aggressive scale-down,” look for cooldown / scale-in stabilization, not “delete the max replica setting.”

Designing scale for an AI backend

Scenario — Maya’s ranking API and embed worker

Maya runs two apps in one environment:

1. ranker-api — external ingress, min replicas 1, max 30, HTTP concurrent-requests rule. Users need low latency; cold start is unacceptable.
2. embed-worker — ingress disabled, min replicas 0, max 50, Azure Service Bus scaler on queue embed-jobs. Overnight cost should be near zero; daytime backlogs should drain fast.

She also adds a cron rule on ranker-api raising the floor to 5 replicas during a daily product launch window, while HTTP rules still handle surprise spikes. Event Hubs is reserved for a third app that tails product telemetry.

That design shows the AI-200 skill: match scaler to workload, set min/max deliberately, and use cooldown so scale-in does not undo scale-out during bursty AI traffic.

Implementation checklist

• Choose scaler type from the workload’s true bottleneck (HTTP vs queue vs stream vs schedule)
• Set min for latency vs cost tradeoff; set max for safety
• Provide scaler auth (secret/identity) so KEDA can read Azure metrics or queue lengths
• Verify ingress mode matches the scaler (HTTP needs ingress; workers often disable it)
• Watch scale behavior in metrics: replica count vs queue depth/lag/concurrency
• Tune cooldown if you see flapping

Common exam traps

• Using HTTP scaling on an ingress-disabled queue worker
• Leaving max replicas unset/unlimited in a cost-sensitive stem
• Expecting CPU-only autoscale to react to Service Bus backlog
• Confusing revision traffic split (deployment strategy) with replica scale-out (capacity)
• Forgetting that min=0 implies possible cold start on the next event/request

Master these KEDA patterns and you can implement event-driven Container Apps solutions confidently in Domain 1—then connect them to Service Bus/Event Hubs skills that also appear in Domain 3.