EC2 stop vs terminate are two different instance states in the AWS EC2 lifecycle. Understanding the differences is important to ensure you’re best managing your resources, which has implications for your applications, resource costs, and more.
What Happens When You Stop EC2 Instances
To look at stop vs terminate EC2 actions, we’ll start with “stopped”. The EC2 “stopped” state indicates that an instance is shut down and cannot be used. Basically, it is a temporary shutdown for when you are not using an instance, but you will need it later. The attached bootable EBS volume will not be deleted.
Here are a few important things to know about how stopped instances behave:
- Host computer – after being stopped, once restarted, an instance will be moved to a new host computer (in most cases).
- IP Addresses
- IPv4 addresses – instances keep their private IPv4 addresses. When restarted, it will get a new public IPv4 address.
- Elastic IP addresses (IPv4) – the exception to the above is Elastic IP addresses, which will persist after an instance is stopped and restarted.
- IPv6 addresses – instances retain IPv6 addresses when stopped and restarted.
- Instance store volumes – data is erased when stopped.
- Root device volume – the volume attached to the instance is preserved.
- RAM (contents of memory) – the RAM is erased when stopped.
- Billing – you are not billed for stopped EC2 instances. This makes stopping instances when not in use a valuable cost-saving strategy – more on this later in the article.
- However, you are billed for some attached resources regardless of the instance state – such as Amazon EBS volumes and Elastic IP addresses.
- You are not charged for data transfer fees.
- When an instance is stopped and then started, a new billing period begins for a minimum of one minute.
AWS EC2 Stop Instances Use Cases
Reasons you may want to use the “stopped” state include:
- Stop and restart to resolve unexpected status check fails or incorrectly running applications.
- Save money by turning resources off when not needed – for example, turning non-production resources off on nights and weekends.
- Change the instance type and other attributes, for example, to achieve instance rightsizing. You can only modify the instance type, user data, kernel, and RAM disk when an instance is stopped.
Instance Types That Cannot Be Stopped
When you launch your instances from an AMI you can choose between AMIs backed by Amazon EBS or backed by instance store. Instance store-backed instances cannot be stopped.
Additionally, instances in auto scaling groups are not designed to be stopped individually. This will typically trigger a health check and your instances will be marked as unhealthy so your instances will be terminated or replaced. You can “suspend” this action for an individual auto scaling group, or detach the instance from the group and then stop it.
Previously, the AWS stop instance state could not be used for spot instances, but this functionality was added for persistent spot requests with EBS-backed spot instances in January 2020
Hibernate EC2 Instances
Notice also that there is a “stopping” state between running and stopped. If the instance is preparing to be stopped, you are not charged for usage, but if it is preparing to hibernate, usage is billed.
The hibernate action is a “suspend-to-disk” action that saves the contents from the instance memory to your Amazon EBS root volume. So, processes that were previously running can be restored when the instance is started. This allows a quick restart, without having to wait for caches and other memory-centric application components that slow down restarts.
Otherwise, hibernation is similar to stopping and a hibernated instance also goes from the “stopping” to “stopped” state (and as mentioned above, it is still billed while in the “stopping” state, but not “stopped.”)
Note that in order to be hibernated, instances must enable this ability when launching the instance – you can’t enable or disable after launch. Review AWS’s EC2 hibernation prerequisites for details regarding which types of instances can enable this option.
What Happens When You Terminate EC2 Instances
To terminate, on the other hand, is a permanent deletion. Use this when you are finished with an instance, as terminated instances can’t be recovered.
Here are a few things to note about the behavior of terminated instances:
- Host computer – none.
- IP Addresses
- IPv4 addresses – none.
- Elastic IP addresses (IPv4) – the Elastic IP address is disassociated from the instance.
- IPv6 addresses – none.
- Instance store volumes – data is erased when terminated.
- Root device volume – the volume is deleted by default.
- RAM (contents of memory) – the RAM is erased when terminated.
- Billing – you are not billed for terminated EC2 instances.
- The “shutting-down” state exists between running and terminated. You are not billed once an instance goes into this state.
- You will be billed for any volumes or snapshots Read more about orphaned resources here.
Regarding billing, there can be some confusion regarding reserved instances. Reserved instances are not capacity reservations, but more like pre-paid credits. Therefore, when you stop an instance that had a reservation applied to it, that does not reduce the cost of your reserved instance. To that end, check out savings plans instead.
As you can see, the AWS EC2 stop vs terminate statuses serve very different functions.
Start and Stop EC2 Instances on a Schedule to Reduce Costs
As mentioned above, temporarily stopping an EC2 instance is a great way to save money. The typical use case is to set non-production instances – such as those used for development, testing, staging, and QA – on an on/off schedule, to turn off nights and weekends when not in use. Just by turning an instance off for 12 hours/day and on weekends, you can reduce the cost by 65%.
Even better is to set those on/off schedules based on your actual usage data. We built ParkMyCloud to do just that. You can connect ParkMyCloud to your AWS account using a limited-access IAM role, and the platform will analyze your usage data and recommend on/off schedules for your resources, which can then be automatically applied. Users typically get a 12X ROI or more, reducing costs by 65%. Sound too good to be true? Give it a try in your own environments with a 14-day free trial today.