ECS Autoscaling Mistakes To Avoid

10 min read

ECS autoscaling should handle traffic changes without you thinking about it. In practice, most teams end up babysitting their scaling policies, overprovisioning to avoid incidents, or discovering cost spikes weeks after they started. The root cause is rarely a misconfiguration — more often, teams are applying static scaling rules to workloads that change behavior with every release.

This guide covers the most common ECS autoscaling mistakes seen in production & how to fix them before they become expensive.

In this article:

How Does ECS Autoscaling Work?

ECS autoscaling operates at two layers, and most scaling problems come from misunderstanding how they interact.

Service autoscaling adjusts the desired task count for an ECS service based on CloudWatch metrics. You configure it through Application Auto Scaling with one of three policy types:

Target tracking maintains a specific metric value (e.g., keep average CPU at 60%). ECS adds or removes tasks to hold that target.
Step scaling triggers discrete task count changes at defined thresholds, giving you more control over how aggressively the service responds.
Scheduled scaling adjusts min/max capacity on a fixed schedule for predictable traffic patterns like business hours or seasonal peaks.

Cluster autoscaling manages EC2 instances through capacity providers. When ECS can't place new tasks because the cluster is full, the capacity provider signals the underlying Auto Scaling Group to add instances. This layer only reacts to placement failures — it does not increase your service's desired count.

One detail that catches teams off guard: ECS publishes metrics to CloudWatch at one-minute intervals. The autoscaler then needs additional time to evaluate the alarm, calculate the response, & provision new tasks. That end-to-end lag means scaling decisions always trail real-time demand.

Common ECS Autoscaling Mistakes

Scaling on the Wrong Metric

The most frequent mistake is scaling on CPU when the workload is memory-bound, or vice versa. CPU and memory utilization are the default CloudWatch metrics, and most teams pick one without load testing first to determine which resource actually saturates under pressure.

Consider a service that processes file uploads. Memory grows with each concurrent upload, but CPU stays relatively flat. A CPU-based scaling policy would never trigger, even as the service runs out of memory and starts killing tasks. The fix is straightforward but often skipped: run a load test, identify which resource depletes first, & scale on that metric.

For services that consume both resources unevenly, configure dual target tracking policies. ECS handles the interaction correctly. It scales out when either metric breaches the target but only scales in when both metrics agree it's safe.

Ignoring Cooldown Periods

Short cooldown periods cause scaling oscillation. The service scales out, metrics drop, it immediately scales back in, metrics spike again, & the cycle repeats. We see this most often with scale-in cooldowns set below 300 seconds: short enough that the service sheds capacity before the traffic lull is confirmed.

A good starting point: keep scale-out cooldowns short (60 seconds) so you respond quickly to traffic increases, and keep scale-in cooldowns longer (300 to 600 seconds) so you don't prematurely shed capacity during temporary lulls. These values should be tuned based on your traffic patterns, not left at defaults.

Setting Capacity Limits Too Tight

Teams frequently set max capacity too low to "control costs" and end up throttling their own services during traffic spikes. The better cost control is a well-tuned scaling policy combined with reasonable maximums, not an artificially low ceiling that causes outages.

On the other end, setting min capacity too low (especially to 1) means a single task failure takes down the service entirely. For anything production-critical, a minimum of 2 tasks across availability zones provides basic fault tolerance.

Confusing Service Scaling With Cluster Scaling

This is one of the most common misunderstandings. Capacity providers manage EC2 instances. Service autoscaling manages task counts. They serve different purposes, and one does not replace the other.

We see teams configure capacity providers and assume their services will scale with demand. They won't. Capacity providers only respond when ECS can't place tasks. If your service desired count never changes, the cluster never needs to grow.

You need both layers configured: service autoscaling to adjust task counts based on load, and capacity providers to ensure the cluster has room for those tasks.

Understand ECS Autoscaling Mistakes

See how Sedai explains ECS autoscaling mistakes in 2026 for scale, control & operational efficiency.

Why ECS Autoscaling Fails Under Real-World Conditions

The mistakes above are configuration issues. The deeper problem is that ECS autoscaling was designed around static thresholds, and real workloads aren't static.

Releases Change Resource Profiles

Every deployment can shift how your service consumes resources. A code change that introduces a new caching layer might cut CPU usage by 30%, making your existing scaling thresholds too aggressive. A dependency upgrade might increase memory consumption per request, causing memory-based policies to trigger earlier than expected.

Most teams don't re-evaluate their scaling policies after every release. The result is a gradual drift between what the autoscaler expects and how the application actually behaves. Over weeks and months, this drift compounds into either chronic overprovisioning (wasting budget) or underprovisioning (degrading performance).

CloudWatch Lag Creates Blind Spots

ECS reports metrics to CloudWatch once per minute. The autoscaler evaluates those metrics, waits for alarm thresholds to breach, applies cooldown logic, & then initiates task changes. End to end, you're looking at 2 to 5 minutes — an eternity for services with sub-second latency requirements.

The standard workaround is to overprovision (run more baseline capacity than you need), which keeps the service safe but quietly inflates costs. Mis-sized containers & oversized resources account for roughly 8 to 12% of unnecessary cloud spend across most organizations running ECS.

Deployments Disrupt Scaling Behavior

