I’ve seen scripts (though I don’t have links handy) that do this based on no active logins and no CPU load for X minutes as well. On the other tack, I’ve seen a lot of one-off processes that trigger a shutdown when they complete (and write their output/logs to S3 or somewhere durable). Often a Lambda is used for the control plane—it responds to signals and runs outside the actual host.
I like this idea a lot, but I’m nervous about setting the right CPU threshold. Too low and it never shuts off, too high and it shuts down in the middle of something when waiting for a slow download. But possibly if I looked at load logs I’d see it’s so clearly either ~zero or >>zero that it’s not fussy?
The rabbit hole can go deep, and probably isn’t worth getting too fancy for single-digit hosts. Fleets of thousands of spot instances benefit from the effort. Like everything, dev-time vs runtime-complexity vs cost-efficiency is a tough balance.
When I was doing this often, I had different modes for “dev mode, which includes human-timeframe messing about” and “prod mode”, which was only for monitored workloads. In both cases, automating the “provision, spin up, and initial setup”, as well as the “auto-shutdown if not measurably used for N minutes (60 was my default)” with a one-command script made my life much easier.
I’ve seen scripts (though I don’t have links handy) that do this based on no active logins and no CPU load for X minutes as well. On the other tack, I’ve seen a lot of one-off processes that trigger a shutdown when they complete (and write their output/logs to S3 or somewhere durable). Often a Lambda is used for the control plane—it responds to signals and runs outside the actual host.
I like this idea a lot, but I’m nervous about setting the right CPU threshold. Too low and it never shuts off, too high and it shuts down in the middle of something when waiting for a slow download. But possibly if I looked at load logs I’d see it’s so clearly either ~zero or >>zero that it’s not fussy?
The rabbit hole can go deep, and probably isn’t worth getting too fancy for single-digit hosts. Fleets of thousands of spot instances benefit from the effort. Like everything, dev-time vs runtime-complexity vs cost-efficiency is a tough balance.
When I was doing this often, I had different modes for “dev mode, which includes human-timeframe messing about” and “prod mode”, which was only for monitored workloads. In both cases, automating the “provision, spin up, and initial setup”, as well as the “auto-shutdown if not measurably used for N minutes (60 was my default)” with a one-command script made my life much easier.