Most SCS-C02 data-protection questions have a comfortable answer: encrypt it with KMS, restrict the key policy, done. Then the exam hands you a harder scenario — you have to process plaintext credit-card numbers or private keys on an EC2 instance, but you must guarantee that no one with access to that instance, including root and your own administrators, can ever read the plaintext. Encryption at rest does not solve that; the data is decrypted in memory to be used. The AWS-blessed answer is AWS Nitro Enclaves, and it is one of the few “confidential computing” topics the AWS Certified Security - Specialty (SCS-C02) exam expects you to recognize and reason about.
This guide walks Nitro Enclaves the way the exam frames it: what the isolation boundary actually is, how cryptographic attestation lets AWS KMS trust an enclave, the exact kms:RecipientAttestation condition keys that trip candidates up, the build-and-run workflow with nitro-cli, and the decision cues that separate Enclaves from CloudHSM, Dedicated Hosts, and plain KMS. If you want the wider data-protection picture first, the SCS-C02 KMS and data protection guide sets the foundation; here we focus entirely on Enclaves.
What AWS Nitro Enclaves Actually Are
A Nitro Enclave is an isolated execution environment carved out of a single parent EC2 instance. It is a separate, hardened, highly constrained virtual machine that borrows some of the parent instance’s vCPUs and memory but runs completely walled off from it. The same Nitro Hypervisor that isolates one EC2 instance from another is used to isolate the enclave’s vCPUs and memory from its own parent instance — so the parent has no way to read into the enclave’s memory.
Three properties define the boundary, and the exam leans on all three:
- No persistent storage. An enclave has no disk. Anything it needs must be passed in at runtime; nothing survives a restart.
- No interactive access. You cannot SSH into an enclave. There is no shell, no operator login, no debugger attach from the outside.
- No external networking. An enclave has no network interface and cannot reach the internet, a VPC, or any other host — not even other enclaves.
The only channel in or out is a secure local socket to the parent instance — a virtual socket (vsock) that carries a byte stream between the parent and the enclave over the Nitro Hypervisor. Every request the enclave answers and every result it returns crosses that vsock. This is the mental model the exam rewards: the enclave is a black box that the parent can talk to but never look inside.
A few operational facts worth memorizing:
| Property | Detail |
|---|---|
| Isolation mechanism | Nitro Hypervisor isolates enclave vCPUs and memory from the parent |
| Processor support | Processor-agnostic — Intel, AMD, and AWS Graviton instances built on Nitro |
| Enclaves per parent | Up to 4 per parent instance; enclaves cannot talk to each other |
| Lifecycle | Enclaves live only while the parent is running; stop/terminate the parent and its enclaves die |
| Networking | None — only the local vsock to the parent |
| Cost | No additional charge — you pay standard EC2 rates for the parent |
| Not supported | Outposts, Local Zones, Wavelength Zones; cannot combine with instance hibernation |
That “no additional charge” line is a genuine exam fact and a favorite distractor trap: candidates assume a hardware-backed isolation feature must carry a premium like CloudHSM does. It does not — you pay only for the EC2 instance.
Why Encryption Alone Is Not Enough
To see why Enclaves exist, follow the data. You encrypt a customer’s Social Security number with a KMS key and store it in S3 — excellent, it is protected at rest. But to use it (validate it, tokenize it, run a fraud model against it), some process has to decrypt it into plaintext in memory. On an ordinary EC2 instance, that plaintext now sits in the address space of a process that a root user, a compromised sidecar, a memory-scraping exploit, or a curious administrator could read. Your encryption boundary and your processing boundary are the same host, and that host has humans and other software on it.
Nitro Enclaves separate those boundaries. The plaintext only ever exists inside the enclave’s isolated memory, which the parent — and therefore every user and process on the parent — cannot read. This is what AWS means by confidential computing: reducing the trusted computing base for sensitive data to a measured, attestable environment, and removing the operator from the trust equation.
On the exam, the signal phrases are unmistakable:
- “…so that administrators of the instance cannot access the plaintext data.”
- “…process highly sensitive data (PII, PCI cardholder data, cryptographic keys) in an isolated environment.”
- “…reduce the trusted computing base for a sensitive workload.”
Any of these points at Nitro Enclaves, not at a bigger instance, a Dedicated Host, or a tighter security group.
Attestation: How KMS Learns to Trust an Enclave
Isolation is only half the story. If the enclave is a black box, how does AWS KMS know it is talking to the right, unmodified black box and not an attacker’s imposter? The answer is cryptographic attestation.
When an enclave boots, the Nitro Hypervisor measures it and produces a signed attestation document. Those measurements live in Platform Configuration Registers (PCRs) — cryptographic hashes of exactly what is running:
| PCR | What it measures |
|---|---|
| PCR0 | Hash of the entire enclave image (the EIF) |
| PCR1 | Hash of the Linux kernel and bootstrap |
| PCR2 | Hash of the application inside the enclave |
| PCR3 | Hash of the IAM role assigned to the parent instance |
| PCR4 | Hash of the parent instance ID |
| PCR8 | Hash of the certificate used to sign the enclave image (when signed) |
The attestation document is signed by the Nitro Hypervisor (a trust root AWS controls) and also carries a public key the enclave generates. Because the measurements are hashes, any change to the image, kernel, or application produces different PCRs — so an attacker who tampers with the enclave code cannot reproduce a valid, matching attestation.
The exam does not ask you to memorize every PCR number, but it does expect you to know that:
- Attestation proves an enclave’s identity and integrity (“only authorized, unmodified code is running”).
- The proof is a signed attestation document containing PCR measurements.
- KMS (and other services) can be configured to only act when the measurements match.
KMS Condition Keys: Gating Decryption on Attestation
This is the single most testable Nitro Enclaves mechanic, and the exact condition-key names are what candidates get wrong.
Nitro Enclaves integrates with AWS KMS through the Nitro Enclaves SDK, which exposes three attestation-aware operations: kms-decrypt, kms-generate-data-key, and kms-generate-random. When the enclave calls one of these, the SDK attaches the enclave’s attestation document to the KMS request. KMS then validates the PCR measurements in that document against condition keys in the KMS key policy before allowing the operation. The KMS actions this covers are kms:Decrypt, kms:GenerateDataKey, and kms:GenerateRandom.
The two condition keys are:
kms:RecipientAttestation:ImageSha384— matches the SHA-384 image hash (PCR0) of the enclave.kms:RecipientAttestation:PCR<n>— matches a specific PCR (for examplekms:RecipientAttestation:PCR0,PCR1,PCR2,PCR8).
Here is the pattern AWS documents — a key policy that only lets an attested enclave use the key, and only when its measurements match:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "Enable enclave data processing",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:role/data-processing" },
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:GenerateRandom"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"kms:RecipientAttestation:ImageSha384": "<enclave image hash>",
"kms:RecipientAttestation:PCR0": "<PCR0 measurement>"
}
}
}]
}The elegant part — and a point the exam likes to test — is the failure mode: if a request arrives without an attestation document (for example, the same IAM role calling kms:Decrypt from the parent instance or from anywhere else), the kms:RecipientAttestation condition cannot be satisfied, so the request is denied. The role’s permission to decrypt is effectively bound to being inside the attested enclave. Even a full compromise of the parent instance’s credentials does not unlock the ciphertext, because the attacker cannot forge matching PCR measurements.
The End-to-End Data-Protection Pattern
Put attestation and KMS together and you get the canonical Nitro Enclaves workflow AWS documents for protecting sensitive data:
- Create a KMS key and write a key policy whose
AllowforDecrypt/GenerateDataKeyis gated bykms:RecipientAttestationconditions matching your enclave’s measurements. - Encrypt the sensitive data client-side. Call
GenerateDataKeyto get a plaintext + encrypted data key, encrypt the data with the plaintext key using a client library such as the AWS Encryption SDK, then discard the plaintext key. - Store the encrypted data and the encrypted data key somewhere ordinary, such as Amazon S3. Neither the parent instance nor S3 can read the plaintext.
- At processing time, the parent passes the ciphertext and the encrypted data key across the vsock into the enclave.
- Inside the enclave, the app calls
kms-decrypt(attestation attached). KMS verifies the PCRs, returns the plaintext data key encrypted to the enclave’s public key from the attestation document, and the enclave unwraps it, decrypts the data, does its work, and returns only the result over the vsock.
The plaintext data key and the plaintext data exist only inside the enclave’s isolated memory. That is the whole point.
Building and Running an Enclave: nitro-cli and the EIF
You will not be asked to write enclave code on the SCS-C02, but you are expected to recognize the build artifacts and tooling.
- Launch the parent EC2 instance with enclave support enabled (
--enclave-options 'Enabled=true') on a supported instance type, and install the Nitro Enclaves CLI and allocator. - The allocator service (
nitro-enclaves-allocator) reserves the vCPUs and memory that will be handed to the enclave. - Package your application into an Enclave Image File (EIF) with
nitro-cli build-enclave(typically from a Docker image), then start it withnitro-cli run-enclave.
# Build the enclave image (EIF) from a container image
nitro-cli build-enclave \
--docker-uri my-enclave-app:latest \
--output-file my-enclave.eif
# The build prints the PCR measurements — PCR0/1/2 — that you
# paste into the KMS key policy condition keys.
# Run the enclave with 2 vCPUs and 512 MiB, in debug mode for testing
nitro-cli run-enclave \
--eif-path my-enclave.eif \
--cpu-count 2 \
--memory 512 \
--debug-modebuild-enclave is where the PCR values come from — you feed those measurements straight into the kms:RecipientAttestation conditions above. One production caution the exam may hint at: debug mode disables attestation guarantees (measurements are zeroed), so a debug enclave must never be trusted with real key-policy grants.
ACM for Nitro Enclaves: Protecting TLS Private Keys
There is a second flagship use case AWS calls out, and it maps to a distinct exam scenario. AWS Certificate Manager (ACM) for Nitro Enclaves lets a web server (for example nginx on the parent) terminate TLS while the private key lives inside the enclave and is never exposed on the instance. The parent handles the network socket; the cryptographic signing happens inside the enclave. If a scenario says “terminate HTTPS on EC2 but ensure the TLS private key is never accessible on the instance’s file system or to its administrators,” that is ACM for Nitro Enclaves, not IAM, not a tighter file permission, not Secrets Manager.
Telling Nitro Enclaves Apart on the Exam
The wrong answers in Enclaves questions are all legitimate isolation or key services, so the discriminator is what boundary the scenario cares about:
| Scenario wording | Right answer | Why not the others |
|---|---|---|
| ”Process plaintext PII so instance admins/root cannot read it” | Nitro Enclaves | A bigger/dedicated instance still exposes memory to its own admins |
| ”Restrict decryption to a verified, unmodified environment” | KMS key policy with kms:RecipientAttestation | A normal key policy trusts the IAM principal anywhere it runs |
| ”Isolate our workloads from other AWS customers on the hardware” | Dedicated Hosts / Dedicated Instances | Enclaves isolate from your own host, not from tenancy |
| ”Store keys in dedicated, single-tenant hardware (FIPS 140-2/3 Level 3), we manage it” | AWS CloudHSM | Enclaves are compute isolation, not a key store |
| ”Managed key storage and policy for encrypting data at rest” | AWS KMS | KMS stores/uses keys; Enclaves isolate processing |
Two traps recur. First, Dedicated Hosts vs Enclaves: Dedicated Hosts give you physical isolation from other tenants but do nothing to hide memory from your own root user — Enclaves do the opposite. Second, CloudHSM vs Enclaves: CloudHSM is about where keys are stored and who manages the HSM; Enclaves are about where sensitive data is processed. They can even be complementary, but a question asking to “process data in isolation” is Enclaves, while “single-tenant, customer-managed hardware key store with full FIPS control” is CloudHSM (see the KMS and data protection guide for the KMS-vs-CloudHSM line).
How This Fits the SCS-C02 Blueprint
Nitro Enclaves sits squarely in the Data Protection domain, with a foot in Infrastructure Security (compute isolation) and Identity and Access Management (the KMS key policy that binds decryption to attestation). It rewards candidates who already understand KMS key policies, data keys, and envelope encryption, then adds the twist that a machine’s measured identity, not just an IAM principal, can be a condition on key use. If envelope encryption and key policies still feel shaky, shore them up with the KMS deep dive and the broader infrastructure security guide before you drill Enclaves.
Practice Under Real Exam Conditions
Nitro Enclaves questions are quick points if you have internalized three things: the isolation boundary (no storage, no interactive access, no networking, vsock-only), attestation with PCRs, and the kms:RecipientAttestation condition keys that deny any request lacking a valid attestation. The reliable way to make those reflexes automatic is repeated exposure to scenario-style questions that phrase the problem the way the real exam does.
Sailor.sh’s AWS Security Specialty (SCS-C02) Certification-Ready Mock Exam Bundle is built for exactly that — scenario-driven questions across all six domains, with explanations that reinforce why Enclaves beat a Dedicated Host or CloudHSM in a given wording. Pair the mocks with the full SCS-C02 exam guide for 2026, and treat every data-protection question you miss as a chance to sharpen the Enclaves-vs-everything-else distinction. (Nitro Enclaves remains in scope as candidates transition toward SCS-C03, so the concepts here carry forward.)
Frequently Asked Questions
What problem do AWS Nitro Enclaves solve that KMS encryption does not?
KMS protects data at rest and in transit, but to use sensitive data a process must decrypt it into memory — and on a normal instance that plaintext is readable by root, other processes, and administrators. Nitro Enclaves isolate the processing of that plaintext into a hardened VM that the parent instance and its users cannot read, closing the gap between the encryption boundary and the processing boundary.
What are the isolation guarantees of a Nitro Enclave?
An enclave has no persistent storage, no interactive access (no SSH), and no external networking. Its only channel is a secure local socket (vsock) to the parent instance, and the Nitro Hypervisor isolates its vCPUs and memory so even root on the parent cannot read enclave memory.
What is attestation and what are PCRs?
Attestation is the process by which the Nitro Hypervisor produces a signed attestation document proving an enclave’s identity and integrity. The document contains Platform Configuration Registers (PCRs) — cryptographic hashes of the enclave image (PCR0), kernel (PCR1), application (PCR2), parent IAM role (PCR3), instance ID (PCR4), and signing certificate (PCR8). Any change to the code changes the measurements.
Which KMS condition keys work with Nitro Enclaves?
kms:RecipientAttestation:ImageSha384 and kms:RecipientAttestation:PCR<n>. They gate the KMS actions kms:Decrypt, kms:GenerateDataKey, and kms:GenerateRandom. A request that lacks a matching attestation document fails the condition and is denied — even for an otherwise-authorized IAM role.
How are Nitro Enclaves different from CloudHSM and Dedicated Hosts?
CloudHSM is a single-tenant, customer-managed hardware key store; Dedicated Hosts/Instances give physical isolation from other tenants; Nitro Enclaves isolate sensitive data processing from your own instance and its administrators. They solve different problems and can be combined.
Do Nitro Enclaves cost extra?
No. There is no additional charge for Nitro Enclaves — you pay standard Amazon EC2 rates for the parent instance and for any other AWS services you use, such as KMS.
Conclusion
AWS Nitro Enclaves are the SCS-C02’s answer to a problem plain encryption cannot solve: processing sensitive data on EC2 while keeping the plaintext out of reach of the instance’s own users, processes, and administrators. Remember the boundary (no storage, no interactive access, no networking, vsock-only), remember that attestation with PCR measurements proves the enclave is the right, unmodified environment, and remember that kms:RecipientAttestation condition keys bind KMS decryption to that attestation so a stolen IAM role is useless outside the enclave. Learn to separate Enclaves (isolated processing) from CloudHSM (dedicated key storage) and Dedicated Hosts (tenant isolation), and this once-obscure feature turns into dependable points across the Data Protection, Infrastructure Security, and IAM domains of the exam.