AWS External Key Store (XKS): Complete Implementation Guide 2026

AWS External Key Store (XKS) is an AWS KMS custom key store backed by a key manager you run outside AWS. AWS services keep calling AWS KMS as usual, but every encrypt and decrypt under an XKS key also needs your external key, reached through an XKS proxy you operate. AWS KMS cannot create, view or delete that key, and if you disconnect the proxy, AWS can no longer decrypt the data (AWS KMS Developer Guide).

That control comes with real complexity and a shift in operational responsibility. This guide covers what the AWS external key store is, whether you need it, how to set up the XKS proxy and the key store step by step, the latency and availability limits AWS sets, the error codes you will meet, and what it costs beyond the KMS bill.

---

Table of Contents

1. What is AWS XKS?
2. How AWS XKS Works
3. XKS vs. Other Key Management Options
4. When You Actually Need XKS
5. Requirements and Prerequisites
6. Step-by-Step Implementation Guide
7. The XKS Proxy: Deep Dive
8. XKS Proxy Options: Build or Buy
9. Running an AWS External Key Store with DuoKey
10. Security Best Practices
11. Common Challenges and Troubleshooting
12. Compliance and Audit Considerations
13. FAQ

---

What is AWS XKS?

AWS External Key Store (XKS) is a feature of AWS Key Management Service (KMS) that lets you use encryption keys that are generated, stored and managed entirely outside of AWS infrastructure -- in hardware or software you own and control.

Announced at re:Invent 2022 and now a mature capability, XKS addresses a specific gap: organizations that need the breadth of AWS services but cannot, by regulation or policy, allow their cryptographic root keys to reside on AWS infrastructure.

Under standard AWS KMS, Amazon manages the key material inside its own secure infrastructure. You control access to keys, but the keys themselves live in AWS. XKS inverts this: your keys live in your infrastructure and AWS calls out to them when it needs to perform cryptographic operations.

Key Terminology

One clarification that surprises many architects: XKS uses double encryption. Each XKS-backed KMS key has two backing keys: AWS KMS key material generated in AWS KMS HSMs, and your external key. Data is encrypted with the first, then the result is encrypted with the second. Ciphertext protected by XKS is therefore always at least as strong as standard KMS ciphertext, and neither AWS KMS nor the holder of the external key can decrypt it alone (AWS: double encryption).

What XKS supports, and what it doesn't

• Symmetric keys only. An external key must be a 256-bit AES key that can encrypt and decrypt. Asymmetric keys, HMAC keys, imported key material, automatic key rotation and multi-Region keys are not supported in custom key stores.
• Same KMS APIs and pricing. You call AWS KMS with the same APIs and parameters, and AWS KMS prices XKS keys like standard KMS keys. You pay separately for the external key manager, the proxy and the network around them.
• Regions. External key stores are available in every AWS Region where AWS KMS runs, except China (Beijing) and China (Ningxia).
• Quotas. Up to 10 custom key stores (CloudHSM and external combined) per account and Region.

(AWS KMS Developer Guide: External key stores)

---

How AWS XKS Works

Understanding the request flow is essential before you commit to XKS. Every encrypt or decrypt operation follows this path:

1. An AWS service (S3, EBS, RDS, etc.) calls AWS KMS to encrypt or decrypt a data key
2. AWS KMS identifies that the KMS key is backed by an external key store
3. KMS forwards the cryptographic request to your XKS proxy via HTTPS
4. Your XKS proxy authenticates the request and forwards it to your external key manager
5. Your external key manager performs the cryptographic operation
6. The result travels back through the proxy to KMS
7. KMS completes the operation and returns results to the AWS service

This entire round-trip happens synchronously. The proxy API specification states that if KMS does not receive a response from the XKS proxy within 250 ms, the call times out, and it asks for a ping latency of 35 ms or less between the AWS Region and your key manager (XKS Proxy API Specification). If any step in the chain fails, the KMS operation fails, and depending on the AWS service, that failure can cascade.

The plaintext data key itself is never sent to the proxy: AWS KMS sends the ciphertext produced by its own key material, and your key manager encrypts that.

The Shared Responsibility Shift

This is where many organizations underestimate XKS. Under standard KMS, AWS handles availability, patching, scaling and disaster recovery of the key infrastructure. Under XKS, you take on all of that for your proxy and external key manager -- including the physical facility, power, cooling, network, OS and application layers.

