# Backup and restore for DynamoDB DynamoDB offers on-demand backups and point-in-time recovery (PITR) backups to help protect your DynamoDB data from disaster events and offers data archiving for long-term retention. You can back up tables from a few megabytes to hundreds of terabytes of data, with no impact on performance and availability to your production applications. All backups are automatically encrypted, cataloged, and easily discoverable. With on-demand backups, you can create a snapshot backup of your table that DynamoDB stores and manages. You're charged based on the size and duration of your backups. Using on-demand backup, you can restore your entire DynamoDB table to the exact state it was in when the backup was created. There are two options for creating and managing DynamoDB on-demand backups: + DynamoDB + [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) You can use the DynamoDB on-demand backup capability to create full backups of your tables for long-term retention, and archiving for regulatory compliance needs. You can back up and restore your table data anytime from the AWS Management Console or with a single API call. Point-in-time recovery (PITR) backups are fully managed by DynamoDB and provide up to 35 days of recovery points at a per second granularity. To use point-in-time recovery, which are continuous backups, enable point-in-time recovery (PITR) on your DynamoDB table. You get charged based on the size of your DynamoDB table for the duration you have PITR enabled on the table. Enabling Point-in-Time Recovery (PITR) on your DynamoDB table continuously backs up your data. This helps you restore your table to a specific point in time within the PITR recovery period by creating a new DynamoDB table with the exact state of your original table at that point in time. Point-in-time recovery helps protect your DynamoDB tables from accidental write or delete operations. With point-in-time recovery, you don't have to worry about creating, maintaining, or scheduling on-demand backups. For example, suppose that a test script writes accidentally to a production DynamoDB table. With point-in-time recovery, you can restore your table to any point in time during the last 35 days. You can set the recovery period to any value between 1 and 35 days. After you enable point-in-time recovery, you can restore to any point in time from five minutes before the current time until the configured recovery period. DynamoDB maintains incremental backups of your table. In addition, point-in-time operations don't affect performance or API latencies. You can restore a DynamoDB table to a point in time using the AWS Management Console, the AWS Command Line Interface (AWS CLI), or the DynamoDB API. The point-in-time recovery process restores to a new table. For more information about AWS Region availability and pricing, see [Amazon DynamoDB pricing](https://aws.amazon.com/dynamodb/pricing). **Note** Tagging and [attribute-based access control (ABAC)](access-control-resource-based.md) aren't supported for DynamoDB backups. To use ABAC with backups, we recommend that you use [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html). Tags aren't preserved in restored tables. You need to add tags to restored tables before you can use tag-based conditions in your policies. The following video will give you an introductory look at the backup and restore concept and talk more about point-in-time recovery. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/g4WPLFXLwDE/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/g4WPLFXLwDE) **Topics** + [Point-in-time backups for DynamoDB](Point-in-time-recovery.md) + [Using on-demand DynamoDB backup and restore](backuprestore_HowItWorks.md) + [Understanding Amazon DynamoDB billing for backups](backup-restore-billing.md) + [Restore a table in DynamoDB](pointintimerecovery_restores.md) + [Using AWS Backup with DynamoDB](backuprestore_HowItWorksAWS.md) # Point-in-time backups for DynamoDB Amazon DynamoDB point-in-time recovery (PITR) provides automatic continuous backups of your DynamoDB table data. Point-in-time recovery (PITR) backups are fully managed by DynamoDB and provide up to 35 days of recovery points at a per second granularity. With point-in-time recovery, you don't have to worry about creating, maintaining, or scheduling on-demand backups. This section provides an overview of how the process works in DynamoDB. ## Before you begin Before you enable point-in-time recovery (PITR) on an Amazon DynamoDB table, consider the following: + Setting the `RecoveryPeriodinDays` allows you to shorten the time period for which continuous backups are taken. By default, your `RecoveryPeriodinDays` is 35. However, you can set it to be any value between 1 and 35. Shortening the `RecoveryPeriodinDays` has no impact on PITR pricing because the price is based on the size of table and local secondary indexes. + If you disable point-in-time recovery and later re-enable it on a table, you reset the start time for which you can recover that table. As a result, you can only immediately restore that table using the `LatestRestorableDateTime`. + You can enable point-in-time recovery on each local replica of a global table. When you restore the table, the backup restores to an independent table that is not part of the global table. If you are using [Global Tables version 2019.11.21 (Current)](GlobalTables.md) of global tables, you can create a new global table from the restored table. For more information, see [How DynamoDB global tables work](V2globaltables_HowItWorks.md). + You can also restore your DynamoDB table data across AWS Regions such that the restored table is created in a different Region from where the source table resides. You can do cross-Region restores between AWS commercial Regions, AWS China Regions, and AWS GovCloud (US) Regions. You pay only for the data you transfer out of the source Region and for restoring to a new table in the destination Region. + AWS CloudTrail logs all console and API actions for point-in-time recovery to enable logging, continuous monitoring, and auditing. For more information, see [Logging DynamoDB operations by using AWS CloudTrail](logging-using-cloudtrail.md). **Topics** + [Before you begin](#Point-in-time-before-beginning) + [Enable point-in-time recovery in DynamoDB](PointInTimeRecovery_Howitworks.md) # Enable point-in-time recovery in DynamoDB Amazon DynamoDB point-in-time recovery (PITR) provides automatic backups of your DynamoDB table data. This section provides an overview of how the process works in DynamoDB. **Note** DynamoDB charges for PITR based on the size of each DynamoDB table, including table data and local secondary indexes. Changing the recovery window (for example, from 35 days to 1 day) doesn't reduce the price. The cost remains the same regardless of the recovery period you choose. The configured maximum recovery period doesn't impact the price you're charged for turning on PITR. To determine your backup charges, DynamoDB continuously monitors the size of the tables that have PITR turned on. You're billed for PITR usage until you turn off PITR for each table. **Topics** + [Enabling point-in-time recovery](#howitworks_enabling) + [Enable PITR (console)](#howitworks-enable-pitr-console) + [Enable PITR (AWS CLI)](#howitworks-enable-pitr-cli) + [Enable PITR (CloudFormation)](#howitworks-enable-pitr-cfn) + [Enable PITR (API)](#howitworks-enable-pitr-api) + [Recovery Period](#howitworks-pitr-recovery-period) + [Edit PITR](#howitworks-pitr-editing) + [Delete a table with PITR enabled](#howitworks-pitr-deleting-table) ## Enabling point-in-time recovery You can enable point-in-time recovery using the AWS Management Console, AWS Command Line Interface (AWS CLI), or the DynamoDB API. When enabled, point-in-time recovery provides continuous backups until you explicitly turn it off. After you enable point-in-time recovery, you can restore to any point in time within `EarliestRestorableDateTime` and `LatestRestorableDateTime`. `LatestRestorableDateTime` is typically five minutes before the current time. For more information, see [Restoring a DynamoDB table to a point in time](PointInTimeRecovery.Tutorial.md). **Note** The point-in-time recovery process always restores to a new table. ## Enable PITR (console) **To enable PITR using the DynamoDB console** 1. Navigate to the DynamoDB console. 1. Choose **Tables** from the left navigation and select your DynamoDB table. 1. From the **Backups** tab, for the **Point in Time Recovery** option, choose **Edit**. 1. Choose **Turn on point-in-time recovery**. 1. Choose a value between 1 and 35 for your backup recovery period. This indicates the maximum time period for which the continuous backup is recoverable. ## Enable PITR (AWS CLI) **Note** If you receive errors when running AWS CLI commands, see [Troubleshoot AWS CLI errors](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-troubleshooting.html). Make sure you're using the most recent AWS CLI version. Run the [update-continuous-backups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/dynamodb/update-continuous-backups.html) command with the **point-in-time-recovery-specification** setting turned on: ``` aws dynamodb update-continuous-backups \ --table-name Music \ --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true,RecoveryPeriodInDays=35 ``` ## Enable PITR (CloudFormation) Use the [AWS::DynamoDB::Table](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html) resource with the `PointInTimeRecoverySpecification` property turned on: ``` Resources: iotCatalog: Type: AWS::DynamoDB::Table Properties: ... PointInTimeRecoverySpecification: PointInTimeRecoveryEnabled: true RecoveryPeriodInDays: 35 ``` **Request syntax example:** ``` { "PointInTimeRecoverySpecification": { "PointInTimeRecoveryEnabled": boolean, "RecoveryPeriodInDays: number }, "TableName": "string" } ``` ## Enable PITR (API) Run the [UpdateContinuousBackups](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateContinuousBackups.html) API operation with the `PointInTimeRecoverySpecification` parameter turned on. **Request syntax example:** ``` { "PointInTimeRecoverySpecification": { "PointInTimeRecoveryEnabled": boolean, "RecoveryPeriodInDays" : number }, "TableName": "string" } ``` **Response syntax example:** ``` { "ContinuousBackupsDescription": { "ContinuousBackupsStatus": "string", "PointInTimeRecoveryDescription": { "PointInTimeRecoveryStatus": "string", "EarliestRestorableDateTime": number, "RecoveryPeriodInDays": number, "LatestRestorableDateTime": number } } } ``` **Python** ``` import boto3 dynamodb = boto3.client('dynamodb') response = dynamodb.update_continuous_backups( TableName=, PointInTimeRecoverySpecification={ 'PointInTimeRecoveryEnabled': True, 'RecoveryPeriodInDays': 35 } ) ``` ## Recovery Period You can set the recovery period for continuous backups to be any number between 1 and 35 days. This `RecoveryPeriodInDays` determines the time period for which your continuous backups are maintained. For example, if you set this value to be 30 days, you'll only have the ability to restore your table to any point in time from the past 30 days. **Note** DynamoDB charges for PITR based on the size of each DynamoDB table, including table data and local secondary indexes. The configured maximum recovery period doesn't impact the price you're charged for turning on PITR. For details on pricing, see [DynamoDB pricing](https://aws.amazon.com/dynamodb/pricing/on-demand/). ## Edit PITR You can edit the PITR setting on your table and change the recovery period. If you change the recovery period and increase it to a value higher than previously set, your `EarliestRestorePoint` will not change immediately. Since the recovery period is a rolling window, DynamoDB will continue to take automatic backups until the new increased period reached. If you change the recovery period and decrease it to a value lower than previously set, your `EarliestRestorePoint` will immediately decrease to match your recovery period, and any continuous backups that fall outside of the new set value will not be recoverable. ## Delete a table with PITR enabled When you delete a table that has point-in-time recovery enabled, DynamoDB automatically creates a backup snapshot called a *system backup* and retains it for 35 days (at no additional cost). You can use the system backup to restore the deleted table to the state it was in before deletion. All system backups follow a standard naming convention of *table-name*`$DeletedTableBackup`. **Note** Once a table with point-in-time recovery enabled is deleted, you can use system backup to restore that table to a single point in time. The system backup will be created upon table deletion, and is a snapshot of the table right before the table is deleted. # Using on-demand DynamoDB backup and restore Amazon DynamoDB supports stand-alone on-demand backup and restore features. Those features are available to you independent of whether you use AWS Backup. You can use the DynamoDB on-demand backup capability to create full backups of your tables for long-term retention and archival for regulatory compliance needs. You can back up and restore your table data anytime with a single click on the AWS Management Console or with a single API call. Backup and restore actions run with zero impact on table performance or availability. You can create table backups using the console, the AWS Command Line Interface (AWS CLI), or the DynamoDB API. For more information, see [Backing up a DynamoDB table](Backup.Tutorial.md). For information about restoring a table from a backup, see [Restoring a DynamoDB table from a backup](Restore.Tutorial.md). # Backing up and restoring DynamoDB tables with DynamoDB: How it works You can use the DynamoDB on-demand backup feature to create full backups of your Amazon DynamoDB tables. This feature is available independently from AWS backup. This section provides an overview of what happens during the DynamoDB backup and restore process. ## Backups When you create an on-demand backup with DynamoDB, a time marker of the request is cataloged. The backup is created asynchronously by applying all changes until the time of the request to the last full table snapshot. DynamoDB backup requests are processed instantaneously and become available for restore within minutes. **Note** Each time you create an on-demand backup, the entire table data is backed up. There is no limit to the number of on-demand backups that can be taken. All backups in DynamoDB work without consuming any provisioned throughput on the table. DynamoDB backups do not guarantee causal consistency across items; however, the skew between updates in a backup is usually much less than a second. While a backup is in progress, you can't do the following: + Pause or cancel the backup operation. + Delete the source table of the backup. + Disable backups on a table if a backup for that table is in progress. If you don't want to create scheduling scripts and cleanup jobs, you can use AWS Backup to create backup plans with schedules and retention policies for your DynamoDB tables. AWS Backup runs the backups and deletes them when they expire. For more information, see the [AWS Backup Developer Guide](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html). In addition to AWS Backup, you can schedule periodic or future backups by using AWS Lambda functions. For more information, see the blog post [A serverless solution to schedule your Amazon DynamoDB On-Demand backup](https://aws.amazon.com/blogs/database/a-serverless-solution-to-schedule-your-amazon-dynamodb-on-demand-backup/). If you're using the console, any backups created using AWS Backup are listed on the **Backups** tab with the **Backup type** set to `AWS`. **Note** You can't delete backups marked with a **Backup type** of AWS using the DynamoDB console. To manage these backups, use the AWS Backup console. To learn how to perform a backup, see [Backing up a DynamoDB table](Backup.Tutorial.md). ## Restores You restore a table without consuming any provisioned throughput on the table. You can do a full table restore from your DynamoDB backup, or you can configure the destination table settings. When you do a restore, you can change the following table settings: + Global secondary indexes (GSIs) + Local secondary indexes (LSIs) + Billing mode + Provisioned read and write capacity + Encryption settings **Important** When you do a full table restore, the destination table is set with the same provisioned read capacity units and write capacity units as the source table, as recorded at the time the backup was requested. The restore process also restores the local secondary indexes and the global secondary indexes. You can also restore your DynamoDB table data across AWS Regions such that the restored table is created in a different Region from where the backup resides. You can do cross-Region restores between AWS commercial Regions, AWS China Regions, and AWS GovCloud (US) Regions. You pay only for the data that you transfer out of the source Region and for restoring to a new table in the destination Region. Restores can be faster and more cost-efficient if you choose to exclude some or all secondary indexes from being created on the new restored table. You must manually set up the following on the restored table: + Auto scaling policies + AWS Identity and Access Management (IAM) policies + Amazon CloudWatch metrics and alarms + Tags + Stream settings + Time to Live (TTL) settings + Deletion protection settings + Point in time recovery (PITR) settings You can only restore the entire table data to a new table from a backup. You can write to the restored table only after it becomes active. **Note** You can't overwrite an existing table during a restore operation. Restore times are directly related to the configuration of your tables (such as the size of your tables and the number of underlying partitions) and other related variables. A best practice when planning for disaster recovery is to regularly document average restore completion times and establish how these times affect your overall Recovery Time Objective. To learn how to perform a restore, see [Restoring a DynamoDB table from a backup](Restore.Tutorial.md). You can use IAM policies for access control. For more information, see [Using IAM with DynamoDB backup and restore](backuprestore_IAM.md). All backup and restore console and API actions are captured and recorded in AWS CloudTrail for logging, continuous monitoring, and auditing. # Backing up a DynamoDB table This section describes how to use the Amazon DynamoDB console or the AWS Command Line Interface to back up a table. **Topics** ## Creating a table backup (console) Follow these steps to create a backup named `MusicBackup` for an existing `Music` table using the AWS Management Console. **To create a table backup** 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. You can create a backup by doing one of the following: + On the **Backups** tab of the `Music` table, choose **Create backup**. + In the navigation pane on the left side of the console, choose **Backups**. Then choose **Create backup**. 1. Make sure that `Music` is the table name, and enter **MusicBackup** for the backup name. Then, choose **Create backup** to create the backup. ![\[Create backup console screen with the table name and backup name filled in.\]](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/images/confirm_createbackup.png) **Note** If you create backups using the **Backups** section in the navigation pane, the table isn't preselected for you. You have to manually choose the source table name for the backup. While the backup is being created, the backup status is set to **Creating**. After the backup is complete, the backup status changes to **Available**. ![\[On-demand backups console page. Status of MusicBackup is showing as Available.\]](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/images/confirm_backup.png) ## Creating a table backup (AWS CLI) Follow these steps to create a backup for an existing table `Music` using the AWS CLI. **To create a table backup** + Create a backup with the name `MusicBackup` for the `Music` table. ``` aws dynamodb create-backup --table-name Music \ --backup-name MusicBackup ``` While the backup is being created, the backup status is set to `CREATING`. ``` { "BackupDetails": { "BackupName": "MusicBackup", "BackupArn": "arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01489602797149-73d8d5bc", "BackupStatus": "CREATING", "BackupCreationDateTime": 1489602797.149 } } ``` After the backup is complete, its `BackupStatus` should change to `AVAILABLE`. To confirm this, use the `describe-backup` command. You can get the input value of `backup-arn` from the output of the previous step or by using the `list-backups` command. ``` aws dynamodb describe-backup \ --backup-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01489173575360-b308cd7d ``` To keep track of your backups, you can use the `list-backups` command. It lists all your backups that are in `CREATING` or `AVAILABLE` status. ``` aws dynamodb list-backups ``` The `list-backups` command and the `describe-backup` command are useful to check information about the source table of the backup. # Restoring a DynamoDB table from a backup This section describes how to restore a table from a backup using the Amazon DynamoDB console or the AWS Command Line Interface (AWS CLI). **Note** If you want to use the AWS CLI, you must configure it first. For more information, see [Accessing DynamoDB](AccessingDynamoDB.md). **Topics** ## Restoring a table from a backup (console) The following procedure shows how to restore the `Music` table by using the `MusicBackup` file that is created in the [Backing up a DynamoDB table](Backup.Tutorial.md) tutorial. **Note** This procedure assumes that the `Music` table no longer exists before restoring it using the `MusicBackup` file. **To restore a table from a backup** 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Backups**. 1. In the list of backups, choose `MusicBackup`. ![\[Screenshot of the backups list and the create backup button.\]](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/images/select_musicbackup.png) 1. Choose **Restore**. 1. Enter **Music** as the new table name. Confirm the backup name and other backup details. Then choose **Restore table** to start the restore process. **Note** You can restore the table to the same AWS Region or to a different Region from where the backup resides. You can also exclude secondary indexes from being created on the new restored table. In addition, you can specify a different encryption mode. Tables restored from backups are always created using the DynamoDB Standard table class. ![\[Screenshot of the restore table from backup screen with backup table details.\]](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/images/restore_table.png) The table that is being restored is shown with the status **Creating**. After the restore process is finished, the status of the `Music` table changes to **Active**. ## Restoring a table from a backup (AWS CLI) Follow these steps to use the AWS CLI to restore the `Music` table using the `MusicBackup` that is created in the [Backing up a DynamoDB table](Backup.Tutorial.md) tutorial. **To restore a table from a backup** 1. Confirm the backup that you want to restore by using the `list-backups` command. This example uses `MusicBackup`. ``` aws dynamodb list-backups ``` To get additional details for the backup, use the `describe-backup` command. You can get the input `backup-arn` from the previous step. ``` aws dynamodb describe-backup \ --backup-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01489173575360-b308cd7d ``` 1. Restore the table from the backup. In this case, the `MusicBackup` restores the `Music` table to the same AWS Region. ``` aws dynamodb restore-table-from-backup \ --target-table-name Music \ --backup-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01489173575360-b308cd7d ``` 1. Restore the table from the backup with custom table settings. In this case, the `MusicBackup` restores the `Music` table and specifies an encryption mode for the restored table. **Note** The `sse-specification-override` parameter takes the same values as the `sse-specification-override` parameter used in the `CreateTable` command. To learn more, see [Managing encrypted tables in DynamoDB](encryption.tutorial.md). ``` aws dynamodb restore-table-from-backup \ --target-table-name Music \ --backup-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01581080476474-e177ebe2 \ --sse-specification-override Enabled=true,SSEType=KMS,KMSMasterKeyId=abcd1234-abcd-1234-a123-ab1234a1b234 ``` You can restore the table to a different AWS Region from where the backup resides. **Note** The `sse-specification-override` parameter is mandatory for cross-Region restores but optional for restores in the same Region as the source table. When performing a cross-Region restore from the command line, you must set the default AWS Region to the desired destination Region. To learn more, see [Command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) in the *AWS Command Line Interface User Guide*. ``` aws dynamodb restore-table-from-backup \ --target-table-name Music \ --backup-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01581080476474-e177ebe2 \ --sse-specification-override Enabled=true,SSEType=KMS ``` You can override the billing mode and the provisioned throughput for the restored table. ``` aws dynamodb restore-table-from-backup \ --target-table-name Music \ --backup-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01489173575360-b308cd7d \ --billing-mode-override PAY_PER_REQUEST ``` You can exclude some or all secondary indexes from being created on the restored table. **Note** Restores can be faster and more cost-efficient if you exclude some or all secondary indexes from being created on the restored table. ``` aws dynamodb restore-table-from-backup \ --target-table-name Music \ --backup-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01581081403719-db9c1f91 \ --global-secondary-index-override '[]' \ --sse-specification-override Enabled=true,SSEType=KMS ``` **Note** The secondary indexes provided should match existing indexes. You cannot create new indexes at the time of restore. You can use a combination of different overrides. For example, you can use a single global secondary index and change provisioned throughput at the same time, as follows. ``` aws dynamodb restore-table-from-backup \ --target-table-name Music \ --backup-arn arn:aws:dynamodb:eu-west-1:123456789012:table/Music/backup/01581082594992-303b6239 \ --billing-mode-override PROVISIONED \ --provisioned-throughput-override ReadCapacityUnits=100,WriteCapacityUnits=100 \ --global-secondary-index-override IndexName=singers-index,KeySchema=["{AttributeName=SingerName,KeyType=HASH}"],Projection="{ProjectionType=KEYS_ONLY}",ProvisionedThroughput="{ReadCapacityUnits=5,WriteCapacityUnits=5}" \ --sse-specification-override Enabled=true,SSEType=KMS ``` To verify the restore, use the `describe-table` command to describe the `Music` table. ``` aws dynamodb describe-table --table-name Music ``` The table that is being restored from the backup is shown with the status **Creating**. After the restore process is finished, the status of the `Music` table changes to **Active**. **Important** While a restore is in progress, don't modify or delete your IAM role policy; otherwise, unexpected behavior can result. For example, suppose that you removed write permissions for a table while that table is being restored. In this case, the underlying `RestoreTableFromBackup` operation would not be able to write any of the restored data to the table. After the restore operation is complete, you can modify or delete your IAM role policy. IAM policies involving [source IP restrictions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip) for accessing the target restore table should have the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-viaawsservice](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-viaawsservice) key set to `false` to ensure that the restrictions apply only to requests made directly by a principal. Otherwise, the restore will be canceled. If your backup is encrypted with an AWS managed key or a customer managed key, don't disable or delete the key while a restore is in progress, or the restore will fail. After the restore operation is complete, you can change the encryption key for the restored table and disable or delete the old key. # Deleting a DynamoDB table backup This section describes how to use the AWS Management Console or the AWS Command Line Interface (AWS CLI) to delete an Amazon DynamoDB table backup. **Note** If you want to use the AWS CLI, you have to configure it first. For more information, see [Using the AWS CLI](AccessingDynamoDB.md#Tools.CLI). **Topics** ## Deleting a table backup (console) The following procedure shows how to use the console to delete the `MusicBackup` that is created in the [Backing up a DynamoDB table](Backup.Tutorial.md) tutorial. **To delete a backup** 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Backups**. 1. In the list of backups, choose `MusicBackup`. ![\[Screenshot showing the MusicBackup with status as available.\]](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/images/select_musicbackup.png) 1. Choose **Delete**. Confirm that you want to delete the backup by typing **delete** and clicking **Delete**. ## Deleting a table backup (AWS CLI) The following example deletes a backup for an existing table `Music` table using the AWS CLI. ``` aws dynamodb delete-backup \ --backup-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01489602797149-73d8d5bc ``` # Using IAM with DynamoDB backup and restore You can use AWS Identity and Access Management (IAM) to restrict Amazon DynamoDB backup and restore actions for some resources. The `CreateBackup` and `RestoreTableFromBackup` APIs operate on a per-table basis. For more information about using IAM policies in DynamoDB, see [Identity-based policies for DynamoDB](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies). The following are examples of IAM policies that you can use to configure specific backup and restore functionality in DynamoDB. ## Example 1: Allow the CreateBackup and RestoreTableFromBackup actions The following IAM policy grants permissions to allow the `CreateBackup` and `RestoreTableFromBackup` DynamoDB actions on all tables: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:CreateBackup", "dynamodb:RestoreTableFromBackup", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:BatchWriteItem" ], "Resource": "*" } ] } ``` ------ **Important** DynamoDB RestoreTableFromBackup permissions are necessary on the source backup, and DynamoDB read and write permissions on the target table are necessary for restore functionality. DynamoDB RestoreTableToPointInTime permissions are necessary on the source table, and DynamoDB read and write permissions on the target table are necessary for restore functionality. ## Example 2: Allow CreateBackup and deny RestoreTableFromBackup The following IAM policy grants permissions for the `CreateBackup` action and denies the `RestoreTableFromBackup` action: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["dynamodb:CreateBackup"], "Resource": "*" }, { "Effect": "Deny", "Action": ["dynamodb:RestoreTableFromBackup"], "Resource": "*" } ] } ``` ------ ## Example 3: Allow ListBackups and deny CreateBackup and RestoreTableFromBackup The following IAM policy grants permissions for the `ListBackups` action and denies the `CreateBackup` and `RestoreTableFromBackup` actions: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["dynamodb:ListBackups"], "Resource": "*" }, { "Effect": "Deny", "Action": [ "dynamodb:CreateBackup", "dynamodb:RestoreTableFromBackup" ], "Resource": "*" } ] } ``` ------ ## Example 4: Allow ListBackups and deny DeleteBackup The following IAM policy grants permissions for the `ListBackups` action and denies the `DeleteBackup` action: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["dynamodb:ListBackups"], "Resource": "*" }, { "Effect": "Deny", "Action": ["dynamodb:DeleteBackup"], "Resource": "*" } ] } ``` ------ ## Example 5: Allow RestoreTableFromBackup and DescribeBackup for all resources and deny DeleteBackup for a specific backup The following IAM policy grants permissions for the `RestoreTableFromBackup` and `DescribeBackup` actions and denies the `DeleteBackup` action for a specific backup resource: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:DescribeBackup", "dynamodb:RestoreTableFromBackup" ], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01489173575360-b308cd7d" }, { "Effect": "Allow", "Action": [ "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:BatchWriteItem" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "dynamodb:DeleteBackup" ], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/01489173575360-b308cd7d" } ] } ``` ------ **Important** DynamoDB RestoreTableFromBackup permissions are necessary on the source backup, and DynamoDB read and write permissions on the target table are necessary for restore functionality. DynamoDB RestoreTableToPointInTime permissions are necessary on the source table, and DynamoDB read and write permissions on the target table are necessary for restore functionality. ## Example 6: Allow CreateBackup for a specific table The following IAM policy grants permissions for the `CreateBackup` action on the `Movies` table only: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["dynamodb:CreateBackup"], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/Movies" ] } ] } ``` ------ ## Example 7: Allow ListBackups The following IAM policy grants permissions for the `ListBackups` action: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["dynamodb:ListBackups"], "Resource": "*" } ] } ``` ------ **Important** You can't grant permissions for the `ListBackups` action on a specific table. ## Example 8: Allow access to AWS Backup features You will need API permissions for the `StartAwsBackupJob` action for a successful backup with advanced features, and the `dynamodb:RestoreTableFromAwsBackup` action to successfully restore that backup. The following IAM policy grants AWS Backup the permissions to trigger backups with advanced features and restores. Also note that if the tables are encrypted the policy will need access to the [AWS KMS key](encryption.usagenotes.html#dynamodb-kms-authz). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DescribeQueryScanBooksTable", "Effect": "Allow", "Action": [ "dynamodb:StartAwsBackupJob", "dynamodb:DescribeTable", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Books" }, { "Sid": "AllowRestoreFromAwsBackup", "Effect": "Allow", "Action": [ "dynamodb:RestoreTableFromAwsBackup" ], "Resource": "*" } ] } ``` ------ ## Example 9: Deny RestoreTableToPointInTime for a Specific Source Table The following IAM policy denies permissions for the `RestoreTableToPointInTime` action for a specific source table: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "dynamodb:RestoreTableToPointInTime" ], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Music" } ] } ``` ------ ## Example 10: Deny RestoreTableFromBackup for all Backups for a Specific Source Table The following IAM policy denies permissions for the `RestoreTableToPointInTime` action for all backups for a specific source table: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "dynamodb:RestoreTableFromBackup" ], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Music/backup/*" } ] } ``` ------ # Understanding Amazon DynamoDB billing for backups This guide provides details about how DynamoDB billing works for backups. We'll break down the various components that contribute to the overall cost, providing clear explanations and practical examples. DynamoDB offers on-demand backups and point-in-time recovery (PITR) backups to help protect your DynamoDB data from disaster events and offers data archiving for long-term retention. ## How it works DynamoDB on-demand backups are billed monthly. If you take a backup on any particular day of the month, you’ll see a single charge for that backup calculated for the remaining days of the month (example: creating a backup on the 27th, you will only be charged for the few days remaining in that month, applied as a single charge on the 27th). If you retain your previously taken backups for subsequent months, you'll always see a full month’s charge for that backup applied on the 1st. If the backup is removed before the month’s end, the charges will be adjusted based on actual usage. As an example, if you created a backup on July 27th, and it is maintained through the month of August, you will see the following charges for that backup: + A charge on July 27th for the remaining days of July + A charge on August 1st for the entire month of August + A charge on the 1st of every subsequent month that backup exists When backups are maintained for DynamoDB tables, you may observe that the expense for the `DynamoDB (Region)-TimedBackupStorage-ByteHrs` usage metric seems abnormally high on the 1st of the month. In addition, if you check this metric at the start of a new month and compare it against previous billing cycles, you may observe what appears to be a large spike in usage. This is by design. On the 1st of every month, any existing DynamoDB backups will have usage charges for the entire month applied. Any DynamoDB backups that are removed during the month will have their usage expense prorated to reflect actual usage. As a result, you may see the charge (applied on the 1st) decrease throughout the month. This is because retention policies apply expirations or manual deletions to carried over backups occur. This will be explored in a scenario below. Similarly, you'll notice smaller spikes throughout the month as new backups are created, with their charges applied on the day of creation for the remainder of the month. ## DynamoDB backup billing example Here is an example of what you may see in Cost Explorer at the start of the month: ![\[Image showing DynamoDB billing chart in Cost Explorer.\]](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/images/ddb-backups-billing-ce.png) Notice how February 1st appears to have a much larger spike relative to previous months. Let’s break down why this occurs. From the [DynamoDB Pricing Page](https://aws.amazon.com/dynamodb/pricing/on-demand/): *“The total backup storage size billed each month is the sum of all backups of DynamoDB tables. DynamoDB monitors the size of on-demand backups continuously throughout the month to determine your backup charges.”* This explains why the bill consistently shows a large spike in usage on the 1st of every month. Any existing backups coming into a new month have a full month’s charges applied to the 1st. Put another way, if you enter the month with 300 DynamoDB backups, you will see a full month’s usage charges applied on the 1st day of the month for all 300 backups. New backups taken throughout the month will incur usage charges from the day of creation until the end of the month. **What if the backup is deleted mid-month?** Here are a few scenarios to consider: 1. If a backup from the previous month is deleted on the 15th of the current month, the usage charges for that backup,still applied on the 1st, will be adjusted to the actual usage instead of the assumed full month of usage previously applied. The example below explains this more in detail. 1. When you create a backup during the month, usage charges for the remainder of the month are applied to the day it was created. However, if you delete this backup before the month ends, your usage charges will be adjusted to include only the days the backup was active, still applied on its creation date. **Why does the current month’s usage appear to be so much higher on the 1st than previous months, and what happens if I remove the backups?** To answer this important 2-part question, let’s set up an example scenario using the following information: + **Length of Month**: 30 Days + **DynamoDB Backup Frequency**: 10/day, 300/mo + **DynamoDB Backup Retention Policy**: 30 Days + **DynamoDB Per-Backup Cost**: \$12/day, \$160/mo + **Previous 1st of Month Total** (`TimedBackupStorage-ByteHrs`, checked on the 1st of the Current Month): \$19,300 + **Previous Month Total** (`TimedBackupStorage-ByteHrs`): \$118,600 + **Current 1st of Month Total** (`TimedBackupStorage-ByteHrs`, Checked on the 1st): \$118,000 + **Changes in DynamoDB Usage Month-to-Month**: None Using the information above, we can see that 300 backups were created in the previous month with a policy to maintain them for 30 days. On the 1st of a new month, all of these backups still remain as they've not yet hit the end of their recovery period. However, with each passing day, the oldest sets of backups will begin to drop off, as shown here: **DynamoDB backup dropoff table** | New month | Day 1 | Day 2 | Day 3 | Day 4 | Day 5 | | --- | --- | --- | --- | --- | --- | | Total previous month backups carried over | 300 | 290 | 280 | 270 | 260 | + On the 1st, we can see 300 backups @ \$160/mo per backup, totaling \$118,000 of `TimedBackupStorage-ByteHrs` applied. This is in contrast to the previous month, where the entire month’s total was \$118,600. + On the 2nd, 10 of those backups will have expired and drop off. When this occurs, the applied charge for those backups will be adjusted to **Actual Usage** instead of **Assumed Usage**. This results in those 10 backups, previously with an applied charge on the 1st of \$1600 (10 Backups x 30 Days) being adjusted down to \$120 (10 Backups x 1 Day). + The following day, the next block of 10 will expire and drop, shifting their usage from 30 days down to 2 days, reducing their charge to \$140 (10 Backups x 2 Days). With every passing day, we’ll see that larger-than-previous-month spike begin to shrink. If we expand this to cover the entire month, we’ll observe the following: **DynamoDB Backup Charges (1st of Month) Progression** | 300 backups in blocks of 10 | 1st | 10th | 20th | 30th | | --- | --- | --- | --- | --- | | Block 1 | \$1600 | \$120 | \$120 | \$120 | | Block 2 | \$1600 | \$140 | \$140 | \$140 | | Block 3 | \$1600 | \$160 | \$160 | \$160 | | Block 4 | \$1600 | \$180 | \$180 | \$180 | | Block 5 | \$1600 | \$1100 | \$1100 | \$1100 | | Block 6 | \$1600 | \$1120 | \$1120 | \$1120 | | Block 7 | \$1600 | \$1140 | \$1140 | \$1140 | | Block 8 | \$1600 | \$1160 | \$1160 | \$1160 | | Block 9 | \$1600 | \$1180 | \$1180 | \$1180 | | Block 10 | \$1600 | \$1600 | \$1200 | \$1200 | | Block 11 | \$1600 | \$1600 | \$1220 | \$1220 | | Block 12 | \$1600 | \$1600 | \$1240 | \$1240 | | Block 13 | \$1600 | \$1600 | \$1260 | \$1260 | | Block 14 | \$1600 | \$1600 | \$1280 | \$1280 | | Block 15 | \$1600 | \$1600 | \$1300 | \$1300 | | Block 16 | \$1600 | \$1600 | \$1320 | \$1320 | | Block 17 | \$1600 | \$1600 | \$1340 | \$1340 | | Block 18 | \$1600 | \$1600 | \$1360 | \$1360 | | Block 19 | \$1600 | \$1600 | \$1380 | \$1380 | | Block 20 | \$1600 | \$1600 | \$1600 | \$1400 | | Block 21 | \$1600 | \$1600 | \$1600 | \$1420 | | Block 22 | \$1600 | \$1600 | \$1600 | \$1440 | | Block 23 | \$1600 | \$1600 | \$1600 | \$1460 | | Block 24 | \$1600 | \$1600 | \$1600 | \$1480 | | Block 25 | \$1600 | \$1600 | \$1600 | \$1500 | | Block 26 | \$1600 | \$1600 | \$1600 | \$1520 | | Block 27 | \$1600 | \$1600 | \$1600 | \$1540 | | Block 28 | \$1600 | \$1600 | \$1600 | \$1560 | | Block 29 | \$1600 | \$1600 | \$1600 | \$1580 | | Block 30 | \$1600 | \$1600 | \$1600 | \$1600 | | 1st of month total (\$1) | \$118,000 | \$113,500 | \$110,400 | \$19,300 | As a new block drops off each day, it has its usage adjusted to how many days it existed, versus the full month amount. As a result, by month’s end the charges observed on the 1st will have dropped from the initial \$118,000 down to the expected \$19,300. This number, combined with the newly created backups through the month (which will have a billing table similar to the above, but reversed), will result in a monthly expense in line with last month’s \$118,600. # Restore a table in DynamoDB You can restore a DynamoDB table from your PITR backup or your on-demand backups using the AWS Management Console, the AWS Command Line Interface (AWS CLI), or the DynamoDB API. The recovery process restores to a new DynamoDB table. ## Restoring a table using point-in-time recovery You can restore your table to any point in time up till the `EarliestRestoreableDateTime`. **Important** If you disable point-in-time recovery and later enable it on a table, you reset the start time for which you can recover that table. As a result, you can only immediately restore that table using the `LatestRestorableDateTime`. When you restore using point-in-time recovery, DynamoDB restores your table data to the state based on the selected date and time (day:hour:minute:second) to a new table. You restore a table without consuming any provisioned throughput on the table. You can do a full table restore using point-in-time recovery, or you can configure the destination table settings. You can change the following table settings on the restored table: + Global secondary indexes (GSIs) + Local secondary indexes (LSIs) + Billing mode + Provisioned read and write capacity + Encryption settings **Important** When you do a full table restore, the destination table is set with the same provisioned read capacity units and write capacity units that the source table had when the backup was requested. For example, suppose that a table's provisioned throughput was recently lowered to 50 read capacity units and 50 write capacity units. You then restore the table's state to three weeks ago, at which time its provisioned throughput was set to 100 read capacity units and 100 write capacity units. In this case, DynamoDB restores your table data to that point in time with the provisioned throughput from that time (100 read capacity units and 100 write capacity units). You can also restore your DynamoDB table data across AWS Regions such that the restored table is created in a different Region from where the source table resides. You can do cross-Region restores between AWS commercial Regions, AWS China Regions, and AWS GovCloud (US). You pay only for the data you transfer out of the source Region and for restoring to a new table in the destination Region. **Note** Cross-Region restore isn't supported if the source or destination Region is Asia Pacific (Hong Kong) or Middle East (Bahrain). Restores can be faster and more cost-efficient if you exclude some or all indexes from being created on the restored table. You must manually set the following on the restored table: + Auto scaling policies + AWS Identity and Access Management policies + Amazon CloudWatch Events metrics and alarms + Tags + Stream settings + Time to Live (TTL) settings + Point-in-time recovery settings The time it takes you to restore a table varies based on multiple factors and isn't always correlated with the size of the table. # Restoring a DynamoDB table to a point in time Amazon DynamoDB point-in-time recovery (PITR) provides continuous backups of your DynamoDB table data. You can restore a table to a point in time using the DynamoDB console or the AWS Command Line Interface (AWS CLI). The point-in-time recovery process restores to a new table. If you want to use the AWS CLI, you must configure it first. For more information, see [Accessing DynamoDB](AccessingDynamoDB.md). **Topics** + [Restoring a DynamoDB table to a point in time (console)](#restoretabletopointintime_console) + [Restoring a table to a point in time (AWS CLI)](#restorepointintime_cli) ## Restoring a DynamoDB table to a point in time (console) The following example demonstrates how to use the DynamoDB console to restore an existing table named `Music` to a point in time. **Note** This procedure assumes that you have enabled point-in-time recovery. To enable it for the `Music` table, on the **Backups** tab, in the **Point-in-time recovery (PITR)** section, choose **Edit** and then check the box next to **Enable point-in-time-recovery**. **To restore a table to a point in time** 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Tables**. 1. In the list of tables, choose the `Music` table. 1. On the **Backups** tab of the `Music` table, in the **Point-in-time recovery (PITR)** section, choose **Restore**. 1. For the new table name, enter **MusicMinutesAgo**. **Note** You can restore the table to the same AWS Region or to a different Region from where the source table resides. You can also exclude secondary indexes from being created on the restored table. In addition, you can specify a different encryption mode. 1. To confirm the restorable time, set the restore date and time to **Earliest**. Then choose **Restore** to start the restore process. The table that is being restored is shown with the status **Restoring**. After the restore process is finished, the status of the `MusicMinutesAgo` table changes to **Active**. ## Restoring a table to a point in time (AWS CLI) The following procedure shows how to use the AWS CLI to restore an existing table named `Music` to a point in time. **Note** This procedure assumes that you have enabled point-in-time recovery. To enable it for the `Music` table, run the following command. ``` aws dynamodb update-continuous-backups \ --table-name Music \ --point-in-time-recovery-specification PointInTimeRecoveryEnabled=True ``` **To restore a table to a point in time** 1. Confirm that point-in-time recovery is enabled for the `Music` table by using the `describe-continuous-backups` command. ``` aws dynamodb describe-continuous-backups \ --table-name Music ``` Continuous backups (automatically enabled on table creation) and point-in-time recovery are enabled. ``` { "ContinuousBackupsDescription": { "PointInTimeRecoveryDescription": { "PointInTimeRecoveryStatus": "ENABLED", "EarliestRestorableDateTime": 1519257118.0, "LatestRestorableDateTime": 1520018653.01 }, "ContinuousBackupsStatus": "ENABLED" } } ``` 1. Restore the table to a point in time. In this case, the `Music` table is restored to the `LatestRestorableDateTime` (\$15 minutes ago) to the same AWS Region. ``` aws dynamodb restore-table-to-point-in-time \ --source-table-name Music \ --target-table-name MusicMinutesAgo \ --use-latest-restorable-time ``` **Note** You can also restore to a specific point in time. To do this, run the command using the `--restore-date-time` argument, and specify a timestamp. You can specify any point in time within the configured recovery period, which can be set to any value between 1 and 35 days. For example, the following command restores the table to the `EarliestRestorableDateTime`. ``` aws dynamodb restore-table-to-point-in-time \ --source-table-name Music \ --target-table-name MusicEarliestRestorableDateTime \ --no-use-latest-restorable-time \ --restore-date-time 1519257118.0 ``` Specifying the `--no-use-latest-restorable-time` argument is optional when restoring to a specific point in time. 1. Restore the table to a point in time with custom table settings. In this case, the `Music` table is restored to the `LatestRestorableDateTime` (\$15 minutes ago). You can specify a different encryption mode for the restored table, as follows. **Note** The `sse-specification-override` parameter takes the same values as the `sse-specification-override` parameter used in the `CreateTable` command. To learn more, see [Managing encrypted tables in DynamoDB](encryption.tutorial.md). ``` aws dynamodb restore-table-to-point-in-time \ --source-table-name Music \ --target-table-name MusicMinutesAgo \ --use-latest-restorable-time \ --sse-specification-override Enabled=true,SSEType=KMS,KMSMasterKeyId=abcd1234-abcd-1234-a123-ab1234a1b234 ``` You can restore the table to a different AWS Region from where the source table resides. **Note** The `sse-specification-override` parameter is mandatory for cross-Region restores but optional for restores to the same Region as the source table. The `source-table-arn` parameter must be provided for cross-Region restores. When performing a cross-Region restore from the command line, you must set the default AWS Region to the desired destination Region. To learn more, see [Command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) in the *AWS Command Line Interface User Guide*. ``` aws dynamodb restore-table-to-point-in-time \ --source-table-arn arn:aws:dynamodb:us-east-1:123456789012:table/Music \ --target-table-name MusicMinutesAgo \ --use-latest-restorable-time \ --sse-specification-override Enabled=true,SSEType=KMS,KMSMasterKeyId=abcd1234-abcd-1234-a123-ab1234a1b234 ``` You can override the billing mode and the provisioned throughput for the restored table. ``` aws dynamodb restore-table-to-point-in-time \ --source-table-name Music \ --target-table-name MusicMinutesAgo \ --use-latest-restorable-time \ --billing-mode-override PAY_PER_REQUEST ``` You can exclude some or all secondary indexes from being created on the restored table. **Note** Restores can be faster and more cost-efficient if you exclude some or all secondary indexes from being created on the new restored table. ``` aws dynamodb restore-table-to-point-in-time \ --source-table-name Music \ --target-table-name MusicMinutesAgo \ --use-latest-restorable-time \ --global-secondary-index-override '[]' ``` You can use a combination of different overrides. For example, you can use a single global secondary index and change provisioned throughput at the same time, as follows. ``` aws dynamodb restore-table-to-point-in-time \ --source-table-name Music \ --target-table-name MusicMinutesAgo \ --billing-mode-override PROVISIONED \ --provisioned-throughput-override ReadCapacityUnits=100,WriteCapacityUnits=100 \ --global-secondary-index-override IndexName=singers-index,KeySchema=["{AttributeName=SingerName,KeyType=HASH}"],Projection="{ProjectionType=KEYS_ONLY}",ProvisionedThroughput="{ReadCapacityUnits=50,WriteCapacityUnits=50}" \ --sse-specification-override Enabled=true,SSEType=KMS \ --use-latest-restorable-time ``` To verify the restore, use the `describe-table` command to describe the `MusicEarliestRestorableDateTime` table. ``` aws dynamodb describe-table --table-name MusicEarliestRestorableDateTime ``` The table that is being restored is shown with the status **Creating** and restore in progress as **true**. After the restore process is finished, the status of the `MusicEarliestRestorableDateTime` table changes to **Active**. **Important** While a restore is in progress, don't modify or delete the AWS Identity and Access Management (IAM) policies that grant the IAM entity (for example, user, group, or role) permission to perform the restore. Otherwise, unexpected behavior can result. For example, suppose that you remove write permissions for a table while that table is being restored. In this case, the underlying `RestoreTableToPointInTime` operation can't write any of the restored data to the table. IAM policies involving source IP restrictions for accessing the target restore table can similarly cause issues. You can modify or delete permissions only after the restore operation is completed. # Using AWS Backup with DynamoDB Amazon DynamoDB can help you meet regulatory compliance and business continuity requirements through enhanced backup features in AWS Backup. AWS Backup is a fully managed data protection service that makes it easy to centralize and automate backups across AWS services, in the cloud, and on premises. Using this service, you can configure backup policies and monitor activity for your AWS resources in one place. To use AWS Backup, you must affirmatively [opt-in](https://docs.aws.amazon.com/aws-backup/latest/devguide/service-opt-in.html). Opt-in choices apply to the specific account and AWS Region, so you might have to opt in to multiple Regions using the same account. For more information, see the [AWS Backup Developer Guide](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html). Amazon DynamoDB is natively integrated with AWS Backup. You can use AWS Backup to schedule, copy, tag and life cycle your DynamoDB on-demand backups automatically. You can continue to view and restore these backups from the DynamoDB console. You can use the DynamoDB console, API, and AWS Command Line Interface (AWS CLI) to enable automatic backups for your DynamoDB tables. **Note** Any backups made through DynamoDB will remain unchanged. You will still be able to create backups through the current DynamoDB workflow. Enhanced backup features available through AWS Backup include: **Scheduled backups** - You can set up regularly scheduled backups of your DynamoDB tables using backup plans. **Cross-account and cross-Region copying** - You can automatically copy your backups to another backup vault in a different AWS Region or account, which allows you to support your data protection requirements. **Cold storage tiering** - You can configure your backups to implement life cycle rules to delete or transition backups to colder storage. This can help you optimize your backup costs. **Tags** - You can automatically tag your backups for billing and cost allocation purposes. **Encryption** – DynamoDB on-demand backups managed through AWS Backup are now stored in the AWS Backup vault. This allows you to encrypt and secure your backups by using an AWS KMS key that is independent from your DynamoDB table encryption key. **Audit backups** – You can use AWS Backup Audit Manager to audit the compliance of your AWS Backup policies and to find backup activity and resources that are not yet compliant with the controls that you defined. You can also use it to automatically generate an audit trail of daily and on-demand reports for your backup governance purposes. **Secure backups using the WORM model ** – You can use AWS Backup Vault Lock to enable a write-once-read-many (WORM) setting for your backups. With AWS Backup Vault Lock, you can add an additional layer of defense that protects backups from inadvertent or malicious delete operations, changes to backup recovery periods, and updates to lifecycle settings. To learn more, see [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html). These enhanced backup features are available in all AWS Regions. To learn more about these features, see the [AWS Backup Developer Guide](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html). **Topics** + [Backing up and restoring DynamoDB tables with AWS Backup: How it works](GettingStartedBackupsAWS.md) + [Creating backups of DynamoDB tables with AWS Backup](CreateBackupAWS.md) + [Copying a backup of a DynamoDB table with AWS Backup](CrossRegionAccountCopyAWS.md) + [Restoring a backup of a DynamoDB table from AWS Backup](Restore.TutorialAWS.md) + [Deleting a backup of a DynamoDB table with AWS Backup](Delete.TutorialAWS.md) + [Usage note differences between on-demand backups managed by AWS Backup and DynamoDB](UsageNotesAWS.md) # Backing up and restoring DynamoDB tables with AWS Backup: How it works You can use the on-demand backup feature to create full backups of your Amazon DynamoDB tables. This section provides an overview of what happens during the backup and restore process. ## Backups When you create an on-demand backup with AWS Backup, a time marker of the request is cataloged. The backup is created asynchronously by applying all changes until the time of the request to the last full table snapshot. Each time you create an on-demand backup, the entire table data is backed up. There is no limit to the number of on-demand backups that can be taken. **Note** Unlike DynamoDB Backups, backups made with AWS Backup are not instantaneous. While a backup is in progress, you can't do the following: + Pause or cancel the backup operation. + Delete the source table of the backup. + Disable backups on a table if a backup for that table is in progress. AWS Backup provides automated backup schedules, retention management, and lifecycle management. This removes the need for custom scripts and manual processes. AWS Backup runs the backups and deletes them when they expire. For more information, see the [AWS Backup Developer Guide](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html). If you're using the console, any backups created using AWS Backup are listed on the **Backups** tab with the **Backup type** set to `AWS_BACKUP`. **Note** You can't delete backups marked with a **Backup type** of `AWS_BACKUP` using the DynamoDB console. To manage these backups, use the AWS Backup console. To learn how to perform a backup, see [Backing up a DynamoDB table](Backup.Tutorial.md). ## Restores You restore a table without consuming any provisioned throughput on the table. You can do a full table restore from your DynamoDB backup, or you can configure the destination table settings. When you do a restore, you can change the following table settings: + Encryption settings **Important** When you do a full table restore, the destination table is set with the same provisioned read capacity units and write capacity units that the source table had when the backup was requested. The restore process also restores the local secondary indexes and the global secondary indexes. You can copy a backup of your DynamoDB table data to a different AWS Region and then restore it in that new Region. You can copy and then restore backups between AWS commercial Regions, AWS China Regions, and AWS GovCloud (US) Regions. You pay only for the data you copy from the source Region and the data you restore to a new table in the destination Region. AWS Backup will restore the tables with all the original indexes. You must manually set up the following on the restored table: + Auto scaling policies + AWS Identity and Access Management (IAM) policies + Amazon CloudWatch metrics and alarms + Tags + Stream settings + Time to Live (TTL) settings + Deletion protection settings + Point in time recovery (PITR) settings You can only restore the entire table data to a new table from a backup. You can write to the restored table only after it becomes active. **Note** AWS Backup restores are nondestructive. You can't overwrite an existing table during a restore operation. Restore times are directly related to the configuration of your tables (such as the size of your tables and the number of underlying partitions) and other related variables. A best practice when planning for disaster recovery is to regularly document average restore completion times and establish how these times affect your overall Recovery Time Objective. To learn how to perform a restore, see [Restoring a DynamoDB table from a backup](Restore.Tutorial.md). You can use IAM policies for access control. For more information, see [Using IAM with DynamoDB backup and restore](backuprestore_IAM.md). All backup and restore console and API actions are captured and recorded in AWS CloudTrail for logging, continuous monitoring, and auditing. # Creating backups of DynamoDB tables with AWS Backup This section describes how to turn on AWS Backup to create on-demand and scheduled backups from your DynamoDB tables. ** [Turning on AWS Backup features](#CreateBackupAWS_enabling) [On-demand backups](#CreateBackupAWS_on-demand) [Scheduled backups](#CreateBackupAWS_scheduled)** + [Turning on AWS Backup features](#CreateBackupAWS_enabling) + [On-demand backups](#CreateBackupAWS_on-demand) + [Scheduled backups](#CreateBackupAWS_scheduled) ## Turning on AWS Backup features You must turn on AWS Backup to use it with DynamoDB. To turn on AWS Backup, go through the following steps: 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Backups**. 1. In the Backup Settings window, choose **Turn on**. 1. A confirmation screen will appear. Choose **Turn on features**. AWS Backup features are now available for your DynamoDB tables. If you choose to turn off AWS Backup features after they’ve been turned on, follow these steps: 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Backups**. 1. In the Backup Settings window, choose **Turn off**. 1. A confirmation screen will appear. Choose **Turn off features**. If you can’t turn the AWS Backup features on or off, your AWS admin may need to perform those actions. ## On-demand backups To create an on-demand backup of a DynamoDB table, follow these steps: 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Backups**. 1. Choose **Create backup**. 1. From the dropdown menu that appears, choose **Create an on-demand backup**. 1. To create a backup managed by AWS Backup with warm storage and other basic features, choose **Default Settings.** To create a backup that can be transitioned to cold storage, or to create a backup with DynamoDB features instead of AWS Backup, choose **Customize settings**. If you want to create this backup with previous DynamoDB features instead, choose **Customize settings** and then choose **Backup with DynamoDB**. 1. When you have completed the settings, choose **Create backup.** ## Scheduled backups To schedule a backup, follow these steps. 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Backups**. 1. From the dropdown menu that appears, choose **Schedule backups with AWS Backup**. 1. You will be taken to AWS Backup to create a backup plan. # Copying a backup of a DynamoDB table with AWS Backup You can make a copy of a current backup. You can copy backups to multiple AWS accounts or AWS Regions on demand or automatically as part of a scheduled backup plan. You can also automate a sequence of cross-account and cross-Region copies for Amazon DynamoDB Encryption Client. Cross-Region replication is especially valuable if you have business continuity or compliance requirements to store backups a minimum distance away from your production data. Cross-account backups are useful for securely copying your backups to one or more AWS accounts in your organization for operational or security reasons. If your original backup is inadvertently deleted, you can copy the backup from its destination account to its source account, and then start the restore. Before you can do this, you must have two accounts that belong to the same organization in the Organizations service. Copies inherit the source backup's configuration unless you specify otherwise, with one exception: if you specify that your new copy "Never" expire. With this setting, the new copy still inherits its source expiration date. If you want your new backup copy to be permanent, either set your source backups to never expire, or specify your new copy to expire 100 years after its creation. **Note** If you're copying to another account, you must first have permission from that account. To copy a backup, do the following: 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Backups**. 1. Select the check box next to the backup you want to copy. + If the backup you want to copy is grayed out, you must enable [advanced features with AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/advanced-ddb-backup.html). Then create a new backup. You can now copy this new backup to other Regions and accounts, and copy any other new backups going forward. 1. Choose **Copy.** 1. If you want to copy the backup to another account or Region, select the check box next to **Copy the recovery point to another destination**. Then select whether you will to copy to another Region in your account, or to a different account in a different Region. **Note** To restore a backup to another Region or account, you must first copy the backup to that Region or account. 1. Select the desired vault the file will be copied into. You can also create a new backup vault if desired. 1. Choose **Copy backup**. # Restoring a backup of a DynamoDB table from AWS Backup This section describes how to restore a backup of a DynamoDB table from AWS Backup. ** [Restoring a DynamoDB table from AWS Backup](#Restore.TutorialAWS.simple) [Restoring a DynamoDB table to another Region or account](#Restore.TutorialAWS.another)** + [Restoring a DynamoDB table from AWS Backup](#Restore.TutorialAWS.simple) + [Restoring a DynamoDB table to another Region or account](#Restore.TutorialAWS.another) ## Restoring a DynamoDB table from AWS Backup To restore your DynamoDB tables from AWS Backup, follow these steps: 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/) 1. In the navigation pane on the left side of the console, choose **Tables.** 1. Choose the **Backups** tab. 1. Select the check box next to the previous backup that you want to restore from. 1. Choose **Restore**. You will be taken to the **Restore table from backup** screen. 1. Enter the name for the newly restored table, the encryption that this new table will have, the key you want the restore to be encryped with, and other options. 1. When you're finished, choose **Restore.** ## Restoring a DynamoDB table to another Region or account To restore a DynamoDB table to another Region or account, you will first need to copy the backup to that new Region or account. In order to copy to another account, that account must first grant you permission. After you have copied your DynamoDB backup to the new Region or account, it can be restored with the process in the previous section. # Deleting a backup of a DynamoDB table with AWS Backup This section describes how to delete a backup of a DynamoDB table with AWS Backup. A DynamoDB backup created through AWS Backup features is stored in an AWS Backup vault. In order to delete this kind of backup, do the following: 1. Sign in to the AWS Management Console and open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/). 1. In the navigation pane on the left side of the console, choose **Backups**. 1. On the screen that follows, choose **Continue to AWS Backup**. You will be taken to the AWS Backup console. To learn more on how to delete backups on the AWS Backup console, see [Deleting backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-backups.html). For more information about AWS Backup see [Backup and recovery using AWS Backup](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/aws-backup.html) in the *AWS Prescriptive Guidance*. # Usage note differences between on-demand backups managed by AWS Backup and DynamoDB This section describes the technical differences between on-demand backups managed by AWS Backup and DynamoDB. AWS Backup has some different workflows and behaviors than DynamoDB. These include: **Encryption** - Backups created with the AWS Backup plan are stored in an encrypted vault with a key that is managed by the AWS Backup service. The vault has access control policies for additional security. **Backup ARN** - The backup files created by AWS Backup will now have an AWS Backup ARN, which could impact the user permission model. Backup resource names (ARNs) will change from `arn:aws:dynamodb` to `arn:aws:backup`. **Deleting backups** - Backups that are created with AWS Backup can only be deleted from the AWS Backup vault. You will not be able to delete AWS Backup files from the DynamoDB console. **Backup process** - Unlike DynamoDB backups, backups made with AWS Backup are not instantaneous. **Billing** - Backups of DynamoDB tables with AWS Backup features are billed from AWS Backup. **IAM roles** - If you're managing access through IAM roles, you will also need to configure a new IAM role with these new permissions: ``` 1. "dynamodb:StartAwsBackupJob", 2. "dynamodb:RestoreTableFromAwsBackup" ``` `dynamodb:StartAwsBackupJob` is needed for a successful backup with AWS Backup features, and `dynamodb:RestoreTableFromAwsBackup` is needed to restore from a backup made with AWS Backup features. To see these permissions in a complete IAM policy, see Example 8 in [Using IAM](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_IAM.html).