Scaling Azure Container Apps with HTTP, CPU, and Memory Rules

The Fundamentals of Scaling in Azure Container Apps

Azure Container Apps handles automatic horizontal scaling by adding or removing instances of your application. These instances are called replicas. The scaling process is governed by a set of declarative rules you define.

To get a solid grasp of these core concepts, let's start with a short video.

As the video explained, scaling in Azure Container Apps is defined by a few key elements:

• Replicas: Instances of your container app. More replicas mean more capacity to handle load.
• Scale Limits: You define the minimum and maximum number of replicas your app can scale between. Setting the minimum to 0 enables "scale to zero" for cost savings when the app is idle. Setting it to 1 or higher ensures at least one instance is always running, which can prevent "cold starts".
• Scale Rules: These define the criteria for when to add or remove replicas.

Azure Container Apps supports three main categories of scale rules:

1. HTTP traffic: Scales based on the number of concurrent requests.
2. CPU or Memory usage: Scales based on resource utilization.
3. Custom (Event-driven): Scales based on various event sources like messages in a queue (e.g., Azure Service Bus, Azure Queue Storage) or events from Azure Event Hubs. This is powered by KEDA (Kubernetes Event-driven Autoscaling) under the hood.

Today, we will focus on the first two categories: HTTP and CPU/Memory, as they are fundamental and frequently tested.

Configuring HTTP-Based Scaling

The most common scenario for a web application is to scale based on incoming traffic. You can configure a rule that adds replicas when the number of concurrent HTTP requests per replica exceeds a certain threshold.

Visual Configuration in the Azure Portal

The Azure Portal provides an intuitive way to visualize and set up scaling rules.

When you edit a revision, you can navigate to the Scale tab to add a rule.

As you can see, you give the rule a name, select "HTTP Scaling" as the type, and set the Concurrent requests threshold. For example, setting it to 100 means a new replica will be added for every 100 concurrent requests the app is handling.

Configuration with the Azure CLI

For automation and consistency, the Azure CLI is the preferred method. In the last lesson, you used az containerapp up. To modify an existing app, you'll use az containerapp update.

The command to add an HTTP scale rule looks like this:

az containerapp update \
  --name my-dotnet-app-aca \
  --resource-group <YourResourceGroupName> \
  --min-replicas 1 \
  --max-replicas 5 \
  --scale-rule-name http-scale-rule \
  --scale-rule-http-concurrency 50

This command updates your container app to:

• Scale between 1 and 5 replicas.
• Use a rule named http-scale-rule.
• Trigger a scale-out action when concurrent requests exceed 50 per replica.

Testing and Verifying HTTP Scaling

To see scaling in action, you need to generate load. While professional tools exist, you can simulate load with simple command-line tools.

After sending a burst of requests, you can go to your container app in the Azure Portal, navigate to Monitoring > Metrics, and select the Replica Count metric. You will see a graph showing your app scaling out to handle the load and then scaling back in after the traffic subsides.

Configuring CPU and Memory-Based Scaling

For applications whose load isn't directly correlated with HTTP requests (like background jobs performing intensive computations), scaling based on CPU or memory usage is more appropriate.

A crucial point to remember for the exam: CPU and memory-based scale rules do not support scaling to zero. You must set a minimum replica count of at least 1.

Configuration with the Azure CLI

You can add CPU or memory scaling rules using a similar az containerapp update command, but with a different rule type and metadata.

To add a CPU scaling rule:

This rule will scale out the app if the average CPU utilization across all replicas exceeds 70%.

az containerapp update \
  --name my-cpu-bound-app \
  --resource-group <YourResourceGroupName> \
  --min-replicas 1 \
  --max-replicas 4 \
  --scale-rule-name cpu-scale-rule \
  --scale-rule-type cpu \
  --scale-rule-metadata "type=Utilization value=70"

To add a memory scaling rule:

This rule will scale out the app if the average memory usage across all replicas exceeds 70%.

az containerapp update \
  --name my-memory-intensive-app \
  --resource-group <YourResourceGroupName> \
  --min-replicas 1 \
  --max-replicas 4 \
  --scale-rule-name memory-scale-rule \
  --scale-rule-type memory \
  --scale-rule-metadata "type=Utilization value=70"

You can have multiple scale rules defined for a single container app. The first rule to have its condition met will trigger the scaling action.

Conclusion

Excellent work! You now understand how to implement automatic scaling in Azure Container Apps, a fundamental skill for building resilient and cost-effective cloud-native applications.

Let's summarize the key takeaways:

• Horizontal Scaling: ACA scales by changing the number of replicas (instances) of your application.
• Scale Rules: Scaling is driven by rules based on triggers like HTTP concurrency, CPU utilization, or memory usage.
• Scale Limits: You always define a minimum and maximum number of replicas.
• Scale to Zero: Only certain rule types, like HTTP, allow you to scale to zero replicas. CPU and memory-based scaling require a minimum of at least one replica.
• Configuration: The az containerapp update command is the primary tool for scripting and automating the configuration of scale rules.
• Revisions: Remember that any change to a container app's scaling configuration creates a new, immutable revision.

In our next lesson, we will explore the concept of revisions more deeply. You will learn how to manage multiple revisions and use them to implement strategies like blue-green deployments and A/B testing for safer application updates.