Most SCS-C02 data-protection questions expect one reflex: encrypt with AWS KMS, tighten the key policy, done. Then the exam hands you a scenario where that reflex is not enough — a regulator or an internal policy says the key material must live in single-tenant hardware you control, or even outside AWS entirely, and you must still let AWS services like Amazon S3, Amazon EBS, and Amazon RDS encrypt against those keys as if they were ordinary KMS keys. That is exactly what KMS custom key stores exist for, and the exam rewards candidates who can tell the four “where does the key material live” options apart under scenario pressure.
This guide walks custom key stores the way the SCS-C02 frames them: the key material origin spectrum, how an AWS CloudHSM key store and an external key store (XKS) split the KMS control plane from a data plane you own, the prerequisites and failure modes that show up as distractors, and the one discriminator candidates get wrong — the belief that “CloudHSM means a higher FIPS level than KMS.” If envelope encryption, data keys, and key policies still feel shaky, read the SCS-C02 KMS and data protection guide first; this post assumes that foundation and focuses entirely on where keys physically live and who controls the HSM.
Where AWS KMS Key Material Normally Lives
By default, when you create a KMS key, AWS generates the key material inside AWS-owned, multi-tenant hardware security modules (HSMs) and never lets it leave those HSMs in plaintext. You never see the raw key; you call Encrypt, Decrypt, GenerateDataKey, and friends, and the HSM does the cryptography. This default store is managed entirely by AWS: availability, durability across multiple Availability Zones, patching, and scaling are all AWS’s responsibility.
The property that changes when you reach for a custom key store is not the strength of the cryptography and not the FIPS validation level — it is who owns and controls the HSM, and where the key material and the cryptographic operations physically happen. The exam builds its custom-key-store questions on that distinction, so anchor on it.
The Four Key Material Origin Values
Every KMS key has an origin attribute that tells you where its key material came from. Memorizing these four values is the fastest way to answer a whole class of SCS-C02 questions, because a scenario’s requirement usually maps to exactly one origin.
| Origin value | Where key material is generated / stored | Who controls the HSM | Typical driver |
|---|---|---|---|
AWS_KMS (default) | AWS-owned multi-tenant KMS HSMs | AWS | Default; simplest, fully managed |
EXTERNAL | You generate it outside AWS and import it into KMS | AWS (stored in KMS HSMs after import) | “We must generate key material ourselves” / bring-your-own-key |
AWS_CLOUDHSM | Your AWS CloudHSM cluster (single-tenant) | You (dedicated CloudHSM cluster) | Single-tenant, dedicated, customer-controlled HSM |
EXTERNAL_KEY_STORE | Your external key manager outside AWS | You (your own key management system) | Key material must never live inside AWS |
The first two keys still live inside AWS HSMs. The last two are custom key stores — the KMS key is a metadata object and policy surface inside KMS, but the actual key material sits in an HSM you are responsible for.
Imported Key Material (EXTERNAL Origin) in One Paragraph
Before custom key stores, know the EXTERNAL origin, because the exam likes to contrast it with them. With imported key material (sometimes called bring-your-own-key), you create a KMS key with Origin=EXTERNAL, download a public wrapping key and import token from KMS, wrap your own key material, and upload it. AWS then stores that material in its own HSMs — so you controlled generation but AWS still controls the HSM. Imported keys carry real operational weight: KMS cannot rotate them automatically, you must keep a copy of the material outside AWS (KMS does not retain a re-importable copy), and you can set them to expire. When a scenario says “we must generate the key ourselves” but says nothing about a dedicated or external HSM, the answer is imported key material, not a custom key store. When the scenario insists on where the HSM lives, you are into custom-key-store territory.
Custom Key Stores: KMS Control Plane, Your Data Plane
A custom key store keeps the familiar KMS front door — the same API calls, the same key policies, the same grants, the same integration with S3, EBS, RDS, Secrets Manager, and every other service that takes a KMS key ARN — while relocating the HSM that performs the cryptography out of AWS’s default fleet and into hardware you own or control. KMS becomes the control plane (identity, authorization, auditing through AWS CloudTrail, metadata); your HSM becomes the data plane (key storage and cryptographic operations).
There are two kinds, and telling them apart is the core exam skill:
- AWS CloudHSM key store — backed by an AWS CloudHSM cluster in your account. Single-tenant, dedicated HSMs, but still inside AWS.
- External key store (XKS) — backed by a key manager outside AWS, reached through a proxy you run. The key material never enters AWS at all.
Both add operational responsibility. With the default store, AWS owns availability and durability. With either custom key store, you own the availability, latency, and durability of the backing HSM, and if that backing store is unreachable, KMS operations against those keys fail.
AWS CloudHSM Key Stores
An AWS CloudHSM key store associates one KMS custom key store with exactly one AWS CloudHSM cluster in the same account and Region. When you create a KMS key in the key store, KMS creates the key’s metadata (ID, ARN, policy) in KMS and creates the actual key material in the HSMs of your cluster. Cryptographic operations for those keys are performed in your cluster, not in the shared KMS fleet, giving you dedicated, single-tenant hardware while keeping the KMS integration surface intact.
Prerequisites the Exam Turns Into Distractors
The CloudHSM cluster you attach must meet a specific checklist, and half of these appear as wrong answers or “why did the connection fail” scenarios:
- The cluster must be active — created, initialized, client software installed, and activated.
- At least two active HSMs, in different Availability Zones. This is a favorite exam number. A single-HSM cluster cannot back a key store.
- Private subnets in at least two AZs. Deleting one of those subnets later breaks the connection with a
SUBNET_NOT_FOUNDerror. - A dedicated
kmsusercrypto user (CU) must exist in the cluster, created without the 2FA option — KMS logs in askmsuser(and rotates its password on connect) to manage keys. Enabling 2FA onkmsuseris irreversible and blocks the connection. - The trust anchor certificate (
customerCA.crt, generated when you initialized the cluster) must be uploaded to KMS. - Mutual TLS (mTLS) must not be enabled on the cluster; KMS does not support it.
- One cluster per key store — the cluster cannot already back another custom key store, and KMS keys are not interoperable across clusters even when they share a backing key.
- KMS cannot communicate over IPv6 with CloudHSM key stores.
Creating and Connecting
You create the key store with CreateCustomKeyStore, passing the cluster ID, the kmsuser password, and the trust anchor certificate:
aws kms create-custom-key-store \
--custom-key-store-name ExampleCloudHSMKeyStore \
--cloud-hsm-cluster-id cluster-1a23b4cdefg \
--key-store-password <kmsuser-password> \
--trust-anchor-certificate file://customerCA.crtA new key store is created disconnected. Before you can create keys in it, you connect it to its cluster:
aws kms connect-custom-key-store --custom-key-store-id cks-1234567890abcdef0Then you create keys with the custom key store ID and Origin=AWS_CLOUDHSM. One constraint worth memorizing: KMS keys in a CloudHSM key store are symmetric encryption keys only — no asymmetric keys, no HMAC keys, no automatic key rotation for these keys. If a scenario needs an asymmetric key pair, a CloudHSM key store is the wrong answer.
The Operational Trade-off
Because the key material lives in your cluster, you own its availability and durability. If you disconnect the key store, or the cluster loses quorum, every KMS operation against keys in that store fails until it is reconnected — S3 objects will not decrypt, encrypted EBS volumes will not mount, and so on. That “disconnect the key store to make all keys instantly unusable” behavior is both a legitimate emergency control (a fast, reversible way to suspend use of every key at once) and a common exam scenario. Contrast it with the default store, where AWS guarantees the HSMs are always available.
External Key Stores (XKS)
An external key store takes the idea one step further: the key material and the cryptographic operations live in a key manager entirely outside AWS — an on-premises HSM, a third-party key management appliance, or another provider’s key manager. This is the answer for the hardest data-sovereignty requirement: “the key material must never reside within AWS, and we must be able to cut off AWS’s access ourselves.” KMS keys created here have Origin=EXTERNAL_KEY_STORE.
The XKS Proxy and Its Connectivity
AWS KMS never talks to your external key manager directly. It sends every cryptographic request to an external key store proxy (XKS proxy) that you deploy and operate, which translates KMS’s requests into calls to your key manager. The proxy is the seam, and it authenticates KMS using mutual TLS. There are two connectivity models, and the exam expects you to know both:
| Connectivity | How KMS reaches the proxy | When to choose it |
|---|---|---|
| Public endpoint | Over the public internet to a public proxy URI, secured with mTLS | Simpler; acceptable when the proxy can be safely exposed with strong auth |
| VPC endpoint service | Privately through AWS PrivateLink, no internet exposure | Keep proxy traffic off the public internet; typical for stricter networks |
What Lives Where — and Who Owns Availability
With XKS, all cryptographic operations happen in your external key manager; AWS KMS is purely a control plane and audit surface. That has two consequences the exam leans on:
- AWS never has your key material. You can revoke access at the proxy or in your key manager and AWS immediately loses the ability to use those keys.
- You own availability, latency, and durability — completely. If your proxy or external key manager is unreachable, the keys are unusable. AWS makes this explicit: XKS keys are excluded from the availability SLA of any AWS service that uses them, because their availability depends on infrastructure AWS does not run. Latency is also higher, because every operation is a network round trip to your key manager.
When a scenario stresses “keys outside the cloud,” “hold your own key,” “we must be able to destroy the key beyond AWS’s reach,” or a data-residency mandate that forbids key material in AWS, XKS is the intended answer — with the understood cost of running and guaranteeing that external infrastructure yourself.
The FIPS Trap: KMS Is Also Level 3 Now
Here is the discriminator candidates most often get wrong. Older study material claims the CloudHSM answer wins because “KMS is only FIPS 140-2 Level 2, and CloudHSM is Level 3.” That comparison is out of date. AWS KMS now protects all KMS keys — regardless of creation date or origin — with HSMs validated under FIPS 140-3 Security Level 3. (The KMS API endpoints are separately FIPS 140-2 validated, but the HSMs doing the cryptography are 140-3 Level 3.) So you cannot pick CloudHSM over the default store simply because you need “Level 3.”
The real reasons to choose a custom key store are about control and tenancy, not validation level:
- Single-tenant, dedicated hardware you can point to in an audit (CloudHSM key store).
- Direct administrative control of the HSM and its users.
- Key material physically outside AWS (XKS), for a sovereignty or “cloud provider must never hold the key” mandate.
If a question offers “because KMS is not FIPS 140-3 Level 3” as the justification for CloudHSM, it is a distractor. The justification is single-tenant control or external residency.
Decision Guide: Which Store for Which Requirement
| The scenario requires… | Choose |
|---|---|
| Standard encryption; AWS manages everything; lowest ops burden | Default KMS key store (AWS_KMS) |
| We must generate the key material ourselves; AWS may still hold it | Imported key material (EXTERNAL origin) |
| Single-tenant, dedicated, customer-controlled HSM (still in AWS) | AWS CloudHSM key store (AWS_CLOUDHSM) |
| Key material must live and be used outside AWS | External key store / XKS (EXTERNAL_KEY_STORE) |
| Isolate processing of plaintext from the instance’s own admins | AWS Nitro Enclaves — a different tool; see below |
That last row matters because Nitro Enclaves is the classic decoy against custom key stores. Enclaves protect where sensitive data is processed; custom key stores protect where keys are stored and who owns the HSM. They are complementary, not substitutes — see the Nitro Enclaves guide for that boundary. For the plain “single-tenant HSM vs default KMS” decision framed at architecture level, the SAP-C02 security and compliance scenarios post covers the standalone CloudHSM-versus-KMS call; this post is the KMS-integration layer beneath it.
Common SCS-C02 Exam Traps
- “Higher FIPS level” as the reason for CloudHSM. Outdated — KMS HSMs are FIPS 140-3 Level 3. The reason is single-tenant control.
- Asymmetric or HMAC keys in a CloudHSM key store. Not supported — those stores hold symmetric encryption keys only.
- Assuming AWS guarantees availability of custom-key-store keys. You own it; XKS keys are explicitly excluded from AWS availability SLAs, and a disconnected CloudHSM key store makes its keys instantly unusable.
- Confusing “generate our own key material” with “custom key store.” Generating your own material is the
EXTERNAL(imported) origin; it does not by itself require a dedicated or external HSM. - Thinking XKS keys are cached in AWS. They are not — every operation calls out to your proxy and key manager, which is why latency and availability are your problem.
- A single-HSM CloudHSM cluster. A key store needs a cluster with at least two active HSMs across AZs.
How This Maps to the Exam
Custom key stores sit squarely in the SCS-C02 Data Protection domain, with a foot in Management and Security Governance (the operational responsibility you take on) and Identity and Access Management (the key policies and grants that still govern who can use the key, wherever its material lives). Questions rarely ask you to configure a cluster end to end; they ask you to match a control or residency requirement to the right origin and to reason about the failure modes — what breaks when the backing store is unreachable, why an imported key cannot auto-rotate, why “Level 3” is not a differentiator. If KMS fundamentals still feel thin, reinforce them with the KMS and data protection deep dive and the broader infrastructure security guide before drilling custom key stores.
Frequently Asked Questions
What is the difference between an AWS CloudHSM key store and an external key store (XKS)?
Both are custom key stores where KMS is the control plane and the cryptographic operations happen in an HSM you control. In a CloudHSM key store that HSM is an AWS CloudHSM cluster in your account — single-tenant, but still inside AWS. In an external key store (XKS) the key manager lives outside AWS, and KMS reaches it through an XKS proxy you operate. Choose CloudHSM for dedicated single-tenant hardware; choose XKS when the key material must never reside in AWS.
Is AWS CloudHSM more FIPS-compliant than AWS KMS?
Not in the way older material implies. AWS KMS now protects all keys with HSMs validated under FIPS 140-3 Security Level 3, so CloudHSM is not “a higher level.” CloudHSM’s advantage is single-tenant, dedicated, customer-controlled hardware, not a higher FIPS validation.
What does the KMS key “origin” tell me?
It says where the key material came from and lives: AWS_KMS (AWS generates it, default), EXTERNAL (you import your own material into AWS HSMs), AWS_CLOUDHSM (your CloudHSM cluster), and EXTERNAL_KEY_STORE (your external key manager via XKS). Matching a requirement to one of these four values answers most custom-key-store questions.
What happens to my keys if the backing store goes down?
They become unusable until the store is reachable again. If you disconnect a CloudHSM key store or its cluster loses quorum, every operation against those keys fails. XKS keys depend on your proxy and external key manager, and AWS explicitly excludes them from service availability SLAs. This is why custom key stores add operational responsibility you do not carry with the default store.
Can I use a custom key store key with S3, EBS, or RDS like any other KMS key?
Yes. The point of a custom key store is that the KMS key ARN behaves like any other for integrated services and API calls; only the location of the HSM changes. CloudHSM key stores hold symmetric encryption keys only, which covers the standard “encrypt this service with a KMS key” use cases.
Conclusion
Custom key stores are the SCS-C02’s answer to a requirement plain KMS cannot meet: keeping key material in hardware you control, or outside AWS altogether, without giving up the KMS integration every AWS service relies on. Anchor on the four origins (AWS_KMS, EXTERNAL, AWS_CLOUDHSM, EXTERNAL_KEY_STORE), remember that a custom key store splits the KMS control plane from an HSM data plane you own, and internalize the two consequences that matter: you take on availability and durability, and the reason to leave the default store is single-tenant or external control — not a higher FIPS level, because KMS HSMs are already FIPS 140-3 Level 3. Get those distinctions automatic and a dense corner of the Data Protection domain turns into reliable points.
The fastest way to make these distinctions reflexive is scenario practice that forces the “which origin, and why” decision under time pressure. Sailor.sh’s AWS Security Specialty (SCS-C02) Certification-Ready Mock Exam Bundle drills exactly these data-protection scenarios across all six domains, with explanations that reinforce why a CloudHSM key store, an XKS, or plain KMS is right for a given wording. Pair the mocks with the full SCS-C02 exam guide for 2026, and treat every key-management question you miss as a chance to sharpen the origin-to-requirement mapping. (Custom key stores remain in scope as candidates transition toward SCS-C03, so the concepts here carry forward.)