AWS DynamoDB Global Tables with KMS Multi-Region Keys (MRKs) PLUS Client-Side Encryption | Overview.

AWS DynamoDB Global Tables with KMS Multi-Region Keys (MRKs) PLUS Client-Side Encryption  - Overview.

Focus:

• Intro,
• Core Architecture Components,
• How the Workflow Operates,
• Configuration Guidelines,
• Overview of DynamoDB Global Tables,
• Overview of KMS Multi-Region Keys (MRKs),
• Overview of Client-Side Encryption,
• Why Combine Them,
• How It Works (High-Level Flow),
• Step 1 — Encrypting a DynamoDB item (Client-Side),
• Step 2 — Cross-Region Replication (Global Tables),
• Step 3 — Decrypting in Another Region,
• Configuration Setup (step-by-step) CLI,
• Step-A1: Create primary MRK in Region A (us-east-2) 
• Step-A2: Replicate primary MRK in Region B (us-west-1)
• Step-B: Configure Encryption Client (In twtech app),
• Step-C: Encrypt Data Locally,
• Step-D: Store Encrypted Data in DynamoDB,
• Performance and Security Considerations,
• Encryption Context & Access Control,
• When to Use MRKs + Client-Side Encryption,
• When to Use MRKs + Client-Side Encryption (Ideal for).
• When NOT to Use MRKs + Client-Side Encryption (NOT Ideal for),
• Limitations,
• Summary Layers & Roles.

Intro:

• Combining AWS DynamoDB Global Tables with KMS Multi-Region Keys (MRKs) and client-side encryption allows twtech to maintain data confidentiality across multiple regions while ensuring low-latency access. 
• This architecture uses the AWS Database Encryption SDK (formerly the DynamoDB Encryption Client) to protect sensitive fields before they leave twtech application. 

Core Architecture Components

• DynamoDB Global Tables: Automatically replicates twtech data across selected AWS regions, providing 99.999% availability and local read/write performance.
• KMS Multi-Region Keys (MRKs): These are specialized KMS keys that share the same key ID and key material across different regions. 
• KMS Multi-Region Keys (MRKs) allow data encrypted in one region to be decrypted in another without cross-region API calls or re-encryption.
• Client-Side Encryption: Using the AWS Database Encryption SDK, twtech encrypt specific attributes (like PII) at the application level. 
• The data is already encrypted when it reaches DynamoDB. 

How the Workflow Operates

• Encryption (Region A): twtech application uses a local primary MRK to encrypt sensitive attributes and then performs a PutItem operation to the local DynamoDB replica.
• Replication: DynamoDB Global Tables replicates the encrypted record (the ciphertext) to replica tables in other regions.
• Decryption (Region B): A regional application instance reads the encrypted record and uses its local replica MRK to decrypt the data. 
• Since the primary and replica MRKs share the same key material, the local KMS can decrypt the data directly. 

Configuration Guidelines

• Use Global Tables Version 2019.11.21+: This version allows the AWS Database Encryption SDK to work without special configuration of reserved replication fields.
• Symmetric Keys Only: The Direct KMS Provider used for this setup requires a symmetric encryption KMS key.
• Key Identification: It is recommended to use the full Key ARN in twtech code to ensure the client identifies the correct regional replica key for local calls.
• Permissions: Applications in each region must have kms:GenerateDataKey and kms:Decrypt permissions on their respective regional MRKs

NB:

This is a complex topic because it blends three distinct security and replication models:

1. DynamoDB multi-region replication (Global Tables),
2. AWS KMS multi-region key infrastructure, 
3. The AWS Encryption SDK / DynamoDB Encryption Client for client-side encryption.

1. Overview of DynamoDB Global Tables

• Global Tables provide multi-region, fully managed replication. 
• Data written in one region is automatically replicated to other participating regions.

Core idea:

• Each replica table has the same data, and DynamoDB manages replication asynchronously.

 Overview of KMS Multi-Region Keys (MRKs)

• MRKs ensure that cryptographically identical KMS keys exist in multiple regions, allowing:
• Encryption in one region
• Decryption in another
• without transferring key material.

  Overview of Client-Side Encryption

• Unlike server-side encryption (SSE), client-side encryption encrypts data before it ever reaches DynamoDB.
• twtech (the application) manage encryption/decryption using AWS SDKs (e.g., AWS Encryption SDK or DynamoDB Encryption Client).

 2. Why Combine Them

• Have data replicated globally
• Require data confidentiality even from AWS (client-side encryption)
• Need encryption to be region-agnostic — decryptable in multiple regions

