Data Protection on AWS: KMS, ACM, Secrets, and Security Services (SOA-C03)

A data classification scheme decides how much protection each dataset gets, and every control in this lesson hangs off it. A typical three-tier scheme — public, internal, and confidential — maps directly to controls: public data needs integrity but not secrecy; internal data gets baseline encryption and private access; confidential data (PII, credentials, financial records) gets customer managed KMS keys, tight resource policies, access logging, and active monitoring.

Classification lives in tags

Operationally, classification is a tag. A consistent tag such as DataClassification=confidential on buckets, volumes, and databases is something machines can act on: IAM policies can condition on it, automation can filter on it, and AWS Config rules can be scoped to it. A spreadsheet of classifications drives no control at all. Three mechanisms turn the tag into an enforced scheme:

• Tag policies (AWS Organizations) define the standard: the exact capitalization of the tag key and its allowed values. Attached to the organization root or an OU, a tag policy is inherited by every account beneath it, and its compliance report lists resources whose tags break the standard (for example confidential versus Confidential versus CONF). You can also turn on enforcement for chosen resource types so noncompliant tagging operations are refused. Tag policies standardize tags; they do not add missing ones or protect the data.
• Tag-scoped AWS Config rules apply the tier's controls. A Config rule's scope can be limited to resources carrying a tag key, or a key and value, so a rule such as "EBS volumes must be encrypted" evaluates only DataClassification=confidential resources and reports their compliance continuously.
• Organization Config rules deploy that rule to every member account in one action, from the management account or from a Config delegated administrator account (typically the security account), which then sees compliance across the organization. That is the organization-native alternative to pushing per-account rules with CloudFormation StackSets.

Amazon Macie: checking that the labels are true

Amazon Macie is the discovery tool that keeps the scheme honest for S3. Macie uses machine learning and pattern matching to find sensitive data — names, credentials, card numbers, and other PII — inside S3 objects, and it reports where your classification is wrong: the "internal" bucket that actually holds customer PII. Macie also evaluates bucket-level posture, flagging buckets that are publicly accessible or unencrypted. When a requirement says "identify sensitive data stored in S3," the answer is Macie — not GuardDuty, which watches for threats, and not Inspector, which scans for vulnerabilities. Macie runs in two complementary modes:

A scheduled job is incremental: its first run analyzes the objects that already exist only if you select include existing objects, and each later run analyzes objects created or changed since the previous run. Set the sampling depth to 100% when every object must be inspected.

Encryption decides what Macie can read. Objects under SSE-S3 or the AWS managed key aws/s3 are analyzed normally. Objects under a customer managed KMS key are analyzed only if that key's policy allows the Macie service-linked role to call kms:Decrypt; otherwise they are reported as not analyzed. Objects encrypted with SSE-C (customer-provided keys) or encrypted client-side cannot be analyzed at all. Macie findings flow to EventBridge and Security Hub, so a discovery can trigger the same remediation loop as any other finding.

KMS underpins encryption at rest across AWS, and operations work focuses on configuration and access, not cryptography. Services use envelope encryption: your KMS key encrypts data keys, and data keys encrypt the actual data.

Default EBS encryption

Your first account-level move is enabling EBS encryption by default. It is a setting per account and per Region: turning it on in one Region does nothing in another, and the default key you choose must be a KMS key in that same Region (the AWS managed key aws/ebs unless you pick a customer managed key). Once it is on, every new volume and snapshot copy in that Region is encrypted and unencrypted volumes can no longer be created there, with no application changes required. It does not touch volumes that already exist — those need the walkthrough below.

Choosing a customer managed key as the default has one well-known trap. Instances launched by Amazon EC2 Auto Scaling create their volumes through the Auto Scaling service-linked role, so the key policy must allow that role to use the key — including kms:CreateGrant. Without it, instances that administrators launch by hand work fine while every Auto Scaling launch terminates immediately with Client.InternalError.

Key policies, IAM, grants, and cross-account use

Every KMS key has a resource-based key policy, and it is the primary authority: if the key policy does not permit an action — directly, or by delegating to IAM with the standard "enable IAM policies" statement — no IAM policy can grant it. Grants provide temporary, programmatic access and are commonly created by AWS services on your behalf (EBS and Auto Scaling use them).

Cross-account key use requires both sides: the key policy in the owning account must allow the external account or role, and the caller's IAM policy must allow the KMS actions on the key's full key ARN. An alias ARN in an IAM policy's Resource element does not authorize use of the key behind it. Because both sides are needed, AWS managed keys (aws/s3, aws/ebs, aws/secretsmanager and the like) can never be used cross-account: their key policies are owned by AWS and cannot be edited. Anything shared across accounts must be encrypted with a customer managed key.

