This chapter covers EC2 Hibernation, a feature that allows you to pause and resume EC2 instances while preserving the in-memory state. For the SAA-C03 exam, understanding hibernation is crucial for designing cost-optimized and resilient architectures, particularly for workloads with long-running processes or stateful applications. Questions on hibernation appear in approximately 5-8% of exams, often in scenarios involving batch processing, development environments, or instances that need to be paused and resumed without losing application state. Mastering this topic will help you choose the right instance lifecycle management strategy and avoid common pitfalls.
Jump to a section
Imagine you are playing a complex video game on a console. You have the game paused, but the console is still running, consuming power, and keeping the game state in RAM. This is like a stopped EC2 instance—the instance is not running, but the EBS root volume persists, and you still pay for attached storage. Now, consider a feature called 'Suspend to Disk' on some laptops. When you close the lid, the laptop copies the entire contents of RAM (the current state of all open applications, documents, and browser tabs) to a file on the hard drive. Then it completely powers off the RAM and CPU, drawing zero power. When you open the lid later, the laptop reads that file back into RAM, and you resume exactly where you left off—all applications open, cursor blinking in the same spot. This is EC2 Hibernation. The 'RAM contents' are the in-memory state of the EC2 instance. Hibernation saves that state to the EBS root volume (the 'hard drive') and then stops the instance, allowing you to stop paying for the compute (vCPU and RAM) while preserving the exact application state. When you start the instance again, it reads the saved state back into RAM, and the OS resumes without a full boot cycle. This is fundamentally different from a standard stop/start, which is like turning off the console completely—you lose the game session and must reload from your last save point. Hibernation preserves the 'live' state, enabling faster resumption and saving costs by not keeping the instance running during idle periods.
What is EC2 Hibernation and Why Does It Exist?
EC2 Hibernation is a feature that allows you to pause an EC2 instance and then resume it later, preserving the in-memory state (RAM) of the instance. When you hibernate an instance, Amazon EC2 signals the operating system to perform a suspend-to-disk operation (hibernation). The OS writes the contents of the RAM to the root EBS volume (encrypted, if applicable) and then powers down the instance. When you start the instance again, the RAM contents are read back from the EBS volume, and the instance resumes exactly where it left off—all applications, processes, and data in memory are restored.
Hibernation exists to solve the problem of preserving instance state during a stop/start cycle. A standard stop/start operation terminates all processes and clears RAM, requiring a full OS boot and application restart. This can take minutes and may cause data loss for in-memory caches or long-running computations. Hibernation reduces resume time to typically 30-90 seconds (depending on the amount of RAM) and preserves the exact state, making it ideal for:
Development and test environments that need to be paused overnight.
Batch processing jobs that run for hours and need to be paused during peak hours.
Instances running memory-intensive applications that take a long time to warm up.
How Hibernation Works Internally
The hibernation process involves several steps at the AWS and OS level:
Initiation: You can hibernate an instance via the AWS Management Console, AWS CLI (aws ec2 stop-instances --instance-id i-1234567890abcdef0 --hibernate), or the Amazon EC2 API. The instance must have hibernation enabled at launch (cannot be enabled later).
OS Hibernation: The instance receives an ACPI S3 (Suspend to RAM) or S4 (Hibernate) signal, depending on the OS. For supported Linux AMIs, the pm-hibernate command is triggered. The OS then:
Freezes all user-space processes.
Writes the entire contents of RAM to the swap space or a dedicated hibernation file on the root EBS volume.
For Linux, the swap space must be at least equal to the size of the RAM to accommodate the hibernation image.
For Windows, the root volume must have enough free space for the hibernation file (hiberfil.sys), which is typically 40-75% of RAM size.
The OS then powers off the instance.
AWS Handling: After the OS shuts down, AWS marks the instance as stopped (hibernated). The EBS root volume remains attached, and any additional EBS volumes remain attached. The instance retains its private IP address, Elastic IP addresses (if associated), and ENI attachments.
Resumption: When you start the instance (via Console, CLI aws ec2 start-instances --instance-ids i-1234567890abcdef0, or API), AWS powers on the instance. The BIOS reads the hibernation image from the root volume, loads it into RAM, and the OS resumes exactly where it left off. The instance is now in the running state.
Key Components, Values, Defaults, and Timers
Supported Instance Families: Hibernation is supported for instances from the following families: M3, M4, M5, M5a, M5n, M5zn, M6a, M6i, M6g, M7g, C3, C4, C5, C5a, C5n, C5d, C6a, C6i, C6g, C7g, R3, R4, R5, R5a, R5n, R5b, R6a, R6i, R6g, R7g, T2, T3, T3a, T4g, X1, X1e, X2gd, X2idn, X2iedn, z1d, and high-memory instances (u-*). Note: Bare metal instances, GPU instances (P, G, F), and some older families are not supported.
Supported Operating Systems: Amazon Linux 2, Amazon Linux 2023, Ubuntu 16.04/18.04/20.04/22.04 (LTS), Windows Server 2012 R2, 2016, 2019, 2022, and RHEL 7.x/8.x. Not all Linux distros support hibernation out of the box.
Root Volume Requirements:
Must be an EBS volume, not instance store.
Must be encrypted (either with a default AWS managed key or a customer managed key). Hibernation does not support unencrypted root volumes.
For Linux, the root volume must have a swap space that is at least the size of the instance's RAM. The swap can be in a separate partition or a swap file.
For Windows, the root volume must have enough free space to store the hibernation file (hiberfil.sys), which is typically 40-75% of RAM size.
Maximum RAM: Hibernation supports instances with up to 150 GB of RAM. Instances with more than 150 GB RAM cannot be hibernated.
Hibernation Duration: There is no maximum time limit for hibernation—you can keep an instance hibernated indefinitely. However, you continue to pay for EBS storage and Elastic IP addresses (if not associated with a running instance).
Stop vs. Hibernate: A standard stop does not preserve RAM; a hibernate does. You can force a regular stop even if hibernation is enabled by using the --no-hibernate flag.
Configuration and Verification
To enable hibernation on a new instance:
Using AWS CLI:
aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t3.large --block-device-mappings DeviceName=/dev/xvda,Ebs={Encrypted=true,DeleteOnTermination=true} --hibernation-options Configured=trueUsing Console: When launching an instance, under 'Advanced details', set 'Hibernation' to 'Enabled'. You must also encrypt the root volume.
Verification:
Check if an instance has hibernation enabled:
aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[0].Instances[0].HibernationOptions.Configured'To hibernate:
aws ec2 stop-instances --instance-ids i-1234567890abcdef0 --hibernateThe instance state becomes stopped with a reason code Client.UserInitiatedHibernate.
Interaction with Related Technologies
Auto Scaling: Hibernation is not compatible with Auto Scaling groups that use instance refresh or scale-in policies. If you hibernate an instance in an ASG, the ASG may treat it as unhealthy and terminate it.
Elastic Load Balancing: Hibernated instances are deregistered from the load balancer. When resumed, they are re-registered (if health checks pass).
CloudWatch: Hibernation events are logged in CloudTrail.
EBS Snapshots: You can take snapshots of the root volume while the instance is hibernated, which captures the hibernation state. However, restoring from that snapshot will not automatically restore the hibernation state—you must start the instance normally.
Instance Metadata: The instance metadata (e.g., instance ID, AMI ID) remains the same after hibernation.
Instance Store: If the instance has instance store volumes, the data on those volumes is lost upon hibernation (since instance store is ephemeral). Only EBS-backed instances can be hibernated.
Initiate Hibernation
The user triggers a hibernation via the AWS Management Console, CLI, or API. The command `aws ec2 stop-instances --instance-ids i-1234567890abcdef0 --hibernate` sends a stop request with the Hibernate flag set to true. AWS receives the request and verifies that the instance has hibernation enabled, the root volume is encrypted, and the instance type supports hibernation. If validation fails, the request is rejected with an error. If valid, AWS sends an ACPI S4 (Hibernate) signal to the instance's operating system.
OS Hibernation Process
The operating system receives the ACPI S4 signal and begins the hibernation routine. In Linux, the `pm-hibernate` utility (or equivalent) is invoked. The OS freezes all user-space processes, flushes file system buffers, and writes the entire contents of RAM to the configured swap space on the root EBS volume. For Windows, the kernel writes the memory contents to `hiberfil.sys`. The size of the hibernation image is roughly equal to the instance's RAM size. The OS then powers off the instance by issuing a system shutdown command. At this point, the instance is in a stopped state from AWS's perspective.
AWS Marks Instance as Stopped
After the OS shuts down, the hypervisor detects the power-off and updates the instance state to `stopped`. The stop reason is set to `Client.UserInitiatedHibernate`. AWS preserves the instance's configuration: private IP address, Elastic IP associations, ENI attachments, and EBS volume attachments. The EBS root volume now contains the hibernation image. The instance is no longer billed for compute (vCPU and RAM), but EBS storage costs continue. The instance can remain in this state indefinitely.
Resuming the Instance
When the user starts the instance (e.g., `aws ec2 start-instances --instance-ids i-1234567890abcdef0`), AWS powers on the instance. The BIOS performs a minimal POST and then detects the hibernation image on the root volume. Instead of a full boot, the system loads the hibernation image from the swap space (or hiberfil.sys) directly into RAM. This process typically takes 30-90 seconds, depending on RAM size and EBS volume performance. The OS then restores the state of all processes and applications exactly as they were before hibernation.
Post-Resumption State
After resumption, the instance is in the `running` state and resumes normal operation. All applications, network connections, and data in memory are restored. However, any network connections that were open before hibernation may time out and need to be re-established (e.g., TCP connections). The instance retains its original private IP address, public IP (if any), and security group settings. CloudTrail logs the start event. The instance continues to be billed for compute and storage. The hibernation image on the root volume is deleted after a successful resume to free up space.
Enterprise Scenario 1: Cost Optimization for Development Environments
A large software company runs hundreds of development EC2 instances that are used during business hours (9 AM to 6 PM) but remain idle overnight and on weekends. Without hibernation, developers would either leave instances running (incurring compute costs 24/7) or stop them at night and endure a 5-10 minute boot and application warm-up each morning. By enabling hibernation on these instances, the company can stop them at 6 PM and start them at 9 AM, saving approximately 15 hours of compute costs per instance per day. The resume time is under 60 seconds, so developers can start working immediately. The root volumes are encrypted using AWS KMS, and the swap space is sized to match the RAM (e.g., 16 GB swap for a 16 GB RAM instance). The company uses AWS Instance Scheduler to automate hibernation based on a cron schedule. They also monitor CloudTrail logs to ensure hibernation is working correctly. A common issue is that developers forget to save their work before hibernation, but since hibernation preserves the in-memory state, unsaved work is retained—unlike a standard stop.
Enterprise Scenario 2: Batch Processing with Interruptible Workloads
A financial services firm runs long-running Monte Carlo simulations on EC2 instances. These simulations can take 8-12 hours and consume large amounts of RAM (up to 64 GB). The firm uses Spot Instances to reduce costs, but Spot Instances can be interrupted with a 2-minute warning. Without hibernation, an interruption would cause the simulation to fail and lose all progress. By enabling hibernation on Spot Instances, the firm can hibernate the instance upon receiving the interruption notice (via a CloudWatch Event or the instance metadata). The simulation state is preserved on the root EBS volume. When the Spot Instance becomes available again (or a new one is launched from the same AMI), the instance resumes from the hibernation state and continues the simulation. This requires careful configuration: the root volume must be encrypted, swap space must be large enough, and the instance must be launched with hibernation enabled. The firm also uses a lifecycle hook in Auto Scaling to trigger hibernation before termination. This approach saves costs by using Spot Instances while avoiding total loss of progress.
Scenario 3: Compliance and Audit Holds
A healthcare company needs to temporarily pause an EC2 instance that is processing sensitive patient data during a compliance audit. The instance holds in-memory data that cannot be written to disk due to regulatory requirements. However, the company must stop the instance to avoid incurring compute costs during the audit hold period. Hibernation allows them to preserve the in-memory state (including the sensitive data) on the encrypted root volume. The instance is stopped, and the audit team can review the configuration without the instance running. After the audit, the instance is resumed, and processing continues. The key consideration is that the root volume must be encrypted at rest, which is already a compliance requirement. The company also ensures that no instance store volumes are attached, as those would lose data. They test the hibernation process in a staging environment to verify that the application resumes correctly without data corruption.
What SAA-C03 Tests on EC2 Hibernation
The exam tests your ability to identify when to use hibernation versus other lifecycle options (stop, terminate, reboot) and how it impacts cost and performance. Specific objective codes: Domain 4 (Cost-Optimized Architectures), Objective 4.1 (Identify cost-effective storage and compute). You must know:
The prerequisites: encrypted root volume, instance family support, RAM <= 150 GB, and enabled at launch.
The difference between stop and hibernate: stop clears RAM, hibernate preserves it.
That you pay for EBS storage while hibernated, but not for compute.
That hibernation is not supported with instance store volumes, Auto Scaling, or certain instance types.
Common Wrong Answers and Why Candidates Choose Them
Wrong: 'Hibernation can be enabled on a running instance.' Candidates often think it's a feature you can toggle on/off. Reality: Hibernation must be enabled at launch time. You cannot enable it on an existing instance. You must launch a new instance with the --hibernation-options Configured=true flag.
Wrong: 'Hibernation preserves data on instance store volumes.' Candidates confuse instance store with EBS. Reality: Instance store volumes are ephemeral and their data is lost upon hibernation (since the instance stops). Only EBS volumes persist.
Wrong: 'Hibernation reduces EBS storage costs.' Candidates may think that hibernation compresses the RAM image. Reality: The hibernation image consumes swap space on the root volume, which is billed as EBS storage. You still pay for the full root volume size. There is no cost reduction for storage.
Wrong: 'Hibernation works with any instance type.' Candidates often assume all instance types support hibernation. Reality: Only specific families (M, C, R, T, etc.) support it. GPU, bare metal, and some older types do not.
Specific Numbers and Terms on the Exam
Maximum RAM supported: 150 GB.
Supported root volume: EBS only, must be encrypted.
Must be enabled at launch: --hibernation-options Configured=true.
Hibernation duration: No limit (indefinite).
Resume time: Typically 30-90 seconds.
Linux swap requirement: At least the size of RAM.
Windows hiberfil.sys: Typically 40-75% of RAM.
Edge Cases and Exceptions
Spot Instances: Hibernation can be used with Spot Instances, but if the Spot Instance is terminated due to capacity, the hibernation state is lost. You must use a lifecycle hook to hibernate before termination.
Auto Scaling: Hibernation is not recommended with Auto Scaling because the ASG may terminate hibernated instances. However, you can use a custom lifecycle hook to hibernate before scale-in.
Reserved Instances: Hibernation does not affect Reserved Instance billing. You pay for the compute time only when the instance is running.
Elastic IP: If you hibernate an instance with an Elastic IP, the EIP remains associated, but you may incur charges if the instance is stopped (hibernated) and the EIP is not associated with a running instance. (AWS does not charge for one EIP associated with a stopped instance, but check current pricing.)
How to Eliminate Wrong Answers
If the question mentions preserving in-memory state, look for 'hibernate' as the answer. If it mentions 'stop' or 'terminate', they are wrong.
If the scenario involves instance store, eliminate hibernation.
If the root volume is not encrypted, eliminate hibernation.
If the instance type is a GPU or bare metal, eliminate hibernation.
If the question asks about reducing compute costs for idle instances, hibernation is a valid option, but also consider scheduled scaling or stopping. Hibernation is best when you need to preserve state.
Hibernation preserves the in-memory state of an EC2 instance by saving RAM contents to the encrypted root EBS volume.
Hibernation must be enabled at launch time; it cannot be enabled on an existing instance.
Supported instance families include M, C, R, T, and others; GPU, bare metal, and some older types are not supported.
Maximum RAM for hibernation is 150 GB.
Root volume must be encrypted (AWS managed or customer managed key).
For Linux, swap space must be at least equal to the instance's RAM size.
For Windows, the root volume must have enough free space for the hibernation file (hiberfil.sys), typically 40-75% of RAM.
Hibernation is not compatible with instance store volumes; data on instance store is lost.
You are billed for EBS storage while the instance is hibernated, but not for compute (vCPU and RAM).
Hibernation can be used with Spot Instances, but you must handle termination notifications to hibernate before interruption.
Auto Scaling does not natively support hibernation; you may need custom lifecycle hooks.
Resume time is typically 30-90 seconds, much faster than a full boot.
These come up on the exam all the time. Here's how to tell them apart.
Stop (Standard)
Instance state is stopped; RAM is cleared.
Full OS boot on start (2-5 minutes).
No prerequisites (encryption optional).
Works with all instance types.
No additional swap space requirement.
Hibernate
Instance state is stopped; RAM is preserved on root EBS volume.
Resume from hibernation (30-90 seconds).
Requires encrypted root volume, specific instance families, RAM ≤ 150 GB, enabled at launch, and swap space (Linux) or hiberfil.sys space (Windows).
Not supported with instance store, GPU, or bare metal instances.
Requires swap space at least equal to RAM (Linux) or free space for hiberfil.sys (Windows).
Hibernate
Instance is stopped; compute costs stop.
Preserves in-memory state.
Takes 30-90 seconds to resume.
EBS volumes remain attached and unchanged.
Network connections may time out.
Reboot
Instance remains running; compute costs continue.
RAM is cleared (all processes terminate).
Takes 2-5 minutes to reboot (full OS boot).
EBS volumes remain attached and unchanged.
Network connections are reset.
Mistake
Hibernation can be enabled on an existing running instance.
Correct
Hibernation must be enabled at launch time. You cannot enable it on an existing instance. You must launch a new instance with the hibernation option enabled.
Mistake
Hibernation preserves data on instance store volumes.
Correct
Instance store volumes are ephemeral and are lost when the instance stops (including hibernation). Only EBS volumes persist. Hibernation only preserves the in-memory state on the root EBS volume.
Mistake
Hibernation reduces EBS storage costs because the RAM image is compressed.
Correct
The hibernation image is stored in the swap space on the root volume, which consumes EBS storage. You pay for the full root volume size regardless. There is no cost reduction.
Mistake
Hibernation works with any EC2 instance type.
Correct
Only specific instance families support hibernation, including M, C, R, T, and some others. GPU instances (P, G, F), bare metal, and older families do not support hibernation.
Mistake
Hibernation is supported for instances with more than 150 GB of RAM.
Correct
EC2 Hibernation supports instances with up to 150 GB of RAM. Instances with larger RAM cannot be hibernated.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, hibernation must be enabled at launch time. You cannot enable it on an existing running or stopped instance. To use hibernation, you must launch a new instance with the hibernation option enabled. This is a common exam trap—candidates often think it can be toggled later.
Data on instance store volumes is lost because instance store is ephemeral and does not persist through a stop/start cycle (including hibernation). Only EBS volumes retain data. If your application relies on instance store, you should not use hibernation.
While an instance is hibernated, you are not charged for compute (vCPU and RAM). However, you continue to pay for EBS storage (root volume and any additional volumes), Elastic IP addresses (if not associated with a running instance), and any other resources like snapshots. There is no additional charge for the hibernation feature itself.
Yes, Spot Instances support hibernation if the instance type and configuration meet the requirements. However, if the Spot Instance is interrupted due to capacity or price, the instance is terminated (not hibernated) unless you have a lifecycle hook that triggers hibernation before termination. You must handle the Spot Instance interruption notice to hibernate gracefully.
EC2 Hibernation supports instances with up to 150 GB of RAM. Instances with more than 150 GB RAM cannot be hibernated. This is a hard limit enforced by AWS. If you need to use hibernation with larger RAM, consider splitting the workload into smaller instances.
Yes, Windows Server 2012 R2, 2016, 2019, and 2022 support hibernation. The root volume must be encrypted, and there must be enough free space for the hibernation file (hiberfil.sys), which is typically 40-75% of the RAM size. You may need to configure the hibernation file size manually.
Yes, you can take a snapshot of the EBS root volume while the instance is hibernated. The snapshot will include the hibernation image. However, when you create a new instance from that snapshot, it will not automatically resume from hibernation—it will boot normally. The snapshot is useful for backup or cloning the instance state.
You've just covered EC2 Hibernation — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?