Deletions You Schedule on AWS - KMS Waiting Periods, Secrets Manager Recovery Windows, and What Can Be Read or Undone Meanwhile

First Published: 2026-10-23
Last Updated: 2026-10-23

AWS offers services that retain data even after a user requests deletion. In AWS Key Management Service (AWS KMS), ScheduleKeyDeletion allows users to schedule key deletion with a waiting period, after which the key is permanently deleted. In AWS Secrets Manager, DeleteSecret allows users to set a recovery window for secrets, after which they are permanently deleted. Both services allow users to cancel the deletion before the waiting period or recovery window ends.

The previously published When Expired Data Is Actually Deleted on AWS discussed when expired data is actually deleted. Section 6.5 of that article mentioned these two services as a distinct type of deletion—scheduled by the user (with the section heading A Different Type — Deletions That Users Schedule)—and stated, This article does not cover these two types. This article addresses that remaining type.

This article examines scheduled deletions as service-specific contracts. For each service, this article outlines what users can specify, the valid values, what happens if a value is not specified, the state during the waiting period, what actions are permitted and restricted during that period, what an undo brings back, and what is deleted and when after the period ends. It also identifies where this information is visible and what the sources do not state.

This article does not cover recommended deletion procedures, key or secret design, or pricing. It also does not say which service's deletion is safer. The information presented was verified on October 23, 2026. The results in Section 7 were obtained using a small configuration created in the US East (N. Virginia) Region.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. The Scheduled Deletion Contract Tables
4. What Works and What Stops During the Waiting Period
5. What an Undo Brings Back
6. What Is Deleted After the Window, and When
7. What This Configuration Returned
8. What Is Not a Scheduled Deletion
9. Failure Modes
10. Frequently Asked Questions About Scheduled Deletions
11. Summary
12. References

1. Scope and Assumptions

This section will first define the intended audience, the scope of this article, the materials consulted, and the names it uses. The key conclusions are as follows:

The range and default settings for the waiting period vary depending on the service. AWS KMS, AWS Secrets Manager, and AWS Private Certificate Authority (AWS Private CA) have waiting periods of 7 to 30 days, with a default of 30 days. According to the API reference, a restoration period applies to Private CA only when a PENDING_CERTIFICATE or DISABLED CA is deleted; the console procedure in the user guide also lists EXPIRED (Section 4.7). AWS Payment Cryptography has a waiting period of 3 to 180 days, with a default of 7 days. AWS CloudHSM backups have no parameter to specify a waiting period and can be restored up to 7 days after the deletion request.
Even during the waiting period, not all operations are halted. While KMS keys will experience failures for all cryptographic operations, 12 specific operations, such as DescribeKey, PutKeyPolicy, and CancelKeyDeletion, will still succeed. The impact on data keys protected by a key is delayed until the key is used again. The public key of an asymmetric key can continue to be used outside of AWS KMS. Secrets Manager will not return the value of a secret.
An undo does not always return to the original state. KMS keys will transition to a Disabled state, requiring EnableKey to be used. Private CA will revert to the state prior to deletion, and Payment Cryptography keys will transition to a CREATE_COMPLETE state.
Data may not be immediately deleted at the end of the waiting period. Both KMS and Payment Cryptography state that the actual waiting period might be up to 24 hours longer than scheduled. Secrets Manager states that it does not guarantee when data will be deleted after the recovery window.

1.1 Who This Article Is For

This article is intended for the following readers:

Operations and security personnel responsible for designing procedures to decommission KMS keys, Secrets Manager secrets, and Private CA certificate authorities (CAs)
Those who believe: "During the waiting period, nothing can be used, so the impact is immediately apparent," "If canceled, the resource will return to its original, enabled state," "It will be deleted exactly on the last day of the waiting period," and "The waiting period is consistently between 7 and 30 days across all services."

Each of these assumptions either does not match the documentation or holds only under conditions. The KMS developer guide states that

the effect on data keys encrypted by the KMS key, and on data encrypted by the data key, is delayed until the KMS key is used again

. The CancelKeyDeletion API reference states that When this operation succeeds, the key state of the KMS key is Disabled. The Secrets Manager API reference states that There is no guarantee of a specific time after the recovery window for the permanent delete to occur. For the Payment Cryptography DeleteKeyInDays setting, the API reference states Minimum value of 3. Maximum value of 180.

1.2 What This Article Covers and Does Not Cover

This article focuses on deletion requests initiated by users, where the service confirms the deletion after a waiting period, and the user has the option to cancel the deletion during that period. This article refers to this as a "scheduled deletion." Specifically, the following five deletions, each a pair of a scheduling operation and an undo operation, are the rows of the tables:

AWS KMS: ScheduleKeyDeletion and CancelKeyDeletion
AWS Secrets Manager: DeleteSecret and RestoreSecret
AWS Private CA: DeleteCertificateAuthority and RestoreCertificateAuthority
AWS Payment Cryptography: DeleteKey and RestoreKey
AWS CloudHSM: DeleteBackup and RestoreBackup

This article does not cover:

Pricing and billing details.
Deletion on expiration (such as DynamoDB TTL, S3 lifecycle policies, and CloudWatch Logs retention periods). This topic is covered in the previously published When Expired Data Is Actually Deleted on AWS.
KMS key design, envelope encryption, and key rotation. Warnings against treating key deletion as a cleanup task, and examples of policies using kms:TrailingDaysWithoutKeyUsage, are discussed in the previously published AWS KMS Envelope Encryption and Data Key Caching Patterns.
Private CA hierarchy design and revocation. This is covered in the previously published AWS Private CA Hierarchy Design.
Choosing between Secrets Manager and Parameter Store, and how to implement secret rotation. This is discussed in the previously published AWS Secrets Manager and Parameter Store Decision Guide.
CloudHSM cluster operations and the process for manually deleting key material.
Guarantees for the physical destruction of data, such as media disposal.

The five rows presented in this article represent the scheduled deletions that were investigated. This article does not state that these are the only scheduled deletions available within AWS. The behavior of deletions for services such as Amazon Cognito, Amazon Route 53 domains, Amazon ECR, AWS IAM Identity Center, Amazon Lightsail, and AWS Backup, among others, is not covered in this article.

1.3 Sources Read and the Date They Were Checked

This article is based on documents reviewed on October 23, 2026.

AWS KMS API Reference (ScheduleKeyDeletion, CancelKeyDeletion, DeleteImportedKeyMaterial, DescribeKey, KeyMetadata, Encrypt, Decrypt, GetPublicKey), and Developer Guide (page on key deletion, and the pages under it on scheduling, cancellation, the alarm, and deletion permissions, key states, unusable keys, condition keys, determining past usage, CloudTrail DeleteKey, EventBridge).
AWS Secrets Manager API Reference (DeleteSecret, RestoreSecret, GetSecretValue, DescribeSecret, ListSecrets, CreateSecret, and others), and User Guide (deletion, restoration, monitoring of scheduled secret deletion, CloudTrail, secrets managed by other services, troubleshooting).
AWS Private CA API Reference (DeleteCertificateAuthority, RestoreCertificateAuthority, CertificateAuthority), and User Guide (deletion, restoration).
AWS Payment Cryptography API Reference (DeleteKey, RestoreKey), and the page on key deletion in the User Guide.
AWS CloudHSM API Reference (DeleteBackup, RestoreBackup, Backup), and the pages on deleting and restoring backups in the User Guide.
Documentation on boundary types (AWS Organizations CloseAccount, AWS Account Management page on account closure, Amazon EBS page on the Recycle Bin, Amazon DynamoDB Developer Guide page on DynamoDB Streams).
The What's New post of April 27, 2026, on tracking the last usage of KMS keys.
Two pages from the AWS re:Post Knowledge Center (one on secrets and one on Private CA), and the AWS CDK API Reference for SecretProps (description of secrets with the same name).

