Skip to content

Event Scalers in Azure Container Apps

Event scalers are the primary fit for worker-style apps where pending work exists outside the HTTP request path. Azure Container Apps implements these through KEDA-backed custom scale rules.

Event-driven rule pattern

The common rule shape is:

template:
  scale:
    minReplicas: 0
    maxReplicas: 30
    rules:
      - name: worker-rule
        custom:
          type: <keda-scaler-type>
          metadata:
            <key>: <value>
          auth:
            - secretRef: <secret-name>
              triggerParameter: <parameter-name>

flowchart TD
    A[Queue or event backlog grows] --> B[KEDA custom scaler polls source]
    B --> C[Desired replica count rises]
    C --> D[Worker revision scales out]
    D --> E[Backlog drains]
    E --> F[Scale in toward minReplicas]

Supported event-scaler families

Event source Scaler type Learn-confirmed metadata/auth details Notes
Azure Service Bus azure-servicebus queueName, namespace, messageCount, auth mapping for connection Learn provides explicit examples
Azure Queue Storage azure-queue accountName, queueName, queueLength, secret or managed identity examples Covers Azure Storage Queue workloads
Azure Event Hubs Event Hubs via KEDA custom rule Source family is documented, but current Learn page does not include a full Azure Container Apps metadata example Validate exact metadata before production
Apache Kafka Kafka via KEDA custom rule Source family is documented, but current Learn page does not include a full Container Apps metadata example Validate exact metadata before production

Service Bus example

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --min-replicas 0 \
  --max-replicas 30 \
  --scale-rule-name "servicebus-orders" \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata "queueName=orders" "namespace=$SERVICEBUS_NAMESPACE" "messageCount=25" \
  --scale-rule-auth "connection=servicebus-connection"
Command Purpose
az containerapp update Adds an event-driven scale rule to the app so replica count responds to Service Bus backlog instead of fixed manual scaling.
--min-replicas 0 / --max-replicas 30 Defines the lower and upper scale bounds, allowing scale-to-zero savings while capping burst expansion.
--scale-rule-type azure-servicebus with --scale-rule-metadata ... Selects the Service Bus scaler and specifies the queue, namespace, and backlog threshold that should trigger more replicas.
--scale-rule-auth "connection=servicebus-connection" Tells the scaler which secret-backed connection setting to use when authenticating to the queue.

Azure Queue Storage example

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --min-replicas 0 \
  --max-replicas 40 \
  --scale-rule-name "storagequeue-ingest" \
  --scale-rule-type azure-queue \
  --scale-rule-metadata "queueName=ingest" "queueLength=50" "accountName=$STORAGE_ACCOUNT" \
  --scale-rule-auth "connection=storage-connection"
Command Why it is used
az containerapp update ... Updates the existing Container App configuration without recreating the app.

Identity options

Microsoft Learn documents two common patterns:

  • Secret-based auth using secretRef mappings for trigger parameters such as connection
  • Managed identity using the identity field for supported scalers

Example managed identity shape from Learn:

{
  "type": "azure-queue",
  "metadata": {
    "accountName": "<storage-account>",
    "queueName": "<queue-name>",
    "queueLength": "1"
  },
  "identity": "system"
}

Conservative guidance for Event Hubs and Kafka

Full metadata examples specific to Container Apps for Event Hubs and Kafka are not currently enumerated in Microsoft Learn

Microsoft Learn confirms these event-source families are supported through KEDA-backed scaling, but the current page does not provide the complete metadata key sets in the way it does for Service Bus and Azure Queue. Validate exact metadata against the current scaler contract before production rollout.

Portal view: Scale blade (revision without the event-scaler scale-to-zero pattern)

Scale blade for a Container App with a "Based on revision" dropdown selected, an "Edit and deploy" command, a "Scale rule settings" section, a "Min / max replicas" row with value "1 - 3", and a "Scale rules" section stating "There are no scaling rules defined for this revision".

[Observed] On the selected Scale tab, the Scale rule settings section shows a Min / max replicas row with the value 1 - 3. The Scale rules section shows the empty-state message There are no scaling rules defined for this revision. No row labeled azure-servicebus, azure-queue, or any other KEDA scaler type is visible inside the Scale rules section.

[Inferred] The Min / max replicas lower bound rendered as 1 is consistent with this page's framing of event-scaler revisions as a different shape from what this image shows, since the Event-driven rule pattern YAML and the Service Bus example and Azure Queue Storage example all set minReplicas: 0 / --min-replicas 0. The empty Scale rules section header is consistent with the Supported event-scaler families table that lists scaler type values (such as azure-servicebus and azure-queue) as entries that would appear inside this section once added.

[Not Proven] This image does not show any azure-servicebus, azure-queue, Event Hubs, or Kafka rule configured, and the queueName, namespace, messageCount, accountName, or queueLength metadata fields shown in the examples above are not visualized here. It does not show any secretRef, connection, or identity field corresponding to the Identity options section. It does not show the Edit and deploy panel.

See Also

Sources