Key rotation

Rotation replaces the key material behind a key while keeping the same key ID and ARN; KMS keeps old material so existing ciphertext still decrypts, and nothing needs to be re-encrypted.

Key states

A key must be Enabled to be used. A Disabled key fails cryptographic calls with DisabledException; a key in Pending deletion (the 7–30 day waiting period after ScheduleKeyDeletion) fails them with KMSInvalidStateException. Neither is an AccessDenied error. During the waiting period you can call CancelKeyDeletion, which returns the key to the Disabled state, so you must also call EnableKey before workloads can use it again. After the waiting period ends the key and anything encrypted only under it are unrecoverable.

Troubleshooting a KMS failure

When a workload throws a KMS error, triage in order: the key state (DisabledException or KMSInvalidStateException is a key-state problem, not a permissions problem), the key policy (does it allow this principal, or delegate to IAM?), the caller's IAM policy (does it allow kms:Decrypt or kms:GenerateDataKey on this key ARN?), then grants. An EC2 instance failing to use an encrypted volume is almost always missing KMS permissions on the volume's key, not EBS permissions.

You cannot switch on encryption in place for an existing EBS volume or RDS instance. The fix is always the same shape: snapshot, copy with encryption, restore.

Scenario: a production RDS MySQL instance is unencrypted and a new compliance requirement says every database must be encrypted with a customer managed key. The sequence:

1. Take a snapshot of the unencrypted instance.
2. Copy the snapshot, enabling encryption on the copy and selecting the KMS key. The encrypted copy is the pivot.
3. Restore a new DB instance from the encrypted snapshot copy.
4. Cut the application over — update the connection endpoint or rename the instances — during a maintenance window, because writes made after the snapshot will not carry over unless you re-sync them (for example with replication from the old instance until cutover).
5. Verify the new instance, then delete the old one.

RDS rules out the shortcuts. It does not allow:

• turning on encryption for an existing unencrypted DB instance;
• restoring an unencrypted snapshot directly to an encrypted DB instance — only the encrypted copy works;
• creating an encrypted read replica of an unencrypted DB instance (or an unencrypted replica of an encrypted one).

EBS follows the same pattern, with a little more flexibility: snapshot the volume, copy the snapshot with encryption enabled (CopySnapshot with Encrypted and a KmsKeyId) — or create an encrypted volume straight from the unencrypted snapshot — then stop the instance and swap the volumes. Enable default EBS encryption first so nothing new is ever created unencrypted again.

S3: choosing the key

S3 is gentler: every new object is encrypted at rest automatically, with SSE-S3 as the baseline even when the bucket has no encryption configured and the upload sends no encryption headers. Changing a bucket's default encryption only affects new writes — existing objects keep their original encryption until you copy them over themselves. The real decision is which key controls decryption:

S3 Bucket Keys reduce SSE-KMS cost and request volume by deriving a short-lived bucket-level key from your KMS key instead of calling KMS for every object. They change cost, not authority: access is still governed by the underlying KMS key's policy, so enabling a Bucket Key does not make aws/s3-encrypted objects readable from another account.

AWS Certificate Manager issues free public TLS certificates and deploys them to the services that terminate TLS for you: Elastic Load Balancing, CloudFront, and API Gateway. You never handle the private key; ACM manages storage, deployment, and renewal, which is exactly what makes it operationally safe.

Renewal

Request certificates with DNS validation: ACM gives you a CNAME record, you publish it in Route 53 (one click when the hosted zone is in the same account), and the certificate validates and then renews automatically for as long as the record stays in place. Email validation requires a human to respond at renewal time — avoid it. ACM's managed renewal keeps the same certificate ARN and redeploys the renewed certificate to the integrated services that use it, so no listener or distribution needs to be touched.

Which certificates renew themselves:

• ACM-issued public certificates — yes, while DNS validation still succeeds. The classic expired-certificate incident is a deleted validation CNAME.
• Private certificates issued through AWS Private CA and requested in ACM — yes, ACM renews them without validation.
• Imported certificates (from any outside CA) — never. You must obtain a new certificate and re-import it into the same ARN before expiry.
• Certificates in the IAM certificate store — never; IAM only stores them, and nothing monitors or renews them.

Monitoring expiry

ACM publishes the DaysToExpiry CloudWatch metric per certificate, issued and imported alike, so a CloudWatch alarm can page before a certificate lapses. ACM also sends events to EventBridge:

One EventBridge rule on Approaching Expiration that targets SNS therefore covers every certificate in the account and Region — including ones added later — without per-certificate alarms. The AWS Config managed rule acm-certificate-expiration-check is another account-wide option.

