Cloud Sovereignty Deep Dive - AWS KMS Control Plane Analysis

The Problem

A common assumption is that AWS External Key Store (XKS) provides complete sovereignty over encryption keys because the key material never leaves the customer’s HSM. But there’s a gap between key material protection (can’t be extracted) and key usage control (can still be used under legal compulsion).

AWS documentation emphasizes what IS protected without clarifying what ISN’T. Security architects need to understand the real trust boundaries before designing encryption strategies.

Update (February 2026): The AWS European Sovereign Cloud went GA on January 14, 2026. This significantly changes the risk calculus for European customers. See the dedicated section below.

TL;DR

• XKS protects key material (cannot be extracted) but not key usage (can still be used under legal compulsion)
• The KMS control plane sits between your IAM policies and your external HSM—AWS controls this layer
• AWS European Sovereign Cloud now offers a middle ground: EU legal entity, EU-only operators, no non-EU dependencies
• True sovereignty requires client-side encryption where AWS never sees plaintext or keys
• For most workloads, European Sovereign Cloud + XKS is now the pragmatic choice for regulated European data
• Cost jumps significantly: KMS ~$15k/3Y → XKS ~$450k/3Y → Client-side ~$650k/3Y

Who Should Read This

Role	Why This Matters
Security Architects	Understand the real trust boundaries before designing encryption strategies
CISOs	Make informed risk decisions about cloud sovereignty claims
Compliance Officers	Know what “customer-controlled keys” actually means for audit purposes
CTOs / Tech Leaders	Evaluate cloud adoption for regulated or sensitive workloads

The Solution

Map the full control flow (not just data flow) and choose the appropriate level of protection based on data classification and risk tolerance.

How It Works

The Trust Boundary Analysis

Even with XKS, the control flow is:

┌─────────────────────────────────────────────────────────────────┐
│                    AWS CONTROL PLANE                            │
│                                                                 │
│   ┌─────────────┐      ┌─────────────┐      ┌─────────────┐    │
│   │ IAM Policy  │ ──►  │     KMS     │ ──►  │   XKS/HSM   │    │
│   │             │      │   Service   │      │  (customer) │    │
│   └─────────────┘      └─────────────┘      └─────────────┘    │
│                                                                 │
│   Customer controls     AWS controls        Customer controls   │
│   (via console)         (infrastructure)    (key material)     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

The gap: The KMS service layer sits between IAM policy evaluation and the external HSM. This service layer is AWS-controlled infrastructure.

Detailed Attack Surface (Standard AWS Regions)

                        LEGAL COMPULSION SCENARIO
                        ========================

┌──────────────────────────────────────────────────────────────────────┐
│                        AWS INFRASTRUCTURE                            │
│                        (US jurisdiction)                             │
│                                                                      │
│   NORMAL FLOW:                                                       │
│   ┌─────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────┐  │
│   │  Your   │───►│ IAM Policy  │───►│     KMS     │───►│   XKS   │──┼─►
│   │  App    │    │ Evaluation  │    │   Service   │    │  Proxy  │  │
│   └─────────┘    └─────────────┘    └─────────────┘    └─────────┘  │
│                                                                      │
│   COMPELLED FLOW:                                                    │
│   ┌─────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────┐  │
│   │ Gov/NSA │───►│  BYPASSED   │───►│   Modified  │───►│   XKS   │──┼─►
│   │ Request │    │             │    │     KMS     │    │  Proxy  │  │
│   └─────────┘    └─────────────┘    └─────────────┘    └─────────┘  │
└──────────────────────────────────────────────────────────────────────┘
                                                              │
┌─────────────────────────────────────────────────────────────┼────────┐
│                      YOUR INFRASTRUCTURE                    │        │
│                                                             ▼        │
│   XKS Proxy receives valid KMS request ─────────────► ┌──────────┐  │
│   HSM has no way to know it's unauthorized            │   HSM    │  │
│   HSM responds with decryption ◄──────────────────────│          │  │
│                                                       └──────────┘  │
│   ⚠️  KEY MATERIAL PROTECTED                                        │
│   ❌  KEY USAGE NOT PROTECTED                                       │
└─────────────────────────────────────────────────────────────────────┘

