Hibernate is just like good old hibernate from windows XP days. You save the RAM to disk. And resume your processes on next boot and they won't even notice they were stopped! (Except for the time has changed...)
It might be really helpful for low priority batch processing.
Disclaimer: I've never tested this.
The ideal case scenario imho (one step beyond this stop/start-at-will feature) would be "convertible" spot - being able to migrate to on-demand with zero downtime when ec2 needs that capacity back - that'd solve a lot of my problems.
Some AZs don't have much capacity for certain types of instances.
Fun fact: An availability zone A for person 1 is not guaranteed to be the same as availability zone A of person 2. AWS mixes them up per account.
This post is different: with on-demand instances you can stop them whenever you like and only be charged for storage while they're in the stopped state and then start them up when you need them again (keeping all the same settings, like the IP, etc). A stop/start is also the way to effectively move your instance to new hardware if there is an instance with the underlying host. Annoyingly, the stop/start API calls were rejected for spot instances. This announcement means this is now finally possible.
One tip, as an easy way to track api changes in aws, checkout https://awsapichanges.info/
It's for persistent spot requests, so presumably it doesn't include defined-duration spot instances. Perhaps that will come later.
Perfectly possible to work around it even if not, of course.