The key state table in the AWS KMS Developer Guide, which shows the feasibility of operations using icons, was reviewed. This article interpreted the table by reading the names of the icon images in the HTML of the page, and checked the result against a rendered screenshot of the page.

1.4 Names

This article uses the following names:

Scheduled Deletion: A deletion requested by the user, confirmed by the service after a waiting period, during which the user can cancel the deletion.
Waiting Period: The period from when a deletion is requested to when it is confirmed. The name of this period varies by service: KMS refers to it as a "waiting period," Secrets Manager as a "recovery window," Private CA as a "restoration period," and Payment Cryptography also as a "waiting period." This article uses "waiting period" when referring to the concept across different services, but retains the service-specific name when discussing the details of a particular service.
Waiting State: The state of a resource during the waiting period. Examples include KMS's PendingDeletion and Private CA's DELETED.
Undo: An action to cancel a scheduled deletion during the waiting period. Examples include KMS's CancelKeyDeletion and Secrets Manager's RestoreSecret.

The term "deletion" appears with a different meaning in other articles on this site. When you specify DELETE in Amazon EventBridge Scheduler's ActionAfterCompletion, the Scheduler deletes the schedule after the final invocation. This is a pre-configured setting, and does not involve a waiting period or cancellation. The deletion of records that exceed a stream's retention period is the expiration type of deletion. Neither of these are included in the "scheduled deletion" discussed in this article (Section 8).

Although the name suggests otherwise, Private CA's DELETED state is a waiting state that can be restored. This article does not interpret DELETED as a state where the deletion is complete.

2. How to Read the Tables

This section defines the columns in the tables presented in Section 3, as well as how to indicate the source of default values.

2.1 Columns

The tables in Section 3 utilize 11 column headers. Six of them are You Set, Allowed Values, If You Set Nothing, At the Boundary, Where It Shows, and No Statement Found. These six columns are common to the articles on this site that deal with time-based AWS contracts. The article about Amazon EventBridge Scheduler added the Source of the Default column, while this article adds the Waiting State, Undo, Undo Leaves It, and After the Window columns.

Column	What the cell holds
`You Set`	What the user can write in the deletion request
`Allowed Values`	The values the API Reference allows, as of 2026-10-23
`If You Set Nothing`	What happens when the user writes no waiting period
`Source of the Default`	Which source states the value in `If You Set Nothing`
`Waiting State`	The state name the resource has during the waiting period
`At the Boundary`	What works and what stops during the waiting period
`Where It Shows`	Where the waiting period and its end become visible
`No Statement Found`	What the sources do not state, after a search of the sources in Section 1.3
`Undo`	The operation that cancels the scheduled deletion
`Undo Leaves It`	The state the resource is in after the undo succeeds
`After the Window`	What is deleted after the waiting period ends, and what the sources say about the timing

The first column is labeled Setting. This article writes the service and its deletion operation in this column.

2.2 How the Source of a Default Is Written

In the Source of the Default column, this article writes one of the following two labels:

Label	What it means
`API Reference`	The description of the request parameter or the operation in the API Reference of the service
`No parameter`	The operation has no parameter for the waiting period; the period comes from the description of the operation

2.3 No Statement Found, the Sources Disagree, and the Documentation Does Not List

This article writes the following three as different things.

No statement found: This refers to instances where, despite searching the sources in Section 1.3, no corresponding text was found. The No Statement Found column and the places where the body says that no statement was found indicate this. This does not constitute proof of absence.
The sources disagree: This describes situations where two different sources, or two different locations in the same source, provide conflicting information regarding the same matter. This article presents both sources, identifying their origins, without designating either as incorrect.
The documentation does not list: This refers to instances where a particular value is not in the list of values.

2.4 Values from the Sources and Values Returned in This Configuration

The tables in Sections 3 through 6, and Section 8, contain only the values from the sources. In Section 7, the values returned in this article's configuration are placed in a separate column from the values from the sources. The values presented in Section 7 are a record of that configuration on that day, and are not values that the sources guarantee.

3. The Scheduled Deletion Contract Tables

This section outlines the contract of each scheduled deletion, service by service. The information is organized into three tables: "What You Write," "What Happens While Waiting," and "Undo and After the Window." The order of rows is consistent across all three tables.

What Happens After You Schedule a Deletion

3.1 What You Write

Setting	`You Set`	`Allowed Values`	`If You Set Nothing`	`Source of the Default`
AWS KMS `ScheduleKeyDeletion`	`PendingWindowInDays`	7 to 30 days	30 days	`API Reference`
AWS Secrets Manager `DeleteSecret`	`RecoveryWindowInDays`, or `ForceDeleteWithoutRecovery`; not both in the same call	7 to 30 days, stated in the parameter description; `ForceDeleteWithoutRecovery` deletes with no recovery window	30 days	`API Reference`
AWS Private CA `DeleteCertificateAuthority`	`PermanentDeletionTimeInDays`	7 to 30 days, for a CA in `PENDING_CERTIFICATE` or `DISABLED`	30 days	`API Reference`
AWS Payment Cryptography `DeleteKey`	`DeleteKeyInDays`	3 to 180 days	7 days	`API Reference`
AWS CloudHSM `DeleteBackup`	`BackupId` only	No waiting-period parameter	Restorable up to 7 days after the request	`No parameter`

3.2 What Happens While Waiting

Setting	`Waiting State`	`At the Boundary`	`Where It Shows`	`No Statement Found`
AWS KMS `ScheduleKeyDeletion`	`PendingDeletion`; `PendingReplicaDeletion` for a multi-Region primary key that still has replica keys	Cryptographic operations fail; 12 operations, including `DescribeKey`, `PutKeyPolicy`, and `CancelKeyDeletion`, succeed; the effect on data keys is delayed until the KMS key is used again; public keys outside AWS KMS keep working	`KeyState` and `DeletionDate` from `DescribeKey`; the `is pending deletion` error message in CloudTrail	Which of `DisabledException` and `KMSInvalidStateException` each cryptographic operation returns
AWS Secrets Manager `DeleteSecret`	No state identifier was found; `DeletedDate` appears in `DescribeSecret`	The secret value cannot be retrieved; `ListSecrets` omits the secret unless `IncludePlannedDeletion` is set	`DeletionDate` in the `DeleteSecret` response; `DeletedDate` in `DescribeSecret`; the `marked for deletion` error message from `GetSecretValue` in CloudTrail	Whether `TagResource`, `PutSecretValue`, and `UpdateSecret` succeed; whether the API accepts a new secret with the same name
AWS Private CA `DeleteCertificateAuthority`	`DELETED`, which is restorable	A CA deleted in `CREATING` or `FAILED` has no restoration period and cannot be restored	`Status` and `RestorableUntil` from `DescribeCertificateAuthority`	Whether a CA in `DELETED` can revoke certificates
AWS Payment Cryptography `DeleteKey`	`DELETE_PENDING`	The key is disabled and cannot be used in cryptographic operations	`KeyState` and `deletePendingTimestamp`	—
AWS CloudHSM `DeleteBackup`	`PENDING_DELETION` (`PENDING_DELETE` in the console procedure of the user guide)	The backup can be restored	`BackupState` and `DeleteTimestamp` from `DescribeBackups`	What else can be done with a backup in `PENDING_DELETION`

3.3 Undo and After the Window