AWS suspends scale-in during ECS deployments but allows scale-out to continue. That asymmetry creates a predictable cost spike with every release.

During a rolling deployment with the default minimumHealthyPercent: 100 and maximumPercent: 200, ECS temporarily runs both old & new task sets simultaneously. As a result, the task count can effectively double during the switchover. That spike in running tasks can trigger capacity provider scale-out at the cluster level — launching EC2 instances you don't actually need for steady-state traffic.

After deployment completes, the excess capacity lingers until scale-in cooldowns expire. If you deploy multiple times per day, the overprovisioning window never fully closes. Blue/green deployments amplify this further because the entire replacement task set runs alongside the original until traffic is switched.

The practitioner fix is to lower your capacity provider target capacity to 80-90% so the cluster has headroom to absorb deployment spikes without launching new instances. You can also extend scale-in cooldowns during deployment windows or use deployment circuit breakers to limit how long the overlap persists. But these are manual guardrails — they don't adapt to how each service's resource profile changes from release to release.

Single-Metric Scaling Misses Compound Problems

Real performance degradation is rarely caused by one metric crossing a threshold. A latency-sensitive payment service might show normal CPU & memory utilization while response times climb because of I/O contention, connection pool exhaustion, or downstream dependency slowdowns. Scaling on CPU or memory in that scenario adds tasks that don't address the bottleneck — increasing cost without improving performance.

The native ECS autoscaling framework supports custom CloudWatch metrics, which partially addresses this. But building, publishing, & maintaining custom metrics for every service is operational overhead that scales poorly across dozens or hundreds of services.

How to Fix Your ECS Autoscaling Configuration

If your ECS autoscaling is underperforming, start with these steps:

Load test every service individually. Identify which resource (CPU, memory, or a custom metric) saturates first under realistic traffic. Scale on that metric.
Audit cooldown periods. Scale-out cooldowns should be 60 seconds or less. Scale-in cooldowns should be 300 seconds or more. Adjust based on your service's startup time and traffic volatility.
Set capacity limits that match reality. Max capacity should accommodate your highest realistic traffic peak with headroom. Min capacity should keep services fault-tolerant across availability zones.
Use dual target tracking for mixed workloads. If your service consumes both CPU and memory unevenly, configure separate target tracking policies for each. ECS coordinates them so scale-out is aggressive (either metric can trigger it) &scale-in is conservative (both must agree).
Combine scheduled scaling with target tracking. If your traffic follows predictable patterns (business hours, weekly cycles, seasonal peaks), use scheduled scaling to pre-position capacity. Let target tracking handle the fine-tuning within those windows. For a deeper look at how autonomous optimization handles this continuously, see our guide on mastering autonomous optimization for Amazon ECS.
Revisit scaling policies after every major release. Resource consumption profiles change with code changes. A scaling policy that was optimal three months ago may be overprovisioning or underprotecting today.

These steps will improve your autoscaling significantly. But they're still manual, periodic adjustments in an environment that changes continuously. The services that stay optimized are the ones where scaling adapts to workload behavior in real time, not on a quarterly review cycle.

How Can Sedai Help You With ECS Autoscaling?

The core challenge with ECS autoscaling is that it reacts to symptoms, not workload behavior. Thresholds drift as traffic, releases, and infrastructure change, and keeping them tuned manually across services becomes unsustainable.

Sedai takes a different approach. It continuously learns how each service behaves and autonomously adjusts scaling, rightsizing, and policies based on real application data, balancing cost, performance, and availability as conditions evolve.

Palo Alto Networks, running thousands of ECS services at scale, used this approach to execute over 89,000 production changes autonomously and save $3.5M in cloud costs. Their scaling configurations stay current without engineers manually re-tuning after each deployment.

If your team is spending time tuning ECS autoscaling policies that keep drifting, or overprovisioning because you can't afford the risk of getting it wrong, see how Sedai's platform handles it.

FAQs

What is the best ECS autoscaling metric for web services?

For most HTTP-based services, ALB request count per target is more responsive than CPU utilization because it scales on actual demand rather than resource consumption. Combine it with a CPU target tracking policy as a safety net so the service also scales when compute-bound processing drives up utilization independent of request volume.

How do I prevent ECS scaling oscillation?

Scaling oscillation happens when scale-in cooldowns are too short. Set scale-in cooldowns to at least 300 seconds & scale-out cooldowns to 60 seconds or less. If you use dual target tracking policies for CPU &memory, ECS will only scale in when both metrics agree, which naturally reduces oscillation without additional configuration.

Should I use ECS Fargate or EC2 for autoscaling?

Fargate simplifies autoscaling because you skip cluster capacity management entirely. You only configure service autoscaling, and AWS handles the compute. The tradeoff is cost: Fargate is more expensive for steady, predictable workloads. A common pattern is to run baseline capacity on EC2 (or EC2 with Spot) & burst to Fargate for unpredictable spikes using mixed capacity provider strategies.

How does ECS autoscaling behave during deployments?

AWS suspends scale-in during ECS deployments but allows scale-out to continue. Rolling deployments with default settings can temporarily double your running task count, triggering unnecessary cluster scale-out. To limit this, lower your capacity provider target capacity to 80-90% & consider extending scale-in cooldowns during deployment windows so you have a controlled window for scale-in rather than oscillation