AWS External Key Store (XKS): Achieve True Cloud Sovereignty

Table of Contents

1. What Is AWS External Key Store and Why Use It
2. AWS KMS vs XKS: Control and Sovereignty Compared
3. Architecture Requirements for XKS Deployment
4. Step-by-Step XKS Configuration Guide
5. Integrating XKS with S3, EBS, and RDS Encryption
6. Monitoring and Auditing Your External Key Store
7. Compliance Benefits: GDPR, DORA, and Sovereignty
8. Conclusion
9. References and Further Reading

For enterprises operating in regulated industries, the question of who controls encryption keys has become a board-level concern. The AWS External Key Store (XKS) addresses this directly by allowing organizations to maintain cryptographic keys outside of AWS infrastructure entirely—a capability that fundamentally changes the data sovereignty equation for cloud deployments.

Announced in late 2022 and now maturing into production-ready deployments across financial services, healthcare, and government sectors, XKS represents AWS's acknowledgment that some organizations cannot cede key custody to any cloud provider, regardless of contractual assurances. This technical guide walks enterprise security architects through the architecture, deployment, and compliance implications of implementing AWS XKS with external key management solutions.

What Is AWS External Key Store and Why Use It

AWS External Key Store is a custom key store type within AWS Key Management Service (KMS) that allows you to store and use encryption keys in an external key manager that you own and control. Unlike standard AWS KMS keys—which are generated, stored, and managed within AWS-controlled hardware security modules (HSMs)—XKS keys never exist inside AWS infrastructure.

The Technical Foundation

When you create an XKS-backed KMS key, AWS KMS communicates with your external key manager through a secure API proxy. Every cryptographic operation—encrypt, decrypt, sign, verify—requires a real-time call to your external key manager. AWS never caches or stores the key material; it serves only as an orchestration layer.

This architecture means:

• Key material remains exclusively in your custody at all times
• AWS cannot access your data even with a valid warrant or government request
• You retain the ability to revoke access instantaneously by disconnecting the external key store
• Cryptographic operations maintain full audit trails in your external key manager

When XKS Becomes Essential

Organizations typically adopt AWS External Key Store when standard AWS KMS falls short of their requirements:

Requirement	Standard KMS	XKS
Keys stored outside AWS	No	Yes
Cloud provider cannot access keys	No	Yes
Instant revocation capability	Limited	Full
Dual-control key management	No	Yes
Geographic key residency	AWS-controlled	Customer-controlled
Regulatory approval for sensitive workloads	Often insufficient	Meets strictest requirements

Financial institutions subject to DORA (Digital Operational Resilience Act), healthcare organizations processing PHI under strict HIPAA interpretations, and government contractors with sovereignty mandates increasingly find XKS to be the only architecture that satisfies auditor and regulator scrutiny.

AWS KMS vs XKS: Control and Sovereignty Compared

Understanding the distinction between standard AWS KMS and XKS requires examining where control actually resides across the key lifecycle.

Standard AWS KMS: Shared Custody

With standard AWS KMS, Amazon generates keys inside AWS-operated CloudHSM hardware. These HSMs are certified to FIPS 140-2 Level 3, and AWS implements rigorous operational controls. However, several sovereignty gaps remain:

1. AWS retains technical capability to access key material (even if policy prohibits it)
2. Key operations occur on AWS infrastructure, leaving metadata in AWS logs
3. Revocation depends on AWS policy enforcement, not physical control
4. Geographic residency is limited to AWS region availability

For many workloads, these tradeoffs are acceptable. For regulated industries handling European citizen data, financial transactions, or classified information, they often are not.

XKS: Genuine Key Sovereignty

The aws kms external key architecture through XKS inverts this model:

Control Point: Key Generation

• Standard KMS: AWS generates key material inside AWS HSMs
• XKS: You generate keys in your own HSM or key management system

Control Point: Key Storage

• Standard KMS: Key material encrypted and stored in AWS infrastructure
• XKS: Key material never leaves your external key manager

Control Point: Cryptographic Operations

• Standard KMS: Operations execute inside AWS HSMs
• XKS: Operations execute inside your external key manager via API calls

Control Point: Audit and Logging

• Standard KMS: CloudTrail logs (AWS-controlled)
• XKS: Your key manager logs + CloudTrail (dual visibility)

Control Point: Access Revocation

• Standard KMS: Requires AWS policy change propagation
• XKS: Disconnect XKS proxy = immediate, complete revocation

This aws data sovereignty model addresses the core concern: no single party—including AWS—can access your data without your ongoing, active cooperation.

The Trust Boundary Reality

Consider a scenario where a government authority serves AWS with a lawful data access request for encrypted S3 objects. With standard KMS, AWS can technically comply by using the customer's KMS key to decrypt the data. With XKS, AWS can only provide encrypted ciphertext—useless without access to your external key manager, which you control.

This is not a theoretical distinction. European regulators under GDPR's Schrems II implications, Swiss FINMA requirements, and emerging NIS2 mandates increasingly require organizations to demonstrate that cloud providers cannot unilaterally access protected data.

Architecture Requirements for XKS Deployment

Deploying XKS requires careful architecture planning across network, compute, and cryptographic components. The system must meet stringent availability and latency requirements while maintaining security boundaries.

Core Infrastructure Components

A production XKS deployment requires four primary components:

1. External Key Manager Your HSM or software-based key management system that generates, stores, and performs cryptographic operations on key material. This must support the XKS Proxy API specification.

Compatible external key managers include:

• DuoKey's MPC-based key management platform
• Thales CipherTrust Manager
• Fortanix SDKMS
• HashiCorp Vault Enterprise (with XKS plugin)
• nCipher nShield HSMs

