[300bps]

I always say the best way to learn a new technology is to work on a real-world project that you are interested in.

The person that set this up got an amazing education on use of real-world AWS services.

A lot of IT people aren't aware that things like this exist. They think moving to the cloud means sending all your virtual servers to your provider of choice and running them 24x7 like you did on-prem. In my opinion it's more about architecting solutions so that resources pop into existence for the exact # of milliseconds they're needed and then they're released. This is a clever step along that path.

[Aeolun]

Most people that move a whole set of on-prem machines to virtual servers actually need them on and available all day long.

[300bps]

What you're saying is true for a tiny minority of use cases.

The vast majority of use cases are better off with variable resource availability. Unless you're doing something akin to mining cryptocurrency 24x7x365 most workloads are variable to some degree.

So maybe instead of one giant server that processes requests you use a single small server that is available 24x7x365. Then if your workload increases at 8 am you use an autoscaling group to spin up 3 more. Then at 5 pm it goes back down to 1. And maybe you have a batch process that kicks off at 2 am every night so you spin up 4 servers to process requests. This is just one example so it's important not to focus on it and respond with, "Well what about x!" AWS has many ways to fulfill the promise of accomplishing tasks with minimal resources.

And all of this is just a step on the path to serverless computing with things like Lambda and DynamoDB or serverless RDS.