Setting	`Undo`	`Undo Leaves It`	`After the Window`
AWS KMS `ScheduleKeyDeletion`	`CancelKeyDeletion`	`Disabled`; `EnableKey` is needed before use	Deletes the key, its key material, and its aliases; the actual waiting period might be up to 24 hours longer than scheduled; CloudTrail records `DeleteKey` as an `AwsServiceEvent`, and EventBridge receives `KMS CMK Deletion`
AWS Secrets Manager `DeleteSecret`	`RestoreSecret`	The deletion time stamp is removed, and the secret value can be retrieved again	Deletes the secret and all of its versions as a background task with low priority; no guarantee of a specific time; CloudTrail records `EndSecretVersionDelete`
AWS Private CA `DeleteCertificateAuthority`	`RestoreCertificateAuthority`	The pre-deletion status; `UpdateCertificateAuthority` is needed to make it `ACTIVE`	The CA cannot be restored; the user guide says it is permanently deleted at the end of the restoration period; no statement found on delay
AWS Payment Cryptography `DeleteKey`	`RestoreKey`	`CREATE_COMPLETE`; `deletePendingTimestamp` is removed; `Enabled` is `false` in the user guide's CLI example	`DELETE_COMPLETE`; the user guide says the actual waiting period might be up to 24 hours longer
AWS CloudHSM `DeleteBackup`	`RestoreBackup`	`READY` in the CLI example of the user guide	The backup can no longer be restored; `DeleteTimestamp` is the time of permanent deletion

The tables show the following three points:

Across the five rows, there are three variations regarding the range and default values for the waiting period: three with a range of 7 to 30 days and a default of 30 days, one with a range of 3 to 180 days and a default of 7 days, and one with no parameter that can be restored up to 7 days.
The name of the waiting state varies depending on the service. In the documentation reviewed, no state identifiers were found for Secrets Manager. The waiting state can be determined by the presence or absence of the DeletedDate field.
In the three rows where the documentation states the state after an undo, there are three states. KMS has a Disabled state, Private CA reflects the state before deletion, and Payment Cryptography has a CREATE_COMPLETE state.

4. What Works and What Stops During the Waiting Period

This section examines, for each service, which operations are permitted and which are blocked during the waiting period. KMS is the most complex, with operations allowed or denied one by one, and some impacts arising later.

4.1 Setting the Waiting Period

The KMS ScheduleKeyDeletion API reference states, By default, AWS KMS applies a waiting period of 30 days, but you can specify a waiting period of 7-30 days. The description for PendingWindowInDays clarifies,

This value is optional. If you include a value, it must be between 7 and 30, inclusive. If you do not include a value, it defaults to 30.

A line specifies, Valid Range: Minimum value of 7. Maximum value of 30.

KMS allows you to restrict the values that can be specified for the waiting period using a condition key within a policy. Regarding kms:ScheduleKeyDeletionPendingWindowInDays, the developer guide states,

you can use the kms:ScheduleKeyDeletionPendingWindowInDays condition key to further constrain the waiting period, such as enforcing a minimum waiting period within the valid range.

An example of a key policy that rejects scheduling with a waiting period of 21 days or less is provided. The kms:TrailingDaysWithoutKeyUsage condition key, announced in the What's New post of April 27, 2026, is a condition key that restricts ScheduleKeyDeletion and DisableKey based on the number of days since the key was last used. Examples of policies using this condition key, and their limitations, are discussed in Section 11.3 of the previously published AWS KMS Envelope Encryption and Data Key Caching Patterns.