NB:

• That’s exactly what KMS MRKs solve.
• Without MRKs, client-side encryption would produce ciphertext that can only be decrypted in one region.
• With MRKs, the same data can be decrypted anywhere that a replica key exists.

 3. How It Works (High-Level Flow)

Step 1 — Encrypting a DynamoDB item (Client-Side)

1. twtech application in Region A writes an item to a DynamoDB Global Table.
2. The client (using the DynamoDB Encryption Client) requests a data key from AWS KMS (using an MRK).
3. AWS KMS in Region A:
• Uses the local replica of the MRK.
• Returns a data encryption key (DEK) — plaintext and ciphertext versions.
4. The application encrypts item attributes using the plaintext DEK.
5. The encrypted item (and ciphertext DEK) is stored in DynamoDB.

Step 2 — Cross-Region Replication (Global Tables)

• DynamoDB automatically replicates the encrypted item and its ciphertext DEK (Data Encryption Key) to other regions.
• The ciphertext DEK (Data Encryption Key) remains valid globally because it’s encrypted under an MRK.

Step 3 — Decrypting in Another Region

1. Application in Region B reads the item from the replicated DynamoDB table.
2. It retrieves the ciphertext DEK (Data Encryption Key).
3. It calls AWS KMS in Region B (which has the replica MRK) to decrypt it.
4. The plaintext DEK (Data Encryption Key) is returned.
5. The item attributes are decrypted locally using that DEK (Data Encryption Key).

Result:

• Encrypted in Region A, decrypted in Region B — without cross-region key traffic.

 4. Detailed Architecture:

NB:
The ciphertext DEK (Data Encryption Key) and the encrypted item both replicate, but no key material leaves KMS.

 5. Configuration Setup (step-by-step) CLI

Step-A1. Create primary MRK in Region A (us-east-2)

aws kms create-key --multi-region --description "DynamoDB MRK"

Step-A2: Replicate primary MRK in Region B (us-west-1)

aws kms replicate-key \

  --key-id arn:aws:kms:us-east-2:accountID:key/twtechmrk-123 \

  --replica-region us-west-1

Step-B. Configure Encryption Client (In twtech app):

from aws_encryption_sdk.keyrings.aws_kms import AwsKmsKeyring

key_arn = "arn:aws:kms:us-east-2:accountID:key/twtechmrk-123"

keyring = AwsKmsKeyring(generator_key_id=key_arn)

NB:

• The keyring automatically uses the regional endpoint where the app runs (thanks to the shared MRK ID).

Step-C. Encrypt Data Locally

ciphertext, encryptor_header = aws_encryption_sdk.encrypt(

    source=b"{\"UserId\":twtwchuserID123, \"SSN\": \"999-99-9999\"}",

    keyring=keyring

)

Step-D: Store Encrypted Data in DynamoDB

• Store ciphertext and the associated metadata (from the header) as attributes.

 6. Performance and Security Considerations

Aspect	Description
Latency		Each region uses its local KMS endpoint — minimal latency.
Data sovereignty		No cross-region key use; MRKs comply with region-level key control.
DR / Failover		If one region fails, others can continue decrypting locally.
Auditability		CloudTrail logs operations per region.
Consistency		MRK ensures consistent crypto properties across regions.

 7. Encryption Context & Access Control

• When encrypting with KMS, twtech always use an encryption context to bind ciphertext to a specific table or item type.

Sample:

encryption_context = {

    "TableName": "twtechCustomerData",

    "Region": "us-east-2"

}

NB:

• Decryption will fail if the context doesn’t match — adding another layer of protection against misuse.

 8. When to Use MRKs + Client-Side Encryption (Ideal for):

• Global applications handling PII / financial / regulated data
• Multi-region disaster recovery environments
• Zero-trust architectures where data is protected even from AWS operators

When NOT to Use MRKs + Client-Side Encryption (NOT Ideal for):

• Low-sensitivity or transient data (adds operational complexity)
• Workloads already covered by SSE-KMS (server-side encryption)

 9. Limitations

• Eventual consistency: 
•  DynamoDB Global Tables replication is asynchronous (with events of processes that do not occur at the same time) ; 
• encryption clients must tolerate transient differences (temporary variation).

 10. Summary Layers & Roles

Layer	Role
KMS MRK		Provides cross-region, identical cryptographic key material.
DynamoDB Global Tables		Replicates encrypted data across regions.
Encryption Client		Handles local encryption/decryption using MRK-backed DEKs.
Result		End-to-end, region-resilient, client-side encrypted replication.