“Nothing is built on stone; All is built on sand, but we must build as if the sand were stone.”
Jorge Luis Borges
Every time facing a task of configuring how the system should scale out and scale in, we decide what metrics and policies will be more effective. But what if this is not an option, i.e. the service is represented by legacy application, written years ago, not well documented, etc. and we still want to run it and autoscale? I have already described CPU based policies and what challenges they may have so that ideally would be to check the configuration and fix the possible root cause.
Nowadays a lot of companies decide to work from home due to quarantine. For many people work from home sounds like a paradise - freedom, no traffic issues to get to the office and back home, the opportunity to focus on the tasks and relax whenever you want. Yes, all this is true, but a lot of people do not have an experience of working from home so freedom and independence may come with a big price to pay, so that the paradise may turn into hell.
In many cases, custom metrics may be useful to make more ad-hoc configuration of autoscaling in AWS. For example, a custom metric can allow an autoscaling group to react more rapidly on spikes or to take into account the health state of hosts for concurrency based metrics. ActiveConnectionCount per Healthy Host metric may be helpful to scale in an application, that may stop to respond to health-checks if it is fully loaded. In general, this metric may be used both to rapidly react on spikes, regardless of application type and may be more effective than CPU based and RequestPerHost metrics.