Autoscaling is not just about scaling. It’s also about high availability.

I have two or three ASGs up with a minimum and maximum of two and an HTTP health check that will kill an instance if the health check doesn’t pass and bring up another one.

I also have applications that autoscale based on queue sizes.

Auto scaling means you will be provisioning the server on the fly when needed which manes names, IP addresses are not important.

Scenario I am referring to involves application team closely guarding their servers like babies which means they are married to server names and IP addresses. These are cloned from on-premises and load balancing is just sticky sessions going to one node with other one sitting idle until first one fails.

And that’s a bad design. The limit of the amount of times that I will get up in the middle of the night because of a non redundant, non HA process is one before I put that on the top of the list to redesign the architecture (not the program necessarily).

I know but that's how risk averse people at large companies behave. They are a) they lack understand and b) risk averse because risk reward ratio is high.

First group is rare.

I think auto-scaling is only really relevant to 12-factor-style stateless applications. Otherwise you have to do sticky sessions, and that complicates things considerably, and isn't even a silver bullet.

Even with on prem solutions, I would hope that most websites are behind a load balancer with at least two instances. Storing session state on the web server hasn’t been something that I’ve ever done and I have been developing websites since at least 2002.

Legacy applications may not be websites, and might be stateful (or so I am told).

But how many store data locally as opposed to in a database? Even for stateful applications, if you have the source code, you could put an http listener on it for your target group to ping as a health check and put your data on FSx. If the app became unhealthy, kill the server and bring a new instance up. Have a minimum and maximum of one.

I wouldn’t go that far though. I would probably use something like Consul to do a local health check first and restart the app if it dies and then do the target group/health check as a second level check.

I was thinking more like some off-the-shelf solution purchased years ago that is something of a black box to those that operate it... subtle failure modes, lack of instrumentation, and opaque inner state.

Agreed but IT bosses just picks up these keywords and start throwing them around as benefits of cloud. Heck I had a CIO getting excited about moving to micro services when his entire landscape had only COTS application.