KMS vs CloudHSM: Choosing Correctly

KMS should be the default choice for the overwhelming majority of encryption key needs: it's fully managed, integrates natively across nearly every AWS service (S3, EBS, RDS encryption and more all use KMS directly), requires no cluster administration, and is priced per-key and per-API-call rather than requiring dedicated hardware provisioning. CloudHSM becomes the right choice specifically when one of a few concrete requirements exists: a compliance framework explicitly mandates single-tenant (not shared) hardware for key storage; an application requires direct access to standard cryptographic interfaces (PKCS#11, Java JCE, Microsoft CNG/KSP) that KMS's managed API doesn't expose; or a legacy system was built assuming direct HSM access and can't be easily adapted to KMS's API model. A common exam and real-world signal: if the scenario explicitly mentions 'dedicated hardware,' 'single-tenant HSM,' or a specific cryptographic standard interface requirement, that's pointing at CloudHSM; if it's a general 'encrypt this data at rest' requirement with no such specifics, KMS is almost always the right, simpler, cheaper answer.