Enforcing TLS

On S3, add a bucket policy that denies all actions when aws:SecureTransport is false — plain HTTP requests are rejected outright, whatever else allows them. On an Application Load Balancer, keep port 80 open but configure its listener as a redirect to HTTPS, so clients are upgraded rather than stranded.

On Amazon RDS, the server enforces TLS through a parameter in a custom DB parameter group (the default group cannot be edited): require_secure_transport = ON for MySQL and MariaDB, and rds.force_ssl = 1 for PostgreSQL and SQL Server (newer PostgreSQL versions already default to 1). Enforcement only guarantees encryption; to prove the client reached the genuine endpoint, the client must verify the server certificate against the RDS certificate bundle — ssl-mode=VERIFY_IDENTITY for MySQL clients, sslmode=verify-full for PostgreSQL clients.

Finally, know the trade-off between terminating TLS at the load balancer — simpler certificate management and offloaded crypto, but plaintext between the load balancer and targets — and end-to-end encryption, where the ALB re-encrypts to HTTPS targets. A requirement that traffic be "encrypted in transit at every hop" is pointing you at end-to-end.

Secrets never belong in code, user data scripts, AMIs, or plaintext environment files — you cannot protect what has already leaked into an artifact. Workloads fetch them at runtime, over an IAM-authorized API call using their instance profile or task role, from one of two services.

AWS Secrets Manager is purpose-built for secrets: KMS-encrypted storage, fine-grained IAM and resource-policy control, and — its defining feature — automatic rotation. For Amazon RDS, Aurora, Redshift, and DocumentDB there are managed rotation templates; other secrets rotate through a custom Lambda rotation function (or, for onboarded SaaS partners, managed external secrets that need no Lambda). It charges per secret per month.

For a new RDS or Aurora database, the least-effort option is RDS-managed master user passwords: turn on the option to manage the master password in Secrets Manager and RDS generates the password, stores it in a secret it owns, and rotates it on a schedule (every seven days by default) without any rotation function for you to maintain.

Systems Manager Parameter Store stores configuration, and its SecureString type is a KMS-encrypted parameter — a perfectly good home for a static secret. It has two tiers:

Parameter policies only delete or notify: an expiration policy removes the parameter at a time you set, and the notification policies send EventBridge events. None of them changes the underlying credential, so they are not rotation. Parameter Store has no native rotation at all.

The selection logic: credentials that must rotate automatically — database passwords, API keys under a rotation policy — go to Secrets Manager; static secrets where cost matters and rotation is not required go to a standard-tier SecureString parameter. Both integrate with IAM for least-privilege reads and encrypt with KMS keys.

Sharing a secret with another account

Cross-account access to a Secrets Manager secret needs three things: a resource-based policy on the secret that allows the other account's role secretsmanager:GetSecretValue; a customer managed KMS key for the secret whose key policy lets that role decrypt (a secret under the default aws/secretsmanager key cannot be read from another account, because that key policy cannot be changed); and the role's own IAM permissions for both. Secret replication does not solve this — it copies a secret to other Regions of the same account, not to other accounts.

Skill 4.2.5 is about configuring reports and remediating findings, so know exactly what each service finds.

Amazon GuardDuty is threat detection. It continuously analyzes CloudTrail events, VPC Flow Logs, and DNS query logs — no agents, no traffic interception — and raises findings for active threats: an EC2 instance communicating with a cryptocurrency-mining pool, credentials used from an anomalous location, port scanning, or data exfiltration patterns. GuardDuty detects; it does not prevent or block — remediation is a separate step you automate.

Amazon Inspector is vulnerability management. It continuously scans EC2 instances (via the Systems Manager agent or agentless snapshot scanning), ECR container images, and Lambda functions for known CVEs and unintended network reachability, prioritizing findings by severity. Inspector tells you what could be exploited; GuardDuty tells you what is being attacked.

AWS Config contributes configuration compliance: rule evaluations — unencrypted volumes, security groups open to SSH from anywhere, drifted settings — plus a configuration timeline that records how each resource changed over time.

AWS Security Agent, named in the exam guide alongside these services, works on applications rather than account telemetry: it performs on-demand penetration testing of applications, with security code scanning and threat modeling of designs offered in preview, reporting the security issues it finds so they can be fixed. It does not monitor logs for live threats (GuardDuty) or inventory CVEs across a fleet (Inspector).

Security Hub CSPM and the new Security Hub

