Determine Appropriate Data Security Controls

Core Idea

Protecting data — at rest and in transit — is treated as the most important layer of security design. This task blends encryption fundamentals, compliance tooling, data classification/lifecycle, and disaster recovery strategy.

Encryption Fundamentals (vocabulary you must know cold)

• Encryption at rest: protects stored data, typically a single-party concern (protects against unauthorized access/theft).
• Encryption in transit: protects data moving between two-or-more parties.
• Plaintext: unencrypted data (not necessarily "text" — can be docs, images, binaries).
• Algorithm: takes plaintext + key → produces ciphertext.
• Key: the "password" input to the algorithm.
• Ciphertext: the encrypted output.
• Symmetric vs. asymmetric encryption/keys — know the conceptual difference (one key vs. key pair).

Key Management Services

• AWS KMS vs. AWS CloudHSM: KMS is the managed, multi-tenant option for most encryption-key needs; CloudHSM gives you a dedicated, single-tenant hardware security module — choose CloudHSM when you need full control over the HSM (e.g., strict regulatory/compliance demands) or need KMS and CloudHSM to work together (KMS backed by a custom key store in CloudHSM).
• Understand cross-Region key management, key rotation cadence differences by key type, and how to attach access policies to keys.
• AWS Certificate Manager (ACM): issues/renews certificates for encryption in transit (e.g., TLS on ALB/CloudFront).

Amazon S3 Encryption Options

• Client-side encryption: object encrypted before it leaves the client — customer controls everything.
• Server-side encryption (data always travels over HTTPS in transit; S3 encrypts at rest on arrival):
  • SSE-C: customer-provided keys.
  • SSE-S3: S3-managed keys.
  • SSE-KMS: customer master keys stored in KMS.
• Know when each is appropriate — SSE-C for customer-managed key material without KMS, SSE-KMS for auditable key usage + fine-grained key policies, SSE-S3 for the simplest no-key-management case.

Compliance

• Security and compliance is a shared responsibility between AWS and the customer.
• AWS Artifact: self-service repository for AWS's security/compliance reports and online agreements (e.g., SOC reports, PCI docs).

Data Classification & Defense in Depth (AWS CAF security perspective)

Five capabilities to reason about for any data-protection design:

1. IAM
2. Detective controls
3. Infrastructure security
4. Data protection
5. Incident response

Layer multiple controls (defense in depth) across two categories: preventative and detective. Not all data is equal — classify it, and let classification drive control strength.

Performance vs. Protection Trade-offs

• Encrypting an EBS volume is presented as the least-effort way to protect data generated on an EC2 instance (vs. moving it to an encrypted S3 bucket) — a durability + effort trade-off, not just a security one.
• Know which services see no performance impact from encryption and which see a slight impact (e.g., KMS-backed RDS reads, S3 reads) — and understand the distinction between root keys and data keys in envelope encryption.

Access-Pattern-Driven Data Protection

• S3 lets you manage security at the bucket level and at path/object granularity.
• S3 Lifecycle configurations (rule-based, time-driven transitions) vs. S3 Intelligent-Tiering (automatic, access-pattern-driven, no rules to write) — know when each is the better fit.

Disaster Recovery Strategies (the four-tier ladder)

Ordered by increasing cost/complexity and decreasing RTO/RPO:

1. Backup and restore — lowest cost; adequate for a single-AZ/data-center-loss scenario in an otherwise well-architected HA workload.
2. Pilot light
3. Warm standby
4. Multi-site active-active — highest cost; needed when "disaster" means Region loss or when regulatory requirements demand it.

• Active/passive: one site serves traffic, the other is idle until failover.
• Know backup mechanisms per service: EBS snapshots, DynamoDB backup, RDS/Aurora snapshots, EFS backup (via AWS Backup), Redshift snapshot, Neptune snapshot, DocumentDB, and S3 Cross-Region Replication (async, versioned, choose your restore point).
• AWS Backup: centralizes configure/schedule/monitor for EBS, EC2, RDS/Aurora, DynamoDB, EFS, Storage Gateway, FSx (Windows/Lustre); supports cross-Region copy for DR.
• AWS Storage Gateway: the go-to answer for hybrid (on-prem + cloud) storage/backup scenarios.

Exam Angle

Expect RPO/RTO-driven scenario questions matched against the four DR tiers, "which S3 encryption option" questions keyed on who controls the key, and "least effort / most durable" trade-off questions around EBS vs. S3.

Practical Examples

KMS vs. CloudHSM: A fintech company needs to encrypt data with keys that AWS manages, rotates, and integrates cleanly with S3/EBS/RDS — KMS is the fit for 95% of scenarios like this. A different company, under a regulatory mandate (e.g., PCI DSS with a "must use FIPS 140-2 Level 3, single-tenant HSM" clause), needs exclusive, dedicated control over the hardware generating keys — that points to CloudHSM. A hybrid case: they want KMS's easy AWS-service integration but the keys must live in a customer-controlled HSM — use KMS with a custom key store backed by CloudHSM.

S3 SSE options, matched to scenario: You upload objects and don't want to manage any keys at all — SSE-S3. You want every key-usage event logged in CloudTrail and want to control who can use the key via a KMS key policy — SSE-KMS. You have strict internal policy requiring you (not AWS) to supply and hold the actual encryption key material, with AWS never persisting it — SSE-C. You need the encryption to happen before the object ever leaves your laptop/server — client-side encryption.

"Least effort" EBS vs. S3: An EC2 instance running a batch job writes intermediate output files to its attached volume; the data needs to be encrypted and durable but doesn't need to be Region-wide accessible. Least-effort answer: just use an encrypted EBS volume (checkbox at creation, or encrypt-in-place via snapshot copy) — moving the data to S3 first would add an unnecessary transfer step and application-level rewrite.

RPO/RTO to DR tier, matched: A marketing website that can tolerate a few hours of downtime and losing the last day's blog-post edits → Backup and Restore (cheapest, RPO/RTO measured in hours). A trading platform that must recover within minutes and lose at most seconds of data → Warm Standby or Multi-Site Active-Active depending on budget. A mid-tier internal app, core customer database must stay warm but the compute layer can be rebuilt on demand → Pilot Light (DB replicating continuously, app servers stay off until needed).

S3 Lifecycle vs. Intelligent-Tiering: Application log files are hot for exactly 30 days, then never touched again except for a yearly compliance pull — you know the access pattern, so a Lifecycle policy (Standard → Glacier at day 30) is simpler and cheaper than paying Intelligent-Tiering's monitoring fee. A user-generated-content bucket where some photos go viral and get hit constantly while others are never viewed again, and you can't predict which — use Intelligent-Tiering to let S3 auto-detect and move objects per-object.

AWS Artifact in practice: A customer's security team asks for AWS's SOC 2 report and a signed HIPAA BAA before they'll approve using AWS for a new healthcare workload. You don't email AWS support — you pull both directly from AWS Artifact, self-service, in minutes.