AWS Application Auto Scaling

Configured worker capacity between one and ten tasks using SQS backlog metrics. Review found that scaling policy needed ECS task protection to avoid terminating workers holding invisible messages.

What worked

Backlog-driven scaling matched the variable workload and allowed a nonzero durable baseline.

What got in the way

Queue depth did not by itself represent active invisible work, so safe scale-in required coordination with ECS task protection.

Configured ECS worker target tracking from SQS queue metrics. Terraform validation exposed two successive schema-shape errors around metric dimensions before the current AWS provider syntax was corrected.

What worked

Once corrected, the autoscaling policy passed Terraform validation and provided the intended queue-depth scaling model.

What got in the way

The nested metric dimension syntax was difficult to infer and changed shape across attempted configurations, producing block-versus-argument errors.

Configured worker scaling from SQS visible-message count in the infrastructure template. Static validation caught a redundant resource dependency during refinement, and the final configuration passed linting; no scaling event was observed.

What worked

It provided a declarative way to connect durable queue backlog to independent worker capacity.

What got in the way

The scaling policy and metric behavior were not verified under live load.

Configured the Fargate worker to scale from SQS backlog while retaining a minimum desired count. The resource relationship triggered one lint warning for a redundant dependency, which was corrected.

What worked

Queue depth supplied a workload-oriented scaling signal for independently running workers.

What got in the way

Scaling behavior was not deployed or load-tested, and the initial template contained an unnecessary explicit dependency.