What XKS Protects Against

Threat	XKS Effective?
Key extraction (copying key material)	✅ Yes
Rogue AWS employee accessing keys	✅ Partially
Physical data center seizure	✅ Yes
Legal compulsion to USE keys	❌ No
AWS control plane modification	❌ No

The Mechanism

If a government compels AWS to modify the KMS control plane:

1. An unauthorized principal could be injected at the service level
2. KMS receives the decrypt request
3. KMS calls the customer’s XKS Proxy
4. The XKS Proxy sees a valid KMS request → responds
5. Data is decrypted

The key material was never extracted, but the key was used.

Legal Framework

Law	Scope
CLOUD Act (2018)	US gov can compel US companies to provide data stored anywhere
FISA Section 702	Surveillance of non-US persons
National Security Letters	Secret demands with gag orders

Key point: AWS is a US legal entity → subject to US jurisdiction regardless of data location, customer location, or “Sovereign Cloud” branding.

The Business Deterrent

The legal framework above describes what’s theoretically possible. But there’s a powerful counter-force: economic reality.

If AWS were caught complying with secret government orders to decrypt European customer data:

Consequence	Impact
Immediate trust collapse	Enterprise customers would flee overnight
Regulatory retaliation	EU could ban AWS operations entirely
Competitor advantage	Every non-US cloud provider gains massively
Revenue destruction	AWS’s ~$100B annual revenue at existential risk

The game theory: A US government demand to secretly decrypt European enterprise data would effectively be asking AWS to commit business suicide. The rational response is to fight such orders in court, restructure to make compliance impossible, or accept contempt charges rather than comply.

This isn’t naive optimism—it’s economic deterrence. The same logic that prevents nuclear powers from using their weapons: the cost of action exceeds any possible benefit.

The “canary” evidence: No major hyperscaler has ever been publicly caught complying with secret decryption orders for enterprise customers. Given the scale of investigative journalism, whistleblower incentives, and warrant canary monitoring, a major incident would likely surface. The absence of evidence isn’t proof, but it’s meaningful signal.

Bottom line: The legal compulsion risk is real but heavily mitigated by business incentives. AWS has more to lose from compliance than from resistance.

AWS European Sovereign Cloud (January 2026)

The AWS European Sovereign Cloud went generally available on January 14, 2026. This represents AWS’s most significant sovereignty investment: €7.8 billion in infrastructure, jobs, and skills development.

What’s Different

Aspect	Standard AWS Regions	European Sovereign Cloud
Legal entity	Amazon Web Services, Inc. (US)	Dedicated EU legal entity (German law)
Operators	Global AWS staff	EU citizens located in EU only
Management	US-based leadership	EU-resident managing directors
Oversight	Standard AWS governance	Independent advisory board (EU citizens)
Infrastructure	Global dependencies	No critical non-EU dependencies
Metadata	May leave region	Stays in EU (IAM, configs, labels)
Isolation	Logical separation	Physical AND logical separation
Resilience	Connected to global AWS	Can operate if isolated from world

Architecture

┌─────────────────────────────────────────────────────────────────────┐
│              AWS EUROPEAN SOVEREIGN CLOUD                           │
│              (EU jurisdiction - German law)                         │
│                                                                     │
│   ┌─────────────────────────────────────────────────────────────┐  │
│   │  Partition: aws-eusc    Region: eusc-de-east-1              │  │
│   │                                                              │  │
│   │  • Dedicated IAM system (EU-only)                           │  │
│   │  • Dedicated billing system (EUR, EU currencies)            │  │
│   │  • European Trust Service Provider for certificates         │  │
│   │  • European TLDs for Route 53 nameservers                   │  │
│   │  • Technical controls block non-EU access                   │  │
│   └─────────────────────────────────────────────────────────────┘  │
│                                                                     │
│   Operated by: EU citizens in EU                                    │
│   Managed by: Stéphane Israël, Stefan Hoechbauer (EU residents)    │
│   Oversight: Independent EU advisory board                          │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘
         │
         │ No critical dependencies
         ▼
    Can operate indefinitely even if isolated from global AWS