The Secrets Manager DeleteSecret API reference states, The minimum recovery window is 7 days. The default recovery window is 30 days. The description for RecoveryWindowInDays reads, The number of days from 7 to 30 that Secrets Manager waits before permanently deleting the secret. There is no Valid Range entry; the range is defined in the description itself. The parameters ForceDeleteWithoutRecovery and RecoveryWindowInDays cannot be used together in the same call (You can't use both this parameter and RecoveryWindowInDays in the same call.).

The Private CA DeleteCertificateAuthority API reference states,

By default, if you do not set the PermanentDeletionTimeInDays parameter, the CA remains restorable for 30 days. You can set the parameter from 7 to 30 days.

The Payment Cryptography DeleteKey API reference states, The default waiting period is 7 days. The entry for DeleteKeyInDays specifies, Valid Range: Minimum value of 3. Maximum value of 180. The user guide also states, between 3–180 days.

For CloudHSM's DeleteBackup request, only the BackupId is required. The API reference states, A backup can be restored up to 7 days after the DeleteBackup request is made.

4.2 AWS KMS — Which Operations Work

The KMS developer guide's key state page provides a table that indicates, for each key state, whether each operation will succeed, fail, or succeed under specific conditions. The table begins with the following note:

This table includes only the API operations that use an existing KMS key. Other operations, such as CreateKey and ListKeys, are omitted.

The table's columns combine Pending deletion and Pending replica deletion into a single column.

What Still Works While a KMS Key Is Pending Deletion

According to the table as of October 23, 2026, reading the column for pending deletion reveals the following.

Result while pending deletion	Operations
Succeeds	`CancelKeyDeletion`, `DeleteAlias`, `DescribeKey`, `GetKeyPolicy`, `ListAliases`, `ListGrants`, `ListKeyPolicies`, `ListResourceTags`, `PutKeyPolicy`, `RetireGrant`, `RevokeGrant`; `DeleteImportedKeyMaterial` (fails with `UnsupportedOperationException` for a KMS key that cannot have imported key material)
Succeeds only under certain conditions	`GetKeyRotationStatus`, `ListKeyRotations` (fail for a KMS key in a custom key store); `UpdateAlias` (succeeds when the source key is pending deletion, fails when the destination key is)
Fails with `DisabledException` or `KMSInvalidStateException`	`Encrypt`, `Decrypt`, `ReEncrypt`, `GenerateDataKey`, `GenerateDataKeyWithoutPlaintext`, `GenerateDataKeyPair`, `GenerateDataKeyPairWithoutPlaintext`, `Sign`, `Verify`, `GenerateMac`, `VerifyMac`, `DeriveSharedSecret`, `GetPublicKey`, `CreateGrant`, `ReplicateKey`, `UpdatePrimaryRegion`
Fails with `KMSInvalidStateException`	`CreateAlias`, `TagResource`, `UntagResource`, `EnableKey`, `DisableKey`, `UpdateKeyDescription`, `ScheduleKeyDeletion`
Fails; the exception depends on the key type	`EnableKeyRotation`, `DisableKeyRotation`, `RotateKeyOnDemand` (`KMSInvalidStateException`, or `UnsupportedOperationException` for a KMS key in a custom key store); `GetParametersForImport` (`KMSInvalidStateException` for a KMS key with imported key material, or `UnsupportedOperationException` for a KMS key that cannot have imported key material); `ImportKeyMaterial` (`UnsupportedOperationException` for a KMS key that cannot have imported key material)

This table indicates the following:

Besides cryptographic operations, other actions can fail while a key is pending deletion. These include TagResource, CreateAlias, UpdateKeyDescription, EnableKey, and DisableKey. To reactivate a key that is pending deletion, you must first execute CancelKeyDeletion.
Operations that are permitted while a key is pending deletion include reading key information, modifying key policies, revoking grants, and deleting aliases, as well as cancellation operations. The developer guide's page on the alarm also lists ListKeys, CancelKeyDeletion, and PutKeyPolicy as examples of permitted operations during the waiting period.
The exceptions returned by 16 operations, primarily related to cryptographic operations, are noted in the table's footnotes as [2] or [3]. Footnote 2 states: DisabledException: <key ARN> is pending deletion (or pending replica deletion). Footnote 3 states: KMSInvalidStateException: <key ARN> is pending deletion (or pending replica deletion). The table does not specify which exception is returned. In the configuration described in Section 7.1, all three operations (Encrypt, Decrypt, and GenerateDataKey) returned a KMSInvalidStateException.
GetPublicKey also fails. It is not possible to retrieve a new public key from an asymmetric key that is pending deletion.

4.3 AWS KMS — Effects That Appear Later

The developer guide's page on unusable keys states the following regarding the impact when a KMS key becomes unusable:

When a KMS key becomes unusable, the effect is almost immediate (subject to eventual consistency). The key state of the KMS key changes to reflect its new condition, and all requests to use the KMS key in cryptographic operations fail. However, the effect on data keys encrypted by the KMS key, and on data encrypted by the data key, is delayed until the KMS key is used again, such as to decrypt the data key.

The page lists Scheduling the KMS key for deletion as one potential cause for a key becoming unusable. The example provided is Amazon EBS. When an EC2 instance attaches a volume, the decrypted data key remains in Nitro hardware. Even after the key is made unusable, the page states, This has no immediate effect on the EC2 instance or the EBS volume. When the volume is detached, the data key is deleted, and the next time it is attached, the page continues, the attachment fails.

Therefore, the fact that nothing happens during a waiting period does not prove that the key is no longer being used. The developer guide's page on key deletion also states, Scheduling the deletion of a KMS key might not immediately affect data keys encrypted by the KMS key.

4.4 AWS KMS — Public Keys of Asymmetric Keys

Asymmetric key public keys can be extracted and used outside of AWS KMS. The developer guide's page on key deletion states:

However, scheduling deletion has no effect on public keys outside of AWS KMS. Users who have the public key can continue to use them to encrypt messages. They do not receive any notification that the key state is changed. Unless the deletion is canceled, ciphertext created with the public key cannot be decrypted.

Users who possess the public key can continue to encrypt messages, whether the key is pending deletion or has already been deleted. The resulting ciphertext cannot be decrypted unless the deletion is canceled. The developer guide's page on the alarm states: This Amazon CloudWatch alarm cannot detect use of the public key of an asymmetric KMS key outside of AWS KMS. Usage of the public key outside of AWS KMS is not recorded within AWS KMS.

Regarding asymmetric keys with the ENCRYPT_DECRYPT usage, the developer guide recommends checking CloudTrail logs to determine whether the public key was downloaded and shared, and to confirm that it is not being used outside of AWS KMS. It then states Then, consider disabling the KMS key instead of deleting it. This is the recommendation of the source.

4.5 AWS KMS — Multi-Region Keys and Custom Key Stores

With multi-Region keys, the start of the waiting period differs between the primary key and its replicas. The ScheduleKeyDeletion API reference states the following about a primary key that still has replica keys.

If you schedule the deletion of a primary key with replicas, its key state changes to PendingReplicaDeletion and it cannot be replicated or used in cryptographic operations. This status can continue indefinitely. When the last of its replicas keys is deleted (not just scheduled), the key state of the primary key changes to PendingDeletion and its waiting period ( PendingWindowInDays ) begins.

While in the PendingReplicaDeletion state, the waiting period has not yet begun. Regarding the DeletionDate field in the response to the ScheduleKeyDeletion API call, the API reference states that for a primary key with replica keys, this field does not appear. According to the developer guide, You can delete a replica key at any time.

Concerning KMS keys within an AWS CloudHSM key store, the developer guide states that after the waiting period, AWS KMS attempts to delete the key material from the cluster, but this is a best effort process. It continues, AWS KMS does not delete the key material from cluster backups. Clusters created from backups may still contain the deleted key material. Regarding keys in an external key store, the API reference states, Deleting a KMS key from an external key store has no effect on the associated external key. In both types of custom key store, if the key store is disconnected while the key is in the Pending deletion state, the key remains in that state, and its deletion can be canceled at any time during the waiting period.

4.6 AWS Secrets Manager — The Value Is Not Returned

The Secrets Manager DeleteSecret API reference states,

When a secret is scheduled for deletion, you cannot retrieve the secret value. You must first cancel the deletion with RestoreSecret and then you can retrieve the secret.

The deletion section of the user guide states,

Secrets Manager does not immediately delete secrets. Instead, Secrets Manager immediately makes the secrets inaccessible and scheduled for deletion after a recovery window of a minimum of seven days.

No table like the KMS key state table, showing the permissibility of each operation, was found in the Secrets Manager documentation. The only clues were the descriptions of exceptions for each operation. Of the 12 API references reviewed for this article, 11 pages (excluding DescribeSecret)—such as those for GetSecretValue, PutSecretValue, UpdateSecret, TagResource, and RotateSecret—list InvalidRequestException under Possible causes: with the entry The secret is scheduled for deletion. This is a common exception description, and does not explicitly state that the operation will always fail when the secret is pending deletion. This article will treat the behavior of TagResource, PutSecretValue, and UpdateSecret when the secret is pending deletion as matters on which no statement was found. Section 7 shows the results observed in this article's configuration.

The DescribeSecret API reference states that for the DeletedDate field, If a secret is scheduled for deletion, then its details, including the encrypted secret value, is not accessible. The same DescribeSecret API also provides the DeletedDate field for pending secrets. The text does not define what details covers. In the configuration in Section 7.2, a successful DescribeSecret call returned the DeletedDate, tags, and version stages.

The ListSecrets API reference disagrees with itself on the same page. It begins by stating,

Lists the secrets that are stored by Secrets Manager in the AWS account, not including secrets that are marked for deletion. To see secrets marked for deletion, use the Secrets Manager console.

However, it also describes the request parameter IncludePlannedDeletion as, Specifies whether to include secrets scheduled for deletion. By default, secrets scheduled for deletion aren't included. The default behavior of excluding secrets is stated in both locations. The beginning of the page and the description of the parameter contradict each other regarding how to include secrets in the API call.

Regarding replicated secrets, the DeleteSecret API reference states,

You can't delete a primary secret that is replicated to other Regions. You must first delete the replicas using RemoveRegionsFromReplication , and then delete the primary secret. When you delete a replica, it is deleted immediately.

There is no recovery window for deleting replicas.

For secrets managed by other AWS services, the user guide states: The managing service might also restrict you from updating secrets or deleting them without a recovery period.

No statement was found in the Secrets Manager API reference or user guide regarding whether a secret with the same name can be created while the original secret is scheduled for deletion. A page in the Knowledge Center quotes, in its opening question, the error message You can't create this secret because a secret with this name is already scheduled for deletion. when attempting to create a secret with the same name. The subsequent explanation clarifies that You can't create a secret with the previously used name on the Secrets Manager console until the recovery window ends. This applies specifically to the console. The description for SecretProps in AWS CDK states: During that period, it is not possible to create another secret that shares the same name. However, neither is part of the Secrets Manager API specification. In the configuration in Section 7.2, a CreateSecret call to the API also rejected attempts to create a secret with the same name. The description for ForceDeleteWithoutRecovery states:

If you delete a secret and then immediately create a secret with the same name, use appropriate back off and retry logic.

This refers to the scenario immediately following a deletion without a recovery window.

4.7 AWS Private CA — DELETED Is a Waiting State

The API reference for DeleteCertificateAuthority states:

When you successfully call DeleteCertificateAuthority , the CA's status changes to DELETED . However, the CA won't be permanently deleted until the restoration period has passed.

The DELETED status indicates a waiting state, where the CA can still be restored.

The states that can be deleted and the states that have a restoration period are distinct. The Important section of the API reference lists the states that can be deleted as PENDING_CERTIFICATE , CREATING , EXPIRED , DISABLED , or FAILED. It lists the states where a restoration period can be specified as PENDING_CERTIFICATE or DISABLED. A CA deleted in the CREATING or FAILED state has no assigned restoration period and cannot be restored. Attempts to delete an ACTIVE CA will result in an exception unless the CA is first disabled.

The deletion page of the user guide disagrees with itself. The general description (Important) mirrors the API reference, listing PENDING_CERTIFICATE or DISABLED as the states eligible for a restoration period. The console instructions state

If your CA is in the DISABLED , EXPIRED , or PENDING_CERTIFICATE state, the Delete CA page lets you specify a restoration period of 7-30 days.

and include the EXPIRED state. The sources disagree on whether an EXPIRED CA will have a restoration period.

The API reference's Note states, Deleting a CA will invalidate other CAs and certificates below it in your CA hierarchy. The user guide outlines the steps for safely deleting a CA, recommending that you create a replacement CA, disable the old CA, and wait until all certificates issued by the old CA have expired before deleting it. It also notes, AWS Private CA does not check that all of the issued certificates have expired before it processes a delete request. This constitutes a recommendation and a cautionary note in the documentation. The Knowledge Center page for Private CA explains that attempting to call IssueCertificate with a CA that is expired or has been deleted will return an InvalidStateException with the message The certificate authority is not in a valid state for issuing certificates. The same page continues by stating that even if the signing CA has been deleted, it can still be restored within the restoration period. This deletion refers to the waiting state DELETED. No statement was found on whether a DELETED CA can revoke certificates.

4.8 AWS Payment Cryptography and AWS CloudHSM Backups

The DeleteKey API reference for Payment Cryptography states,

When you call this operation, AWS Payment Cryptography disables the specified key but doesn't delete it until after a waiting period set using DeleteKeyInDays .

The reference describes this waiting state as DELETE_PENDING. The user guide states regarding keys pending deletion, An AWS Payment Cryptography key pending deletion cannot be used in any cryptographic operations . The user guide uses the term Pending deletion to describe this state, while the API value is DELETE_PENDING. For the case where you are unsure, the API reference suggests, consider deactivating it instead by calling StopKeyUsage . This is a recommendation outlined in the documentation.

For CloudHSM backups, the BackupState value of the Backup type in the API indicates the waiting state, which is PENDING_DELETION. The user guide's page on backup deletion states, The state of the backup changes to PENDING_DELETE . in the console instructions, while the same page's CLI example uses the term PENDING_DELETION. This article presents the API value PENDING_DELETION in the tables, with the user guide's wording in parentheses.

5. What an Undo Brings Back

This section examines the undo operation and the state after undoing. Of the five rows, Private CA is the one whose documentation says the resource returns to its pre-deletion status. Both KMS and Payment Cryptography, regardless of their state before deletion, move to a predetermined state.

5.1 AWS KMS — Back to Disabled

The CancelKeyDeletion API reference states:

Cancels the deletion of a KMS key. When this operation succeeds, the key state of the KMS key is Disabled . To enable the KMS key, use EnableKey .

Even if the key was previously in the Enabled state, it is in the Disabled state after the cancellation. To resume using the key, you must call EnableKey after CancelKeyDeletion. As shown in the table in Section 4.2, you cannot call EnableKey on a key that is pending deletion.

When you cancel the deletion, the alias remains. The alias is removed only when the waiting period ends and the key is deleted (Section 6.1).

5.2 AWS Secrets Manager — The Deletion Time Stamp Is Removed

The RestoreSecret API reference states, Cancels the scheduled deletion of a secret by removing the DeletedDate time stamp. The user guide's recovery page states, This removes the DeletionDate field, which cancels the scheduled permanent deletion. The DeleteSecret API reference also states, use RestoreSecret to remove the DeletionDate.

The name of the field that disappears upon cancellation is documented in two different ways. The field in the response from DeleteSecret is called DeletionDate, while the fields in the responses from DescribeSecret and ListSecrets are called DeletedDate. This article will retain the original names as they appear in the documentation. In the configuration described in Section 7.2, the two fields held different timestamps. The DeletionDate in the response from DeleteSecret represented the end of the recovery window, while the DeletedDate in the response from DescribeSecret represented the time the deletion was requested.

After cancellation, the secret will once again return a value. The user guide's recovery page states, Before the end of the recovery window, you can recover the secret and make it accessible again.

5.3 AWS Private CA — Back to the Pre-Deletion Status

The RestoreCertificateAuthority API reference states

The status of a restored CA is set to its pre-deletion status when the RestoreCertificateAuthority action returns. To change its status to ACTIVE , call the UpdateCertificateAuthority action.

CAs deleted while in the DISABLED state are restored to the DISABLED state; to make them ACTIVE, use the UpdateCertificateAuthority action. CAs deleted while in the PENDING_CERTIFICATE state cannot be activated until a certificate has been imported using the ImportCertificateAuthorityCertificate action.

5.4 AWS Payment Cryptography and AWS CloudHSM

The RestoreKey API reference states, After Key is restored, the KeyState is CREATE_COMPLETE , and the value for deletePendingTimestamp is removed. The API reference lists StartKeyUsage and StopKeyUsage as related operations for RestoreKey. While DeleteKey puts the key in a waiting state after it is disabled, no statement was found on the RestoreKey page on whether key usage is enabled after a restoration. In the CLI example of restore-key on the key deletion page of the user guide, the KeyState in the output is CREATE_COMPLETE, and Enabled is false.

The API reference for CloudHSM's RestoreBackup states, Restores a specified AWS CloudHSM backup that is in the PENDING_DELETION state. No statement was found in the text on the value of BackupState after the restoration. In the CLI example on the restoration page of the user guide, the BackupState in the output of restore-backup is READY.

6. What Is Deleted After the Window, and When

This section examines what is deleted after the waiting period ends, when this occurs, and where it is recorded.

6.1 What Is Deleted

The AWS KMS ScheduleKeyDeletion API reference states,

After the waiting period ends, AWS KMS deletes the KMS key, its key material, and all AWS KMS data associated with it, including all aliases that refer to it.

The developer guide's key deletion page states, After the waiting period ends, AWS KMS deletes the KMS key, its aliases, and all related AWS KMS metadata.

When a KMS key is deleted, any data encrypted with that key becomes unrecoverable. The API reference's Important section states,

When a KMS key is deleted, all data that was encrypted under the KMS key is unrecoverable. (The only exception is a multi-Region replica key , or an asymmetric or HMAC KMS key with imported key material .)

The developer guide notes, If you mistakenly delete a replica key, you can recreate it by replicating the same primary key in the same Region. Regarding asymmetric and HMAC KMS keys with imported key material, it states,

If you have the original key material, you can create a new KMS key with the same cryptographic properties as an asymmetric or HMAC KMS key that was deleted.

However, regarding symmetric encryption keys, the developer guide states that even if you have the original key material, you cannot create a new key that will decrypt ciphertext encrypted with the deleted key.

The Secrets Manager DescribeSecret API reference states, Some time after the deleted date, Secrets Manager deletes the secret, including all of its versions.

The API reference for Private CA's RestoreCertificateAuthority states: You cannot restore a CA after the restoration period has ended. The API reference for Payment Cryptography's DeleteKey states: After the key is deleted, the KeyState is DELETE_COMPLETE . For CloudHSM's Backup, the DeleteTimestamp field indicates The date and time when the backup will be permanently deleted.

6.2 When It Is Deleted

The documentation does not guarantee that data will be deleted immediately upon the expiration of a specified period. The details for each service are as follows:

Service	What the sources say about the timing
AWS KMS	`However, the actual waiting period might be up to 24 hours longer than the one you scheduled.` (Developer Guide)
AWS Secrets Manager	`Secrets Manager performs the permanent secret deletion at the end of the waiting period as a background task with low priority. There is no guarantee of a specific time after the recovery window for the permanent delete to occur.` (API Reference)
AWS Private CA	`At the end of that period, the private CA is permanently deleted.` (User Guide); no statement found on delay
AWS Payment Cryptography	`However, the actual waiting period might be up to 24 hours longer than the one you scheduled.` (User Guide)
AWS CloudHSM	`DeleteTimestamp` is `The date and time when the backup will be permanently deleted.` (API Reference); no statement found on delay

Both KMS and Payment Cryptography state that the delay may be up to 24 hours. Secrets Manager does not specify an upper limit. The KMS developer guide indicates that to determine the actual deletion time, you should use DescribeKey and, about the console display, advises, Be sure to note the time zone.

The API reference describes the DeletionDate in the DeleteSecret response as

The date and time after which this secret Secrets Manager can permanently delete this secret, and it can no longer be restored. This value is the date and time of the delete request plus the number of days in RecoveryWindowInDays .

This time is the point after which the secret can be permanently deleted, not the time of its actual deletion. Similarly, the KMS DeletionDate is described as The date and time after which AWS KMS deletes the KMS key.

6.3 What Remains

Even after the waiting period, the following may persist:

CloudHSM Key Store Material: AWS KMS removes the key material from the cluster on a best effort basis, and AWS KMS does not delete the key material from cluster backups. The developer guide states that to completely remove key material, you should verify the key's creation date using DescribeKey and delete all cluster backups that may contain that key material.
External Keys for External Key Stores: Deleting a KMS key from an external key store has no effect on the associated external key. However, the API reference states that deleting a KMS key is a destructive and irreversible action, and that external keys and CloudHSM keys alone will not be able to decrypt ciphertext.
Public Keys and Ciphertext Created with Those Public Keys: As described in Section 4.4, once extracted, public keys can continue to be used outside of AWS KMS, and ciphertext created with those keys will no longer be decryptable.

6.4 Where It Is Recorded

When a KMS key is deleted, it is recorded in CloudTrail as a DeleteKey event. The developer guide's CloudTrail section states,

To delete a KMS key, you use the ScheduleKeyDeletion operation. After the specified waiting period expires, AWS KMS deletes the KMS key and records an entry like the following one in your CloudTrail log to record that event.

The example in the guide shows that the userIdentity has invokedBy set to AWS Internal, and the eventType is AwsServiceEvent. DeleteKey is not an API call initiated by the user; rather, it is a service event recorded by AWS KMS after the waiting period has elapsed.

When a key is deleted, KMS sends a KMS CMK Deletion event to Amazon EventBridge. The developer guide explains:

After the waiting period ends, AWS KMS deletes the KMS key and sends a KMS CMK Deletion event to EventBridge. AWS KMS guarantees this EventBridge event. Due to retries, it might generate multiple events within a few seconds that delete the same KMS key.

While this event is guaranteed to be sent, it is possible that multiple events related to the deletion of the same key may be received within a few seconds. A single deletion does not always result in just one event.

The CloudTrail section of the Secrets Manager user guide lists StartSecretVersionDelete, EndSecretVersionDelete, and CancelSecretVersionDelete as service events related to deletion. EndSecretVersionDelete is described as Generated by the Secrets Manager service when a secret version is deleted. CancelSecretVersionDelete is recorded each time a version is restored using RestoreSecret. The SecretVersionDeletion section on the same page describes an event that occurs when Secrets Manager deletes a version after removing its staging label and marking it as deprecated; this is separate from scheduled deletions.

The Payment Cryptography user guide states,

AWS Payment Cryptography records an entry in your AWS CloudTrail log when you schedule deletion of the AWS Payment Cryptography key and when the AWS Payment Cryptography key is actually deleted.

Alarms on use during the waiting period have procedures documented in both the KMS and Secrets Manager documentation. The KMS alarm counts occurrences of the error message Key ARN is pending deletion in CloudTrail. The Secrets Manager alarm counts occurrences of the error message secret because it was marked for deletion when retrieving the secret value using GetSecretValue. The Secrets Manager user guide notes, Other API operations can be performed on the secret without triggering the alarm. Neither alarm triggers on operations it does not count, even during the waiting period. Which signals to alert on, including any use of a key pending deletion, are covered in Section 11.4 of the previously published AWS KMS Envelope Encryption and Data Key Caching Patterns.

7. What This Configuration Returned

The values presented in this section were obtained using the following configuration. These are not values that the documentation guarantees. All timestamps are in UTC. The middle column in each table summarizes what the documentation says, with the basis in Sections 3 through 6.

Region: us-east-1. On October 23, 2026, between 04:12 and 04:16 (UTC), using AWS CLI v2, one symmetric encryption KMS key and one alias were created, along with one Secrets Manager secret containing dummy values. Subsequently, the deletions were scheduled, operations were tried during the waiting period, and the deletions were canceled, in that order.
The CloudTrail event history was reviewed on the same day at 04:37 (UTC). No CloudTrail trails or EventBridge rules were created.
In the exception messages, the key ARN was recorded as <key ARN>. The account ID, key ID, and the trailing characters of the secret ARN have been redacted.

7.1 AWS KMS

What Was Done	What the Sources Say	What Was Returned
`ScheduleKeyDeletion` with 6 days and with 31 days	7 to 30 days	`ValidationException` from the service: `PendingWindowInDays must be between 7 and 30`
`ScheduleKeyDeletion` with 7 days	`DeletionDate` is the date and time after which AWS KMS deletes the key	`KeyState` `PendingDeletion`; `DeletionDate` was 7 days and about 0.7 seconds after the request time recorded on the client; `DescribeKey` returned `Enabled` `false`
`Encrypt`, `Decrypt` of a ciphertext made before scheduling, and `GenerateDataKey`	Fails with `DisabledException` or `KMSInvalidStateException` (`[2] or [3]`)	All three returned `KMSInvalidStateException`: `<key ARN> is pending deletion.`
`ListKeys`, `ListAliases`, `ListResourceTags`, `GetKeyPolicy`, and `PutKeyPolicy` with the same policy	Succeeds (`ListKeys` is not in the key state table)	All succeeded
`TagResource`, `CreateAlias`, `UpdateKeyDescription`, `EnableKey`, `DisableKey`, and a second `ScheduleKeyDeletion`	Fails with `KMSInvalidStateException`	All returned `KMSInvalidStateException`: `<key ARN> is pending deletion.`
`CancelKeyDeletion`	`Disabled`	`KeyState` `Disabled`; the alias remained
`Encrypt` right after the cancel	A disabled key fails with `DisabledException` (`[1]`)	`DisabledException`: `<key ARN> is disabled.`
`EnableKey`, then `Encrypt` and `Decrypt` of the ciphertext made before scheduling	—	`KeyState` `Enabled`; both succeeded

7.2 AWS Secrets Manager

What Was Done	What the Sources Say	What Was Returned
`DeleteSecret` with 6 days, with 31 days, and with both parameters	7 to 30 days; the two parameters cannot be used together	`InvalidParameterException`: `The RecoveryWindowInDays value must be between 7 and 30 days (inclusive).` and `You can't use ForceDeleteWithoutRecovery in conjunction with RecoveryWindowInDays.`
`DeleteSecret` with 7 days	`DeletionDate` is the time of the request plus the recovery window	`DeletionDate` was 7 days and about 0.7 seconds after the request time recorded on the client
`GetSecretValue`	The secret value cannot be retrieved	`InvalidRequestException`: `You can't perform this operation on the secret because it was marked for deletion.`
`DescribeSecret`	The details, including the encrypted secret value, are not accessible; `DeletedDate` is the date the secret is scheduled for deletion	Succeeded; returned `DeletedDate`, the tags, and the version stages; `DeletedDate` was the time of the delete request, not the end of the recovery window
`ListSecrets`	Secrets scheduled for deletion are not included by default	Empty by default; one secret with `IncludePlannedDeletion`
`TagResource`, `PutSecretValue`, `UpdateSecret`	No statement found	All returned the same `InvalidRequestException` as `GetSecretValue`
A second `DeleteSecret` with 7 days during the recovery window	No statement found	Succeeded; `DeletionDate` moved to 7 days after the second request
`CreateSecret` with the same name	No statement found in the API Reference or the user guide; the Knowledge Center quotes the same error message	`InvalidRequestException`: `You can't create this secret because a secret with this name is already scheduled for deletion.`
`RestoreSecret`	The deletion time stamp is removed	`DescribeSecret` no longer returned `DeletedDate`; `GetSecretValue` and the default `ListSecrets` returned the secret again
`DeleteSecret` with `ForceDeleteWithoutRecovery`, twice	Does not return `ResourceNotFoundException` for an already deleted secret	Both succeeded; `DescribeSecret` then returned `ResourceNotFoundException`

7.3 CloudTrail

What Was Done	What the Sources Say	What Was Returned
Failed calls during the waiting period	The KMS alarm counts the `is pending deletion` error message; the Secrets Manager alarm counts the `marked for deletion` message from `GetSecretValue`	Recorded as `AwsApiCall` with `errorCode` and `errorMessage`; the KMS messages ended with `is pending deletion.`, and the Secrets Manager messages contained `marked for deletion`
`RestoreSecret`	`CancelSecretVersionDelete` is logged for each secret version that was restored	No `CancelSecretVersionDelete` was found in the event history about 22 minutes after `RestoreSecret`
`DeleteSecret` with 7 days, and later with `ForceDeleteWithoutRecovery`	`StartSecretVersionDelete` is generated when Secrets Manager starts deletion for a secret version	None after the 7-day request; one `StartSecretVersionDelete` about 20 seconds after the forced deletion, as an `AwsServiceEvent` invoked by `secretsmanager.amazonaws.com`

7.4 What This Configuration Shows, and What It Did Not Show

Based on this configuration, the following can be observed. All of these are the results of a single attempt within a specific configuration and do not represent guaranteed behavior as documented.

Exceptions related to cryptographic operations could have occurred in two ways, as indicated by [2] or [3] in the table in Section 4.2. In this configuration, all three operations resulted in a KMSInvalidStateException. Encrypt calls with a key whose deletion was canceled and that transitioned to a Disabled state resulted in a DisabledException.
Attempts to perform TagResource, PutSecretValue, and UpdateSecret on pending secrets failed with the same exception as GetSecretValue, although documentation did not provide operation-specific information for these actions.
Creating a secret with the same name through the API was also rejected within this configuration, mirroring the error message found on the Knowledge Center page.
Calling DeleteSecret on a secret that was still pending did not result in a rejection. Instead, the recovery window was recalculated, starting from the second request.
The DeletedDate field in DescribeSecret reflected the time the deletion was requested, not the end of the recovery window. The end of the recovery window was indicated in the DeletionDate field in the response to DeleteSecret.
Following a RestoreSecret operation, no CancelSecretVersionDelete events appeared in the CloudTrail event history for approximately 22 minutes. It remains unclear within this configuration whether these events are recorded later or not at all.

This configuration does not reveal information regarding:

Deletion of keys after the waiting period has ended. As of October 23, 2026, the key that was scheduled for deletion again with a 7-day waiting period for cleanup remains in the waiting period (with a DeletionDate of October 30, 2026, at 04:15 UTC). The CloudTrail DeleteKey event, and how much later than the DeletionDate the actual deletion happens, have not been examined yet. This configuration has also not received the EventBridge KMS CMK Deletion event, as no rules were configured to receive it.
Public keys for asymmetric keys, multi-Region keys, custom key stores, or delayed impact on data keys (Sections 4.3-4.5).
AWS Private CA, AWS Payment Cryptography, and AWS CloudHSM backups.

8. What Is Not a Scheduled Deletion

This section differentiates scheduled deletions from deletions of a different type that look similar, presenting them in a single table.

Type	Example	Who starts it	Is there a waiting period?	Can the user undo it?
Scheduled deletion (this article)	KMS `ScheduleKeyDeletion`, Secrets Manager `DeleteSecret`	The user, with a delete request	Yes, set in the request or fixed by the service	Yes, during the waiting period
Expiration	DynamoDB TTL, S3 Lifecycle expiration, CloudWatch Logs retention	The service, when an expiration date set in advance passes	No; the sources describe a delay after expiration	No undo operation; the expiration setting is changed in advance
Deletion protection	Settings that reject a delete request	Not applicable; the delete request is rejected	No	Not applicable
Recycle Bin	Amazon EBS snapshots, EBS-backed AMIs, and EBS volumes under a retention rule	The user deletes; a retention rule keeps the resource	Yes, the retention period of the rule	Yes, restore from the Recycle Bin
Deleting imported key material	KMS `DeleteImportedKeyMaterial`	The user	No	Yes, reimport the same key material
Account closure	Closing an AWS account	The user	The post-closure period of 90 days	Reopening the account; the sources disagree on the route
Deletion after completion	EventBridge Scheduler `ActionAfterCompletion` set to `DELETE`	The service, after the last invocation, as the user set in advance	No	No undo operation

For each row in this table, the relevant text from the sources follows.

Expiration: The previously published When Expired Data Is Actually Deleted on AWS addresses when expired data is actually deleted on AWS. It also covers the delay between the expiration date and the actual deletion process.
Deletion Protection: This setting outright rejects deletion requests and includes no waiting periods or cancellation options. Whether the deletion protection for CloudWatch Logs log groups also prevents deletion based on retention periods is covered in Section 5.7 of the same previously published article.
Recycle Bin: The Amazon EBS Recycle Bin page states, While a resource is in the Recycle Bin, you have the ability to restore it for use at any time. The retention rules that the user creates determine the retention periods. Scheduled deletions, which specify a period in each deletion request, have a different method for defining that period.
Deleting Imported Key Material: The KMS developer guide states, Deleting the key material of a KMS key with imported key material is temporary and reversible. To restore the key, reimport its key material. There is no waiting period. According to the API reference, even if you call DeleteImportedKeyMaterial on a key that is pending deletion, the key's status remains PendingDeletion.
Account Closure: The AWS Organizations CloseAccount API reference states, Resources remaining within the account after closing will be automatically deleted after 90 days. During this 90-day period, the resources cannot be used unless you contact AWS Support to reopen the account. The AWS Account Management page on account closure states, The post-closure period is 90 days. and provides instructions for users to reopen their account. The two documents disagree on the route to reopening. No operation was found that works as an undo API for the closure.
Deletion After Completion: The ActionAfterCompletion feature in Amazon EventBridge Scheduler is covered in the previously published Amazon EventBridge Scheduler Delivery Semantics.
Disabled DynamoDB Streams: The Amazon DynamoDB developer guide addresses data on disabled streams, stating, If you disable a stream on a table, the data in the stream continues to be readable for 24 hours. It continues, There is no mechanism for manually deleting an existing stream. This is deletion by the retention period and is not a scheduled deletion. Where a stream consumer can start is covered in the previously published Where a Stream Consumer Can Start on AWS.

9. Failure Modes

This section lists common failures that can be identified from the data and documentation presented in this article, particularly those likely to occur during operation.

While in the pending deletion state, nothing can be used, so the impact is considered to become apparent quickly. For a KMS key, cryptographic operations and some management operations stop; the key allows operations like DescribeKey and PutKeyPolicy to proceed, but the impact on data keys is delayed until the key is used again. The fact that nothing happens during the waiting period does not prove that the key is not being used (Sections 4.2 and 4.3).
If no alarm is triggered, it is assumed that no one is using the key. The KMS alarm cannot detect the use of the public key outside of AWS KMS. The Secrets Manager alarm only counts calls to GetSecretValue (Sections 4.4 and 6.4).
Once it is canceled, the key is assumed to be usable again. After canceling key deletion with CancelKeyDeletion, the key is in a Disabled state and requires EnableKey to be reactivated (Section 5.1).
It is assumed that the key can be enabled first while it is pending deletion. While a key is in the pending deletion state, neither EnableKey nor DisableKey can be called. CancelKeyDeletion must be called first (Section 4.2).
It is assumed that the key will be completely deleted on the last day of the waiting period. KMS and Payment Cryptography documentation state that the actual waiting period might be up to 24 hours longer, while Secrets Manager documentation does not guarantee a specific time. DeletionDate is the time after which the resource may be deleted (Section 6.2).
It is assumed that the waiting period is 7 to 30 days across all services. Payment Cryptography has a default period of 7 days, ranging from 3 to 180 days. CloudHSM backups have no parameter and can be restored up to 7 days after the request (Section 4.1).
The waiting state of Secrets Manager is assumed to be found using PendingDeletion. In the documentation reviewed, no specific state identifier for Secrets Manager was found. The waiting state can be determined by examining the DeletedDate field (Sections 3.2 and 5.2).
Since it does not appear in ListSecrets, it is assumed that the secret has been deleted. By default, secrets scheduled for deletion are not included in the list (Section 4.6).
DescribeSecret's DeletedDate is interpreted as the time the secret will be deleted. In the configuration described in Section 7.2, DeletedDate was the time the deletion was requested, while the end of the recovery window is indicated in the response to DeleteSecret's DeletionDate (Sections 5.2 and 7.2).
Even if DeleteSecret is called again while the secret is scheduled for deletion, it is assumed that nothing will change. In the configuration described in Section 7.2, the second request is successful, and the recovery window is counted from the time of the second request (Section 7.2).
DELETED for Private CA is interpreted as an irreversible state. However, DELETED represents a waiting state that can still be restored. Irreversible states are those associated with CREATING or FAILED CA deletions, as well as CAs after the restoration period has ended (Section 4.7).
It is assumed that the waiting period for a multi-Region primary key begins from the date it was scheduled. As long as replica keys remain, the status is PendingReplicaDeletion. The waiting period begins after the last replica is deleted (Section 4.5).
It is assumed that deleting a KMS key will also delete all CloudHSM key material. However, AWS KMS does not delete the key material in cluster backups (Section 6.3).
It is assumed that the KMS CMK Deletion event will only be received once. The documentation states that, in some cases, retries may result in multiple KMS CMK Deletion events for the same key (Section 6.4).
The AWS KMS DeleteKey is interpreted as the deletion API called by the user. DeleteKey is a service event recorded by AWS KMS after the waiting period. The user calls ScheduleKeyDeletion (Section 6.4).

10. Frequently Asked Questions About Scheduled Deletions

This section presents the following information in the form of frequently asked questions. References to the sections providing the basis for the answers are indicated in parentheses.

Q1. Does everything stop for a KMS key that is pending deletion?

No. The key is unusable for cryptographic operations and certain administrative operations. The key state table indicates that 12 operations, including DescribeKey, GetKeyPolicy, PutKeyPolicy, ListAliases, ListResourceTags, and CancelKeyDeletion, will still succeed. Operations such as TagResource, CreateAlias, EnableKey, and DisableKey will fail. The impact on data keys protected by the key is delayed until the key is next used (Sections 4.2 and 4.3).

Q2. Can a key be used right after `CancelKeyDeletion`?

No, it will not be immediately usable. If CancelKeyDeletion is successful, the key's status will change to Disabled. To use it, you must subsequently call EnableKey (Section 5.1).

Q3. Is the resource deleted exactly on the last day of the waiting period?

Not necessarily. The documentation does not promise that. Both KMS and Payment Cryptography indicate that the actual waiting period might be up to 24 hours longer than scheduled. Secrets Manager states that it does not guarantee when deletion will occur after the recovery window. The Private CA user guide states that the CA will be permanently deleted at the end of the restoration period, but no statement was found on a delay (Section 6.2).

Q4. Is the waiting period 7 to 30 days in every service?

No. It varies depending on the service. It is 7 to 30 days for KMS, Secrets Manager, and Private CA (with a default of 30 days), but Payment Cryptography has a waiting period of 3 to 180 days, with a default of 7 days. CloudHSM backups can be restored within 7 days of a deletion request, although there is no option to specify a waiting period (Sections 3.1 and 4.1).

Q5. Can the value of a Secrets Manager secret be read while it is scheduled for deletion?

No. The DeleteSecret API documentation states that When a secret is scheduled for deletion, you cannot retrieve the secret value. It also indicates that you should first use RestoreSecret to cancel the deletion. Regarding other operations besides retrieving the value, no specific information was found. In the configuration described in Section 7.2, operations such as TagResource, PutSecretValue, and UpdateSecret also failed with the same exception as GetSecretValue (Sections 4.6 and 7.2).

Q6. Can a new secret be created with the same name as a secret scheduled for deletion?

The documentation does not settle this. The Secrets Manager API reference and user guide do not contain information regarding whether a secret can be created with the same name while the original secret is scheduled for deletion. The Knowledge Center provides the exact wording of the exception message when attempting to create a secret with a duplicate name, stating that it is not possible through the console. The description for SecretProps in AWS CDK also indicates that this is not allowed. However, neither provides a statement from the API specification itself. In the configuration described in Section 7.2, a CreateSecret call to the API was rejected with the same error message presented in the Knowledge Center (Sections 4.6 and 7.2).

Q7. Does `DELETED` in AWS Private CA mean that the CA cannot be restored?

No, it is a waiting state from which the CA can be restored. You can revert it to its state before deletion using RestoreCertificateAuthority. However, CAs deleted while in the CREATING or FAILED states, and CAs whose restoration period has expired, are not recoverable (Sections 4.7 and 5.3).

Q8. Where does it show that a KMS key was actually deleted?

CloudTrail records DeleteKey with the eventType AwsServiceEvent. Amazon EventBridge receives a KMS CMK Deletion event. While this event is guaranteed to be sent, it is possible to receive multiple events for the same key (Section 6.4).

11. Summary

The range and default of the waiting period vary by service: KMS, Secrets Manager, and Private CA allow 7 to 30 days with a default of 30 days, while Payment Cryptography allows 3 to 180 days with a default of 7 days. CloudHSM backups can be restored within a period of up to 7 days (Sections 3.1 and 4.1).
The operations that are halted and those that proceed during the waiting period differ by operation: KMS keys halt cryptographic operations, while 12 other operations continue. The impact on data keys is delayed until the next use, and public keys outside AWS KMS remain usable. Secrets Manager does not return values (Section 4).
The state after an undo may not be the original state: KMS enters a Disabled state, Private CA reverts to its state before deletion, and Payment Cryptography enters a CREATE_COMPLETE state (Section 5).
The end of the period does not represent a guaranteed deletion time: KMS and Payment Cryptography may experience delays of up to 24 hours, and Secrets Manager does not guarantee specific timing (Section 6.2).
Certain elements persist: Key material in CloudHSM cluster backups, external keys, extracted public keys, and the ciphertext created with them remain (Section 6.3).
Confirmation is recorded as a service event: KMS's DeleteKey entry is an AwsServiceEvent, and KMS CMK Deletion may generate multiple events. Secrets Manager records EndSecretVersionDelete (Section 6.4).

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi