New API Documentation - Developer Preview Available
We are excited to announce the developer preview of our new API documentation for AWS SDK for JavaScript v3. Please follow instructions on the landing page to leave us your feedback.
Schedules the deletion of a KMS key. By default, KMS applies a waiting period of 30
days, but you can specify a waiting period of 7-30 days. When this operation is successful,
the key state of the KMS key changes to PendingDeletion and the key can't be used
in any cryptographic operations. It remains in this state for the duration of the waiting
period. Before the waiting period ends, you can use CancelKeyDeletion to
cancel the deletion of the KMS key. After the waiting period ends, KMS deletes the KMS key,
its key material, and all KMS data associated with it, including all aliases that refer to
it.
Deleting a KMS key is a destructive and potentially dangerous operation. 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[BUGBUG-link to
importing-keys-managing.html#import-delete-key.) To prevent the use of a KMS key without
deleting it, use DisableKey.
You can schedule the deletion of a multi-Region primary key and its replica keys at any
time. However, KMS will not delete a multi-Region primary key with existing 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. For details, see Deleting multi-Region keys in the
Key Management Service Developer Guide.
When KMS deletes
a KMS key from an CloudHSM key store, it makes a best effort to delete the associated
key material from the associated CloudHSM cluster. However, you might need to manually delete
the orphaned key material from the cluster and its backups. Deleting a KMS key from an
external key store has no effect on the associated external key. However, for both
types of custom key stores, deleting a KMS key is destructive and irreversible. You cannot
decrypt ciphertext encrypted under the KMS key by using only its associated external key or
CloudHSM key. Also, you cannot recreate a KMS key in an external key store by creating a new KMS
key with the same key material.
For more information about scheduling a KMS key for deletion, see Deleting KMS keys in the
Key Management Service Developer Guide.
The KMS key that you use for this operation must be in a compatible key state. For
details, see Key states of KMS keys in the Key Management Service Developer Guide.
Cross-account use: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
The request was rejected because the state of the specified resource is not valid for this
request.
This exceptions means one of the following:
The key state of the KMS key is not compatible with the operation.
To find the key state, use the DescribeKey operation. For more
information about which key states are compatible with each KMS operation, see
Key states of KMS keys in the Key Management Service Developer Guide.
For cryptographic operations on KMS keys in custom key stores, this exception represents a general failure with many possible causes. To identify the cause, see the error message that accompanies the exception.
Schedules the deletion of a KMS key. By default, KMS applies a waiting period of 30 days, but you can specify a waiting period of 7-30 days. When this operation is successful, the key state of the KMS key changes to
PendingDeletion
and the key can't be used in any cryptographic operations. It remains in this state for the duration of the waiting period. Before the waiting period ends, you can use CancelKeyDeletion to cancel the deletion of the KMS key. After the waiting period ends, KMS deletes the KMS key, its key material, and all KMS data associated with it, including all aliases that refer to it.Deleting a KMS key is a destructive and potentially dangerous operation. 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[BUGBUG-link to importing-keys-managing.html#import-delete-key.) To prevent the use of a KMS key without deleting it, use DisableKey.
You can schedule the deletion of a multi-Region primary key and its replica keys at any time. However, KMS will not delete a multi-Region primary key with existing 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 toPendingDeletion
and its waiting period (PendingWindowInDays
) begins. For details, see Deleting multi-Region keys in the Key Management Service Developer Guide.When KMS deletes a KMS key from an CloudHSM key store, it makes a best effort to delete the associated key material from the associated CloudHSM cluster. However, you might need to manually delete the orphaned key material from the cluster and its backups. Deleting a KMS key from an external key store has no effect on the associated external key. However, for both types of custom key stores, deleting a KMS key is destructive and irreversible. You cannot decrypt ciphertext encrypted under the KMS key by using only its associated external key or CloudHSM key. Also, you cannot recreate a KMS key in an external key store by creating a new KMS key with the same key material.
For more information about scheduling a KMS key for deletion, see Deleting KMS keys in the Key Management Service Developer Guide.
The KMS key that you use for this operation must be in a compatible key state. For details, see Key states of KMS keys in the Key Management Service Developer Guide.
Cross-account use: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
Required permissions: kms:ScheduleKeyDeletion (key policy)
Related operations
CancelKeyDeletion
DisableKey
Example
Use a bare-bones client and the command you need to make an API call.
Param
ScheduleKeyDeletionCommandInput
Returns
ScheduleKeyDeletionCommandOutput
See
input
shape.response
shape.config
shape.Throws
DependencyTimeoutException (server fault)
The system timed out while trying to fulfill the request. You can retry the request.
Throws
InvalidArnException (client fault)
The request was rejected because a specified ARN, or an ARN in a key policy, is not valid.
Throws
KMSInternalException (server fault)
The request was rejected because an internal exception occurred. The request can be retried.
Throws
KMSInvalidStateException (client fault)
The request was rejected because the state of the specified resource is not valid for this request.
This exceptions means one of the following:
The key state of the KMS key is not compatible with the operation.
To find the key state, use the DescribeKey operation. For more information about which key states are compatible with each KMS operation, see Key states of KMS keys in the Key Management Service Developer Guide .
For cryptographic operations on KMS keys in custom key stores, this exception represents a general failure with many possible causes. To identify the cause, see the error message that accompanies the exception.
Throws
NotFoundException (client fault)
The request was rejected because the specified entity or resource could not be found.
Throws
KMSServiceException
Base exception class for all service exceptions from KMS service.
Example
To schedule a KMS key for deletion