Since December 2025 there are two services with the Security Hub name. AWS Security Hub CSPM is the original service under a new name: it runs security standards (such as AWS Foundational Security Best Practices) made of controls, computes a security score, aggregates findings from GuardDuty, Inspector, Macie, Config, and partner tools in the AWS Security Finding Format (ASFF), and supports a delegated administrator for the organization. The new AWS Security Hub correlates findings from those security services into prioritized exposures, using the Open Cybersecurity Schema Framework (OCSF). When a requirement is about standards, controls, a security score, or ASFF findings aggregation, it is Security Hub CSPM.

Operating Security Hub CSPM across an estate involves three features:

• Delegated administrator: one account (usually the security account) manages Security Hub CSPM for every member account in the organization and sees their findings.
• Cross-Region aggregation: designate a home Region and link other Regions to it; findings, updates, and insights from the linked Regions then appear in the home Region. Security Hub CSPM must still be enabled in each linked Region — aggregation centralizes viewing, it does not replace the Regional service.
• Automation rules: created by the administrator account, Regional, they match findings on criteria such as resource tags, control, or account, and update fields such as severity or set the workflow status to SUPPRESSED. Use one to silence findings on resources that are deliberately exempt (for example, tagged as an approved exception) while the control keeps reporting every other resource. Disabling the control instead stops the check for every resource in that account and Region.

Most Task 4.2 questions reduce to picking the service whose job matches the symptom. Anchor on what each one examines and what it produces:

The services overlap in vocabulary, not in function. GuardDuty and Inspector both mention EC2, but only Inspector reports CVEs and only GuardDuty reports active compromise. Macie and GuardDuty both produce "findings," but Macie only ever examines data in S3. Security Hub CSPM generates standards findings of its own, yet it is never the primary detector — if a requirement describes one specific symptom, pick the specialist; if it asks for one consolidated view, a security score, or cross-account aggregation, pick Security Hub CSPM.

A finding that sits unread in a console is not remediation. Every service in this lesson — GuardDuty, Inspector, Macie, Config, and Security Hub — publishes its findings as events to Amazon EventBridge, which makes the operational pattern uniform:

1. Match: an EventBridge rule filters findings by source, type, and severity — for example, GuardDuty findings above a severity threshold.
2. Notify: route matched findings to an SNS topic so the on-call engineer always hears about it, whatever else happens.
3. Remediate: invoke a Lambda function or a Systems Manager Automation runbook that performs the fix — isolate a compromised instance, revoke an open security group rule, or enable a bucket's Block Public Access.

Multi-account remediation

In a GuardDuty organization, findings from member accounts are also delivered to the administrator account, in the same Region where they were generated. Central automation therefore lives in the administrator account, with one EventBridge rule in each Region GuardDuty runs in (EventBridge rules are Regional), and a runbook or function that assumes a remediation role in the affected member account to act on its resources. Nothing has to be deployed per member account except that role.

Config remediation and Security Hub custom actions

AWS Config remediation is attached to a Config rule: when the rule marks a resource noncompliant, the associated SSM Automation runbook runs, automatically or on demand, with no EventBridge rule required. It is driven only by Config rule evaluations — a GuardDuty or Inspector finding cannot trigger it, so threat findings go through EventBridge instead. Security Hub CSPM adds custom actions, which let an analyst send selected findings to EventBridge with one click for semi-automated response.

Two operational judgments matter. First, automate reversible containment freely — isolation, disabling credentials, notifications — but keep a human approval step in front of destructive actions. Second, remediation without a record is a lost audit trail: have the runbook tag what it touched and feed your ticketing flow. Detection → EventBridge (or a Config rule) → runbook is the same loop whether the trigger is a threat, a vulnerability, sensitive data, or configuration drift.

Containment means cutting a compromised instance off from the network while keeping everything an investigation needs. The standard sequence:

1. Isolate it: replace its security groups with an isolation security group that has no rules (or only a rule for your forensics host), and detach it from load balancers and Auto Scaling (suspend processes or set it to standby) so it is not replaced or terminated.
2. Preserve evidence: create EBS snapshots of every attached volume, tag the instance as under investigation, and capture memory if your tooling allows. Keep the instance running — stopping or terminating it destroys the contents of memory (and instance store volumes), which often hold the most useful evidence.
3. Revoke the credentials it may have exposed, such as its role's active sessions or leaked access keys.

Security groups have one property that matters here: they are stateful, and a change to them does not interrupt connections that are already being tracked. Swapping in the isolation group blocks new connections, but an attacker's existing session can continue. Network ACLs are stateless and evaluate every packet, so to cut an in-progress session immediately, add NACL deny entries on the instance's subnet for the attacker's address (inbound and outbound) — knowing that a NACL affects every instance in that subnet.