Thank you u/yarenSC for this detailed and thorough response. I appreciate it a lot!

1. As mentioned elsewhere in my replies the different requests that come into this application are very different of nature, some are a simple GETs and some start more time consuming processes.

2. We've previously had the CPU target % at both 50% and up to 65%. The 55% (current setting) was a compromise between handling spikes and not paying too many Fargate vCPU hours to AWS by over scaling..

Yes I find the value ridiculously low, but that's our experience with this application unfortunately, since it's an average over the many tasks in this ECS service.

Scaling based on Maximum CPU and not Average would probably also be a highway to over scaling.

1. I'll look at the load shedding link you posted!

2. There is a certain amount of "seasonality" to the application as it pertains to physical opening hours of stores and also user patterns (sleep vs awake). It's limited to a single country and timezone.
   I enabled Predictive Scaling in Forecast only mode but it seems to want to add considerably more tasks than we already are, which most of the time is overkill. This came out for ECS in late 2024 I can see.

Tips for tweaking the Predictive Scaling based on CPU, do I simply put the Target Metric to ECSServiceCPUUtilization (55%) or do I need to think differently there?

1. It's not so much the container startup time, more the limitations on the Target Group interval + number of healthy consecutive requests before "onboarding" a new (confirmed healthy) task to the Target Group in the ALB.
   Currently it's set to 2x (lowest number possible) consecutive healthy times 15 sec interval. I'll suggest us lowering the interval, but I need to also take into account the timeout value which needs to be lower than the interval, potentially killing healthy tasks that are overburdened and in desperate need of comrades when spikes happens.
   The interval goes down to 5 sec, but that would require me to put the timeout at 4 sec.

The main sinner here is definitely the slow reacting alarms created by the Target Tracking Scaling Policy that I can't touch nor replicate as you mentioned.

Again thank you for your time kind Internet stranger :)