If your external key manager goes down, AWS services relying on XKS keys cannot encrypt or decrypt. This is not a hypothetical failure mode -- it's the expected behavior and it's your responsibility to design against it.

---

XKS vs. Other Key Management Options

Before you invest in XKS, compare it honestly against alternatives.

XKS vs. Standard AWS KMS (Customer-Managed Keys)

With standard customer-managed keys (CMKs), you control key policies and access -- who can use the key, under what conditions, with full audit logging. AWS still holds the key material in its own KMS infrastructure.

Use CMKs when: you need strong access control and auditability, but your compliance requirements don't mandate that key material lives outside AWS.

Use XKS when: regulations or organizational policy explicitly require that cryptographic key material never resides on third-party (i.e., AWS) infrastructure.

XKS vs. AWS CloudHSM

CloudHSM gives you dedicated, single-tenant Hardware Security Modules inside AWS data centers. You control the HSM, its users and its keys -- AWS has no access to the key material. However, the HSMs themselves are physically in AWS-owned facilities.

Choose CloudHSM if you need dedicated, single-tenant HSMs and can tolerate keys residing physically within AWS. Choose XKS only if your compliance mandate explicitly requires keys to remain outside AWS-owned facilities entirely. For a side-by-side of both custom key store types, see AWS KMS custom key store: CloudHSM vs XKS.

XKS vs. Customer-Managed Keys (Summary)

For the majority of workloads -- including most HIPAA, PCI-DSS and SOC 2 requirements -- standard customer-managed KMS keys are sufficient. XKS is purpose-built for the narrow set of regulations (certain EU data sovereignty requirements, specific financial sector rules, US government mandates) that explicitly require no cloud provider access to key material under any circumstance.

Decision Framework

Ask these three questions in order:

1. Do your regulations explicitly require key material to reside outside your cloud provider's physical infrastructure? If no → use CMKs or CloudHSM.
2. Can you accept higher latency, operational complexity and significantly higher costs? If no → reconsider whether XKS is truly required.
3. Do you have the operational maturity to run a highly available, low-latency key management service? If no → build that capability before implementing XKS.

---

When You Actually Need XKS

XKS exists for a specific compliance scenario, not general security improvement. These are the legitimate use cases:

Regulatory data sovereignty -- Regulations such as GDPR (compounded by the Schrems II ruling) require EU organizations to be able to prove that encryption keys never leave their controlled jurisdiction and to revoke cloud provider access at any time. XKS satisfies this by placing keys in EU-based infrastructure outside AWS.

CLOUD Act exposure mitigation -- Organizations concerned about the US CLOUD Act (which allows US law enforcement to compel US cloud providers to produce data) use XKS to ensure AWS cannot access key material under compulsion. Your external key manager, in a separate jurisdiction, holds the only copy.

Financial services mandates -- Certain central bank regulations and financial sector supervisory frameworks require "operational resilience" provisions that include maintaining control of cryptographic material external to the primary cloud provider.

Government and defense workloads -- US federal agencies handling CUI (Controlled Unclassified Information) or classified data under FedRAMP High or DoD IL frameworks may have explicit key custody requirements.

Zero-trust key architecture -- Organizations implementing strict zero-trust models where no single vendor has complete access to both data and keys.

What XKS is not for: general security hardening, achieving HIPAA compliance (standard KMS is sufficient), reducing AWS vendor lock-in for non-cryptographic reasons, or saving money. It's more expensive and more complex than every alternative.

---

Requirements and Prerequisites

Before you start implementation, validate all of these.

External Key Manager Requirements

Your external key manager must:

• Support AES-256 symmetric keys
• Be capable of performing AES-GCM encrypt and decrypt operations
• Expose an API that your XKS proxy can translate to the AWS XKS specification
• Meet the latency requirement: answer within the 250 ms timeout, ideally from a site with 35 ms or less round-trip time to the AWS Region

The external key manager can be a physical HSM, a virtual HSM, or a software key manager with or without an HSM component, located on premises or in any cloud (AWS). Your options for the proxy that sits in front of it are compared in XKS Proxy Options.

AWS Account Requirements

• AWS KMS enabled in your target regions
• IAM permissions to create and manage custom key stores
• VPC configured if using VPC endpoint service connectivity (recommended)

Network Requirements

XKS supports two connectivity models:

Public endpoint connectivity -- AWS KMS reaches your proxy over the internet via HTTPS. Simpler to configure, but exposes your proxy endpoint to the public internet. Acceptable only with robust mTLS authentication.

