Configure the DynamoDB Encryption Client to encrypt records We’ll assume that you’ve created a DynamoDB global table that’s replicated to the same Regions. Let’s explore that interaction in detail.įigure 2: Using multi-Region keys with DynamoDB global tablesīegin by creating a multi-Region primary key and replicating it into your backup Regions. One significant benefit of multi-Region keys is using them with DynamoDB global tables. Note: If your application will run in only one Region, you should continue to use single-Region keys to benefit from their data isolation properties. You can also create and use multi-Region keys in a single Region and choose to replicate those keys at some later date when you need to move protected data to additional Regions. For example, disaster recovery, global data management, distributed signing applications, and active-active applications that span multiple Regions can all benefit from using multi-Region keys.
Since multi-Region keys avoid cross-Region calls, they’re especially useful for scenarios where you don’t want to depend on another Region or incur the latency of a cross-Region call. You can use multi-Region keys in any client-side application.
This design ensures that all data protected with existing single-Region keys maintain the same data residency and data sovereignty properties. You cannot convert an existing single-Region key to a multi-Region key. The key Amazon Resource Names (ARN) of related multi-Region keys differ only in the Region portion, as shown in the following figure (Figure 1).įigure 1: Multi-Region keys have unique ARNs but identical key IDs In all other aspects, every multi-Region key, whether primary or replica, is a fully functional, independent KMS key resource with its own key policy, aliases, grants, key description, lifecycle, and other attributes. The primary and replica keys share only certain properties, including their key ID, key rotation, and key origin. Replica keys are KMS keys that can be used independently they aren’t a pointer to the primary key. Then, you use the primary key to create a related multi-Region replica key in a different Region of the same AWS partition. To use multi-Region keys, you create a primary multi-Region key with a new key ID and key material. AWS services also let you configure multi-Region keys for server-side encryption in case you want the same key to protect data that needs both server-side and client-side encryption. Multi-Region keys are supported in the AWS KMS console, the AWS KMS API, the AWS Encryption SDK, Amazon DynamoDB Encryption Client, and Amazon S3 Encryption Client. With asymmetric multi-Region keys, you encrypt, decrypt, sign, and verify messages in multiple Regions. With symmetric multi-Region keys, you can encrypt data in one Region and decrypt it in a different Region. Multi-Region keys are a set of interoperable KMS keys that have the same key ID and key material, and that you can replicate to different Regions within the same partition.
#Aws sdk kms client decrypt portable
Multi-Region keys are a new feature from AWS KMS for client-side applications that makes KMS-encrypted ciphertext portable across Regions. If you use client-side encryption, this work adds extra complexity and latency of re-encrypting between regionally isolated KMS keys. AWS services that use your KMS keys for server-side encryption address this challenge by transparently re-encrypting data on your behalf using the KMS keys you designate in the destination Region. However, not sharing keys across Regions creates challenges when you need to move data that depends on those keys across Regions. Region isolation can help you comply with security standards and data residency requirements. From its inception, AWS KMS has been strictly isolated to a single AWS Region for each implementation, with no sharing of keys, policies, or audit information across Regions.