AWS re:Invent 2025 - KMS over the decade: How architecture evolved to earn customer trust-SEC218

AWS re:Invent 2025 - KMS over the Decade: How Architecture Evolved to Earn Customer Trust

Introduction

• Presented by Kevin Lee, Senior Product Manager at AWS, and Samuel Weimoth, Security and Compliance Specialist from the UK
• Covers the evolution of the AWS Key Management Service (KMS) over the years and how it has been designed to earn customer trust

The Need for KMS

• 10 years ago, cloud computing was gaining momentum, and regulated industries were migrating workloads to the cloud
• Encryption was common, but key management was not, with services like S3 and EBS managing keys themselves
• Trying to offer traditional key management in the cloud didn't make sense, as users are authenticated and authorized differently, and HSMs require specialized interfaces

KMS Design Principles

• Security, durability, and availability were the three key design tenets for KMS
• Transparency was also crucial to earn customer trust, including public documentation, independent auditing, and compliance with standards like FIPS 140-3

KMS Architecture and Capabilities

• Highly scalable, processing over 30 billion cryptographic requests per hour
• Provides 99.999% SLA for critical workloads
• Integrated with many AWS services through transparent server-side encryption
• Also available in some SaaS products, allowing customers to bring their own KMS keys

Customer Perspectives on Key Control

• Customers have different interpretations of what it means to "control" encryption keys
• Some are comfortable with the cloud-native approach, while others believe physical ownership of keys is crucial
• AWS has designed its products and services to prevent anyone but the customer and authorized users from accessing content and keys

Key Import and Custom Key Stores

• KMS launched the "Import Key" feature to allow customers to manage their own keys within an HSM they control
• Challenges included key rotation complexity and operational overhead of managing many keys
• Custom Key Stores allow customers to bring their own external key manager and connect it to KMS, but this introduces scalability and availability issues

The KMS HSM

• AWS has invested in developing its own FIPS 140-3 Level 3 certified HSM hardware and firmware
• The HSM has no concept of tenancy, with each request handled independently and keys never stored permanently
• Rigorous processes and controls are in place to ensure software integrity and prevent unauthorized access

External Key Stores (XKS)

• XKS allows customers to use their on-premises HSM with KMS, acting as a proxy
• Introduced to accommodate customers with unreasonable demands, but comes with significant scalability and availability challenges
• Ideal use case is for initial migration, but not recommended for long-term use

Digital Sovereignty and Encryption

• Digital sovereignty encompasses data residency, operator access restrictions, resiliency, and independence/transparency
• KMS and encryption can help address these requirements by ensuring data and keys remain within a specific region and are inaccessible to unauthorized parties

European Sovereign Cloud

• AWS has invested heavily (around $8 billion) to build a dedicated European Sovereign Cloud partition
• Separate infrastructure, operations, and personnel from the commercial AWS cloud
• Contractual, organizational, and technical measures to ensure data and operations remain within the EU and under EU control

Conclusion

• KMS has evolved to provide customers with more control over their encryption keys while maintaining security, scalability, and availability
• Customers should carefully evaluate the trade-offs of different key management options and understand the business impact
• AWS is committed to transparency and earning customer trust, including through the European Sovereign Cloud offering