

# Logically air-gapped vault
<a name="logicallyairgappedvault"></a>

## Overview of logically air-gapped vaults
<a name="lag-overview"></a>

AWS Backup offers a secondary type of vault which can store backups in a container with additional security features. A **logically air-gapped vault** is a specialized vault which provides increased security beyond a standard backup vault, as well as the ability to share vault access to other accounts so that recovery time objectives (RTOs) can be faster and more flexible in case of an incident that requires rapid restoration of resources.

Logically air-gapped vaults come equipped with additional protection features; each vault is encrypted with either an [AWS owned key](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#key-mgmt) (default) or optionally with a customer-managed KMS key, and each vault is equipped with [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)'s compliance mode. The encryption key type information is visible through AWS Backup APIs and console for transparency and compliance reporting.

You can integrate your logically air-gapped vaults with [Multi-party approval](multipartyapproval.md) (MPA) to enable recovery of backups in the vaults even if the vault-owning account is inaccessible, which helps to maintain business continuity. Further more, you can choose to integrate with [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) (RAM) to share a logically air-gapped vault with other AWS accounts (including accounts in other organizations) so that the backups stored within the vault can be restored from an account with which the vault is shared, if needed for data loss recovery or [restore testing](restore-testing.md). As part of this added security, a logically air-gapped vault stores its backups in an AWS Backup service owned account (which results in backups shown as shared outside your organization in modify attribute items in AWS CloudTrail logs).

In the scenario where your logically air-gapped vault owning account is closed (maliciously or otherwise), you can still access backups in the vault (restore or copy them) via MPA until the [post-closure period](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#post-closure-period) ends. After the post-closure period expires, the backups are no longer accessible. During the post-closure period, you can reference the [AWS Account Management documentation](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#what-to-expect-after-closure) to regain control of your account while working on recovery.

For greater resiliency, we recommend creating cross-Region copies in logically air-gapped vaults in same or separate accounts. However, if you want to reduce storage costs by maintaining just a single copy, you can use [Primary backups to logically air-gapped vaults](lag-vault-primary-backup.md), after onboarding to AWS MPA.

You can view the storage pricing for backups of supported services in a logically air-gapped vault on the [AWS Backup pricing](https://aws.amazon.com/backup/pricing/) page.

See [Feature availability by resource](backup-feature-availability.md#features-by-resource) for resource types you can copy to a logically air-gapped vault.

**Topics**
+ [

## Overview of logically air-gapped vaults
](#lag-overview)
+ [

## Use case for logically air-gapped vaults
](#lag-usecase)
+ [

## Compare and contrast with a standard backup vault
](#lag-compare-and-contrast)
+ [

## Create a logically air-gapped vault
](#lag-create)
+ [

## View logically air-gapped vault details
](#lag-view)
+ [

## Creating backups in a logically air-gapped vault
](#lag-creation)
+ [

## Share a logically air-gapped vault
](#lag-share)
+ [

## Restore a backup from a logically air-gapped vault
](#lag-restore)
+ [

## Delete a logically air-gapped vault
](#lag-delete)
+ [

## Additional programmatic options for logically air-gapped vaults
](#lag-programmatic)
+ [

## Understanding encryption key types for logically air-gapped vaults
](#lag-encryption-key-types)
+ [

## Usage of service-owned key
](#lag-service-owned-key)
+ [

## Considerations for security auto-remediation
](#lag-security-auto-remediation)
+ [

## Troubleshoot a logically air-gapped vault issue
](#lag-troubleshoot)
+ [

# Primary backups to logically air-gapped vaults
](lag-vault-primary-backup.md)
+ [

# Multi-party approval for logically air-gapped vaults
](multipartyapproval.md)

## Use case for logically air-gapped vaults
<a name="lag-usecase"></a>

A logically air-gapped vault is a secondary vault that serves as part of a data protection strategy. This vault can help enhance your organization's retention strategy and recovery when you desire a vault for your backups that
+ Is automatically set with a vault lock in [compliance mode](vault-lock.md)
+ By default offers encryption with an AWS owned key. Optionally you can provide a customer managed key
+ Contains backups which, through AWS RAM or MPA, can be shared with and restored from a different account than the one that created the backup

**Considerations and limitations**
+ Unencrypted Amazon Aurora, Amazon DocumentDB, and Amazon Neptune clusters are not supported for logically air-gapped vault, as they do not support encryption of unencrypted DB cluster snapshots.
+ Amazon EC2 offers [EC2 Allowed AMIs](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-allowed-amis.html). If this setting is enabled in your account, add the alias `aws-backup-vault` to your allowlist.

   If this alias is not included, copy operations from a logically air-gapped vault to a backup vault and restore operations of EC2 instances from a logically air-gapped vault will fail with an error message such as "Source AMI ami-xxxxxx not found in Region."
+ The ARN (Amazon Resource Name) of a recovery point stored in a logically air-gapped vault will have `backup` in place of the underlying resource type. For example, if the original ARN begins with `arn:aws:ec2:region::image/ami-*` , then the ARN of the recovery point in the logically air-gapped vault will be `arn:aws:backup:region:account-id:recovery-point:*`.

  You can use the CLI command [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html) to determine the ARN.

## Compare and contrast with a standard backup vault
<a name="lag-compare-and-contrast"></a>

A **backup vault** is the primary and standard type of vault used in AWS Backup. Each backup is stored in a backup vault when the backup is created. You can assign resource-based policies to manage backups stored in the vault, such as the lifecycle of backups stored within the vault.

A **logically air-gapped vault** is a specialized vault with additional security and flexible sharing for faster recovery time (RTO). This vault stores primary backups or copies of backups that were initially created and stored within a standard backup vault.

Backup vaults are encrypted with a key, a security mechanism that limits access to intended users. These keys can be customer managed or AWS managed. See [Copy encryption](encryption.md#copy-encryption) for encryption behavior during copy jobs, including copying into a logically air-gapped vault.

Additionally, a backup vault can have additional security through a vault lock; logically air-gapped vaults come equipped by a vault lock in compliance mode.

Similar to backup vaults, logically air-gapped vaults also support [restricted tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-restrictions) for Amazon EC2 backups.


| Feature | Backup vault | Logically air-gapped vault | 
| --- | --- | --- | 
| [AWS Backup Audit Manager](aws-backup-audit-manager.md) | You can use AWS Backup Audit Manager [Controls and remediation](controls-and-remediation.md) to monitor your backup vaults. | Ensure a backup of a specific resource is stored in [at least one logically air-gapped vault](controls-and-remediation.md#resources-in-lag-vault-control) on a schedule you determine, in addition to controls available to standard vaults. | 
| [Billing](https://aws.amazon.com/backup/pricing/) | Storage and data transfer charges for resources fully managed by AWS Backup occur under "AWS Backup". Other resource type storage and data transfer charges will occur under their respective services. For example, Amazon EBS backups will show under "Amazon EBS"; Amazon S3 backups will show under "AWS Backup". | All billing charges from these vaults (storage or data transfer) occur under "AWS Backup". | 
|   [Regions](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region) | Available in all Regions in which AWS Backup operates | Available in most Regions supported by AWS Backup. Not currently available in Asia Pacific (Malaysia), Canada West (Calgary), Mexico (Central), Asia Pacific (Thailand), Asia Pacific (Taipei), Asia Pacific (New Zealand), China (Beijing), China (Ningxia), AWS GovCloud (US-East), or AWS GovCloud (US-West). | 
|   [Resources](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#supported-resources) | Can store copies of backups for most resource types that support cross-account copy. | See the logically air-gapped vault column in [Feature availability by resource](backup-feature-availability.md#features-by-resource) for resources that can be copied to this vault. | 
|  [ Restore](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html) | Backups can be restored by the same account to which the vault belongs. | Backups can be restored by a different account than the one to which the vault belongs if the vault is shared with that separate account. | 
| [Security](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-considerations.html) |  Can optionally be encrypted with a key (customer managed or AWS managed) Can optionally use a vault lock in compliance or governance mode |  Can be encrypted with an [AWS owned key](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#key-mgmt) or a customer managed key Is always locked with a [ vault lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html) in compliance mode Encryption key type information is preserved and visible when vaults are shared through AWS RAM or MPA  | 
| [Sharing](#lag-share) |  Access can be managed through policies and [AWS Organizations](https://docs.aws.amazon.com/aws-backup/latest/devguide/manage-cross-account.html) Not compatible with AWS RAM  | Can optionally be shared across accounts using [AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) | 

## Create a logically air-gapped vault
<a name="lag-create"></a>

You can create a logically air-gapped vault either through the AWS Backup console or through a combination of AWS Backup and AWS RAM CLI commands.

Each logically air-gapped comes equipped with a vault lock in compliance mode. See [AWS Backup Vault Lock](vault-lock.md) to help determine the retention period values most appropriate for your operation

------
#### [ Console ]

**Create a logically air-gapped vault from the console**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. In the navigation pane, select **Vaults**.

1. Both types of vaults will be displayed. Select **Create new vault**.

1. Enter a name for your backup vault. You can name your vault to reflect what you will store in it, or to make it easier to search for the backups you need. For example, you could name it `FinancialBackups`.

1. Select the radio button for **Logically air-gapped vault**. 

1. *(Optional)* Choose an encryption key. You can select a customer-managed KMS key for additional control over encryption, or use the default AWS-owned key (recommended).

1. Set the **Minimum retention period**.

   This value (in days, months, or years) is the shortest amount of time a backup can be retained in this vault. Backups with retention periods shorter than this value cannot be copied to this vault.

   The minimum value allowed is `7` days. Values for months and years meet this minimum.

1. Set the **Maximum retention period**.

   This value (in days, months, or years) is the longest amount of time a backup can be retained in this vault. Backups with retention periods greater than this value cannot be copied to this vault.

1. *(Optional)* Set the **Encryption key**.

   Specify the key to use with your vault. You can choose an **AWS owned key (managed by AWS Backup)** or enter the ARN for a **Customer managed key** that preferably belongs to a different account to which you have access. AWS Backup recommends using an AWS owned key.

1. *(Optional)* Add tags that will help you search for and identify your logically air-gapped vault. For example, you could add a `BackupType:Financial` tag.

1. Select **Create vault**.

1. Review the settings. If all settings show as you intended, select **Create logically air-gapped vault**.

1. The console will take you to the details page of your new vault. Verify the vault details are as expected.

1. Select **Vaults** to view vaults in your account. Your logically air-gapped vault will be displayed. The KMS key will be available approximately 1 to 3 minutes after the vault creation. Refresh the page to see the associated key. Once the key is visible, the vault is in an available state and can be used.

------
#### [ AWS CLI ]

Create a logically air-gapped vault from CLI

You can use AWS CLI to programmatically carry out operations for logically air-gapped vaults. Each CLI is specific to the AWS service in which it originates. Commands related to sharing are prepended with `aws ram`; all other commands should be prepended with `aws backup`.

Use the CLI command [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-logically-air-gapped-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-logically-air-gapped-backup-vault.html), modified with the following parameters:

```
aws backup create-logically-air-gapped-backup-vault
--region us-east-1 // optional
--backup-vault-name sampleName // required
--min-retention-days 7 // required Value must be an integer 7 or greater
--max-retention-days 35 // required
--encryption-key-arn arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012 // optional
--creator-request-id 123456789012-34567-8901 // optional
```

The optional `--encryption-key-arn` parameter allows you to specify a customer-managed KMS key for vault encryption. If not provided, the vault will use an AWS-owned key.

Example CLI command to create a logically air-gapped vault:

```
aws backup create-logically-air-gapped-backup-vault
--region us-east-1
--backup-vault-name sampleName
--min-retention-days 7
--max-retention-days 35
--creator-request-id 123456789012-34567-8901 // optional
```

Example CLI command to create a logically air-gapped vault with customer-managed encryption:

```
aws backup create-logically-air-gapped-backup-vault
--region us-east-1
--backup-vault-name sampleName
--min-retention-days 7
--max-retention-days 35
--encryption-key-arn arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012
--creator-request-id 123456789012-34567-8901 // optional
```

See [CreateLogicallyAirGappedBackupVault API response elements](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_CreateLogicallyAirGappedBackupVault.html) for information after the create operation. If the operation was successful, the new logically air-gapped vault will have the VaultState of `CREATING`.

Once the creation is complete and the KMS encrypted key has been assigned, the VaultState will transition to `AVAILABLE`. Once available, the vault can be used. `VaultState` can be retrieved by calling [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupVault.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupVault.html) or [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html).

------

## View logically air-gapped vault details
<a name="lag-view"></a>

You can see the vault details such as summary, the recovery points, the protected resources, account sharing, access policy, and tags through the AWS Backup console or the AWS Backup CLI.

------
#### [ Console ]

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. Select **Vaults** from the left-hand navigation.

1. Below the descriptions of vaults will be three lists, **Vaults created by this account**, **Vaults shared through RAM**, and **Vaults accessible through Multi-party approval**. Select the desired tab to view the vaults.

1. Under **Vault name**, click on the name of the vault to open the details page. You can see the summary, the recovery points, the protected resources, account sharing, access policy, and tag details.

   Details display depending on account type: Accounts which own a vault can view account sharing; accounts which do not own a vault will not be able to view account sharing. For shared vaults, the encryption key type (AWS-owned or customer-managed KMS key) is displayed in the vault summary.

------
#### [ AWS CLI ]

View details of a logically air-gapped vault through CLI

The CLI command [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/describe-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/describe-backup-vault.html) can be used to obtain details about a vault. Parameter `backup-vault-name` is required; `region` is optional.

```
aws backup describe-backup-vault
--region us-east-1
--backup-vault-name testvaultname
```

Example of response:

```
{
            "BackupVaultName": "LOG-AIR-GAP-VAULT-TEST",
            "BackupVaultArn": "arn:aws:backup:us-east-1:234567890123:backup-vault:IAD-LAGV-01",
            "VaultType": "LOGICALLY_AIR_GAPPED_BACKUP_VAULT",
            "EncryptionKeyType": "AWS_OWNED_KMS_KEY",
            "CreationDate": "2024-07-25T16:05:23.554000-07:00",
            "NumberOfRecoveryPoints": 0,
            "Locked": true,
            "MinRetentionDays": 8,
            "MaxRetentionDays": 30,
            "LockDate": "2024-07-25T16:05:23.554000-07:00"
}
```

**Note**  
The `VaultType` field is not included in the API response in regions where logically air-gapped vaults are not available.

------

## Creating backups in a logically air-gapped vault
<a name="lag-creation"></a>

Logically air-gapped vaults can be a copy job destination target in a backup plan or a target for an on-demand copy job. It can also be used as a primary backup target. See [Primary backups to logically air-gapped vaults](lag-vault-primary-backup.md).

**Compatible encryption**

A successful copy job from a backup vault to a logically air-gapped vault requires an encryption key that is determined by the resource type being copied.

When you create or copy a backup of a [fully managed resource type](backup-feature-availability.md#features-by-resource), the source resource can be encrypted by a customer managed key or by an AWS managed key.

When you create or copy a backup of other resource types (ones [not fully managed](backup-feature-availability.md#features-by-resource)), the source must be encrypted with a customer managed key. AWS managed keys for not fully managed resources are not supported.

**Create or copy backups to a logically air-gapped vault through a backup plan**

You can copy a backup (recovery point) from a standard backup vault to a logically air-gapped vault by [creating a new backup plan](creating-a-backup-plan.md) or [updating an existing one](updating-a-backup-plan.md) in the AWS Backup console or through the AWS CLI commands [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-backup-plan.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-backup-plan.html) and [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/update-backup-plan.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/update-backup-plan.html). You can also create backups directly in a logically air-gapped vault by using it as a primary target. See [Primary backups to logically air-gapped vaults](lag-vault-primary-backup.md) for more details.

You can copy a backup from one logically air-gapped vault to another logically air-gapped vault on-demand (this type of backup cannot be scheduled in a backup plan). You can copy a backup from a logically air-gapped vault to a standard backup vault as long as the copy is encrypted with a customer managed key.

**On-demand backup copy to a logically air-gapped vault**

To create a one-time [on-demand](recov-point-create-on-demand-backup.md) copy of a backup to a logically air-gapped vault, you can copy from a standard backup vault. Cross-Region or cross-account copies are available if the resource type supports the copy type.

**Copy availability**

A copy of a backup can be created from the account to which the vault belongs. Accounts with which the vault has been shared have the ability to view or a restore a backup, but not to create a copy.

Only [resource types that support cross-Region or cross-account copy](backup-feature-availability.md#features-by-resource) can be included.

------
#### [ Console ]

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. Select **Vaults** from the left-hand navigation.

1. In the vault detail page, all recovery points within that vault are displayed. Place a check mark next to the recovery point you wish to copy.

1. Select **Actions**, and then select **Copy** from the drop-down menu.

1. On the next screen, input the details of the destination.

   1. Specify the destination Region.

   1. Destination backup vault drop-down menu displays eligible destination vaults. Select one with the type `logically air-gapped vault`

1. Select **Copy** once all details are set to your preferences. 

On the **Jobs** page in the console, you can select **Copy** jobs to see current copy jobs.

------
#### [ AWS CLI ]

Use [start-copy-job](https://amazonaws.com/aws-backup/latest/devguide/API_StartCopyJob.html) to copy an existing backup in a backup vault to a logically air-gapped vault.

Sample CLI input:

```
aws backup start-copy-job
--region us-east-1
--recovery-point-arn arn:aws:resourcetype:region::snapshot/snap-12345678901234567
--source-backup-vault-name sourcevaultname
--destination-backup-vault-arn arn:aws:backup:us-east-1:123456789012:backup-vault:destinationvaultname
--iam-role-arn arn:aws:iam::123456789012:role/service-role/servicerole
```

------

For more information, see [ Copying a backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-a-copy.html), [ cross-Region backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html), and [ Cross-account backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html).

## Share a logically air-gapped vault
<a name="lag-share"></a>

You can use AWS Resource Access Manager (RAM) to share a logically air-gapped vault with other accounts you designate. When sharing vaults, the encryption key type information (AWS-owned or customer-managed KMS key) is preserved and visible to accounts with which the vault is shared.

A vault can be shared with an account in its organization or with an account in another organization. The vault cannot be shared with an entire organization, only with accounts within the organization.

Only accounts with specific IAM privileges can share and manage the sharing of vaults.

To share using AWS RAM, ensure you have the following:
+ Two or more accounts that can access AWS Backup
+ Vault-owning account that intends to share has necessary RAM permissions. The permission `ram:CreateResourceShare` is necessary for this procedure. The policy `AWSResourceAccessManagerFullAccess` contains all needed RAM-related permissions:
  + `backup:DescribeBackupVault`
  + `backup:DescribeRecoveryPoint`
  + `backup:GetRecoveryPointRestoreMetadata`
  + `backup:ListProtectedResourcesByBackupVault`
  + `backup:ListRecoveryPointsByBackupVault`
  + `backup:ListTags`
  + `backup:StartRestoreJob`
+ At least one logically air-gapped vault

------
#### [ Console ]

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. Select **Vaults** from the left-hand navigation.

1. Below the descriptions of vaults will be two lists, **Vaults owned by this account** and **Vaults shared with this account**. Vaults owned by the account are eligible to be shared.

1. Under **Vault name**, select the name of the logically air-gapped vault to open the details page.

1. The **Account sharing** pane shows with which accounts the vault is being shared.

1. To begin sharing with another account or to edit accounts already being shared, select **Manage sharing**.

1. The AWS RAM console opens when **Manage sharing** is selected. For steps to share a resource using AWS RAM, see [Creating a resource share in AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) in the *AWS RAM User Guide*.

1. The account invited to accept an invitation to receive a share has 12 hours to accept the invitation. See [ Accepting and rejecting resource share invitations](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared-invitations.html) in the *AWS RAM User Guide*.

1. If the sharing steps are completed and accepted, the vault summary page will show under **Account sharing = “Shared - see account sharing table below**”.

------
#### [ AWS CLI ]

AWS RAM uses the CLI command `create-resource-share`. The access to this command is only available to accounts with sufficient permissions. See [ Creating a resource share in AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) for CLI steps.

Steps 1 through 4 are conducted with the account that owns the logically air-gapped vault. Steps 5 through 8 are conducted with the account with which the logically air-gapped vault will be shared.

1. Log into the owning account OR request a user at your organization with sufficient credentials for accessing the source account completes these steps. 

   1. If a resource share was previously created and you wish to add an additional resource to it, use CLI `associate-resource-share` instead with the ARN of the new vault.

1. Fetch credentials of a role with sufficient permissions to share via RAM. [Input these into the CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-new). 

   1. The permission `ram:CreateResourceShare` is necessary for this procedure. The policy [AWSResourceAccessManagerFullAccess](https://console.aws.amazon.com/iamv2/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSResourceAccessManagerFullAccess) contains all RAM-related permissions. 

1. Use [create-resource-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/create-resource-share.html).

   1. Include the ARN of the logically air-gapped vault.

   1. Example input:

      ```
      aws ram create-resource-share
      --name MyLogicallyAirGappedVault
      --resource-arns arn:aws:backup:us-east-1:123456789012:backup-vault:test-vault-1
      --principals 123456789012
      --region us-east-1
      ```

   1. Example output:

      ```
      {
         "resourceShare":{
            "resourceShareArn":"arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-09876543",
            "name":"MyLogicallyAirGappedVault",
            "owningAccountId":"123456789012",
            "allowExternalPrincipals":true,
            "status":"ACTIVE",
            "creationTime":"2021-09-14T20:42:40.266000-07:00",
            "lastUpdatedTime":"2021-09-14T20:42:40.266000-07:00"
         }
      }
      ```

1. Copy the resource share ARN in the output (which is needed for subsequent steps). Give the ARN to the operator of account you are inviting to receive the share.

1. Obtain the resource share ARN

   1. If you did not perform steps 1 through 4, obtain the resourceShareArn from whomever did.

   1. Example: `arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-09876543`

1. In the CLI, assume credentials of the recipient account.

1. Get resource share invitation with [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/get-resource-share-invitations.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/get-resource-share-invitations.html). For more information, see [ Accepting and rejecting invitations](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared-invitations.html) in the *AWS RAM User Guide*.

1. Accept the invitation in destination (recovery) account.

   1. Use [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/accept-resource-share-invitation.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/accept-resource-share-invitation.html) (can also [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/reject-resource-share-invitation.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/reject-resource-share-invitation.html)).

You can use AWS RAM CLI commands to view shared items:
+ Resources you have shared:

  `aws ram list-resources --resource-owner SELF --resource-type backup:backup-vault --region us-east-1`
+ Show the principal:

  `aws ram get-resource-share-associations --association-type PRINCIPAL --region us-east-1`
+ Resources shared by other accounts:

  `aws ram list-resources --resource-owner OTHER-ACCOUNTS --resource-type backup:backup-vault --region us-east-1`

------

## Restore a backup from a logically air-gapped vault
<a name="lag-restore"></a>

You can restore a backup stored in a logically air-gapped vault from either the account that owns the vault or from any account with which the vault is shared.

See [Restoring a backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html) for information on how to restore a recovery point through the AWS Backup console.

Once a backup has been shared from a logically air-gapped vault to your account, you can use [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html) to restore the backup.

A sample CLI input can include the following command and parameters:

```
aws backup start-restore-job
--recovery-point-arn arn:aws:backup:us-east-1:accountnumber:recovery-point:RecoveryPointID
--metadata {\"availabilityzone\":\"us-east-1d\"}
--idempotency-token TokenNumber
--resource-type ResourceType
--iam-role arn:aws:iam::number:role/service-role/servicerole
--region us-east-1
```

## Delete a logically air-gapped vault
<a name="lag-delete"></a>

See [delete a vault](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault.html#delete-a-vault). Vaults cannot be deleted if they still contain backups (recovery points). Ensure the vault is empty of backups before you initiate a delete operation.

Deletion of a vault also deletes the key associated with the vault seven days after the vault is deleted in accordance with key deletion policy.

The following sample CLI command [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-backup-vault.html) can be used to delete a vault.

```
aws backup delete-backup-vault
--region us-east-1 
--backup-vault-name testvaultname
```

## Additional programmatic options for logically air-gapped vaults
<a name="lag-programmatic"></a>

The CLI command [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html) can be modified to list all the vaults owned by and present in the account:

```
aws backup list-backup-vaults
--region us-east-1
```

To list just the logically air-gapped vaults, add the parameter

```
--by-vault-type LOGICALLY_AIR_GAPPED_BACKUP_VAULT
```

Include the parameter `by-shared` to filter the returned list of vaults to show only shared logically air-gapped vaults. The response will include encryption key type information for each shared vault.

```
aws backup list-backup-vaults
--region us-east-1
--by-shared
```

Example response showing encryption key type information:

```
{
    "BackupVaultList": [
        {
            "BackupVaultName": "shared-logically air-gapped-vault",
            "BackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:shared-logically air-gapped-vault",
            "VaultType": "LOGICALLY_AIR_GAPPED_BACKUP_VAULT",
            "EncryptionKeyType": "AWS_OWNED_KMS_KEY",
            "CreationDate": "2024-07-25T16:05:23.554000-07:00",
            "Locked": true,
            "MinRetentionDays": 7,
            "MaxRetentionDays": 30
        }
    ]
}
```

**Note**  
The `VaultType` field is not included in the API response in regions where logically air-gapped vaults are not available.

## Understanding encryption key types for logically air-gapped vaults
<a name="lag-encryption-key-types"></a>

Logically air-gapped vaults support different encryption key types, and this information is visible through AWS Backup APIs and console. When vaults are shared through AWS RAM or MPA, the encryption key type information is preserved and made visible to accounts with which the vault is shared. This transparency helps you understand the encryption configuration of vaults and make informed decisions about backup and restore operations.

### Encryption key type values
<a name="encryption-key-type-values"></a>

The `EncryptionKeyType` field can have the following values:
+ `AWS_OWNED_KMS_KEY` - The vault is encrypted with an AWS-owned key. This is the default encryption method for logically air-gapped vaults when no customer-managed key is specified.
+ `CUSTOMER_MANAGED_KMS_KEY` - The vault is encrypted with a customer-managed KMS key that you control. This option provides additional control over encryption keys and access policies.

**Note**  
AWS Backup recommends using AWS owned keys with logically air-gapped vaults.
If your organization policy requires using a customer managed key, AWS does not recommend using keys from the same account, except for testing. For production workloads, use a customer managed key from another account in a secondary organization dedicated to recovery as a best practice. You can reference the blog [ Encrypt AWS Backup logically air-gapped vaults with customer-managed keys](https://aws.amazon.com/blogs/storage/encrypt-aws-backup-logically-air-gapped-vaults-with-customer-managed-keys/) to gather more insights into setting up CMK based logically air-gapped vaults.
 You can only select an AWS KMS encryption key during vault creation. Once created, all backups contained in the vault will be encrypted with that key. You cannot change or migrate your vaults to use a different encryption key.

### Key policy for CMK encrypted logically air-gapped vault creation
<a name="key-policy-lag-vault-creation"></a>

When creating a logically air-gapped vault with a customer managed key, you must apply the AWS-managed policy `AWSBackupFullAccess` to your account role. This policy includes `Allow` actions that enable AWS Backup to interact with AWS KMS for grant creation on KMS keys during backup, copy, and storage operations. Additionally, you must ensure your customer managed key (if used) policy includes specific required permissions.
+ The CMK must be shared with the account where the logically air-gapped vault resides

```
{  
    "Sid": "Allow use of the key to create a logically air-gapped vault",  
    "Effect": "Allow",  
    "Principal": {  
        "AWS": "arn:aws:iam::[account-id]:role/TheRoleToAccessAccount"  
    },  
    "Action": [  
        "kms:CreateGrant",  
        "kms:DescribeKey"  
    ],  
    "Resource": "*",  
   "Condition": {  
        "StringLike": {  
            "kms:ViaService": "backup.*.amazonaws.com"  
        }  
   }  
}
```

**Key policy for copy/restore**

To prevent job failures, review your AWS KMS key policy to ensure it includes all required permissions and doesn't contain any deny statements that could block operations. The following conditions apply:
+ For all copy scenarios, the CMKs must be shared with the source copy role

```
{  
    "Sid": "Allow use of the key for copy",  
    "Effect": "Allow",  
    "Principal": {  
        "AWS": "arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole"      //[Source copy role]          
    },  
    "Action": [  
        "kms:Encrypt",  
        "kms:Decrypt",  
        "kms:ReEncrypt*",  
        "kms:GenerateDataKey*",  
        "kms:DescribeKey"  
    ],  
    "Resource": "*",  
   "Condition": {  
         "StringLike": {  
            "kms:ViaService": "backup.*.amazonaws.com"  
         }  
   }  
},  
{  
    "Sid": "Allow AWS Backup to create grant on the key for copy",  
    "Effect": "Allow",  
    "Principal": {  
        "AWS": "arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole" //[Source copy role]   
    },  
    "Action": [  
        "kms:CreateGrant"  
    ],  
    "Resource": "*",  
    "Condition": {  
        "Bool": {  
            "kms:GrantIsForAWSResource": "true"  
        },  
        "StringLike": {  
            "kms:ViaService": "backup.*.amazonaws.com"  
        }  
    }  
}
```
+ When copying from a CMK encrypted logically air-gapped vault to a backup vault, the CMK must also be shared with the destination account SLR

```
{  
    "Sid": "Allow use of the key for copy from a CMK encrypted logically air-gapped vault to normal backup vault",
    "Effect": "Allow",  
    "Principal": {  
        "AWS": ["arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole",      //[Source copy role]  
                "arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]    
    },  
    "Action": [  
        "kms:Encrypt",  
        "kms:Decrypt",  
        "kms:ReEncrypt*",  
        "kms:GenerateDataKey*",  
        "kms:DescribeKey"  
    ],  
    "Resource": "*"  
},  
{  
    "Sid": "Allow AWS Backup to create grant on the key for copy",  
    "Effect": "Allow",  
    "Principal": {  
          "AWS": ["arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole",      //[Source copy role]  
                  "arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]   
    },  
    "Action": [  
        "kms:CreateGrant"  
    ],  
    "Resource": "*",  
    "Condition": {  
        "Bool": {  
            "kms:GrantIsForAWSResource": "true"  
        }  
    }  
}
```
+ When copying or restoring from a recovery account using RAM/MPA shared logically air-gapped vault

```
{  
    "Sid": "Allow use of the key for copy/restore from a recovery account",  
    "Effect": "Allow",  
    "Principal": {  
        "AWS": ["arn:aws:iam::[recovery-account-id]:role/service-role/AWSBackupDefaultServiceRole", //[Recovery account copy/restore role]
                "arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"] //[Destination SLR]    
    },  
    "Action": [  
        "kms:Encrypt",  
        "kms:Decrypt",  
        "kms:ReEncrypt*",  
        "kms:GenerateDataKey*",  
        "kms:DescribeKey"  
    ],  
    "Resource": "*"  
},  
{  
    "Sid": "Allow AWS Backup to create grant on the key for copy",  
    "Effect": "Allow",  
    "Principal": {  
        "AWS": ["arn:aws:iam::[recovery-account-id]:role/service-role/AWSBackupDefaultServiceRole" //[Recovery account copy/restore role]    
                "arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]  
                  
    },  
    "Action": [  
        "kms:CreateGrant"  
    ],  
    "Resource": "*",  
    "Condition": {  
        "Bool": {  
            "kms:GrantIsForAWSResource": "true"  
        }  
    }  
}
```

**IAM Role**

When performing logically air-gapped vault copy operations, customers can utilize the `AWSBackupDefaultServiceRole` which includes the AWS-managed policy `AWSBackupServiceRolePolicyForBackup`. However, if customers prefer to implement a least-privilege policy approach, their IAM policy must include a specific requirement:
+ The source account's copy role must have access permissions to both the source and destination CMKs.

```
{  
    "Version": "2012-10-17"		 	 	 ,		 	 	   
    "Statement": [  
         {  
            "Sid": "KMSPermissions",  
            "Effect": "Allow",  
            "Action": "kms:DescribeKey",  
            "Resource": [  
                "arn:aws:kms:*:[source-account-id]:key/*",  - Source logically air-gapped vault CMK -   
                "arn:aws:kms:*:[destination-account-id]:key/*".  - Destination logically air-gapped vault CMK -   
            ]  
        },  
        {  
            "Sid": "KMSCreateGrantPermissions",  
            "Effect": "Allow",  
            "Action": "kms:CreateGrant",  
            "Resource": [  
                "arn:aws:kms:*:[source-account-id]:key/*",  - Source logically air-gapped vault CMK -   
                "arn:aws:kms:*:[destination-account-id]:key/*".  - Destination logically air-gapped vault CMK -   
            ]  
            "Condition": {  
                "Bool": {  
                    "kms:GrantIsForAWSResource": "true"  
                }  
            }  
        },  
    ]  
}
```

Consequently, one of the most common customer errors occurs during copy when customers fail to provide sufficient permissions on their CMKs and copy roles.

### Viewing encryption key types
<a name="viewing-encryption-key-types"></a>

You can view encryption key type information through both the AWS Backup console and programmatically using the AWS CLI or SDKs.

**Console:** When viewing logically air-gapped vaults in the AWS Backup console, the encryption key type is displayed in the vault details page under the security information section.

**AWS CLI/API:** The encryption key type is returned in the response of the following operations when querying logically air-gapped vaults:
+ `list-backup-vaults` (including `--by-shared` for shared vaults)
+ `describe-backup-vault`
+ `describe-recovery-point`
+ `list-recovery-points-by-backup-vault`
+ `list-recovery-points-by-resource`

### Considerations for vault encryption
<a name="encryption-key-type-considerations"></a>

When working with logically air-gapped vaults and encryption key types, consider the following:
+ **Key selection during creation:** You can optionally specify a customer-managed KMS key when creating a logically air-gapped vault. If not specified, an AWS-owned key will be used.
+ **Shared vault visibility:** Accounts with which a vault is shared can view the encryption key type but cannot modify the encryption configuration.
+ **Recovery point information:** The encryption key type is also available when viewing recovery points within logically air-gapped vaults.
+ **Restore operations:** Understanding the encryption key type helps you plan restore operations and understand any potential access requirements.
+ **Compliance:** The encryption key type information supports compliance reporting and audit requirements by providing transparency into the encryption methods used for backup data.

## Usage of service-owned key
<a name="lag-service-owned-key"></a>

AWS Backup creates and manages encryption keys that are used to encrypt all the backup data stored in logically air-gapped vaults, to protect and prevent loss of access of the encryption key during a data loss event.
+ These keys are free of charge and do not count against the AWS KMS quotas for your account.
+ A single key is only used for a specific vault and is not shared with any other account or other purpose.
+ These keys are deleted once the assigned (empty) vault is also deleted.
+ These keys are created using the [SYMMETRIC\$1DEFAULT key spec](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html#symmetric-cmks).
+ The default rotation policy is 90 days. You can request rotation (once every 6 months) of service-owned encryption keys for your logically air-gapped vaults through a support ticket.

Visit the [AWS KMS documentation](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) to learn more.

## Considerations for security auto-remediation
<a name="lag-security-auto-remediation"></a>

When AWS Backup copies an EC2 (AMI) backup to a logically air-gapped vault, it temporarily grants `launchPermission` (on the AMI) and `createVolumePermission` (on associated EBS snapshots) to a service-owned account. These permissions are automatically revoked after the copy completes.

These operations generate `ModifyImageAttribute` and `ModifySnapshotAttribute` events in your AWS CloudTrail logs, with `userIdentity.invokedBy` set to `backup.amazonaws.com`.

If you have security auto-remediation logic (e.g., Amazon EventBridge rules with AWS Lambda) that monitors these events and revokes cross-account sharing, you must exclude events where `userIdentity.invokedBy` is `backup.amazonaws.com`. Otherwise, copy jobs to logically air-gapped vaults will fail with: "You do not have permission to access the storage of this ami."

This exclusion is safe because the copy is authorized by your vault access policies (`backup:CopyFromBackupVault` on the source vault and `backup:CopyIntoBackupVault` on the destination vault), which are evaluated before any EC2 attribute modifications occur. The temporary permissions are granted only to a fixed AWS service-owned account and are automatically revoked after the copy completes.

Example EventBridge rule event pattern that excludes AWS Backup operations:

```
{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["ModifySnapshotAttribute", "ModifyImageAttribute"],
    "userIdentity": {
      "invokedBy": [{"anything-but": "backup.amazonaws.com"}]
    }
  }
}
```

## Troubleshoot a logically air-gapped vault issue
<a name="lag-troubleshoot"></a>

If you encounter errors during your workflow, consult the following example errors and suggested resolutions:

### `EC2 AMI copy job to logically air-gapped vault fails with permission error`
<a name="w2aac15c13c31b5"></a>

**Error:** `Copy job fails with "You do not have permission to access the storage of this ami."`

**Possible cause:** During an EC2 AMI copy job to a logically air-gapped vault, AWS Backup temporarily grants launch permission (AMI) and create volume permission (EBS snapshot) to a service-owned account, generating `ModifyImageAttribute` and `ModifySnapshotAttribute` events in your AWS CloudTrail logs. If you have security auto-remediation logic (such as EventBridge rules with Lambda) that monitors these events and automatically revokes cross-account sharing permissions, it can remove the temporary access before the copy completes.

**Note**  
This can similarly happen for copy jobs for other resources like Amazon FSx.

**Resolution:** Update your EventBridge rule event pattern to exclude operations performed by AWS Backup. Specifically, exclude events where `userIdentity.invokedBy` is `backup.amazonaws.com` to ensure your auto-remediation logic does not revoke the temporary cross-account permissions that AWS Backup grants during the copy process.

### `AccessDeniedException`
<a name="w2aac15c13c31b7"></a>

**Error:** `An error occured (AccessDeniedException) when calling the [command] operation: Insufficient privileges to perform this action."`

**Possible cause:** The parameter `--backup-vault-account-id` was not included when one of the following requests was run on a vault shared by RAM:
+ `describe-backup-vault`
+ `describe-recovery-point`
+ `get-recovery-point-restore-metadata`
+ `list-protected-resources-by-backup-vault`
+ `list-recovery-points-by-backup-vault`

**Resolution:** Retry the command that returned the error, but include the parameter `--backup-vault-account-id` that specifies the account that owns the vault.

### `OperationNotPermittedException`
<a name="w2aac15c13c31b9"></a>

**Error:** `OperationNotPermittedException` is returned after a `CreateResourceShare` call.

**Possible cause:** If you attempted to share a resource, such as a logically air-gapped vault, with another organization, you may get this exception. A vault can be shared with an account in another organization, but it cannot be shared with the other organization itself.

**Resolution:** Retry the operation, but specify an account as the value for `principals` instead of an organization or OU.

### Encryption key type not displayed
<a name="w2aac15c13c31c11"></a>

**Issue:** The encryption key type is not visible when viewing a logically air-gapped vault or its recovery points.

**Possible causes:**
+ You are viewing an older vault that was created before encryption key type support was added
+ You are using an older version of the AWS CLI or SDK
+ The API response does not include the encryption key type field

**Resolution:**
+ Update your AWS CLI to the latest version
+ For older vaults, the encryption key type will be populated automatically and should appear in subsequent API calls
+ Verify you are using the correct API operations that return encryption key type information
+ For shared vaults, verify that the vault is properly shared through AWS Resource Access Manager

### "FAILED" VaultState with AccessDeniedException in CloudTrail logs
<a name="w2aac15c13c31c13"></a>

**Error in CloudTrail:** `"User: <assumed role> is not authorized to perform: kms:CreateGrant on this resource because the resource does not exist in this Region, no resource-based policies allow access, or a resource-based policy explicitly denies access"`

**Possible causes:**
+ The vault was created using a customer managed key, but the assumed role does not have CreateGrant permission on the key policy required to use the key for vault creation

**Resolution:**
+ Grant the permissions specified in the [Key policy for CMK encrypted logically air-gapped vault creation](#key-policy-lag-vault-creation) section, then retry the vault creation workflow.

# Primary backups to logically air-gapped vaults
<a name="lag-vault-primary-backup"></a>

## Overview
<a name="lag-primary-backup-overview"></a>

The logically air-gapped vault primary backup feature offers you the option to specify a logically air-gapped vault as a primary backup destination within the same account, for both scheduled and on-demand backup jobs. This eliminates the need to maintain separate copies in both a standard backup vault and a logically air-gapped vault, reducing costs and simplifying workflows while preserving the security benefits of logical air-gapping.

You can assign a logically air-gapped vault as the primary target in backup plans, organization-wide policies, or on-demand backups. Previously, to back up to a logically air-gapped vault, you first had to create a backup in a backup vault and then copy it to a logically air-gapped vault. With this feature, depending on the resource type, AWS Backup can create backups directly in your logically air-gapped vault or automatically manage temporary backups that are copied to your logically air-gapped vault and then deleted.

The behavior depends on two factors:
+ Whether the resource type is supported by logically air-gapped vault.
+ Whether the resource type supports [full AWS Backup management](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#full-management).

**Warning**  
We recommend integrating your logically air-gapped vaults with [Multi-party approval](https://docs.aws.amazon.com/aws-backup/latest/devguide/multipartyapproval.html) (MPA) if you adopt this capability. This enables recovery of backups in the vault even if the vault-owning account is inaccessible.

There is no new pricing for this feature. You are only charged for backups stored in logically air-gapped vaults and for temporary snapshots (during their retention period in the system) for applicable resources at prevailing rates. See [AWS Backup pricing](https://aws.amazon.com/backup/pricing/) for details.

**Topics**
+ [

## Overview
](#lag-primary-backup-overview)
+ [

## How it works
](#lag-primary-backup-how-it-works)
+ [

## Cost considerations
](#lag-primary-backup-cost)
+ [

## Configure logically air-gapped vault primary backup
](#lag-primary-backup-configure)
+ [

## Monitor logically air-gapped vault primary backup
](#lag-primary-backup-monitor)
+ [

## Onboarding and migration
](#lag-primary-backup-onboarding)
+ [

## Troubleshooting
](#lag-primary-backup-troubleshooting)

## How it works
<a name="lag-primary-backup-how-it-works"></a>

You can onboard to this feature by updating your existing backup plan or creating a new one and adding a logically air-gapped vault ARN (field name: `TargetLogicallyAirGappedBackupVaultArn`) as a primary backup target. You can perform this operation either through the AWS Backup console or through AWS Backup CLI commands.

```
"TargetLogicallyAirGappedBackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:AirGappedVault",
```

When you specify both a backup vault and a logically air-gapped vault as targets for your backup jobs, AWS Backup determines the appropriate workflow based on the resource type and encryption configuration.

![\[alt text not found\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/images/lag-vault-primary-backup-execution.png)


**Supported resources for primary backup to logically air-gapped vaults**  
To view the full list of supported resources for logically air-gapped vaults, [see AWS Backup feature availability](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-for-all-resources). All resources that support logically air-gapped vaults follow the principle of maintaining only one copy of your backup, rather than storing two separate copies, when this feature is used.

**Warning**  
Resources not currently supported for this feature may have their support enabled in the future. When that occurs, your newly supported resource will automatically start backing up in the logically air-gapped vault using the workflow shown above.

**Considerations and limitations:**  

+ **Same account and Region only** – Your logically air-gapped vault must be in the same AWS account and Region as your resources to use this feature. You cannot create backups directly cross-account or cross-Region. We recommend backing up to a logically air-gapped vault in the same Region to enable faster recovery without requiring a copy. If you require a copy of your data in a second Region for Disaster Recovery (DR), we recommend either cross-Region replication of your primary resources for quick failover or cross-Region recovery point copies to a locked backup vault.
+ **Constraints with using AWS managed keys** – Resources not supporting full AWS Backup management and encrypted with AWS managed keys (for example, `aws/ebs`, `aws/rds`) cannot be copied to logically air-gapped vaults. These resources must be encrypted with a customer managed KMS key or be unencrypted. Resources supporting full AWS Backup management **do not have this constraint.**
+ **Backup frequency and concurrent copies** – For resources not supporting full AWS Backup management, ensure your backup frequency allows sufficient time for copies to complete. If backups are scheduled more frequently than copies can finish, copy jobs will queue and may eventually fail. For guidance on concurrent copy limits, [see quotas](aws-backup-limits.md#lag-vault-quotas-table).
+ **Lifecycle compatibility** – The retention period specified in your backup plan must be compatible with the minimum and maximum retention periods configured for your logically air-gapped vault.
+ **Locked backup vaults** – If your target backup vault has a vault lock enabled, temporary recovery points cannot be deleted manually and will be retained until either the copy completes or the retention period expires.
+ **Restore testing, indexing, and scanning** – Restore testing, recovery point indexing, and malware scanning will ignore temporary recovery points with a `DELETE_AFTER_COPY` lifecycle. Recovery point indexing does not support recovery points in logically air-gapped vault. Malware scanning does not support scheduled scans of copied recovery points, which includes automatic copies taken as part of primary backups to logically air-gapped vault.

### Resources supporting full AWS Backup management
<a name="lag-primary-backup-full-management"></a>

Some resource types, such as Amazon EFS, Amazon S3, Amazon DynamoDB with [AWS Backup advanced features](https://docs.aws.amazon.com/aws-backup/latest/devguide/advanced-ddb-backup.html) etc., that support full AWS Backup management, can back up directly to your logically air-gapped vault. No recovery point is created in your backup vault, and no copy operation is required. Any scheduled copy actions in your backup plan use the recovery point in your logically air-gapped vault as the source.

Resources that support continuous backup, such as Amazon S3, can also perform continuous backup directly to a logically air-gapped vault.

For a list of resource types supporting full AWS Backup management and logically air-gapped vaults, see [Feature availability by resource](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource) in the columns labeled "Full management" and "Logically air-gapped vault".

### Resource not supporting full AWS Backup management
<a name="lag-primary-backup-not-full-management"></a>

Resources such as Amazon EBS/EC2, Amazon Aurora, and Amazon FSx cannot back up directly to logically air-gapped vaults. For these resource types, AWS Backup creates a temporary recovery point in your backup vault and then automatically copies it to your logically air-gapped vault.

The temporary recovery point has a special lifecycle setting called `DELETE_AFTER_COPY`. Once the copy to your logically air-gapped vault completes successfully, AWS Backup automatically deletes the temporary recovery point. All other scheduled copy actions in your backup plan start in parallel with the copy to your logically air-gapped vault and do not impact your current copy experience.

If the copy to your logically air-gapped vault fails, the temporary recovery point is retained in your backup vault according to the retention period you specified. This helps you ensure that you always have a usable recovery point after a backup job completes. If the recovery point is later manually copied to the logically air-gapped vault, it is automatically cleaned up according to the `DELETE_AFTER_COPY` rule.

**Warning**  
Resources encrypted with AWS managed keys (for example, `aws/ebs`) are not supported for copy to logically air-gapped vaults. These resources must be encrypted with an AWS Key Management Service customer managed key or be unencrypted. Resources supporting full AWS Backup management do not have this constraint.

#### Delete after copy lifecycle
<a name="lag-primary-backup-delete-after-copy"></a>

Temporary recovery points have a new lifecycle attribute called `DeleteAfterEvent` with a value of `DELETE_AFTER_COPY`. This attribute indicates that the recovery point will be deleted automatically after all copy jobs are complete, or after the retention period you specified, whichever comes first.

A temporary recovery point is deleted when all the following conditions are true:
+ All automatic and scheduled copy jobs have finished.
+ There is a completed copy job to your target logically air-gapped vault with a retention period at least as long as the source recovery point.

If you need to prevent manual deletion of the temporary recovery point while copies are ongoing, consider using a locked backup vault as your target backup vault.

#### Continuous backup for Resource not supporting full AWS Backup management
<a name="lag-primary-backup-continuous-backup"></a>

For resources such as Amazon Aurora, if you enable continuous backup, AWS Backup creates a continuous recovery point in your backup vault and takes a temporary snapshot that is copied to your logically air-gapped vault. The temporary snapshot should be automatically deleted after the copy is completed, regardless of whether the copy succeeds or fails, because you retain a continuous recovery point in your backup vault.

If you do not want to create a continuous recovery point for Amazon Aurora in your backup vault, but do want a continuous recovery point for Amazon S3 in your logically air-gapped vault, then you can disable continuous backup (`EnableContinuousBackup`) setting in the current plan and enable S3 continuous from a different plan.

You can learn more about Aurora backup storage in [Understanding Amazon Aurora backup storage usage](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-storage-backup.html#aurora-storage-backup.automated).

### Unsupported resources
<a name="lag-primary-backup-unsupported"></a>

If a resource type is not supported by logically air-gapped vaults, or if a non-fully managed resource is encrypted with an AWS managed key, AWS Backup creates the backup in your backup vault only. No copy to your logically air-gapped vault is attempted. The backup job completes successfully with a message indicating why the backup did not go to your logically air-gapped vault.

## Cost considerations
<a name="lag-primary-backup-cost"></a>
+ This feature does not incur new charges. You only pay for the storage in your vaults.
+ For resources supporting full AWS Backup management, maintaining backups only in your logically air-gapped vault can result in significant cost savings compared to maintaining two backup copies in both a backup vault and a logically air-gapped vault.
+ For resources not supporting full AWS Backup management, you are charged for both the temporary recovery point in your backup vault and the recovery points in your logically air-gapped vault.
  + You can still achieve significant cost savings from retention of just a single backup copy, but these savings can vary based on your backup frequency and change rate.
  + Lower backup frequencies generally produce greater savings because temporary recovery points occupy storage for a shorter percentage of your billing period.
  + Some resources have minimum billing durations, which increase costs for temporary recovery points.
+ Disable Tags or ACLs metadata retrieval in your backup configuration if you do not use these S3 features. This reduces API calls and associated charges for metadata checks during copy operations.

## Configure logically air-gapped vault primary backup
<a name="lag-primary-backup-configure"></a>

You can configure logically air-gapped vault primary backup through the AWS Backup console, the AWS CLI, AWS CloudFormation, or AWS Organizations backup policies.

### Configure a Backup plan
<a name="lag-primary-backup-configure-plan"></a>

------
#### [ Console ]

**To configure logically air-gapped vault primary backup for a backup plan**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com//backup).

1. In the navigation pane, choose **Backup plans**, and then choose **Create backup plan** or select an existing backup plan to edit.

1. In the **Backup rule configuration** section, specify your backup rule settings.

1. For **Backup vault**, choose the backup vault where temporary recovery points will be stored (for non-fully managed resources) or where backups will be stored if they cannot be placed in your logically air-gapped vault.

1. For **Logically air-gapped vault (Optional)**, choose the logically air-gapped vault where you want your backups to be stored.
**Note**  
The logically air-gapped vault must be in the same account and Region as your backup vault.

1. Configure the remaining backup rule settings, including lifecycle and copy options.

1. Choose **Create plan** or **Save changes**.

------
#### [ AWS CLI ]

Use the CLI command [https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#create-backup-plan-cli](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#create-backup-plan-cli) to create a new plan, or [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_UpdateBackupPlan.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_UpdateBackupPlan.html) to update an existing plan, and include the `TargetLogicallyAirGappedBackupVaultArn` parameter in your backup rule.

Example CLI command to create a backup plan using a JSON document:

```
aws backup create-backup-plan --cli-input-json file://PATH-TO-FILE/test-backup-plan.json
```

Example CLI command to create a backup plan directly in CLI:

```
aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "MyPlan",
  "Rules": [
    {
      "RuleName": "MyRule",
      "TargetBackupVaultName": "MyBackupVault",
      "TargetLogicallyAirGappedBackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:MyLagVault",
      "ScheduleExpression": "cron(0 1 ? * * *)",
      "ScheduleExpressionTimezone": "America/Los_Angeles",
      "StartWindowMinutes": 60,
      "CompletionWindowMinutes": 120,
      "Lifecycle": {
        "DeleteAfterDays": 35
      }
    }
  ]
}'
```

------

### Configure on-demand backup
<a name="lag-primary-backup-configure-ondemand"></a>

------
#### [ Console ]

**To configure logically air-gapped vault primary backup for an on-demand backup**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com//backup).

1. In the navigation pane, choose **Protected resources**.

1. On the **Protected resources** page, choose **Create on-demand backup**.

1. Select the resource type and resource ARN you want to back up.

1. For **Backup vault**, choose the backup vault.

1. For **Logically air-gapped vault (Optional)**, choose the logically air-gapped vault where you want the backup to be stored.

1. Configure the remaining settings and choose **Create on-demand backup**.

------
#### [ AWS CLI ]

Use the start-backup-job command with the new `--logically-air-gapped-backup-vault-arn` parameter:

```
aws backup start-backup-job \
  --backup-vault-name MyBackupVault \
  --logically-air-gapped-backup-vault-arn arn:aws:backup:us-east-1:123456789012:backup-vault:MyLagVault  \
  --resource-arn arn:aws:ec2:us-east-1:123456789012:volume/vol-abcd1234  \
  --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole  \
  --lifecycle DeleteAfterDays=35
```

------

## Monitor logically air-gapped vault primary backup
<a name="lag-primary-backup-monitor"></a>

You can monitor the status of your backups and copy jobs using the AWS Backup console, AWS CLI, or Amazon EventBridge events.

### Monitor for Backup Jobs
<a name="lag-primary-backup-monitor-backup-jobs"></a>

Monitor backup job status ([https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupJob.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupJob.html)) to ensure your resources remain protected. A failed backup job indicates no recovery point was created.
+ **Verify recovery point creation location** - When a backup job completes successfully, you have a recovery point in either your target backup vault or your target logically air-gapped vault. Check the `BackupVaultArn` field to determine where the recovery point was created.
+ **Verify job status** - If a resource is not supported by logically air-gapped vaults, the backup job completes with a `MessageCategory` of `LOGICALLY_AIR_GAPPED_BACKUP_VAULT_NOT_SUPPORTED` and a status message explaining why the backup was created in your backup vault instead.
+ **Verify temporary recovery point type** - To check if a recovery point is temporary, look for the `RecoveryPointLifecycle.DeleteAfterEvent` field with a value of `DELETE_AFTER_COPY`.

### Monitor for Copy Jobs
<a name="lag-primary-backup-monitor-copy-jobs"></a>

Monitor copy jobs ([https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListCopyJobs.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListCopyJobs.html)) to your logically air-gapped vault for failures. A failed copy job means your recovery point remains in your standard backup vault without logically air-gapped vault protection.
+ **Verify copy job status** - You can monitor copy job status using the existing `Copy Job State Change` EventBridge event. Optionally, filter on the destination vault (`destinationBackupVaultArn`) to focus on logically air-gapped vault copies.
+ **Verify copies for a source recovery point** - Use the [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListCopyJobs.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListCopyJobs.html) API with the new `BySourceRecoveryPointArn` filter to find all copy jobs associated with a specific recovery point, including both automatic copies to your logically air-gapped vault and scheduled copies to other destinations.
+ **Verify deletion of temporary recovery point** - Track completion of temporary recovery point deletion. If the copy job state is `RUNNING`, the recovery point has not yet been deleted. If the copy to your logically air-gapped vault has `FAILED`, the recovery point will be retained per your specified retention period.

**Note**  
Copy job records expire and are removed 30 days after they finish. After this period, you cannot use `ListCopyJobs` to determine historical copy status.

### Monitor for Recovery point
<a name="lag-primary-backup-monitor-recovery-points"></a>

Monitor for `EXPIRED` recovery points ([https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html)), which may indicate AWS Backup could not delete them (possibly due to missing permissions). `EXPIRED` recovery points can have cost implications.
+ **Verify recovery point state** - Use the existing Recovery Point State Change EventBridge event to monitor expirations.
+ **Verify deletion of temporary recovery point** - If a recovery point with `DeleteAfterEvent: DELETE_AFTER_COPY` has not been deleted, use the `ListCopyJobs` API to determine the reason, as mentioned above.

## Onboarding and migration
<a name="lag-primary-backup-onboarding"></a>

If you currently use copy actions to copy backups to a logically air-gapped vault, you can migrate to logically air-gapped vault primary backup to reduce costs. You can also migrate your existing Amazon S3 continuous backups from a backup vault to a logically air-gapped vault. This guide explains the prerequisites and steps required to migrate to the logically air-gapped vault primary backup feature.

### Prerequisites and Best Practices
<a name="lag-primary-backup-prerequisites"></a>

Before you can effectively use logically air-gapped vault primary backup feature, there are prerequisites and recommended best practices.

**Prerequisites**  


Currently, a logically air-gapped vault as a primary backup target supports only backups within the same AWS account and AWS Region as your backup resources. Logically air-gapped vault backups are inherently stored in separate service accounts, providing cross-account / cross-Org isolation without requiring copies to a separate accounts. If you need cross-Region backups, continue using the logically air-gapped vault as a copy destination. Before migrating to this feature, ensure you meet the following requirements:
+ **Region and account requirements**
  + Your logically air-gapped vault must be in the same AWS account and Region as your resources
+ **Resource compatibility**
  + Verify that your resources are supported by logically air-gapped vaults in [Feature availability by resource](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource).
  + Check if your resources support [full AWS Backup management](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource) or not. The experience of creating air-gapped backups differs between these two types of resources, even though the outcome is similar for both.
+ **Encryption requirements**
  + Resources that do not support full AWS Backup management must be either unencrypted or encrypted with Customer Managed Keys (CMKs). AWS Managed Key (AMK) encrypted resources are not supported by logically air-gapped vault.

**Best Practices**  

+ Start with a pilot migration of non-critical resources.
+ Review and adjust backup frequencies based on copy job performance.
+ Implement comprehensive monitoring before full migration.
+ Regularly verify recovery point creation in intended vaults.

### Planning Your Migration
<a name="lag-primary-backup-planning"></a>
+ Review existing backup plans and policies.
+ Identify which resources support full AWS Backup management and which do not.
  + Resources supporting full AWS Backup management (e.g., EFS, S3) - can backup directly to logically air-gapped vault
  + Resources not supporting full AWS Backup management (e.g., EC2, EBS, FSx) - require temporary backup in backup vault before being copied to Logically air-gapped vault
+ Review your current backup volume and frequency and ensure your configuration aligns with concurrent copy limits for all resources not supporting full AWS Backup management.
  + Skip this step If you already copy to a logically air-gapped vault at the same frequency as your standard vault backups.
  + Consider adjusting backup frequency, if needed, to prevent copy job queuing.
  + If copy job queuing occurs, you will still have a usable recovery point in your standard backup vault while awaiting completion of the copy to your logically air-gapped vault. However, that recovery point will not provide the protection level that Logically air-gapped vault offers.

### Resources supporting full AWS Backup management migration path
<a name="lag-primary-backup-full-management-migration"></a>

For fully managed resources, you can back up directly to your logically air-gapped vault without requiring copy operations.

#### For snapshot-based backups
<a name="lag-primary-backup-snapshot-migration"></a>

This process applies to all snapshot scenarios, regardless of whether your backup vault is locked. When migrating an existing backup plan or using an existing backup vault (primary) and logically air-gapped vault (copy) in a new backup plan:

1. Maintain your existing backup vault or add it as a backup target (`TargetBackupVaultName`). This vault will not store any backups but must be provided for backwards compatibility.

1. Update your backup plan to include the logically air-gapped vault (`TargetLogicallyAirGappedBackupVaultArn`), existing in the same account, as a primary target.

1. Review any existing copy action to another logically air-gapped vault to determine if it is still needed. You can also move this vault as a primary target in Step 2 if it is in the same account.

#### For Amazon S3 continuous backups
<a name="lag-primary-backup-s3-continuous-migration"></a>

Logically air-gapped vault as a primary backup target supports continuous backup for Amazon S3. However, you can maintain only one active continuous recovery point per resource in a single vault. If you have an existing active Amazon S3 continuous recovery point, you must disassociate or delete it before creating a new one in a different vault. Adding a logically air-gapped vault target (from the same account) to your backup plan, with an existing active Amazon S3 continuous recovery point, will cause the continuous backup job to fail.

To migrate your Amazon S3 continuous recovery point to your logically air-gapped vault from an **unlocked backup vault**:

1. Update your backup plan to add a copy action to your logically air-gapped vault. This will reduce your cost to generate the initial backup in your logically air-gapped vault. Skip this step if you are already copying to your local logically air-gapped vault.

1. Verify that at least one snapshot copy completes successfully in your logically air-gapped vault before proceeding.

1. Disassociate existing Amazon S3 continuous recovery point. Call the [DisassociateRecoveryPoint](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DisassociateRecoveryPoint.html) API to change the recovery point status from AVAILABLE to STOPPED. This action preserves your existing backup data while stopping new data from being added.

1. Update backup plan to add logically air-gapped vault (`TargetLogicallyAirGappedBackupVaultArn`) as a backup target.

1. Remove any previous copy actions in the plan.

1. On the next backup plan execution, a new continuous recovery point will be created in your logically air-gapped vault. This recovery point will be incremental, based on the copied snapshot from Step 1.

To migrate your Amazon S3 continuous recovery point to your logically air-gapped vault from a **locked backup vault**:

1. Update your backup plan to add a copy action to your logically air-gapped vault. This will reduce your cost to generate the initial backup in your logically air-gapped vault. Skip this step if you are already copying to your local logically air-gapped vault.

1. Verify that at least one snapshot copy completes successfully in your logically air-gapped vault before proceeding. Ensure the copied snapshot has a retention period long enough to remain available until you complete all the steps.

1. Add the logically air-gapped vault as a primary target and remove any copy action.

   1. This step is required because locked vaults do not support disassociation of continuous recovery points.

   1. Your existing continuous recovery point in the locked backup vault will continue accumulating data until it expires according to its lifecycle.

   1. New continuous backup jobs will fail because only one active continuous recovery point can exist per resource. Since these jobs are failing, no copy actions will execute.

1. Wait for the existing continuous recovery point to expire. After expiration, a new continuous recovery point will be created in the logically air-gapped vault. This recovery point will be incremental based on the copied snapshot from step 1, provided the snapshot still exists in your logically air-gapped vault.

1. Any data accumulated in your standard vault will be lost upon expiration. Only data backed up after the new recovery point creation in the Logically air-gapped vault will be retained.

### Resources not supporting full AWS Backup management migration path
<a name="lag-primary-backup-not-full-management-migration"></a>

Non-fully managed resources require a copy operation to the logically air-gapped vault. The process creates a temporary recovery point (billable) in your standard backup vault, which is automatically copied to your logically air-gapped vault and then deleted after the copy is completed. When you update your backup plan to include a logically air-gapped vault target:
+ Backup jobs will create a recovery point in your backup vault. This has a lifecycle dictated by `DELETE_AFTER_COPY` event.
+ A copy job automatically initiates transferring the recovery point to your logically air-gapped vault.
+ After the copy is completed successfully, the temporary recovery point in your vault is deleted.
+ If the copy fails, the temporary recovery point is retained for a maximum duration according to your specified retention period, ensuring you have a usable recovery point.

## Troubleshooting
<a name="lag-primary-backup-troubleshooting"></a>

### Backup or copy job fails with lifecycle incompatibility error
<a name="lag-primary-backup-troubleshoot-lifecycle"></a>

**Error for backup jobs:** `Backup job failed because the lifecycle is outside the valid range for backup vault.`

**Error for copy jobs:** `Copy job failed. The retention specified in the job is not within the range specified for the target Backup Vault.`

**Possible cause:** Backup jobs or copy jobs fail because the retention period is incompatible with the logically air-gapped vault's minimum or maximum retention settings.

**Resolution:** Update your backup plan to specify a retention period that falls within the minimum and maximum retention periods configured for your logically air-gapped vault.

### Continuous backup jobs fail with "already has continuous backup enabled"
<a name="lag-primary-backup-troubleshoot-continuous"></a>

**Error:** `Bucket {bucket_name} already has continuous backup enabled for another vault Backup job failed.`

**Possible cause:** Continuous backup jobs fail because there is already a continuous recovery point for the resource in another vault.

**Resolution:** Each resource can have only one continuous recovery point. If your backup vault is unlocked, disassociate the existing continuous recovery point using the [disassociate-recovery-point](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DisassociateRecoveryPoint.html) command. If your backup vault is locked, wait until the existing continuous recovery point expires according to its lifecycle.

### Backup job completes with "Completed with issues" - Unsupported resource type
<a name="lag-primary-backup-troubleshoot-unsupported-resource"></a>

**Message:** `Backup job completed successfully to the target backup vault. This resource type is not supported by logically air-gapped backup vault.`

**Possible cause:** Backup jobs for unsupported non-fully managed resources show "Completed with issues" with a message indicating that the resource is not supported.

**Resolution:** Resource types that are not supported will only backup to backup vault. If you want to retain these backups in your backup vault, no action is required. If you prefer not to mix unsupported resources with your logically air-gapped vault, you can:
+ Remove the resource or logically air-gapped vault target from your backup plan for these resources and continue backing up to your backup vault only. You can subsequently add the resource as part of a different plan.

### Backup job completes with "Completed with issues" - Unsupported encryption key
<a name="lag-primary-backup-troubleshoot-encryption-key"></a>

**Message:** `Backup job completed successfully to the target backup vault. This resource is encrypted with an AWS managed key and cannot be copied to a logically air-gapped backup vault.`

**Possible cause:** Backup jobs for unsupported non-fully managed resources show "Completed with issues" with a message indicating that the resource is encrypted with an AWS managed key.

**Resolution:** Non-fully managed resources encrypted with AWS managed keys cannot be copied to logically air-gapped vaults. If you want to retain these backups in your backup vault, no action is required. If you prefer not to mix unsupported resources with your logically air-gapped vault, you can:
+ Re-encrypt your resources with a customer managed KMS key, or
+ Remove the resource or logically air-gapped vault target from your backup plan for these resources and continue backing up to your backup vault only. You can subsequently add the resource as part of a different plan.

### Recovery points remain in `EXPIRED` state
<a name="lag-primary-backup-troubleshoot-expired-recovery-points"></a>

**Possible cause:** Temporary recovery points transition to `EXPIRED` state but are not deleted.

**Resolution:** AWS Backup may lack permissions to delete the recovery points. Verify that your backup role has the necessary IAM permissions. You may need to manually delete `expired` recovery points.

### Copy jobs are queued or failing due to high backup frequency
<a name="lag-primary-backup-troubleshoot-queued-jobs"></a>

**Possible cause:** Copy jobs to logically air-gapped vaults are queuing or failing because backups are scheduled more frequently than copies can complete.

**Resolution:** Reduce your backup frequency or adjust your backup schedule to allow more time between backups. See the [AWS Backup quotas documentation](aws-backup-limits.md#lag-vault-quotas-table) for information about concurrent copy limits.

# Multi-party approval for logically air-gapped vaults
<a name="multipartyapproval"></a>



## Overview of Multi-party approval in a logically air-gapped vault
<a name="multipartyapproval-overview"></a>

AWS Backup offers you the option to add [Multi-party approval](https://docs.aws.amazon.com/mpa/latest/userguide/what-is.html), a capability from AWS Organizations, to your logically air-gapped vaults. Multi-party approval provides an additional option to help to protect critical operations through a distributed approval process. 

Multi-party approval is designed to help protect critical resources and to minimize the time to return to full operation, such as a disruption caused by malicious actors or malware events. This setup can help you restore the contents of a logically air-gapped vault that may have been compromised.

There is no additional cost for integrating and using Multi-party approval teams with AWS Backup logically air-gapped vaults (storage and cross-region transfers charges apply, as shown on the [pricing](https://aws.amazon.com/backup/pricing) page).

An an AWS Backup customer, you can use Multi-party approval to grant approval capabilities of some operations to a group of trusted individuals who can collaboratively approve access to a logically air-gapped vault from a separately-created recovery account in the case of suspected malicious activity that may compromise use of the primary account.

The following steps outline the recommended flow for setting up a recovery AWS organization, setting up Multi-party approval, and then using Multi-party approval with your logically air-gapped vaults:

1. An administrator [creates a new organization through Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started.html) to be used for recovery operations.

1. In the management account of this new organization, the administrator creates and configures an IAM Identity Center (IDC) instance (to enable an organization instance, see [Enable IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-identity-center.html) in the *IAM Identity Center User Guide*. See also the sequence to [Create a Multi-party approval identity source](https://docs.aws.amazon.com/mpa/latest/userguide/setting-up.html) in the *Multi-party approval User Guide*.

1. The administrator then will [create an approval team](https://docs.aws.amazon.com/mpa/latest/userguide/create-team.html), the core group of trusted individuals who will be the primary users of Multi-party approval.

1. The administrator uses AWS RAM to [share an approval team](multipartyapproval-tasks-administrator.md#share-multipartyapproval-team-using-ram) with each account that owns a logically air-gapped vault and the recovery account that needs to request access on that vault.

1. An administrator of the logically air-gapped vault owning account [associates the vault with an approval team](multipartyapproval-tasks-requester.md#associate-multipartyapproval-team).

1. A recovery account [requests access](multipartyapproval-tasks-requester.md#create-restore-access-vault) to an account that has a logically air-gapped vault with an associated Multi-party approval team (“team”). The team associated with the account [approves or denies the request](https://docs.aws.amazon.com/mpa/latest/userguide/respond-request.html).

1. The admin of the account of that owns the logically air-gapped vault can request that [the approval team be disassociated from the vault](multipartyapproval-tasks-requester.md#disassociate-multipartyapproval-team). The request requires current team approval.

1. An administrator can [update approval team membership](https://docs.aws.amazon.com/mpa/latest/userguide/update-team.html) as necessary in accordance with their security practices or when people join or leave your organization.

## Prerequisites and best practices for using Multi-party approval with a logically air-gapped vault
<a name="multipartyapproval-prerequisites"></a>

Before you can effectively and securely use Multi-party approval with your logically air-gapped vaults, there are prerequisites and recommended best practices.

**Best practices:**
+ Two (or more) AWS organizations through Organizations. One should be your primary organization where you have one or more accounts that have at least one logically air-gapped vault. The secondary organization should be your recovery organization. It is in this org where your multi-party approval team will be managed.

**Prerequisites**

1. You have [Set up Multi-party approval](https://docs.aws.amazon.com/mpa/latest/userguide/setting-up.html) and have at least one approval team.

1. At least one account in your primary organization must have a logically air-gapped vault (and the original backup vault).

1. The management account in the primary organization is opted-in to Multi-party approval.
**Tip**  
AWS Backup recommends you apply a Service Control Policy (SCP) to your primary organization and configure it with the appropriate permissions to the organization and to each approval team. See [Multi-party approval terms](#multipartyapproval-terms) section for a sample policy.

1. Your Multi-party approval team from the secondary (recovery) organization is [shared through AWS RAM](multipartyapproval-tasks-administrator.md#share-multipartyapproval-team-using-ram) with both your accounts that own the logically air-gapped vault(s) and your recovery accounts.

## Cross-Region considerations and dependencies when using Multi-party approval
<a name="multipartyapproval-cross-region"></a>

When you enable Multi-party approval and your IAM Identity Center instance in different Regions, Multi-party approval makes calls across Regions to IAM Identity Center. This means that user and group information moves across Regions. Multi-party approval Team resources can only be created and stored in AWS Region US East (N. Virginia).

Other AWS Regions that reference Multi-party approval team resources will depend on AWS Region US East (N. Virginia). Accordingly, Multi-party approval will make cross-Regions calls if your Identity Center instance and/or logically air-gapped vault is not in US East (N. Virginia).

## Multi-party approval terms, concepts, and user personas
<a name="multipartyapproval-terms"></a>

Multi-party approval in your logically air-gapped vault is an integration of AWS Organizations, AWS Account Management, and AWS Backup, along with AWS Identity and Access Management ( IAM) and AWS RAM (RAM) features. Through the CLI, you can interact with each service to send the appropriate commands. You can also use the console, but you will need to navigate to the appropriate service’s console to complete specific tasks.

How you interact with Multi-party approval depends on your roles and responsibilities at your organizations, as well as the permissions you have in your AWS Backup accounts. 

As shown in the [Multi-party approval User Guide](https://docs.aws.amazon.com/mpa/latest/userguide/what-is.html), members of your organization who use multi-party approval will either be a ***requester***, an ***administrator***, or an ***approver***. Specific permissions apply to each [job function](https://docs.aws.amazon.com/mpa/latest/userguide/mpa-concepts.html). In accordance with security best practices, an user should only fulfill one job function.

 **Consoles, portals, and sessions** 

AWS Backup accounts with one or more logically air-gapped vaults can use multi-party approval.

Prior to the multi-party approval process, an administrator utilizes AWS Organizations to create a secondary organization for recovery purposes (a **recovery organization**) if one has not previously been set up.

Then, the administrator utilizes AWS Resource Access Manager (RAM) to set up cross-organization sharing between the primary organization and the recovery organization.

The **primary organization** is home to accounts that own and use a logically air-gapped vault, which stores the protected data.

The recovery organization is home to at least one **recovery account**. This account houses an access point that can serve as a critical ‘back door’ to the shared logically air-gapped vault. This access point is called a **restore access backup vault**. This access vault does not store data; instead, it serves as an access or mount point that mirrors the contents of the source logically air-gapped vault but contains no data that can be changed or deleted. For example, if a customer goes through the restore process for a recovery point in a restore access backup vault, it is the recovery point in the logically air-gapped vault that is restored through cross-account restore by way of the recovery account.

To ensure extra security, customers use this recovery account to carry out protected operations in the primary account, but only after those operations have been given approval by the associated [approval team in an approval session](https://docs.aws.amazon.com/mpa/latest/userguide/mpa-concepts.html#mpa-resources). A session is created by AWS once an approval request has been sent, and that session ends when a threshold of approval team members approves or denies the request or when the allowed session time has passed. 

A team consists of **approvers** (effectively, the *parties* portion of Multi-party approval) who receive email notifications of protected operation requests. These emails confirm that an approval session has begun for the request. Approval is granted once the required minimum threshold of approval is reached. This threshold can be set as the **multi-party approval team** (“Team”) is created.

Multi-party approval teams are managed through the Organizations **multi-party approval portal** (“portal”), an AWS managed application that provides identities a centralized location where approval team members can receive and respond to approval team invitations and operation requests.

# Administrator tasks
<a name="multipartyapproval-tasks-administrator"></a>

Several tasks involving AWS Backup and Multi-party overview required a user with admin permissions and access to the management account.

## Create an approval team
<a name="create-multipartyapproval-team"></a>

A user at your organization with admin permissions for an AWS account needs to [set up Multi-party approval](https://docs.aws.amazon.com/mpa/latest/userguide/setting-up.html) (step 3 in the [Overview](multipartyapproval.md#multipartyapproval-overview)).

Before doing this step, it is recommended as a best practice you have both a primary organization and a secondary organization (for recovery purposes) set up through AWS Organizations (step 1 in [Overview](multipartyapproval.md#multipartyapproval-overview).

See [Create an approval team](https://docs.aws.amazon.com/mpa/latest/userguide/create-team.html#create-team-steps) in the *Multi-party approval user guide* to create your team.

During the [https://docs.aws.amazon.com/mpa/latest/APIReference/API_CreateApprovalTeam.html](https://docs.aws.amazon.com/mpa/latest/APIReference/API_CreateApprovalTeam.html) operation, one of the parameters is `policies`. This is a list of ARNs (Amazon Resource Names) for Multi-party approval resource policies that define permissions that protect the team.

The policy shown in the example in the *Multi-party approval User Guide* in the procedure [Create an approval team](https://docs.aws.amazon.com/mpa/latest/userguide/create-team.html#create-team-steps) contains the policy `["arn:aws:mpa::aws:policy/backup.amazonaws.com/CreateRestoreAccessVault"]` with several necessary permissions. 

Follow these steps to return a list of available policies by using `mpa list-policies`:

1. List Policies: 

   ```
   aws mpa list-policies --region us-east-1
   ```

1. List all policy versions: 

   ```
   aws mpa list-policy-versions --policy-arn arn:aws:mpa:::aws:policy/backup.amazonaws.com/CreateRestoreAccessVault --region us-east-1
   ```

1. Get details on a policy: 

   ```
   aws mpa get-policy-version --policy-version-arn arn:aws:mpa:::aws:policy/backup.amazonaws.com/CreateRestoreAccessVault/1 --region us-east-1
   ```

Expand below to see the policy that will created then attached to your approval team by this operation:

### Restore access vault policy
<a name="restoreaccessvaultpolicy"></a>

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "VaultOwnerPermissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Resource": "*",
      "Action": [
        "mpa:StartSession",
        "mpa:CancelSession"
      ],
      "Condition": {
        "StringEquals": {
          "mpa:RequestedOperation": "backup:RevokeRestoreAccessBackupVault",
          "mpa:ProtectedResourceAccount": "${aws:PrincipalAccount}"
        },
        "Bool": {
          "aws:ViaAWSService": "true"
        }
      }
    }
  ]
}
```

------

## Share a Multi-party approval team using AWS RAM
<a name="share-multipartyapproval-team-using-ram"></a>

You can share a Multi-party approval team with other AWS accounts using [AWS Resource Access Manager (RAM)](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html), step 4 in the [overview](multipartyapproval.md#multipartyapproval-overview).

------
#### [ Console ]

**Share a Multi-party approval team using AWS RAM**

1. Sign in to the [AWS RAM console](https://console.aws.amazon.com/ram/home?region=us-east-1).

1. In the navigation pane, choose **Resource shares**.

1. Choose **Create resource share**.

1. In the **Name** field, enter a descriptive name for your resource share.

1. Under **Resource type**, select **Multi-party approval Team** from the dropdown menu.

1. Under **Resources**, select the approval team you want to share.

1. Under **Principals**, specify the AWS accounts with whom you want to share the approval team.

1. To share with specific AWS accounts, select **AWS accounts** and enter the 12-digit account IDs.

1. To share with an organization or organizational unit, select **Organization** or **Organizational unit** and enter the appropriate ID.

1. (*Optional*) Under **Tags**, add any tags you want to associate with this resource share.

1. Choose **Create resource share**.

The resource share status will initially show as `PENDING`. Once the recipient accounts accept the invitation, the status will change to `ACTIVE`.

------
#### [ CLI ]

To share a Multi-party approval team using AWS RAM through the CLI, use the following commands:

First, identify the ARN of the approval team you want to share:

```
aws mpa list-approval-teams --region us-east-1
```

Create a resource share using the create-resource-share command:

```
aws ram create-resource-share \
--name "MPA-Team-Share" \
--resource-arns "arn:aws:mpa:us-east-1:ACCOUNT_ID:approval-team/TEAM_ID" \
--principals "ACCOUNT_ID_TO_SHARE_WITH" \
--permission-arns "arn:aws:ram::aws:permission/AWSRAMMPAApprovalTeamAccess" \
--region us-east-1
```

To share with an organization instead of specific accounts:

```
aws ram create-resource-share \
--name "MPA-Team-Share" \
--resource-arns "arn:aws:mpa:us-east-1:ACCOUNT_ID:approval-team/TEAM_ID" \
--permission-arns "arn:aws:ram::aws:permission/AWSRAMMPAApprovalTeamAccess" \
--allow-external-principals \
--region us-east-1
```

Check the status of your resource share:

```
aws ram get-resource-shares \
--resource-owner SELF \
--region us-east-1
```

The recipient account(s) will need to accept the resource share invitation:

```
aws ram get-resource-share-invitations --region us-east-1
```

Run in recipient account to accept an invitation:

```
aws ram accept-resource-share-invitation \
--resource-share-invitation-arn "arn:aws:ram:REGION:ACCOUNT_ID:resource-share-invitation/INVITATION_ID" \
--region us-east-1
```

Once the invitation is accepted, the Multi-party approval team will be available for use in the recipient account.

------

AWS offers tools to share account access, including through [AWS Resource Access Manager](logicallyairgappedvault.md#lag-share) and [Multi-party access](https://docs.aws.amazon.com/mpa/latest/userguide/share-team.html). When you choose to share a logically air-gapped vault with another account, consider the following details:


| Feature | AWS RAM based sharing | Multi-party approval based access | 
| --- | --- | --- | 
| Access to logically air-gapped vaults | Once RAM share is complete, the vaults can be accessed. | Any attempt by a different account must be approved by a threshold number of Multi-party approval team members. The approval session automatically expires 24 hours after the request is initiated. | 
| Access removal | The account which owns the logically air-gapped vault can end RAM based sharing at any time. | Access to a vault can only be removed by a request to the Multi-party approval team. | 
| Copy across accounts and/or Regions | Not currently supported. | Backups can be copied within the same account or with other accounts in the same organization as the recovery account. | 
| Cross-Region transfer billing |  | Cross-Region transfers are billed to the same account that owns the restore access backup vault. | 
| Recommended use | Primary use is for data loss recovery and for restore testing. | Primary use is for situations where account access or security is suspected to be compromised. | 
| Regions | Available in all AWS Regions where logically air-gapped vaults are supported. | Available in all AWS Regions where logically air-gapped vaults are supported. | 
| Restores | All supported resource types can be restored from a shared account. | All supported resource types can be restored from a shared account. | 
| Setup | Sharing can occur as soon as the AWS Backup account sets up RAM sharing and the receiving account accepts the share. | Sharing requires the management account to first create a team, then set up RAM sharing. Then, the management account opts in to Multi-party approval and assigns that team to a logically air-gapped vault. | 
| Sharing |  Sharing is done through RAM within same AWS organization or across AWS organizations. Access is granted according to the 'push' model, in which the account that owns the logically air-gapped vault first grants access. Then, the other account accepts access.  |  Access to a logically air-gapped vault is through Organizations supported approval teams within the same AWS organization or across organizations. Access is granted according to the 'pull' model, where the receiving account first requests access, then the approval team grants or denies the request.  | 

# Requester tasks
<a name="multipartyapproval-tasks-requester"></a>

## Associate a Multi-party approval team with a logically air-gapped vault
<a name="associate-multipartyapproval-team"></a>

Requester: **User with access to account that owns the logically air-gapped vault**.

You can associate a Multi-party approval team with a logically air-gapped vault to enable collaborative approval for access to the vault (step 5 in the [Overview](multipartyapproval.md#multipartyapproval-overview)).

------
#### [ Console ]

**Associate a Multi-party approval team with a logically air-gapped vault**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. Navigate to the **Backup vaults** section in the left navigation pane.

1. Select the logically air-gapped backup vault you want to associate with an MPA team.

1. On the **vault details** page, select **Assign approval team**.

1. From the dropdown menu, select the approval team you want to associate with the vault

1. *Optional* Enter a comment explaining the reason for the association.

1. Select **Send request** to submit the association request.

If this is the first approval team to be associated with the vault, the team will be associated with the vault. If the vault already has an associated team, see [Update Multi-party approval team](#update-multpartyapproval-team) for steps.

------
#### [ CLI ]

Use the CLI command `associate-backup-vault-mpa-approval-team`, modified with the following parameters:

```
aws backup associate-backup-vault-mpa-approval-team \
--backup-vault-name VAULT_NAME \
--mpa-approval-team-arn MPA_TEAM_ARN \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```

If this is the first approval team to be associated with the vault, the team will be associated with the vault. If the vault already has an associated team, see [Update Multi-party approval team](#update-multpartyapproval-team) for steps.

------

## Request access to a logically air-gapped vault
<a name="create-restore-access-vault"></a>

Requester: **User with access to recovery account**.

You can request access to a logically air-gapped vault in another account (step 6 in the [Overview](multipartyapproval.md#multipartyapproval-overview)).

After an approval team has granted the request, AWS Backup creates a restore access backup vault in your designated recovery account so that account will have access to recovery points in the connected logically air-gapped vault.

------
#### [ Console ]

**Request access to a logically air-gapped vault**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. Navigate to the **Backup vaults** section in the left navigation pane

1. Select the **Vaults accessible through MPA** tab

1. Select **Request vault access**.

1. Enter the source backup vault ARN of the logically air-gapped vault you want to access.

1. Enter an optional name for the restore access backup vault. If you do not input a name, AWS Backup will assign a name based on the name of the logically air gapped vault.

1. Enter an optional requester comment explaining the reason for the access request.

1. Select **Send request** to submit the access request.

The approval team members associated with the source vault will receive an email notification to approve the request.

Once the request is approved by the required number ("threshold") of team members, the restore access backup vault will be created in the recovery account.

------
#### [ CLI ]

Use the CLI command `create-restore-access-backup-vault`:

```
aws backup create-restore-access-backup-vault \
--source-backup-vault-arn SOURCE_VAULT_ARN \
--backup-vault-name OPTIONAL_VAULT_NAME \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```

The MPA approval team members associated with the source vault will receive a notification to approve the request. Once the request is approved by the required number ("threshold") of team members, the restore access backup vault will be created in the recovery account.

You can check the status of the vault using:

```
aws backup describe-backup-vault \
--backup-vault-name VAULT_NAME \
--region REGION
```

------

## Disassociate Multi-party approval team from logically air gapped vault
<a name="disassociate-multipartyapproval-team"></a>

Requester: **Administrator of account that owns the logically air-gapped vault**.

You can disassociate a Multi-party approval team from a logically air-gapped vault (step 7 in the [Overview](multipartyapproval.md#multipartyapproval-overview)).

------
#### [ Console ]

**Disassociate approval team from logically air-gapped vault**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. Navigate to the **Backup vaults** section in the left navigation pane.

1. Select the logically air-gapped backup vault from which you want to disassociate the approval team.

1. On the **Vault details** page, select **Disassociate approval team**.

1. Enter an optional requester comment explaining the reason for the disassociation.

1. Select **Send request** to submit the disassociation request.

The current approval team members will receive a notification to approve the request.

Once approved by the required number of team members, the team will be disassociated from the vault.

------
#### [ CLI ]

Use the CLI command `disassociate-backup-vault-mpa-approval-team`:

```
aws backup disassociate-backup-vault-mpa-approval-team \
--backup-vault-name VAULT_NAME \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```

The current MPA approval team members will receive a notification to approve the request. Once approved by the required number of team members, the team will be disassociated from the vault.

------

## Revoke restore access backup vault
<a name="revoke-restore-access-vault"></a>

Requester: **Administrator of account that owns the logically air-gapped vault**.

You can revoke access to a restore access backup vault from the source vault account.

------
#### [ Console ]

**Revoke restore access backup vault**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. Navigate to the **Backup vaults** section in the left navigation pane.

1. Select the logically air-gapped backup vault for which you want to revoke access.

1. On the **Vault details** page, scroll down to the **Access through Multi-party approval** section.

1. Find the restore access backup vault you want to revoke, then select **Request to remove vault access**.

1. Enter an optional requester comment explaining the reason for the revocation.

1. Select **Send request** to submit the revocation request.

The approval team members will receive a notification to approve the request.

Once approved by the required number of team members, the restore access backup vault will be deleted from the recovery account

------
#### [ CLI ]

First, list the restore access backup vaults associated with your source vault:

```
aws backup list-restore-access-backup-vaults \
--backup-vault-name SOURCE_VAULT_NAME \
--region REGION
```

Then, use the CLI command `revoke-restore-access-backup-vault`:

```
aws backup revoke-restore-access-backup-vault \
--backup-vault-name SOURCE_VAULT_NAME \
--restore-access-backup-vault-arn RESTORE_ACCESS_VAULT_ARN \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```

The approval team members will receive a notification to approve the request. Once approved by the required number of team members, the restore access backup vault will be deleted from the recovery account.

------

## Update the Multi-party approval team associated with a logically air-gapped vault
<a name="update-multpartyapproval-team"></a>

Requester: **Administrator of account that owns the logically air-gapped vault**.

You can update the Multi-party approval team associated with a logically air-gapped vault (step 8 in the [Overview](multipartyapproval.md#multipartyapproval-overview)).

------
#### [ Console ]

**Update the approval team associated with a logically air-gapped vault**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. Navigate to the **Backup vaults** section in the left navigation pane.

1. Select the logically air-gapped backup vault for which you want to update the approval team.

1. On the vault details page, select **Request approval team change**.

1. From the dropdown menu, select the new approval team you want to associate with the vault.

1. Enter an optional requester comment explaining the reason for the change.

1. Select **Send request** to submit the change request.

The current approval team members will receive an email notification to approve the request.

Once approved by the required number of team members (threshold) from the current MPA team, the new team will be associated with the vault.

------
#### [ CLI ]

Use the CLI command `associate-backup-vault-mpa-approval-team` with the new team ARN:

```
aws backup associate-backup-vault-mpa-approval-team \
--backup-vault-name VAULT_NAME \
--mpa-approval-team-arn NEW_MPA_TEAM_ARN \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```

The current approval team members will receive a notification to approve the request. Once approved by the required number of team members (threshold) from the current team, the new MPA team will be associated with the vault.

------

# Approver tasks
<a name="multipartyapproval-tasks-approver"></a>

A user who is a member of a Multi-party approval team can [approve or deny requests](https://docs.aws.amazon.com/mpa/latest/userguide/approver.html) that are part of a session. Other tasks include:
+ [Respond to requested operations](https://docs.aws.amazon.com/mpa/latest/userguide/respond-request)
+ [View an approval team](https://docs.aws.amazon.com/mpa/latest/userguide/approver-view-team)
+ [View operation history](https://docs.aws.amazon.com/mpa/latest/userguide/view-operation-history)