2. XKS Proxy A middleware component that translates AWS KMS API calls into your external key manager's native API. The proxy handles authentication, request routing, and response formatting.

3. Network Connectivity Private, low-latency connectivity between AWS and your external key manager. Options include:

• AWS PrivateLink (recommended for most deployments)
• VPN over AWS Direct Connect
• Public endpoint with mutual TLS (higher latency, less recommended)

4. Authentication and Authorization Mutual TLS certificates, SigV4 request signing, and your key manager's access control policies working together to authorize every cryptographic operation.

Network Architecture Patterns

The network topology for external key management AWS implementations directly impacts both security posture and operational performance.

Pattern A: Private Endpoint via VPC

AWS Region
├── Customer VPC
│   ├── VPC Endpoint (Interface) for KMS
│   └── PrivateLink Connection
│       └── XKS Proxy (customer network)
│           └── External Key Manager (customer data center)

This pattern keeps all traffic on private networks, eliminating internet exposure. Recommended for financial services and healthcare deployments.

Pattern B: Direct Connect Integration

For organizations with existing AWS Direct Connect circuits, XKS traffic can traverse the same private connectivity used for other hybrid workloads. This reduces incremental infrastructure costs and leverages existing security controls.

Latency and Availability Requirements

XKS imposes strict performance requirements because every AWS encryption operation depends on real-time external key manager responses:

Metric	Requirement	Recommendation
API Latency (P99)	< 250ms	< 100ms for production
Availability	99.99%	Deploy across multiple availability zones
Request Timeout	250ms	Ensure network path supports sub-100ms RTT
Concurrent Connections	Varies by workload	Load test before production

Failing to meet these requirements results in failed encryption/decryption operations, which cascade into application errors. Design for at least 99.99% availability with automatic failover between external key manager instances.

Security Boundary Considerations

When architecting XKS, define clear security boundaries:

1. Network Segmentation: XKS proxy should reside in a dedicated network segment with strict firewall rules permitting only AWS KMS endpoints and your external key manager
2. Certificate Management: Mutual TLS certificates must be rotated regularly and stored in HSM-protected keystores
3. Access Logging: Every XKS API call should generate audit logs in both AWS CloudTrail and your external key manager
4. Failover Strategy: Define explicit procedures for XKS proxy failure scenarios

Step-by-Step XKS Configuration Guide

This aws xks setup guide walks through the technical configuration process, from prerequisites through validation testing.

Prerequisites Checklist

Before beginning configuration, verify:

• External key manager deployed and operational
• XKS proxy component installed and configured
• Network connectivity established between AWS and XKS proxy
• Mutual TLS certificates generated and deployed
• IAM permissions for KMS custom key store operations
• AWS CLI v2 or AWS SDK configured

Step 1: Configure Your External Key Manager

First, create the key material that will back your XKS keys. In your external key manager:

1. Generate a 256-bit AES key (for symmetric encryption) or RSA/ECC key pair (for asymmetric operations)
2. Assign a unique key identifier that AWS KMS will reference
3. Configure access policies permitting the XKS proxy's authentication credentials
4. Enable audit logging for all operations on this key

Step 2: Deploy and Configure the XKS Proxy

The XKS proxy must implement AWS's XKS Proxy API specification. Configuration typically includes:

# Example XKS proxy configuration
proxy:
  listen_address: "0.0.0.0:443"
  tls:
    certificate: "/etc/xks/proxy-cert.pem"
    private_key: "/etc/xks/proxy-key.pem"
    client_ca: "/etc/xks/aws-ca.pem"
  
external_key_manager:
  endpoint: "https://keymanager.internal:8443"
  authentication:
    type: "mutual_tls"
    certificate: "/etc/xks/client-cert.pem"
    private_key: "/etc/xks/client-key.pem"
  
  key_mapping:
    # Maps AWS key IDs to external key manager key IDs
    aws_key_prefix: "xks-"

Step 3: Create the External Key Store in AWS KMS

Using the AWS CLI:

aws kms create-custom-key-store \
  --custom-key-store-name "production-xks" \
  --custom-key-store-type "EXTERNAL_KEY_STORE" \
  --xks-proxy-uri-endpoint "https://xks-proxy.example.com:443" \
  --xks-proxy-uri-path "/kms/xks/v1" \
  --xks-proxy-authentication-credential '{
    "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
    "RawSecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
  }' \
  --xks-proxy-connectivity "VPC_ENDPOINT_SERVICE" \
  --xks-proxy-vpc-endpoint-service-name "com.amazonaws.vpce.eu-west-1.vpce-svc-0123456789abcdef0"

Step 4: Connect the External Key Store

After creation, explicitly connect the key store:

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

AWS KMS will validate connectivity to your XKS proxy. Monitor the connection status:

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

Successful connection shows ConnectionState: CONNECTED.

Step 5: Create KMS Keys Backed by External Keys

With the custom key store connected, create KMS keys that use your external key material:

aws kms create-key \
  --origin "EXTERNAL_KEY_STORE" \
  --custom-key-store-id "cks-1234567890abcdef0" \
  --xks-key-id "external-key-manager-key-id-123" \
  --description "Production encryption key backed by external KM"

The --xks-key-id parameter references the key identifier in your external key manager.

Step 6: Validate End-to-End Encryption

Test the complete encryption path:

# Encrypt test data
aws kms encrypt \
  --key-id "arn:aws:kms:eu-west-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" \
  --plaintext "SGVsbG8gV29ybGQ=" \
  --output text \
  --query CiphertextBlob

# Decrypt and verify
aws kms decrypt \
  --ciphertext-blob fileb://encrypted.bin \
  --output text \
  --query