2.2 KEDA Event-Driven Scaling in Container Apps

Exam AI-200: Developing AI Cloud Solutions on Azure Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Audience Profile & Study Path

2 Chapter 1: Container Registry & App Service Hosting

1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service

3 Chapter 2: Azure Container Apps & KEDA Scaling

2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps

4 Chapter 3: AKS Manifests & Container Troubleshooting

3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps

5 Chapter 4: Cosmos DB for NoSQL Fundamentals

4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels

6 Chapter 5: Cosmos DB Vectors & Change Feed

5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items

7 Chapter 6: Azure PostgreSQL Foundations for AI

6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead

8 Chapter 7: PostgreSQL Vector Workloads & RAG

7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency

9 Chapter 8: Azure Managed Redis for AI Solutions

8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search

10 Chapter 9: Service Bus & Event Grid for AI Pipelines

9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows

11 Chapter 10: Azure Functions for Serverless AI Back Ends

10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps

12 Chapter 11: Key Vault & App Configuration

11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings

13 Chapter 12: OpenTelemetry & KQL Observability

12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios

2.2 KEDA Event-Driven Scaling in Container Apps

Key Takeaways Explain This Topic AI

Azure Container Apps uses KEDA (Kubernetes Event-driven Autoscaling) under the hood so scale rules can react to events and metrics—not only average CPU.

Min replicas can be 0 for true scale-to-zero on event-driven workers; max replicas caps cost and protects downstream dependencies.

HTTP scale rules use concurrent request (or related HTTP) signals; queue/stream scalers such as Azure Service Bus and Azure Event Hubs scale from backlog depth or lag.

Cron scalers schedule replica floors for known busy windows; combine them thoughtfully with event scalers for hybrid traffic patterns.

Cooldown / scale-down behavior prevents flapping: after scale-out, Container Apps waits before removing replicas so short traffic dips do not thrash capacity.

Last updated: July 2026

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

Setting Meaning Exam tip

Min replicas Lower bound of running replicas 0 enables scale to zero when idle (great for workers); use 1+ when you need always-warm HTTP latency

Max replicas Hard cap on scale-out Protects cost and downstream quotas (OpenAI TPM, DB connections)
Replica One running instance of the active revision Scale rules change this count

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.

HTTP scaling idea Practical meaning
Concurrent requests target Aim for N in-flight requests per replica before scaling out
External vs internal ingress Both can generate HTTP scale signals when traffic flows through ingress
Min replicas > 0 Avoids cold start on the first request after idle

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.

Scaler Primary signal Best workload fit
HTTP Concurrent requests / HTTP load Synchronous APIs, webhooks
Service Bus Queue/subscription message count Competing consumers, durable commands
Event Hubs Lag / unprocessed events Streaming partitions, telemetry
Cron Time schedule Predictable peaks, business hours
CPU / memory Resource utilization Steady compute-bound work
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 .

Phase What happens
Scale-out Rules see high signal → replicas increase quickly toward demand (up to max)
Steady Signal matches capacity → replica count holds
Cooldown window Signal drops → platform waits before scale-in
Scale-in Extra replicas shut down gradually toward min

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:

ranker-api — external ingress, min replicas 1 , max 30 , HTTP concurrent-requests rule. Users need low latency; cold start is unacceptable.

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.