Key Management Service:Step 1: Assessment

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:

• Enhanced security: KMS 3.0 provides advanced tenant isolation and a dedicated instance architecture, offering significantly improved security over KMS 1.0.

• Enhanced features: KMS 3.0 supports sharing a single instance across multiple Alibaba Cloud accounts, allows for resource backup within the instance, and integrates with Simple Log Service and an alert management system for a more robust and complete user experience.

• Fine-grained access control: KMS 3.0 supports both identity- and resource-based access control policies, accommodating a variety of resource types and properties.

• Improved performance and reliability:

  • Efficient encryption and decryption: KMS 3.0 instances deliver higher performance, supporting 1,000, 2,000, or 4,000 queries per second (QPS), compared to KMS 1.0's 1000 QPS, catering to diverse performance requirements.

  • Redundancy and fault tolerance: With data backup capabilities and a multi-zone deployment architecture, KMS 3.0 instances achieve 99.95% stability and 99.9999% data availability, mitigating potential failures and ensuring continuous key management service availability.

Business impact and cost assessment

Business impact

Migration impacts the following aspects of the business:

• Terraform configurations: If your KMS 1.0 is Terraform-managed, after migration, Terraform configuration changes are required due to the instance ID attribute added. This change can prevent resource release when you perform management operations.

• Management operations: 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, secrets, or KMS instances during the migration process. We recommend performing the migration during off-peak hours.

The migration has no impact on the following aspects of the business:

• Service availability: 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.

• SDK integration: Self-built applications can seamlessly continue using the original SDK without code or application changes. SDK modifications are not required when using other product SDKs, such as Function Compute (FC), for business encryption and decryption, ensuring a smooth migration process.

• Access control policies: No reconfiguration is needed and existing policies can continue to be used.

• Performance: Before migration, if you use public network access key secrets before migration, you can continue using the original SDK after migration with no performance change. To enhance performance, switch from public network access to VPC network access, with performance depending on the instance type.

Cost assessment

KMS 1.0 and 3.0 instances use different billing methods. Before migration, familiarize yourself with the costs associated with KMS instances. For more information, see Subscription and Pay-as-you-go.

Key migration considerations

KMS 1.0 keys include service keys and customer master keys (CMKs).

Service keys

Service keys do not require migration and continue to function as usual. They can be accessed directly in the new KMS console and are automatically created by cloud products for server-side encryption. Service keys have a standard alias format: alias/acs/<cloud product>.

CMKs

Secret migration considerations

All types of secrets are supported for migration.

When you migrate a secret, consider the following:

• The metadata of the secret, such as secret name, secret status and tags, are migrated along with it. This data remains unchanged after migration.

• If the secret is multi-version, all versions can be migrated.

• If the secret is encrypted by a CMK, you must first migrate the CMK. If the secret is encrypted by a system-managed CMK, you can migrate the secret directly. After migration, the backup and cross-region synchronization function for the secret are not supported. For more information, see Disaster recovery.

• If the secret has automatic rotation enabled, disable it to ensure version consistency before migration.

Quickly check resources to migrate

This method only displays the keys that support migration. For ones that do not, you can view the remaining keys in the old KMS console after the migration, and then contact Alibaba Cloud Technical Support.

1. Log on to the old KMS console and click Migration Tool in the left-side directory.

2. Check if there are resources that need migration.

   If the Migrate in the Actions column is enabled, this indicates that there are resources available for migration in the corresponding region. You can click on the numbers in the Keys Not Migrated and Secrets Not Migrated columns to check the details. The data is displayed by region, so review all regions to ensure that you see all resources that you may want to migrate.

   

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.