AWS XKS vs Native KMS: When External Key Store Is the Right Control

AWS KMS with customer managed keys (CMKs) and AWS External Key Store (XKS) both improve on AWS-managed defaults. Only one keeps unencrypted key material outside Amazon’s infrastructure. This guide helps architects decide which model matches custody, compliance and operations for AWS workloads.

---

Table of Contents

1. What each model does
2. Side-by-side comparison
3. When native KMS CMKs are enough
4. When you need XKS
5. How DuoKey fits XKS
6. Next step

What each model does

Native AWS KMS (customer managed keys)

You create CMKs in AWS KMS, set rotation and grant access through IAM. Governance and auditability improve versus AWS-managed keys. Cryptographic operations still run in AWS KMS; key material resides in AWS HSMs.

AWS External Key Store (XKS)

XKS lets applications keep using AWS KMS APIs while cryptographic operations are routed to an external key manager through an XKS proxy. AWS never receives unencrypted key material for those keys. Encrypt and decrypt happen in infrastructure you operate or mandate.

DuoKey provides an XKS proxy connected to DuoKey’s MPC Vault: operations are authorized under dual-control policy, logged, and keys do not enter AWS infrastructure.

XKS: cryptographic operations route to the external DuoKey MPC Vault. AWS processes ciphertext for those keys.

Side-by-side comparison

AWS-managed keys sit below both: encryption on, keys entirely under Amazon’s control.

When native KMS CMKs are enough

Choose native CMKs when:

• You need customer-managed rotation, IAM grants and CloudTrail evidence inside AWS
• Your threat model accepts cryptographic operations inside AWS KMS
• Contracts or regulators ask for CMKs, not necessarily keys outside Amazon
• You want lower operational surface than running or integrating an external key store

Native CMKs are the right step when AWS-managed keys are insufficient and full external custody is not yet required.

When you need XKS

Choose XKS when:

• You must show that AWS cannot unwrap data keys for regulated workloads at will
• Financial, public-sector or sovereignty programmes require keys outside the cloud operator trust boundary
• Supervisors ask who can decrypt production data and under which policy you control
• The same custody story must align with SaaS external-key patterns (for example Microsoft DKE) across the estate

XKS keeps familiar KMS usage while moving decryption authority off Amazon infrastructure. Designs must account for latency, availability and tested failover, not only the architecture diagram.

How DuoKey fits XKS

Next step

1. List AWS accounts and services that need keys outside Amazon versus CMK governance only.
2. Read the XKS implementation guide if external custody is in scope.
3. Review DuoKey for AWS XKS or schedule a scoped architecture review covering availability and evidence requirements.