Sizing and Scaling Container Apps and Instances

Optimize Resource Allocation for Container Workloads

When deploying containerized applications, resource allocation is the first step to balance application stability against running costs. In Azure Container Apps, developers must configure specific combinations of CPU and memory, ranging from 0.25 vCPUs to 4.0 vCPUs in the consumption plan. Selecting the correct sizing strategy helps prevent performance bottlenecks and ensures that organizations do not pay for unused computing power.

Azure Container Apps offers different workload profiles to match specific application requirements. The Consumption plan is ideal for serverless, rapid-scaling tasks, while Dedicated profiles provide specialized hardware for resource-intensive workloads. Selecting the right profile ensures that memory-heavy or compute-heavy tasks have the necessary resources to run efficiently.

• General Purpose: Balances compute and memory for standard workloads.
• Memory Optimized: Provides extra RAM for data-heavy applications.
• GPU Enabled: Supports high-performance compute for AI and machine learning tasks.

Specialized runtimes like Java require unique configurations because older Java Virtual Machine (JVM) versions might not automatically detect container boundaries. Using the MaxRAMPercentage flag ensures the JVM respects the memory allocated by Azure, which prevents Out-of-Memory (OOM) errors. Once the application is running, health probes monitor stability and dictate traffic flow:

• Liveness Probes: Determine if a container is unhealthy and needs to be restarted.
• Readiness Probes: Check if a container is fully prepared to accept network traffic.
• Startup Probes: Protect slow-starting applications from being killed prematurely.

Implement Dynamic Scaling Strategies for Azure Container Apps

Dynamic scaling allows Azure Container Apps to automatically adjust running instances in response to real-time traffic or system load. This is achieved through horizontal scaling, which scales out by adding container replicas or scales in by removing them. To power this process, the system relies on Kubernetes Event-driven Autoscaling (KEDA) to monitor external event sources and scale the containers accordingly.

Administrators configure scaling rules by specifying the minimum and maximum replica boundaries, such as setting a minimum of one replica and a maximum of ten replicas. These boundaries can be managed using the Azure CLI, ARM templates, Bicep, or the Azure portal. KEDA evaluates these rules and triggers scaling actions based on three main types of parameters:

• Event-driven triggers: Scale based on messages in Azure Service Bus, Event Hubs, Queue Storage, Cosmos DB, Kafka streams, or Timers.
• Resource-based triggers: Adjust replicas based on CPU or memory utilization.
• Time-based triggers: Use cron schedules to scale up or down at predetermined times.

When traffic drops, KEDA can scale applications down to zero replicas, which completely eliminates computing costs for idle workloads. However, when a new request arrives, it triggers a cold start, creating minor latency while the image pulls and the infrastructure provisions. To manage updates safely, developers use revision traffic splitting to route a percentage of traffic to new revisions, allowing for canary or blue/green deployments without causing application downtime.

Configure Scaling Policies for Azure Container Instances

Azure Container Instances (ACI) provide a fast and simple way to run isolated containers without the overhead of managing virtual machines or adopting complex orchestrators. Scaling in ACI focuses on defining clear policies based on workload demands to maintain both application responsiveness and cost efficiency. To manage this effectively, administrators must track performance metrics such as CPU utilization, memory usage, and network throughput.

To apply autoscaling policies to these container instances, administrators use Azure Monitor to set up automated rules. These rules react to changing resource demands or environmental patterns, helping to ensure the application remains cost-effective. These rules can be based on several different criteria:

• Metrics-based scaling: Triggers a scale-up action when a metric like CPU utilization exceeds a set threshold, such as 70%.
• Schedule-based scaling: Proactively adjusts the allocated resources during known peak business hours.
• Combination scaling: Merges metrics and schedule-based rules to optimize both performance and cost.

Maintaining an optimal state in ACI requires a continuous lifecycle of monitoring and adjustment. First, administrators define autoscale rules in the Azure portal or via the Azure CLI. Next, they monitor performance metrics to verify that the active rules are handling the workload correctly. Finally, they adjust resource allocations as needed to preserve the desired level of service.