This topic answers some frequently asked questions (FAQs) about migrating resources from Key Management Service (KMS) 1.0 to 3.0.
Why migrate from KMS 1.0 to 3.0?
To provide higher service quality and stability, KMS 1.0 is planned to enter the End of Full Support (EoFS) phase at 00:00:00 on March 30, 2025 (UTC+8), transitioning to the End of Service (EoS) phase at 00:00:00 on September 30, 2025 (UTC+8). The main benefits of migrating to a KMS 3.0 instance include the following:
Which type of KMS 3.0 instance should I use?
After migration, keys and secrets are stored in the KMS instance, with keys being unique to the region and secrets unique to both the Alibaba Cloud account and the KMS instance within that region. KMS supports the following types of instances:
Software Key Management: Offers key and secret management services, securely storing keys and secrets. It provides high scalability and security, with the master key generated and stored by software.
Hardware Key Management: Connects to a Hardware Security Module (HSM) cluster within Alibaba Cloud HSM, offering key services and secret management with enhanced security and compliance. Before enabling a hardware key management instance, an HSM must be purchased and an HSM cluster must be configured in Alibaba Cloud HSM.
Consider the following factors when selecting a KMS 3.0 instance:
Business requirements: Different KMS 3.0 instances support different software-protected keys. Select the KMS instance that supports the keys to be migrated.
Performance: Consider the queries per second (QPS) of encryption and decryption operations in your business. For high-traffic platforms like e-commerce sites that process many transactions each day, including encryption of payment details and order data, a KMS instance with higher QPS will meet your requirement to avoid transaction delays or failures. Check the supported QPS by each type of KMS 3.0 instance on the buy page.
Security compliance: If your business must comply with national cryptographic regulations and FIPS certification, select hardware key management instance.
Budget for costs: For both types of KMS 3.0 instances you can use either subscription or pay-as-you-go billing. If you use secrets and keys on demand, or are limited to cloud product encryption, we recommend selecting the pay-as-you-go option. For more information on billing methods, see Billing.
In most cases, a software key management instance with 1,000 QPS is sufficient for the majority of users. We recommend starting with this capacity. You can monitor the instance's performance and QPS metrics in the console, both before and after migration. KMS supports on-demand scaling, allowing you to adjust the throughput as needed.
What are the differences between KMS 1.0 and 3.0?
The table below lists the main differences between KMS 1.0 and 3.0. (√ indicates it is supported, and × indicates it is not.)
For more information on the features of KMS 3.0, see KMS 3.0 instance selection.
Feature | KMS 1.0 | KMS 3.0 | KMS 3.0 reference document |
Customer master key (CMK) | √ | √ | |
Bring Your Own Key (BYOK) | √ | √ | |
Hold Your Own Key (HYOK) | × | √ | |
Key rotation | √ | √ | |
Secret rotation | √ | √ | |
Multi-account management | × | √ | |
Multi-VPC management | × | √ | |
Log audit | × | √ | |
Backup and restoration | × | √ | |
Resource monitoring | × | √ | |
Key policies, secret policies | × | √ |
If I already have a KMS instance, do I still need to purchase a KMS 3.0 one?
No, but you need to upgrade the instance to the latest version before migration.
Software key management instance (formerly KMS basic edition instance): For upgrade instructions, see Upgrade the image version of a KMS instance.
Hardware key management instance (formerly KMS standard edition instance): To upgrade the instance, contact us.
Will migration from KMS 1.0 to KMS 3.0 affect business operations?
No. The migration process maintains management and data separation, ensuring business operations continue uninterrupted. During migration, you can get the secret value, cloud product encryption, and application encryption as normal.
However, to prevent migration failures due to data consistency issues, operations related to management, such as creating, modifying, or deleting resources, cannot be performed on keys during the migration process. Therefore, we recommend performing the migration during off-peak hours.
Does the migration tool support rollback?
No, therefore, ensure all details are correct before proceeding to prevent any misoperations on your business. If you encounter any issues after migration, contact us.
How long does key and secret migration take?
In most cases, the migration of keys and secrets is completed within minutes.
Does key and secret migration support batch migration?
Yes, and we recommend using batch migration. Manually select the keys and secrets for migration, ensuring the total number does not exceed 50 at a time. For detailed steps, see Step 2: Migration.
Why is the "Forbidden.NoPermission" error message displayed when I log on to the console to view resources after migration?
Cause
After migration, keys and secrets belong to a specific KMS instance. If a Resource Access Management (RAM) user or a RAM role wants to perform read operations on the KMS instance, the RAM user or RAM role must have the kms:DescribeDKMSInstances permission. If the policy of the RAM user or RAM role does not include kms:DescribeDKMSInstances, the error message is displayed when the RAM user or the RAM role performs read operations on the KMS instance.
If the policy of the RAM user or RAM role is a custom policy, the error message may be displayed. If the policy is a system policy, the error message is not displayed because the Action element in a system policy is usually set to kms:Describe* or kms:*. In this case, a system policy includes kms:DescribeDKMSInstances.
Solution
Add kms:DescribeDKMSInstances to the custom policy of the RAM user or RAM role. For more information, see Modify the document and description of a custom policy.