The Sovereignty Investment

The €7.8B investment isn’t just infrastructure—it’s AWS buying legal and jurisdictional separation. They’re creating a defensible position against future legal compulsion:

• Different legal entity → US courts can’t directly compel an EU company
• EU-only operators → No US persons with access to compel
• No non-EU dependencies → Can’t be forced via infrastructure control
• Independent oversight → Advisory board adds accountability layer

This is essentially an insurance policy. AWS is paying billions to be able to say: “We literally cannot comply—different legal entity, EU-only staff, no access path.”

What This Means for XKS

The European Sovereign Cloud includes AWS KMS. Combined with XKS:

┌─────────────────────────────────────────────────────────────────────┐
│              AWS EUROPEAN SOVEREIGN CLOUD                           │
│              (EU jurisdiction)                                      │
│                                                                     │
│   ┌─────────────┐      ┌─────────────┐      ┌─────────────┐        │
│   │ IAM Policy  │ ──►  │     KMS     │ ──►  │   XKS/HSM   │        │
│   │  (EU-only)  │      │  (EU-only)  │      │  (customer) │        │
│   └─────────────┘      └─────────────┘      └─────────────┘        │
│                                                                     │
│   EU legal entity       EU operators        Customer controls       │
│   EU oversight          EU jurisdiction     key material           │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

The improvement: Even the control plane is now under EU jurisdiction, operated by EU citizens, with no US access path. The theoretical “compelled flow” attack surface is dramatically reduced.

Services Available

The European Sovereign Cloud launched with comprehensive services including:

• Compute: EC2, Lambda, EKS, ECS
• Database: Aurora, DynamoDB, RDS
• Storage: S3, EBS
• AI/ML: SageMaker, Bedrock
• Security: KMS, Private CA, IAM
• Networking: VPC, Route 53

Expansion planned with Local Zones in Belgium, Netherlands, and Portugal.

True Sovereignty Options

Option 1: Client-Side Encryption

┌──────────────┐     ┌─────────────┐     ┌─────────────┐
│ Application  │────►│ Customer    │────►│    AWS      │
│              │     │ HSM         │     │  (ciphertext│
│ Encrypt here │     │ (on-prem)   │     │   only)     │
└──────────────┘     └─────────────┘     └─────────────┘

KMS never involved. AWS stores ciphertext only. Even under compulsion, AWS cannot decrypt.

Option 2: European Sovereign Cloud + XKS

Best of both worlds for European customers:

• EU jurisdiction for control plane
• Customer-controlled key material
• Full AWS service portfolio
• Monitoring capability on XKS Proxy

Option 3: XKS Proxy with Customer Authentication

Customer adds monitoring to the XKS Proxy:

• Request allowlisting
• Anomaly detection
• Rate limiting
• Kill switch

Can detect and block unusual access patterns.

Option 4: Split-Knowledge / Quorum

Both AWS and customer hold separate keys. Neither party can decrypt alone.

Cost Comparison (3-Year TCO)

Approach	3Y Total	Sovereignty Level
KMS (managed)	~$9k	⚠️ Low
KMS (CMK)	~$15k	⚠️ Low
CloudHSM	~$170k	🔶 Medium
European Sovereign Cloud + KMS	~$20k*	🔷 High
XKS + HSM	~$440k	🔷 High
European Sovereign Cloud + XKS	~$460k*	✅ Very High
Client-side	~$660k	✅ Very High

*Pricing in EUR, similar to standard regions. Check AWS European Sovereign Cloud pricing for current rates.

Recommendation Matrix

Data Classification	Recommended Approach
Public	AWS KMS (AWS-managed)
Internal	AWS KMS (Customer-managed CMK)
Confidential (EU)	European Sovereign Cloud + KMS
Confidential (non-EU)	XKS + monitored proxy
Secret/Regulated (EU)	European Sovereign Cloud + XKS
Secret/Regulated (non-EU)	Client-side encryption
Classified	On-premises only