VPC endpoint service connectivity -- AWS KMS connects via an AWS PrivateLink VPC endpoint service you create and maintain. This keeps traffic off the public internet and is the recommended approach for production workloads.

Your proxy must be reachable with:

• TLS 1.2 or higher with a valid certificate
• The proxy URI path must be /kms/xks/v1 (or a prefix ending in that path)
• Port 443 (HTTPS)
• Response time consistently under 250 ms

---

Step-by-Step Implementation Guide

Step 1: Set Up Your External Key Manager

Configure your chosen key manager to generate and store AES-256 keys. Note the external key ID (XksKeyId) for each key you plan to use -- you'll reference this when creating KMS keys.

Ensure your key manager is deployed with high availability. At minimum: active-passive failover. For production: active-active across two or more independent nodes.

Step 2: Deploy the XKS Proxy

Your proxy is the critical piece. Deployment options:

On-premises proxy connecting via public endpoint: Proxy runs in your data center, exposed via public HTTPS endpoint. Use only if VPC connectivity isn't viable.

Proxy on EC2 within a VPC (recommended): Deploy the proxy on an EC2 instance in a private subnet. Create a VPC endpoint service pointed at a Network Load Balancer in front of your proxy. AWS KMS connects via PrivateLink.

Proxy on-premises connecting via VPC: Run the proxy on-premises but connect it to a VPC endpoint service through a Site-to-Site VPN or Direct Connect. Maximum security, maximum complexity.

For high availability, deploy proxy instances across multiple Availability Zones behind a Network Load Balancer.

Authentication between KMS and your proxy uses a SigV4 proxy authentication credential: an access key ID and a secret access key that you configure on both the proxy and in KMS. Never reuse IAM credentials for it. AWS recommends that the proxy accept at least two valid credentials, so you can rotate without downtime, and publishes the XksProxyCredentialAge CloudWatch metric to track credential age (AWS).

Step 3: Configure AWS KMS

Create the external key store using the AWS CLI:

# Create external key store with VPC endpoint service connectivity
aws kms create-custom-key-store \
  --custom-key-store-name "MyExternalKeyStore" \
  --custom-key-store-type EXTERNAL_KEY_STORE \
  --xks-proxy-connectivity "VPC_ENDPOINT_SERVICE" \
  --xks-proxy-uri-endpoint "https://myproxy-private.xks.example.com" \
  --xks-proxy-uri-path "/kms/xks/v1" \
  --xks-proxy-vpc-endpoint-service-name "com.amazonaws.vpce.us-east-1.vpce-svc-0example" \
  --xks-proxy-authentication-credential \
    AccessKeyId=ABCDE12345670EXAMPLE,RawSecretAccessKey=supersecretkeyvalue

Connect the key store:

aws kms connect-custom-key-store \
  --custom-key-store-id cks-1234567890abcdef0

Verify connection status:

aws kms describe-custom-key-stores \
  --custom-key-store-id cks-1234567890abcdef0

A healthy response shows "ConnectionState": "CONNECTED".

Step 4: Create KMS Keys Backed by XKS

aws kms create-key \
  --custom-key-store-id cks-1234567890abcdef0 \
  --xks-key-id "your-external-key-id" \
  --description "XKS-backed key for S3 bucket encryption" \
  --key-usage ENCRYPT_DECRYPT

Step 5: IAM Policy Configuration

Attach a key policy that grants access to the services and principals that need to use the key:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Enable KMS key administration",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/KeyAdminRole"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AppRole"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

Step 6: Testing and Validation

Test the connection explicitly before using the key store in production:

# Test encrypt/decrypt round-trip
aws kms generate-data-key \
  --key-id "arn:aws:kms:us-east-1:123456789012:key/your-key-id" \
  --key-spec AES_256

Test failover scenarios: take your proxy offline and confirm that AWS services handle the failure gracefully and recover when the proxy returns. Never skip this test in staging.

---

The XKS Proxy: Deep Dive

The proxy deserves dedicated attention because it's the most common source of implementation problems.

The proxy implements the AWS KMS External Key Store Proxy API Specification, a REST API over HTTPS with four operations:

(AWS: Proxy APIs)

Proxy Security Requirements

