# Backup and recovery for Amazon EC2 with EBS volumes
AWS provides multiple methods to back up your Amazon EC2 instances. This section covers different aspects of backing up Amazon Elastic Block Store (Amazon EBS) volumes or instance store volumes for storage. Consider AWS Backup as your first choice for managing backups on AWS if it meets your requirements. Remember that backups are good only if they can be restored to the function for which they were intended. The restore and recovery function should be regularly tested to confirm this.
The solution architecture in the following diagram describes a workload environment that exists entirely on AWS with the majority of the architecture based on Amazon EC2. As the following figure shows, the scenario includes web servers, application servers, monitoring servers, databases, Active Directory, and disaster recovery (DR) replication.
![\[Diagram of an example environment with two Availability Zones, private and replica databases in the private subnets, and disaster recovery replication.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/images/workload-environment-aws.png)
AWS provides many fully featured services for many of the Amazon EC2 servers represented in this architecture to perform the undifferentiated work of creating, provisioning, backing up, restoring, and optimizing the instances and storage. Consider whether these services make sense in your architecture to reduce complexity and management. AWS also provides services to improve the availability of your Amazon EC2–based architectures. In particular, consider Amazon EC2 Auto Scaling and Elastic Load Balancing to complement your workloads on Amazon EC2. Using these services can improve the availability and fault tolerance of your architecture and help you to restore impaired instances with minimal user impact.
EC2 instances primarily use Amazon EBS volumes for persistent storage. Amazon EBS provides a number of features for backup and recovery that are covered in detail in this section.
**Topics**
+ [Amazon EC2 backup and recovery with snapshots and AMIs](ec2-backup.md)
+ [Creating EBS volume backups with AMIs and EBS snapshots](new-ebs-volume-backups.md)
+ [Restoring an Amazon EBS volume or an EC2 instance](restore.md)
# Amazon EC2 backup and recovery with snapshots and AMIs
Consider whether you need to create a full backup of an EC2 instance with an Amazon Machine Image (AMI) or take a snapshot of an individual volume.
## Using AMIs or Amazon EBS snapshots for backups
An AMI includes the following:
+ One or more snapshots. Instance-store-backed AMIs include a template for the root volume of the instance (for example, an operating system, an application server, and applications).
+ Launch permissions that control which AWS accounts can use the AMI to launch instances.
+ A block device mapping that specifies the volumes to attach to the instance when it’s launched.
**Note**
In most cases, AMIs for Windows, Red Hat, SUSE, and SQL Server require correct licensing information to be present on the AMI. For more information, see [Understand AMI billing information](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html). When creating an AMI from a snapshot, the `RegisterImage` operation derives the correct billing information from the snapshot's metadata, but this requires the appropriate metadata to be present. To verify if the correct billing information was applied, check the **Platform details** field on the new AMI. If the field is empty or doesn't match the expected operating system code (for example, Windows, Red Hat, SUSE, or SQL), the AMI creation was unsuccessful, and you should discard the AMI and follow the instructions in [Create an AMI from an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami).
You can use AMIs to launch new instances with preconfigured software and data. You can create AMIs when you want to establish a baseline, which is a reusable configuration for launching more instances. When you create an AMI of an existing EC2 instance, a snapshot is taken for all the volumes that are attached to the instance. The snapshot includes the device mappings.
You can’t use snapshots to launch a new instance, but you can use them to replace volumes on an existing instance. If you experience data corruption or a volume failure, you can create a volume from a snapshot that you have taken and replace the old volume. You can also use snapshots to provision new volumes and attach them during a new instance launch.
If you are using platform and application AMIs maintained and published by AWS or from the AWS Marketplace, consider maintaining separate volumes for your data. You can back up your data volumes as snapshots that are separate from the operating system and application volumes. Then use the data volume snapshots with newly updated AMIs published by AWS or from the AWS Marketplace. This approach requires careful testing and planning to back up and restore all custom data, including configuration information, on the newly published AMIs.
The restore process is affected by your choice between AMI backups or snapshot backups. If you create AMIs to serve as instance backups, you must launch an EC2 instance from the AMI as a part of your restore process. You might also need to shut down the existing instance to avoid potential collisions. An example of a potential collision is security identifiers (SIDs) for domain-joined Windows instances. The restore process for snapshots might require you to detach the existing volume and attach the newly restored volume. Or you might need to make a configuration change to point your applications to the newly attached volume.
AWS Backup supports both instance-level backups as AMIs and volume-level backups as separate snapshots:
+ For a full backup of all EBS volumes on the instance, [create an AMI of the EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html). When you want to roll back, use the launch instance wizard to create an instance. In the instance launch wizard, choose **My AMIs**.
+ To back up an individual volume, [create a snapshot](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html). To restore the snapshot, see [Create a volume from a snapshot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot). You can use the AWS Management Console or the AWS Command Line Interface (AWS CLI).
The cost of an instance AMI is the storage of all the volumes on the instance, but not the metadata. The cost for an EBS snapshot is the storage of the individual volume. For more information about volume storage costs, see the [Amazon EBS pricing page](https://aws.amazon.com/ebs/pricing/).
## Server volumes
EBS volumes are the primary persistent storage option for Amazon EC2. You can use this block storage for structured data, such as databases, or unstructured data, such as files in a file system on a volume.
EBS volumes are placed in a specific Availability Zone. The volumes are replicated across multiple servers to prevent the loss of data from the failure of any single component. Failure refers to a complete or partial loss of the volume, depending on the size and performance of the volume.
EBS volumes are designed for an annual failure rate (AFR) of 0.1-0.2 percent. This makes EBS volumes 20 times more reliable than typical commodity disk drives, which fail with an AFR of around 4 percent. For example, if you have 1,000 EBS volumes running for 1 year, you should expect one or two volumes will have a failure.
Amazon EBS also supports a snapshot feature for taking point-in-time backups of your data. All EBS volume types offer durable snapshot capabilities and are designed for 99.999 percent availability. For more information, see the [Amazon Compute Service Level Agreement](https://aws.amazon.com/ec2/sla/).
Amazon EBS provides the ability to create snapshots (backups) of any EBS volume. A snapshot is a base feature for creating backups of your EBS volumes. A snapshot takes a copy of the EBS volume and places it in Amazon S3, where it is stored redundantly in multiple Availability Zones. The initial snapshot is a full copy of the volume; ongoing snapshots store incremental block-level changes only. See the [Amazon EBS documentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html) for details on how to create Amazon EBS snapshots.
You can perform a restore operation, delete a snapshot, or update the snapshot metadata, such as tags, associated with the snapshot [from the Amazon EC2 console](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html) in the same Region that you took the snapshot.
Restoring a snapshot creates a new Amazon EBS volume with full volume data. If you need only a partial restore, you can attach the volume to the running instance under a different device name. Then mount it, and use operating system copy commands to copy the data from the backup volume to the production volume.
Amazon EBS snapshots can also be copied between AWS Regions by using the Amazon EBS snapshot copy capability, as described in the [Amazon EBS documentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copy-snapshot.html). You can use this feature to store your backup in another Region without having to manage the underlying replication technology.
## Establishing separate server volumes
You may already use a standard set of separate volumes for the operating system, logs, applications, and data. By establishing separate server volumes, you can reduce the scope of impact when there are application or platform failures caused by disk space exhaustion. This risk is usually greater with physical hard drives, because you don’t have the flexibility to expand volumes quickly. With physical drives, you must purchase the new drives, back up the data, and then restore the data on the new drives. With AWS, this risk is greatly reduced because you can use Amazon EBS to expand your provisioned volumes. For more information, see the [AWS documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-volume-requirements.html).
Maintain separate volumes for application data, user data, logs, and swap files so that you can use separate backup and restore policies for these resources. By separating volumes for your data, you can also use different volume types based on the performance and storage requirements for the data. You can then optimize and fine-tune your costs for different workloads.
## Considerations for instance store volumes
An instance store provides temporary block-level storage for your instance. This storage is located on disks that are physically attached to the host computer. Instance stores are ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content. They are also preferable for data that are replicated across a fleet of instances, such as a load balanced pool of web servers.
The data in an instance store persists only during the lifetime of its associated instance. If an instance reboots (intentionally or unintentionally), data in the instance store persists. However, data in the instance store is lost under any of the following circumstances.
+ The underlying drive fails.
+ The instance stops.
+ The instance terminates.
Therefore, do not rely on an instance store for valuable, long-term data. Instead, use more durable data storage, such as Amazon S3, Amazon EBS, or Amazon EFS.
A common strategy with instance store volumes is to persist necessary data to Amazon S3 regularly as needed, based on the recovery point objective (RPO) and recovery time objective (RTO). You can then download the data from Amazon S3 to your instance store when a new instance is launched. You can also upload the data to Amazon S3 before an instance is stopped. For persistence, create an EBS volume, attach it to your instance, and copy the data from the instance store volume to the EBS volume on a periodic basis. For more information, see the [AWS Knowledge Center](https://aws.amazon.com/premiumsupport/knowledge-center/back-up-instance-store-ebs/).
## Tagging and enforcing standards for EBS snapshots and AMIs
Tagging all your AWS resources is an important practice for cost allocation, auditing, troubleshooting, and notification. Tagging is important for EBS volumes so that the pertinent information required to manage and restore volumes is present. Tags are not automatically copied from EC2 instances to AMIs or from source volumes to snapshots. Make sure that your backup process includes the relevant tags from these sources. This helps you to set the snapshot metadata, such as access policies, attachment information, and cost allocation, to use these backups in the future. For more information on tagging your AWS resources, refer to the [tagging best practices technical paper](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf).
In addition to the tags you use for all AWS resources, use the following backup-specific tags:
+ Source instance ID
+ Source volume ID (for snapshots)
+ Recovery point description
You can enforce tagging policies by using AWS Config rules and IAM permissions. IAM supports enforced tag usage, so you can write IAM policies that mandate the use of specific tags when acting on Amazon EBS snapshots. If a `CreateSnapshot` operation is attempted without the tags defined in the IAM permissions policy granting rights, the snapshot creation fails with access denied. For more information, see the [blog post on tagging Amazon EBS snapshots on creation and implementing stronger security policies](https://aws.amazon.com/blogs/compute/tag-amazon-ebs-snapshots-on-creation-and-implement-stronger-security-policies/).
You can use AWS Config rules to evaluate the configuration settings of your AWS resources automatically. To help you get started, AWS Config provides customizable, predefined rules called managed rules. You can also create your own custom rules. While AWS Config continuously tracks configuration changes among your resources, it checks whether these changes violate any of the conditions in your rules. If a resource violates a rule, AWS Config flags the resource and the rule as *noncompliant*. Note that the [required-tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html) managed rule does not currently support snapshots and AMIs.
# Creating EBS volume backups with AMIs and EBS snapshots
AWS provides a wealth of options for creating and managing AMIs and snapshots. You can use the approach that meets your needs. A common issue that many customers face is managing the snapshot lifecycle and clearly aligning snapshots by purpose, retention policy, etc. Without proper tagging, there is a risk that snapshots might be deleted accidentally or as part of an automated cleanup process. You might also end up paying for obsolete snapshots that are retained because there is no clear understanding whether they are still needed.
## Preparing an EBS volume before creating a snapshot or AMI
Before you take a snapshot or create an AMI, make the necessary preparations to your EBS volume. Creating an AMI results in a new snapshot for each EBS volume that is attached to the instance, so these preparations also apply to AMIs.
You can take a snapshot of an attached EBS volume that is in use by a powered-on EC2 instance. However, snapshots capture only data that has been written to your EBS volume at the time the snapshot command is issued. This might exclude any data that has been cached by applications or the operating system. A best practice is to have the system in a state where it is not performing any I/O. Ideally, the machine isn’t accepting traffic and is in a stopped state, but this is rare as 24/7 IT operations become the norm. If you can flush any data from system memory to the disk being used by your applications and pause any file writes to the volume long enough to take a snapshot, your snapshot should be complete.
To make a clean backup, you must quiesce the database or file system. The way in which you do this depends on your database or file system.
The process for a database is as follows:
1. If possible, put the database into hot backup mode.
1. Run the Amazon EBS snapshot commands.
1. Take the database out of hot backup mode or, if using a read replica, terminate the read replica instance.
The process for a file system is similar, but it depends on the capabilities of the operating system or file system. For example, XFS is a file system that can flush its data for a consistent backup. For more information, see [xfs\$1freeze](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/xfsfreeze). Alternatively, you can facilitate this process by using a logical volume manager that supports the freezing of I/O.
However, if you can't flush or pause all file writes to the volume, do the following:
1. Unmount the volume from the operating system.
1. Issue the snapshot command.
1. Remount the volume to achieve a consistent and complete snapshot. You can remount and use your volume while the snapshot status is pending.
The snapshot process continues in the background and snapshot creation is fast and captures a point in time. The volumes that you’re backing up are unmounted for only a matter of seconds. You can schedule a small backup window where an outage is expected and handled by clients gracefully.
When you create a snapshot for an EBS volume that serves as a root device, stop the instance before you take the snapshot. Windows provides the Volume Shadow Copy Service (VSS) to help create application-consistent snapshots. AWS provides a Systems Manager document that you can run to take image-level backups of VSS-aware applications. The snapshots include data from pending transactions between these applications and the disk. You don’t have to shut down your instances or disconnect them when you back up all attached volumes. For more information, see the [AWS documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html).
**Note**
If you are creating a Windows AMI so that you can deploy another similar instance, use [EC2Config or EC2Launch](https://aws.amazon.com/premiumsupport/knowledge-center/sysprep-create-install-ec2-windows-amis/) to [Sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview) your instance. Then create an AMI from the stopped instance. Sysprep removes unique information from the Amazon EC2 Windows instance, including the SIDs, computer name, and drivers. Duplicate SIDs can cause issues with Active Directory, Windows Server Update Services (WSUS), login issues, Windows volume key activation, Microsoft Office, and third-party products. Do not use Sysprep with your instance if your AMI is for backup purposes and you want to restore the same instance with all its unique information intact.
## Creating EBS volume snapshots manually from the console
Create snapshots of the appropriate volumes or the entire instance before you make any major changes that have not been fully tested on the instance. For example, you might want to create a snapshot before you upgrade or patch application or system software on your instance.
You can create a snapshot manually from the console. On the Amazon EC2 console, on the **Elastic Block Store Volumes **page, select the volume that you want to back up. Then on the **Actions** menu, choose **Create Snapshot**. You can search for volumes that are attached to a specific instance by entering the instance ID in the filter box.
Enter a description and add the appropriate tags. Add a `Name` tag to make it easier to find the volume later. Add any other appropriate tags based on your tagging strategy.
## Creating AMIs
An AMI provides the information that is required to launch an instance. The AMI includes the root volume and snapshots of the EBS volumes attached to the instance when the image was created. You can’t launch new instances from EBS snapshots alone; you must launch new instances from an AMI.
When you create an AMI, it is created in the account and Region that you are using. The AMI creation process creates Amazon EBS snapshots for each volume attached to the instance, and the AMI refers to these Amazon EBS snapshots. These snapshots reside in Amazon S3 and are highly durable.
After you create an AMI of your EC2 instance, you can use the AMI to re-create the instance or launch more copies of the instance. You can also copy AMIs from one Region to another for application migration or DR.
![\[Creating an image, launching the image to an instance, and creating a copy of the image.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/images/ami-process.png)
An AMI must be created from an EC2 instance unless you are migrating a virtual machine, such as a VMWARE virtual machine, to AWS. To create an AMI from the Amazon EC2 console, select the instance, choose **Actions**, choose **Image**, and then choose **Create Image**.
## Amazon Data Lifecycle Manager
To automate the creation, retention, and deletion of Amazon EBS snapshots, you can use [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html). Automating snapshot management helps you to do the following:
+ Protect valuable data by enforcing a regular backup schedule.
+ Retain backups as required by auditors or internal compliance.
+ Reduce storage costs by deleting outdated backups.
Using Amazon Data Lifecycle Manager, you can automate the snapshot management process for EC2 instances (and their attached EBS volumes) or separate EBS volumes. It supports options such as cross-Region copy, so you can copy snapshots automatically to other AWS Regions. Copying snapshots to alternative Regions is one approach to support DR efforts and restore options in an alternative Region. You can also use Amazon Data Lifecycle Manager to create a snapshot lifecycle policy that supports [fast snapshot restore](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html).
Amazon Data Lifecycle Manager is an included feature of Amazon EC2 and Amazon EBS. There is no charge for Amazon Data Lifecycle Manager.
## AWS Backup
AWS Backup is unique from Amazon Data Lifecycle Manager because you can create a backup plan that includes resources across multiple AWS services. You can coordinate your backup to cover the resources you are using together rather than coordinating the backups of the resources individually.
AWS Backup also includes the concept of backup vaults, which can restrict access to the recovery points for your completed backups. Restore operations can be initiated from AWS Backup rather than proceeding to each individual resource and restoring the backup created. AWS Backup also includes a host of additional features, such as audit management and reporting. For more information, see the [Backup and recovery using AWS Backup[Backup and recovery using AWS Backup](aws-backup.md)](aws-backup.md) section of this guide.
## Performing multi-volume backups
If you want to back up the data on the EBS volumes in a RAID array using snapshots, the snapshots must be consistent. This is because the snapshots of these volumes are created independently. Restoring EBS volumes in a RAID array from snapshots that are out of sync degrades the integrity of the array.
To create a consistent set of snapshots for your RAID array, use the [CreateSnapshots](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSnapshots.html) API operation, or log in to the Amazon EC2 console and choose **Elastic Block Store**, **Snapshots**, **Create Snapshot**.
![\[The Create Snapshot screen for creating a multiple volume snapshot.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/images/multi-volume-snapshot.png)
Snapshots of instances that have multiple volumes attached in a RAID configuration are taken as a multi-volume snapshot, collectively. Multi-volume snapshots provide point-in-time, data-coordinated, and crash-consistent snapshots across multiple EBS volumes attached to an EC2 instance. You do not have to stop your instance to coordinate between volumes to achieve consistency because snapshots are automatically taken across multiple EBS volumes. After the snapshot for the volumes is initiated (usually a second or two), the file system can continue its operations.
After the snapshots are created, each snapshot is treated as an individual snapshot. You can perform all snapshot operations, such as restore, delete, and cross-Region and account copy, as you would with a single-volume snapshot. You can also tag your multi-volume snapshots as you would a single-volume snapshot. We recommend that you tag your multi-volume snapshots to manage them collectively during restore, copy, or retention. For more information, see the [AWS documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html).
You can also perform these backups from a logical volume manager or a file system–level backup. In these cases, using a traditional backup agent enables the data to be backed up over the network. A number of agent-based backup solutions are available on the internet and in the [AWS Marketplace](https://aws.amazon.com/marketplace/).
An alternative approach is to create a replica of the primary system volumes that exist on a single large volume. This simplifies the backup process, because only one large volume must be backed up, and the backup does not take place on the primary system. However, first determine whether the single volume can perform sufficiently during the backup and whether the maximum volume size is appropriate for the application.
## Protecting your Amazon EC2 backups
It is important to consider the security of your backups and to prevent accidental or malicious deletion of your backups. You can use a number of approaches collectively to accomplish this. To prevent the loss of your critical backups due to a security breach, we recommend that you copy your backups to another AWS account. If you have multiple AWS accounts, you can designate a separate account as your archive account to which all the other accounts can copy backups. For example, you can accomplish this with a [cross-account backup in AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html).
Your disaster recovery plan might also require you to be able to reproduce EC2 instances in another AWS Region in case of a regional failure. You can support this goal by copying your backups to another Region within the same account. This can provide an additional layer of accidental deletion protection as well as support disaster recovery (DR) objectives. AWS Backup provides support for [cross-Region backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html).
Consider blocking IAM permissions to the [ec2:DeleteSnapshot](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteSnapshot.html) and [ec2:DeregisterImage](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeregisterImage.html) actions. Instead, you can let your retention policies and methods manage the lifecycle of EBS snapshots and Amazon EC2 AMIs. Blocking delete actions is one way to implement a write-once, read-many (WORM) strategy for your EBS snapshots. You can also use [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html), which provides support for EBS snapshots and other AWS resources.
Additionally, consider blocking the ability for users to share AMIs and EBS snapshots by blocking the [ec2:ModifyImageAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html) and [ec2:ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html) IAM actions. This will prevent your AMIs and snapshots from being shared with AWS accounts that are external to your organization. If you are using AWS Backup, limit users from performing similar operations on backup vaults. For more information, see the [Backup and recovery using AWS Backup](aws-backup.md) section of this guide.
Amazon EBS includes a [Recycle Bin feature](https://docs.aws.amazon.com/ebs/latest/userguide/recycle-bin.html) that can help you restore accidentally deleted EBS snapshots. If you allow your users to delete snapshots, turn this feature on so that needed snapshots aren’t permanently deleted. Users should be particularly careful about deleting multiple snapshots, because the Amazon EC2 console allows you to select multiple snapshots and delete them in one operation. Additionally, be careful when you use cleanup scripts and automation so that you don’t unintentionally delete snapshots you need. The Recycle Bin feature helps provide protection from these types of situations.
## Archiving EBS snapshots
[Archiving your EBS snapshots](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html) can be a cost-effective method for keeping a copy of a volume for reference purposes that you don’t intend to restore for 90 or more days. This can be a good intermediate step before permanently deleting all related snapshots for an EBS volume. For example, you might consider archiving snapshots as an end-of-lifecycle step for EBS volumes that are no longer used. Archiving rather than deleting can also be a more cost effective method of deletion retention instead of using the Recycle Bin.
## Automating snapshot and AMI creation with Systems Manager, the AWS CLI, and the AWS SDKs
Your backup approach might require operations before and after a snapshot or AMI is created. For example, you might need to stop and start services to quiesce the file system. Or you might need to stop and start your instance during AMI creation. You might also need to create backups of multiple components in your architecture collectively, each with its own pre-creation and post-creation steps.
You can reduce your maintenance window times for your backups by automating your process and verifying that your backup process is consistently applied. To automate your custom pre-creation and post-creation operations, script your backup process by using the AWS CLI and the SDK.
Your automation can be defined in a Systems Manager runbook that can be run on demand or during a Systems Manager maintenance window. You can grant your users access to run Systems Manager runbooks without the need to grant them permissions to Amazon EC2 disruptive commands. This can also help you verify that your backup process and tags are applied consistently by your users. You can use the [AWS-CreateSnapshot](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-createsnapshot.html) and [AWS-CreateImage](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-createimage.html) runbooks for creating snapshots and AMIs, or you can grant other users permissions to use them. Systems Manager also includes the [AWS-UpdateLinuxAmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-updatelinuxami.html) and [AWS-UpdateWindowsAmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-updatewindowsami.html) runbooks to automate the AMI patching and AMI creation.
You can also use the AWS CLI and [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/) to automate your snapshot and AMI creation process. You can use the [aws ec2 create-snapshot](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-snapshot.html) AWS CLI command to create a snapshot of an EBS volume as one step in your automation. You can use the [aws ec2 create-snapshots](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-snapshots.html) command to create crash-consistent, synchronized snapshots of all volumes that are attached to your EC2 instance.
You can use the AWS CLI to create new AMIs. You can use the [aws ec2 register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) command to create a new image for your EC2 instance. To automate the shutdown, image creation, and restart of your instances, combine this command with the [aws ec2 stop-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html) and [aws ec2 start-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/start-instances.html) commands.
# Restoring an Amazon EBS volume or an EC2 instance
If you need to restore only a single volume attached to an EC2 instance, you can restore that volume separately, detach the existing volume, and attach the restored volume to your EC2 instance. If you need to restore an entire EC2 instance, including all of its associated volumes, you must use an Amazon Machine Image (AMI) backup of your instance.
To reduce the recovery time and impact to dependent applications and processes, your restore process must consider the resource that it is replacing. For best results, regularly test your restore process in lower environments (for example, non-production) to verify that your process meets your recovery point objective (RPO) and recovery time objective (RTO) and that the restore process works as expected. Consider how the restore process will impact applications and services that depend on the instance you are restoring, and then coordinate the restore as necessary. Try to automate and test the restore process as much as possible to reduce the risk of your restore process failing or being implemented inconsistently.
If you use Elastic Load Balancing, with multiple instances servicing traffic, you can take a failed or impaired instance out of service. Then you can restore a new instance to replace it while the other instances continue to service traffic without disruption to users.
The following restore processes described are for instances that are not using Elastic Load Balancing:
+ Restoring individual files and directories from EBS snapshots
+ Restoring an EBS volume from an Amazon EBS snapshot
+ Creating or restoring an EC2 instance from an EBS snapshot
+ Restoring a running instance from an AMI
## Restoring files and directories from EBS snapshots
[EBS snapshots](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html) provide a point-in-time exact replica of the original volume that was used to create the snapshot. To restore individual files or directories, you must do the following:
1. [First, restore the volume from the EBS snapshot](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html#restore-snapshot) that contains the files or directories.
1. Attach the volume to the EC2 instance to which you want to restore the files.
1. Copy the files from the restored volume to your EC2 instance volume.
1. Detach and delete the restored volume.
## Restoring an EBS volume from an Amazon EBS snapshot
You can restore a volume attached to an existing EC2 instance by creating a volume from its snapshot and attaching it to your instance. You can use the console, the AWS CLI, or the API operations to create a volume from an existing snapshot. You can then mount the volume to the instance by using the operating system.
Note that data from an Amazon EBS snapshot is asynchronously loaded into an EBS volume. If an application accesses the volume where the data is not loaded, there is higher latency than normal while the data is loaded from Amazon S3. To avoid this impact for latency-sensitive applications, you have two options:
+ You can [initialize the EBS volume](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html).
+ For an additional charge, Amazon EBS supports [fast snapshot restore](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html), which eliminates the need initialize your volume.
If you are replacing a volume that must use the same mount point, unmount that volume so that you can mount the new volume in its place. To unmount the volume, first stop any processes that are using the volume. If you are replacing the root volume, you must stop the instance first before you can detach the root volume.
For example, follow these steps to restore a volume to an earlier point-in-time backup by using the console:
1. On the Amazon EC2 console, on the **Elastic Block Store** menu, choose **Snapshots**.
1. Search for the snapshot that you want to restore, and select it.
1. Choose **Actions**, and then choose **Create Volume**.
1. Create the new volume in the same Availability Zone as your EC2 instance.
1. On the Amazon EC2 console, select the instance.
1. In the instance details, make note of the device name that you want to replace in the **Root device** entry or **Block Devices** entries.
1. Attach the volume. The process differs for root volumes and non-root volumes.
For root volumes:
1. Stop the EC2 instance.
1. On the **EC2 Elastic Block Store Volumes** menu, select the root volume that you want to replace.
1. Choose **Actions**, and then choose **Detach Volume**.
1. On the **EC2 Elastic Block Store Volumes** menu, select the new volume.
1. Choose **Actions**, and then choose **Attach Volume**.
1. Select the instance that you want to attach the volume to, and use the same device name that you noted earlier.
For non-root volumes:
1. On the **EC2 Elastic Block Store Volumes** menu, select the non-root volume that you want to replace.
1. Choose **Actions**, and then choose **Detach Volume**.
1. Attach the new volume by choosing it on the **EC2 Elastic Block Store Volumes** menu and then choosing **Actions**, **Attach Volume**. Select the instance that you want to attach it to, and then select an available device name.
1. Using the operating system for the instance, unmount the existing volume, and then mount the new volume in its place.
In Linux, you can use the `umount` command. In Windows, you can use a logical volume manager (LVM) such as the Disk Management system utility.
1. Detach any prior volumes that you may be replacing by choosing it on the **EC2 Elastic Block Store Volumes** menu and then choosing **Actions**, **Detach Volume**.
You can also use the AWS CLI in combination with operating system commands to automate these steps.
## Creating or restoring an EC2 instance from an EBS snapshot
To create a backup that will be used to restore an entire EC2 instance, we recommend creating an Amazon Machine Image (AMI). AMIs capture machine information such as virtualization type. They also create snapshots for each volume that is attached to the EC2 instance, including their device mappings, so that they can be restored in the same configuration.
**Note**
In most cases, AMIs for Windows, Red Hat, SUSE, and SQL Server require correct licensing information to be present on the AMI. For more information, see [Understand AMI billing information](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html). When creating an AMI from a snapshot, the `RegisterImage` operation derives the correct billing information from the snapshot's metadata, but this requires the appropriate metadata to be present. To verify if the correct billing information was applied, check the **Platform details** field on the new AMI. If the field is empty or doesn't match the expected operating system code (for example, Windows, Red Hat, SUSE, or SQL), the AMI creation was unsuccessful, and you should discard the AMI and follow the instructions in [Create an AMI from an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami).
If you must use an EBS snapshot to restore an instance, first create an AMI from an EBS snapshot that will become the root volume for your new EC2 instance:
1. On the Amazon EC2 console, on the **Elastic Block Store** menu, choose **Snapshots**.
1. Search for the snapshot that will be used to create the root volume for your new EC2 instance, and select it.
1. Choose **Actions**, and then choose **Create Image from Snapshot**.
1. Enter a name for your image (for example, `YYYYMMDD-restore-for-i-012345678998765de`), and choose the appropriate options for your new image.
1. (Windows, Red Hat, SUSE, and SQL Server only) To verify if the correct billing information was applied, check the **Platform details** field on the new AMI. If the field is empty or doesn't match the expected operating system code (for example, **Windows** or **Red Hat**), the AMI creation was unsuccessful, and you should discard the AMI and follow the instructions in [Create an AMI from an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami).
After the image is created and available, you can launch a new EC2 instance that will use the EBS snapshot for the root volume.
## Restoring a running instance from an AMI
You can bring up a new instance from your AMI backup to replace an existing, running instance. One approach is to stop the existing instance, keep it offline while you launch a new instance from your AMI, and perform any necessary updates. This approach reduces the risk of conflicts from both instances running simultaneously. It is an acceptable approach if the services that your instance provides are down or you are performing the restore during a maintenance window. After you test your new instance, you can reassign any Elastic IP addresses that were allocated to the old instance. Then you can update any Domain Name Service (DNS) records to point to the new instance.
However, if during a restore you must minimize the downtime of your in-service instance, consider launching and testing a new instance from your AMI backup. Then replace the existing instance with the new instance.
While both instances are running, you must prevent the new instance from causing any platform-level or application-level collisions. For example, you might run into problems with domain-joined Windows instances that are running with the same SIDs and computer name. You might encounter similar issues with network applications and services that require unique identifiers.
To prevent other servers and services from connecting to your new instance before it's ready, use security groups to temporarily block all inbound connections for your new instance except for your own IP address for access and testing. You can also block outbound connections temporarily for the new instance to prevent services and applications from initiating any connections or updates to other resources. When the new instance is ready, stop the existing instance, start services and processes on the new instance, and then unblock any inbound or outbound network connections that you implemented.