XKS Proxy Monitoring

If using XKS, implement monitoring on your proxy:

def handle_kms_request(request):
    log_request(request)

    if request.source_arn not in ALLOWED_ARNS:
        alert("Unauthorized source")
        return DENY

    if get_request_rate() > THRESHOLD:
        alert("Unusual request volume")
        return DENY

    if not is_business_hours():
        alert("Off-hours access attempt")

    return forward_to_hsm(request)

What I Learned

• Marketing vs Architecture — “Sovereignty” features protect key material but may not protect against key usage under legal compulsion
• Trust Boundaries — Always map the full control flow, not just the data flow
• Defense in Depth — XKS is valuable but not sufficient alone for true sovereignty
• Documentation Gaps — Vendor documentation often emphasizes what IS protected without clarifying what ISN’T
• Economic Deterrence — Business incentives can be as powerful as technical controls
• Jurisdictional Engineering — The European Sovereign Cloud shows how infrastructure investment can create legal separation

My Take

The landscape has shifted. When I first analyzed this topic, the European Sovereign Cloud was still “in the works.” Now it’s GA, and it materially changes the risk calculus.

For European organizations with sovereignty requirements, the European Sovereign Cloud is now the default choice. The combination of EU legal entity, EU-only operators, independent oversight, and no non-EU dependencies addresses most practical concerns. Add XKS for defense in depth.

The business deterrent is underappreciated. Legal frameworks describe theoretical powers, but economic reality constrains their use. AWS complying with secret decryption orders for European enterprise customers would be business suicide—€100B+ in annual revenue at risk. This doesn’t make the risk zero, but it makes it extremely low.

Client-side encryption remains the gold standard for organizations that genuinely cannot accept any residual risk. But for most regulated European workloads, European Sovereign Cloud + XKS is now the pragmatic sweet spot.

The uncomfortable truth remains: Perfect sovereignty and cloud convenience are fundamentally at odds. But the gap has narrowed significantly. The European Sovereign Cloud isn’t just marketing—it’s €7.8B of infrastructure specifically designed to create jurisdictional separation.

My practical advice:

1. Classify your data honestly — Not everything is “secret”
2. Default to European Sovereign Cloud for regulated EU workloads
3. Add XKS for crown jewels — Defense in depth
4. Monitor aggressively — Detection > Prevention for most threats
5. Document your risk acceptance — Make it a conscious business decision

Do It Yourself

Key Takeaways

• XKS protects key material, not key usage — your keys cannot be extracted, but AWS infrastructure can still invoke them under legal compulsion. The European Sovereign Cloud mitigates this by placing the control plane under EU jurisdiction.
• Economic deterrence is powerful but not absolute — AWS has €100B+ reasons to resist secret decryption orders, but business incentives aren’t legal guarantees. For truly sensitive data, assume the worst case.
• Data classification drives architecture — not everything needs maximum sovereignty. Public/internal data can use standard KMS. Confidential EU data fits the European Sovereign Cloud. Crown jewels need client-side encryption or European Sovereign Cloud + XKS.

Try It Now

1. Map your data classification — categorize workloads into public, internal, confidential, secret. Use the recommendation matrix in this post to match each tier to an encryption approach.
2. Set up XKS with monitoring — deploy an XKS Proxy with request logging, allowlist validation, and rate limiting. Reference implementation: AWS XKS Proxy samples
3. Evaluate European Sovereign Cloud — if you have EU sovereignty requirements, check service availability for your workloads: AWS European Sovereign Cloud
4. Implement client-side encryption for crown jewels — use the AWS Encryption SDK for application-layer encryption before data touches AWS. Tutorial: Client-side encryption with AWS Encryption SDK
5. Test CloudHSM for on-premises key control — if you need a middle ground between KMS and full client-side, CloudHSM gives you dedicated hardware in AWS regions with FIPS 140-2 Level 3 validation. CloudHSM getting started guide

---

Updated February 2026 to reflect AWS European Sovereign Cloud general availability (January 14, 2026).