• SigV4 authentication of every KMS-to-proxy request, over TLS 1.2 or later with one of the cipher suites AWS lists
• Proxy must validate that requests include a valid requestMetadata field containing the AWS principal ARN and KMS key ARN -- this enables you to implement additional authorization at the proxy layer beyond IAM
• All communication encrypted in transit; no exceptions
• Proxy should not store key material -- it translates requests, it doesn't cache secrets

Building a Custom Proxy

AWS provides an open-source reference implementation in Rust, runnable as a container, compatible with any PKCS#11 HSM. This is a reasonable starting point for organizations using non-vendor-supported key managers.

For production use, add:

• Request/response logging (without logging key material)
• Rate limiting and circuit breakers
• Health check endpoints for load balancer integration
• Metrics export to CloudWatch or your observability stack

Proxy Performance Considerations

Every KMS call for an XKS-backed key involves an external network round-trip. For workloads generating thousands of KMS requests per second, this adds up. AWS caches data keys at the service level (e.g., S3 caches data keys for a few minutes when bucket keys are enabled), which reduces the raw request volume to your proxy -- but you still need to capacity-plan for peak load.

Benchmark your proxy under realistic load before go-live. XKS_PROXY_TIMED_OUT errors indicate your proxy is too slow; XKS_PROXY_INVALID_RESPONSE indicates a protocol issue. AWS also publishes a test client that checks a proxy against the specification.

---

XKS Proxy Options: Build or Buy

Every AWS external key store needs exactly one XKS proxy. AWS lets you build it from the open specification or buy it from a vendor, and the proxy may be part of the key manager itself (AWS).

Questions to ask any vendor before you choose:

1. Where does the key material physically live, and who can operate that site?
2. Can the proxy enforce its own authorization on the requestMetadata (calling principal, KMS key ARN), on top of IAM?
3. How is the 250 ms budget met from your target AWS Region, and with what HA design?
4. What evidence do you get: proxy logs, key manager logs, and a way to correlate them with CloudTrail?
5. How fast can you cut AWS off, and how do you restore access?

---

Running an AWS External Key Store with DuoKey

DuoKey for AWS XKS implements the XKS proxy specification as a built-in feature of DuoKey Cockpit. There is no separate proxy to install: you deploy an XKS endpoint from the same Cockpit interface you use for your other apps and keys, and each endpoint is bound to the vault and key you select (DuoKey docs: AWS XKS overview).

• Key backends. An endpoint uses one vault. DuoKey documents DuoKey MPC (threshold cryptography), HashiCorp Vault (Transit engine) and a cross-account AWS KMS key as backends. With the MPC vault, no single node holds the complete key; see MPC vs HSM for how that differs from a single HSM.
• Connectivity. The proxy can be reached through a public endpoint or a VPC endpoint, the two connectivity models AWS KMS supports (DuoKey docs: Snowflake TSS setup).
• Kill switch. Disconnecting the external key store in AWS KMS, or disabling the DuoKey proxy, cuts AWS off from the key. DuoKey's documentation walks through both cases.
• Services built on XKS. The same endpoint model backs DuoKey's Snowflake Tri-Secret Secure setup and Salesforce External Key Management through AWS KMS.

For the decision between holding the key yourself and letting the provider hold it, see Hold Your Own Key (HYOK).

---

Security Best Practices

Use VPC endpoint service connectivity -- never expose your proxy endpoint publicly unless absolutely necessary. The additional PrivateLink setup is worth the reduced attack surface.

Implement proxy-level authorization -- the requestMetadata in every KMS request includes the calling principal's ARN. Use this to enforce granular policies at the proxy layer: specific IAM roles can only use specific external keys, certain operations are blocked outside business hours, etc.

Rotate proxy authentication credentials on a defined schedule. Use AWS Secrets Manager to store and auto-rotate the secret access key used for KMS-to-proxy authentication.

Monitor and alert on all proxy errors -- specifically watch for XKS_PROXY_TIMED_OUT, XKS_PROXY_NOT_REACHABLE and INVALID_KEY_USAGE errors in CloudTrail. Any sustained error rate should trigger an incident response.

Key lifecycle management -- document explicit procedures for key rotation (your external key manager can rotate key material behind the same XksKeyId), key deletion (coordinate between KMS key deletion and external key deletion -- getting this order wrong causes permanent data loss) and emergency key revocation (your proxy is the kill switch: take it offline and all XKS operations cease).

Disaster recovery -- maintain a tested recovery runbook. If your external key manager suffers a catastrophic failure, you need to restore it and reconnect before any data encrypted with XKS keys becomes inaccessible permanently. Back up your external key material using your key manager's native backup mechanisms.

