Inter-node and in-fleet encryption
Lesson 3 of 3 in Protecting Data in Transit.
SCS-C03 adds a skill that C02 did not test: encryption in transit between the nodes of a distributed workload. It is worth understanding why it needed adding.
Everything so far has been client-to-service: a browser to CloudFront, an SDK to S3, an application to a database. But a Spark job shuffling 400 GB between twenty core nodes, a Kubernetes cluster where pods talk to pods across Availability Zones, and a distributed training job exchanging gradients between eight GPU instances all generate enormous volumes of traffic that never leaves your own fleet and is therefore never covered by the certificate on your load balancer. “We use HTTPS” is not an answer to “is the shuffle encrypted?”, because the shuffle is not HTTP. Each framework has its own mechanism, usually a single configuration flag, and each flag has a prerequisite that is the thing exam questions hide.
The four the guide names explicitly: Amazon EMR, Amazon EKS, SageMaker AI, and Nitro. Learn them as a set — a question that says “encrypt traffic between cluster nodes” is answered by the service’s own inter-node setting, never by a load balancer, a security group, or a VPC endpoint.
| Workload | What is actually encrypted | How you turn it on | The prerequisite or catch |
|---|---|---|---|
Amazon EMR | In-transit traffic between cluster nodes — Spark shuffle, block transfer, the Hadoop RPC layer and the web UIs | An EMR security configuration with in-transit encryption enabled, referenced when the cluster is created | You must supply certificates: a zip of PEM files in S3, or a custom certificate provider class. In-transit and at-rest encryption are separate switches in the same security configuration, and a security configuration cannot be attached to a running cluster |
Amazon EKS — control plane | kubelet and API traffic to the managed control plane, and etcd contents at rest | Always on for the control plane; add secrets envelope encryption with a KMS key for Kubernetes Secrets | Without the KMS provider, Secrets are only base64-encoded in etcd. Envelope encryption can be enabled on existing clusters, and the key then becomes a hard dependency of the cluster |
Amazon EKS — pod to pod | Traffic between pods, which the control-plane TLS does not touch at all | A service mesh with mTLS, a CNI or overlay that encrypts (for example WireGuard-based options), or Nitro hardware encryption where the instance types and path qualify | This is the gap teams assume is covered and is not. Mesh mTLS also brings workload identity, which is usually the real requirement behind the question |
SageMaker AI | Traffic between the containers and instances of a distributed training job |
| It can slow distributed training, particularly for deep learning at scale, so it is off by default — a cost/compliance trade, not an oversight. Set it at job creation; it is not changeable mid-job |
AWS Nitro System | Traffic between supported instances, encrypted in hardware by the Nitro card below the operating system, plus EBS volume traffic | Nothing to configure — it is automatic for supported instance types | Only on supported instance types, in the same Region, in the same VPC or a peered VPC, and only when no intermediate hop is involved — a transit gateway, NAT or load balancer in the path means no Nitro encryption. It is a baseline, not a substitute for application TLS |
Nitro deserves precision because it is simultaneously the strongest and the most over-claimed item on that list. On supported instance types, the Nitro card encrypts traffic to other supported instances using authenticated encryption with 256-bit keys, at the hardware level, with no measurable performance cost and nothing for you to configure or manage. It is genuine, always-on encryption of east-west traffic, and it is why AWS can describe VPC traffic between modern instances as encrypted by default.
The qualifiers are strict and they are what gets tested. It applies only between supported instance types (the list has grown steadily but is not every instance), only within the same Region, only in the same VPC or a peered VPC, and only when the traffic does not pass through an intermediate network device or service — a transit gateway, a NAT gateway, a load balancer, a gateway endpoint. A hop breaks it silently. Nitro also encrypts the traffic between an instance and its EBS volumes and between instances and supported file systems such as FSx, which is why you will see “encrypted in transit” claimed for EBS on Nitro instances with no configuration.
As of October 2026 AWS also offers VPC Encryption Controls, which turns that baseline into something you can verify and require: a monitor mode that reports the encryption status of flows (VPC Flow Logs gain an encryption-status field) and identifies resources that would allow unencrypted communication, and an enforce mode that permits only encrypted flows within and across VPCs in a Region, restricting ENI attachment to encryption-capable instance types. It can be applied per VPC, per account, or organization-wide through declarative policies — the answer to an auditor who asks not “can it be encrypted?” but “prove nothing unencrypted is possible”.
AWS Nitro Enclaves is a different idea from the same hardware lineage, and the exam likes the contrast. An enclave is an isolated compute environment carved out of a parent instance with no persistent storage, no interactive access and no external networking — the only channel is a local vsock to the parent. Its use case is processing data that even your own operators and the parent instance’s own root user must not be able to read: decrypting payment data, handling private keys, running a model over sensitive inputs. Cryptographic attestation lets KMS verify an enclave’s measurements before releasing a key, through a key policy condition on the attestation document — so a key can be made usable only inside an approved enclave image. Enclaves are about isolating processing; Nitro encryption in transit is about protecting links. A question about “sensitive processing that must be isolated from the rest of the instance” means enclaves.
“Encrypt the traffic between the nodes” — reading the question to the right switch
- Which workload is generating the node-to-node traffic?
The answer is always the workload’s own inter-node setting. Load balancers, security groups and VPC endpoints are never the answer to this question — they govern paths in and out, not traffic inside the fleet.
- EMR cluster (Spark / Hadoop)
Create a security configuration with in-transit encryption and reference it when launching the cluster. Supply certificates as a PEM zip in S3 or a custom certificate provider. At-rest encryption is a separate setting in the same configuration — enabling one does not enable the other.
- EKS pods across nodes
Control-plane TLS is already there and is not what the question asks about. For pod-to-pod, use a service mesh with mTLS or an encrypting CNI; for Kubernetes Secrets, enable envelope encryption with a KMS key. Nitro hardware encryption may already cover the link if instance types and path qualify.
- SageMaker AI distributed training
Set
EnableInterContainerTrafficEncryptionon the job. Expect a throughput cost on large distributed jobs, and set it at job creation — this is why the setting exists as an explicit choice rather than a default. - Plain EC2 fleet talking to itself
Supported Nitro instance types in the same VPC or a peered VPC already encrypt in hardware, with no intermediate hop. To require and prove it, use VPC Encryption Controls in enforce mode; to protect traffic that crosses a hop, use application TLS.
- The processing itself must be isolated
Different requirement, different control: Nitro Enclaves, with KMS attestation so the key is only usable inside the approved enclave. No networking, no storage, no operator access — not a transit control at all.
Key terms: Nitro System encryption in transit, AWS Nitro Enclaves, EMR security configuration, Inter-container traffic encryption (SageMaker AI), EKS secrets envelope encryption, VPC Encryption Controls
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.