Alright, let’s talk about hibernation. No, not for you after a long day of debugging—for your EC2 instances. This is the feature that lets you pull off the closest thing to magic in the cloud: you stop an instance, and when you start it back up, it’s exactly as you left it. Your in-memory state—all those unsaved documents, that massive dataset you just loaded into RAM, the 47 open SSH connections you were using to prove a point—is preserved. It’s not a reboot; it’s a pause button.

The secret sauce here is that when you hibernate an instance, the contents of its instance memory (RAM) are written to the Amazon Elastic Block Store (EBS) root volume. Think of it as the world’s most intense core dump, saved to a fast SSD instead of your desktop. When you start it again, AWS reads that memory image back into RAM from the EBS volume and picks up right where it left off. This is why hibernation has a very specific, non-negotiable set of prerequisites. They aren’t suggestions; they’re the laws of physics for this particular bit of magic.

The Strict Prerequisites for Hibernation

You can’t just wave a wand at any instance and expect this to work. The designers made some very specific choices here, and you have to play by their rules.

First, the instance must use an EBS volume as its root device. Instance store volumes are ephemeral; they’re wiped on stop/start. Since we’re saving memory to the root volume, an instance store is a non-starter. It’s like trying to save a file to a RAM disk and then turning off the power.

Second, and this is the big one, your root volume must be encrypted and must be large enough to hold the RAM contents plus whatever space your operating system and applications are using. The math is simple: your root volume size must be greater than or equal to the amount of RAM allocated to the instance. An m5.large has 8 GiB of RAM? Your root volume needs to be at least 9 GiB. I always add a 1-2 GiB buffer for the OS itself, so I’d make it 10 GiB to be safe. If your volume is too small, the hibernation process will fail. AWS does this because it needs a guaranteed, contiguous block of space to write that memory image, and encryption is a hard requirement for the obvious security reasons—you don’t want your memory contents sitting on disk in plain text.

Third, hibernation is only supported for specific instance types (mostly the modern ones: M5, C5, R5, etc.) and it must be enabled at launch. You can’t decide to hibernate an existing, running instance that wasn’t born with this flag set. Here’s how you launch an instance prepped for its eventual hibernation:

aws ec2 run-instances \
    --image-id ami-1234567890EXAMPLE \
    --instance-type m5.large \
    --count 1 \
    --block-device-mappings "[{\"DeviceName\":\"/dev/xvda\",\"Ebs\":{\"VolumeSize\":10,\"Encrypted\":true}}]" \
    --hibernation-options Configured=true

Notice the two critical parts: the VolumeSize is 10 (for our 8 GiB instance) and Encrypted is explicitly set to true. Also, the --hibernation-options flag is set. Miss any one of these, and your hibernation attempt later will be a very quiet failure.

Actually Hibernating and Waking Up

Once your specially-configured instance is running, hibernating it is dead simple. You don’t do it through the AWS CLI or API directly. Instead, you trigger it from within the operating system of the instance itself, just like you would with your laptop.

On Amazon Linux 2 or a Linux distro using systemd, it’s a one-liner:

sudo systemctl hibernate

The instance will begin the process of writing its memory to the root volume and then transition to a stopped state. In the AWS console, its state will read stopped (hibernated). To wake it up? You start it exactly like any other stopped EC2 instance.

aws ec2 start-instances --instance-ids i-1234567890EXAMPLE

The boot process will be noticeably longer than a standard start because AWS is loading that multi-gigabyte memory image back into RAM. But once it’s done, you’ll SSH back in and find your htop session still running and your tail -f still… tailing. It’s deeply satisfying.

The Gotchas and The Gripes

Now, the rough edges. First, the boot time. This isn’t for instances you need to scale in and out rapidly. The hibernation and restoration process takes minutes, not seconds. It’s for those long-running, stateful workhorse instances you need to pause for cost savings but can’t afford to lose the state of.

Second, and this is my biggest gripe: you can’t hibernate an instance that wasn’t launched with the hibernation flag enabled. It’s a one-way door at launch time. This feels like an arbitrary limitation. Why can’t I enable this on a stopped instance if it meets all the other criteria? I don’t know, but I suspect it’s a design choice rooted in ensuring a guaranteed clean state. It’s annoying, but it’s the law.

Finally, be aware of your charges. While the instance itself isn’t running, you are still paying for the EBS volume storage. It’s cheaper than paying for the compute, but it’s not free. Hibernation is a cost-optimization tool, not a cost-elimination one.

So, when should you use it? It’s perfect for development machines, long-running analysis jobs you might need to pause, or even those “oh crap, I need to patch the kernel but I can’t restart my services right now” moments. You hibernate, AWS does its underlying maintenance, and you start back up without your users ever knowing you were gone. It’s a brilliantly useful feature, once you jump through its very specific hoops.