---

Common Challenges and Troubleshooting

Connection Errors

XKS_PROXY_NOT_REACHABLE -- KMS cannot reach the proxy endpoint. Check: network routing, security group rules, NLB health checks, proxy process status.

XKS_PROXY_TIMED_OUT -- Proxy reachable but not responding within the timeout. Check: proxy application logs, external key manager latency, proxy instance CPU/memory, network latency between proxy and key manager. If the round-trip time between the Region and your key manager is above 35 ms, AWS suggests moving the key store to a closer Region or the key manager closer to AWS.

XKS_PROXY_INVALID_RESPONSE -- Proxy responded but the response doesn't conform to the XKS API spec. Check proxy implementation for API version mismatches or serialization bugs.

Authentication Failures

XKS_PROXY_ACCESS_DENIED -- Credential mismatch between KMS and proxy configuration. Verify the AccessKeyId and RawSecretAccessKey match exactly on both sides. Credentials are case-sensitive.

Key Issues

XksKeyNotFoundException -- The XksKeyId you passed to CreateKey doesn't exist in your external key manager, or the proxy can't find it. Verify the key ID is the one the proxy uses to refer to the key.

XksKeyInvalidConfigurationException -- GetKeyMetadata returned a key that is not AES_256, not usable for [ENCRYPT, DECRYPT], or DISABLED in the external key manager. This is independent of the KMS key's enabled status. Fix it at the source.

KMSInvalidStateException on encrypt or decrypt -- AWS KMS cryptographic operations return this exception for every failure related to the external key store's configuration or connection state. Read the error message text to find the cause (AWS: Troubleshooting external key stores).

Debugging Tools

# Check connection state and error codes
aws kms describe-custom-key-stores \
  --custom-key-store-id cks-1234567890abcdef0

# CloudTrail -- filter for XKS-related errors
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=kms.amazonaws.com \
  --start-time 2026-01-01T00:00:00Z

Enable proxy-level access logging and correlate proxy logs with CloudTrail events using the requestId field present in both.

---

Compliance and Audit Considerations

XKS creates a more complex audit trail than standard KMS, but a more complete one -- if you instrument it correctly.

CloudTrail logs every KMS API call involving XKS keys, including the calling principal, key ARN and operation result. This is your primary audit artifact for demonstrating key usage control to regulators.

Proxy-level logs capture every request forwarded from KMS to your external key manager. When configured to log the requestMetadata (which includes the original AWS principal ARN), you have an end-to-end audit trail from AWS service call through to cryptographic operation.

External key manager audit logs provide the authoritative record of which keys were used, when and by which proxy identity.

For GDPR / Schrems II compliance, document:

• Physical location of the external key manager
• Access control policies on the external key manager
• Network path from AWS to proxy (VPC endpoint service is ideal)
• Key backup and recovery procedures that maintain geographic restrictions
• Incident response procedures for key compromise

For PCI-DSS, ensure the external key manager meets key management requirements under PCI-DSS v4.0 Requirement 3.7, including dual control and split knowledge procedures for key custodians.

---

FAQ

Q: What is AWS XKS?

AWS XKS (External Key Store) is a feature of AWS KMS that lets you use encryption keys stored and managed entirely outside AWS infrastructure. Your keys live in your external key manager; AWS calls out to your XKS proxy whenever it needs to perform cryptographic operations.

Q: When do I need XKS instead of standard KMS?

When regulations or organizational policies explicitly require that cryptographic key material never reside on third-party (including cloud provider) infrastructure. Common drivers include GDPR + Schrems II for EU data sovereignty, CLOUD Act mitigation and certain financial sector mandates. For most HIPAA, PCI-DSS and SOC 2 requirements, standard CMKs are sufficient.

Q: What is an XKS proxy?

The XKS proxy is middleware you own and operate. It sits between AWS KMS and your external key manager, translating AWS XKS API requests into your key manager's native protocol. It also provides an additional authorization layer and acts as a kill switch -- disable the proxy and all XKS encrypt/decrypt operations stop.

Q: What happens if my external key manager goes down?

AWS services that rely on XKS-backed keys will be unable to perform new encrypt or decrypt operations. Some services (like S3 with bucket keys enabled) cache data keys for a few minutes, providing brief resilience. But a sustained outage means your AWS workloads cannot process encrypted data. High availability is non-negotiable.

