If your Customer Master Keys (CMKs) do not support version-based automatic rotation, you can manually rotate the CMKs. This is an alternative solution that does not depend on whether automatic key rotation is supported.

Custom data encryption scenario

On-premise or cloud applications can call the API operation to implement custom data encryption. Examples:
  • Encrypt sensitive data such as ID card numbers, credit card information, and home addresses before writing it to databases
  • Encrypt data at the client side before uploading it to OSS
  • Encrypt service profiles that contain sensitive data and SSL key certificates such as application profiles
You can use the key alias feature to rotate encryption keys within applications. The ID and alias of the key are not required when you call the Decrypt API operation.
In this scenario, you must perform the following steps:
  1. Initial configuration
    1. The administrator creates a CMK, whose ID is CMK-A.
    2. The administrator binds the alias/MyAppKey alias to CMK-A.
    3. When the application encryption module calls the Encrypt API operation, the value of the KeyId parameter is alias/MyAppKey. KMS finds that alias/MyAppKey is bound to CMK-A and then uses CMK-A to encrypt data.
    4. When the application decryption module calls the Decrypt API operation, the KeyId parameter is not used. KMS uses the CMK used to encrypt the data to decrypt the data.
  2. Manual rotation
    1. The administrator creates a CMK, whose ID is CMK-B.
    2. The administrator calls the UpdateAlias API operation to bind the alias/MyAppKey alias to CMK-B.
    3. When the application decryption module calls the Encrypt API operation, the value of the KeyId parameter is alias/MyAppKey. KMS finds that alias/MyAppKey is bound to CMK-B and uses CMK-B to encrypt data.
    4. When the application decryption module calls the Decrypt API operation, the KeyId parameter is not used. KMS uses the CMK used to encrypt the data to decrypt the data.

Server encryption scenario

Other cloud services can encrypt their data by integrating KMS API operations. The following situations may occur in key rotation scenarios:
  • Automatic rotation policies configured on KMS affect the server encryption of other cloud services

    Cause: After CMK encryption is configured for cloud services, they will call the GenerateDataKey API operation of KMS to generate data keys. When KMS generates a new primary key version, cloud services use the new version to generate new data key. A typical example of such cloud services is OSS. In this situation, if you want to enable automatic key rotation, you cannot use service managed keys or BYOKs imported to KMS because they do not support automatic rotation.

  • Automatic rotation policies configured on KMS do not affect server encryption of other cloud services

    Cause: After CMK encryption is configured for cloud services, the services only call the GenerateDataKey API operation of KMS once to generate keys to encrypt specific resources. When KMS generates a new primary key version, cloud services will not use it. For example, when encrypting a cloud disk, ECS calls the GenerateDataKey API operation of KMS once to generate a volume encryption key. This key will not be updated again after it is created.

If automatic rotation policies configured on KMS do not affect server encryption of other cloud services or you want to rotate data keys when BYOKs are used, you can change configurations and copy data to achieve the same effect as key rotation. These methods depend on the features of different cloud services. For more information, see documentation of respective cloud services.