AWS Instance Notices and You. Prepping for the Cloud.


Many customers have received varying AWS instance notices related to instance retirement or instance maintenance. These retirement notices often read, “We have important news about your account. EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance in the region.” Similarly maintenance notifications read, “One or more of your Amazon EC2 instances is scheduled for maintenance on for 2 hours starting at .” The big question is: do you know what these notices really mean and how you take care of them? Below we’ll discuss AWS notifications and how to act on them. The two biggest takeaways from theses notices are: run don’t walk, on working to replace affected instances; and make sure your mission critical data lives on Elastic Block Storage (EBS).

AWS Retirement Notices

The courtesy notice many people have seen, before or slightly after an AWS instance going down is related to underlying physical hardware. When you receive this notification it means that AWS received a hardware alert from one of their host machines. An example would be a S.M.A.R.T. hdd message. The date AWS provides in the notice is a best case scenario for that instance to still be available but is also the last date the instance will likely be available. Meaning you should work on taking care of the notice as soon as possible within the timeframe provided in the notice.

The fastest option is to perform a stop and start of the instance, which will place the instance on new hardware. This option works as long as it is a supported instance type (Current EBS Root Instance Types) and is great when all of your data is known to be stored on EBS volumes, meaning you only need to move to a new underlying host. This does not work if you’ve stored mission critical or legally required data on ephemeral disks, as this data will be lost. When an instance is restarted the ephemeral disks are not copied to the new instance although the EBS volumes and instance id are.

The second option is to use a snapshot to rebuild the instance. This option works incredibly well if you store any of your mission critical data on ephemeral disks. If any of the data that is mission critical to your application or business functions live on ephemeral devices, now would be the time to move it to the new instance and on to the EBS volume. This would also be a time to verify why that data isn’t on an EBS volume and make sure in the future it is written to a persistent storage option with AWS.

AWS Maintenance Notices

Similar to retirement notices provided by AWS, maintenance notices are normally a set time frame in which an instance will be unresponsive, after which, the instance should return to normal functions without user intervention. The first question you should ask yourself is, “Is this instance critical to your application/business’ uptime?” If the application can ride out the maintenance downtime period, you should be able to ignore this request and let AWS handle the maintenance period on your behalf. However, if even a couple minutes downtime of the application in question, let alone a couple of hours, will leave your business negatively impacted; we would suggest taking similar steps to provision the instance on new hardware as we described in the above section related to Retirement Notices. Like retirement notices, we recommend that you act early on these notifications to lessen the impact on your environment.

In summary, when receiving AWS notices, please take care of them as soon as possible to prevent it from harming your application or business. If you would like help stopping and starting an instance on Engine Yard Cloud please respond to your maintenance notification ticket along with a scheduled time you would like it done. If you would like assistance looking at your architecture so you can safely ignore those messages going forward please open a ticket with our Support team to assist you.

Free Ebook: PaaS Is Dead

Platform as a Service (PaaS) is experiencing a digital transformation, and despite what some may argue, it’s far from dead. Learn why PaaS continues to prove it has a promising future for DevOps.

PaaS Is Dead

Related posts

PostgreSQL Replication Tutorial For Disaster Recovery

November 24, 2017

This blog post is a step by step tutorial on how to set up PostgreSQL Replication between AWS

Read More

Building a Vagrant Box from Start to Finish

August 1, 2017

Note: This article was originally published at It was recently updated for

Read More

Setting up your ELB Healthcheck

February 28, 2017

To effectively route traffic to your various instances Amazon’s Elastic Load Balancer(ELB) needs

Read More

Ralph Bankston


Subscribe to our Blog