Menu
Amazon Elastic Compute Cloud
User Guide for Linux Instances

Recover Your Instance

You can create an Amazon CloudWatch alarm that monitors an Amazon EC2 instance and automatically recovers the instance if it becomes impaired due to an underlying hardware failure or a problem that requires AWS involvement to repair. Terminated instances cannot be recovered. A recovered instance is identical to the original instance, including the instance ID, private IP addresses, Elastic IP addresses, and all instance metadata. For more information about using Amazon CloudWatch alarms to recover an instance, see Create Alarms That Stop, Terminate, Reboot, or Recover an Instance. To troubleshoot issues with instance recovery failures, see Troubleshooting Instance Recovery Failures in the Amazon EC2 User Guide for Linux Instances.

When the StatusCheckFailed_System alarm is triggered, and the recover action is initiated, you will be notified by the Amazon SNS topic that you selected when you created the alarm and associated the recover action. During instance recovery, the instance is migrated during an instance reboot, and any data that is in-memory is lost. When the process is complete, you'll receive an email notification that includes the status of the recovery attempt and any further instructions. You will notice an instance reboot on the recovered instance.

Examples of problems that cause system status checks to fail include:

  • Loss of network connectivity

  • Loss of system power

  • Software issues on the physical host

  • Hardware issues on the physical host

Important

The recover action is only supported on:

  • C3, C4, M3, M4, R3, T2, and X1 instance types.

  • Instances in a VPC

    Note

    If your instance has a public IP address, it retains the same public IP address after recovery.

  • Instances with shared tenancy (where the tenancy attribute of the instance is set to default)

  • Instances that use Amazon EBS storage exclusively

Currently, the recover action is not supported on:

  • EC2-Classic instances

  • Dedicated tenancy instances

  • Instances running on dedicated hosts

  • Instances with encrypted EBS volumes

  • Instances that use any instance store volumes, including instances launched with block device mappings for instance store volumes

Note

If you are using an AWS Identity and Access Management (IAM) account to create or modify an alarm, you must have the following Amazon EC2 permissions:

  • ec2:DescribeInstanceStatus and ec2:DescribeInstances for all alarms on Amazon EC2 instance status metrics.

  • ec2:StopInstances for alarms with stop actions.

  • ec2:TerminateInstances for alarms with terminate actions.

  • ec2:DescribeInstanceRecoveryAttribute, and ec2:RecoverInstances for alarms with recover actions.

If you have read/write permissions for Amazon CloudWatch but not for Amazon EC2, you can still create an alarm but the stop or terminate actions won’t be performed on the Amazon EC2 instance. However, if you are later granted permission to use the associated Amazon EC2 APIs, the alarm actions you created earlier will be performed. For more information about IAM permissions, see Permissions and Policies in the IAM User Guide.

If you are using an IAM role (e.g., an Amazon EC2 instance profile), you cannot stop, terminate, or reboot the instance using alarm actions. However, you can still see the alarm state and perform any other actions such as Amazon SNS notifications or Auto Scaling policies.

If you are using temporary security credentials granted using the AWS Security Token Service (AWS STS), you cannot stop, terminate, or reboot an Amazon EC2 instance using alarm actions.