Q: Can I use XKS with all AWS services?

AWS states that services which support customer managed keys for symmetric encryption also support KMS keys in an external key store, including S3, EBS and RDS. Always verify your specific service and AWS Region against the current documentation before design commitment.

Q: Does XKS cost more than a standard KMS key?

Not on the AWS bill: AWS KMS prices keys in an external key store the same as standard KMS keys. The extra cost is everything you run yourself: the external key manager, the XKS proxy, load balancing and network links, and the people who operate them.

Q: What latency does an AWS external key store need?

The XKS proxy has to answer each call within 250 ms or AWS KMS times out, and the specification asks for a ping latency of 35 ms or less between the AWS Region and your key manager. Place the key store in the Region closest to your key manager.

Q: Which vendors offer an XKS proxy?

You can build one from AWS's open specification and Rust sample, or use a vendor proxy. Thales, Fortanix, Entrust and Securosys publish XKS integrations, and DuoKey ships an XKS proxy built into DuoKey Cockpit, with an MPC vault among its key backends. See XKS Proxy Options.

Q: Is XKS the same as CloudHSM?

No. CloudHSM provides dedicated hardware HSMs physically located in AWS data centers, but under your exclusive control. XKS takes this further -- your key material lives in infrastructure you operate, outside AWS-owned facilities entirely. XKS has higher operational complexity, higher total cost and higher latency than CloudHSM.

Q: Is XKS the same as BYOK with imported key material?

No. With imported key material, you generate the key and import it, and AWS KMS then holds and uses it inside its own HSMs. That is BYOK. With XKS, the key material never leaves your external key manager and every operation goes through your proxy, which is the hold-your-own-key model. See what BYOK is and BYOK vs HYOK.

Q: How does key rotation work with XKS?

Rotation is more complex than standard KMS. You cannot use KMS automatic key rotation for XKS keys, and you cannot change the XksKeyId attached to a KMS key. Instead, your external key manager rotates the key material associated with the same XksKeyId -- AWS KMS continues referencing the same key ID and your key manager transparently uses the new key material. Coordinate rotation procedures carefully between your key manager operations team and your AWS team.

Q: Can I migrate existing KMS-encrypted data to XKS?

Not directly. There is no re-encryption path that moves existing CMK-encrypted data to XKS without decrypting and re-encrypting each object. For S3, this means iterating through all objects; for EBS volumes, you'd need snapshot-and-restore workflows. Plan migration carefully and budget significant time and cost for large datasets.

---

Conclusion: Is XKS Right for You?

XKS is purpose-built for a narrow, specific compliance scenario. It delivers on its promise -- cryptographic key material under your exclusive control, outside AWS infrastructure -- but at the cost of significant operational complexity, higher latency and substantially higher costs.

Use this checklist before committing:

• Your legal or compliance team has explicitly confirmed that regulations require key material to reside outside cloud provider infrastructure (not just "strong key control" generally)
• You have identified a compatible external key manager and a viable XKS proxy deployment
• You can sustain sub-250ms round-trip latency from your proxy to external key manager
• You have the operational capability to run a highly available key management service
• You have budgeted for the key manager, the proxy, the network links and the on-call team, not just the KMS bill
• You have a tested disaster recovery plan for key manager outages
• You have audited which AWS services you use and confirmed XKS support for each

If you can check all of these, XKS is a well-designed solution to a hard problem. If you're checking fewer than four, take another look at CloudHSM or well-governed CMKs -- they may satisfy your actual requirements with far less operational burden.

---

Further reading

• Hold your own key (HYOK)
• AWS KMS custom key store: CloudHSM vs XKS
• DuoKey for AWS XKS

---

References

• AWS KMS External Key Store -- Official Documentation
• Announcing AWS KMS External Key Store -- AWS Security Blog
• AWS KMS External Key Store Proxy API Specification (GitHub)
• AWS XKS Proxy Reference Implementation (GitHub)
• AWS KMS: Troubleshooting external key stores
• DuoKey Docs: AWS XKS Overview
• AWS Digital Sovereignty Pledge
• NIST SP 800-57: Key Management Guidelines
• PCI-DSS v4.0 Key Management Requirements
• GDPR Article 32 -- Security of Processing
• Fortanix DSM XKS Integration
• Thales CipherTrust XKS Solution
• AWS Well-Architected Framework -- Security Pillar
• Cloud Security Alliance: Cloud Key Management Guidelines