← Design Secure Architectures

▶ Play from here · 223 min

Starts this lesson and continues through 20 more to the end of certification prep.

Data protection, retention and recovery

Why this lesson matters

This is the other half of task statement 1.3. Its skills list includes "Implementing data backups and replications", "Implementing policies for data access, lifecycle, and protection", and its knowledge list includes "Data retention and classification" and "Data recovery".

The exam's framing here is almost always a stated requirement in regulatory language — "must be retained for seven years and must not be deletable", "must be recoverable within 15 minutes", "must be stored at a minimum distance from production". Your job is to map that sentence to exactly one control, and the controls in this lesson are close enough to each other that the mapping has to be precise.

There's also one genuinely counterintuitive fact in here that contradicts lesson 1, and it is the thing most worth carrying out of this module.

S3 Object Lock: WORM, and the mode nobody can undo

From Locking objects with Object Lock, verified 2026-09-21:

"S3 Object Lock can help prevent Amazon S3 objects from being deleted or overwritten for a fixed or variable amount of time, or indefinitely. Object Lock uses a write-once-read-many (WORM) model to store objects."

And the compliance framing that makes it the answer to regulatory questions: "S3 Object Lock has been assessed by Cohasset Associates for use in environments that are subject to SEC 17a-4, CFTC, and FINRA regulations." If a question names one of those three regulations, Object Lock is in the answer.

The hard prerequisite: "Object Lock works only in buckets that have S3 Versioning enabled." Versioning is not optional here, and "enable versioning" will be part of the correct answer.

The two retention modes

Quoted, because the distinction is the whole exam question:

Compliance mode — "In compliance mode, a protected object version can't be overwritten or deleted by any user, including the root user in your AWS account. When an object is locked in compliance mode, its retention mode can't be changed, and its retention period can't be shortened."

Governance mode — "In governance mode, users can't overwrite or delete an object version or alter its lock settings unless they have special permissions. With governance mode, you protect objects against being deleted by most users, but you can still grant some users permission to alter the retention settings or delete the objects if necessary."

⚠️ Compliance mode is irreversible, and AWS says so explicitly: "The only way to delete an object under the compliance mode before its retention date expires is to delete the associated AWS account."

Read that again before you ever enable it. There is no support case, no root override, no break-glass. Delete the account. That is the documented escape hatch, which means there isn't one.

The governance-mode override is a specific, examinable pair:

"To override or remove governance-mode retention settings, you must have the s3:BypassGovernanceRetention permission and must explicitly include x-amz-bypass-governance-retention:true as a request header with any request that requires overriding governance mode."

⚠️ And a console behaviour worth knowing: "By default, the Amazon S3 console includes the x-amz-bypass-governance-retention:true header." So governance mode is weaker in the console than you might expect — anyone with the bypass permission clicking delete in the console will succeed, because the console sends the header for them.

AWS's own selection guidance, compressed:

Legal holds

"Like a retention period, a legal hold prevents an object version from being overwritten or deleted. However, a legal hold doesn't have an associated fixed amount of time and remains in effect until removed. Legal holds can be freely placed and removed by any user who has the s3:PutObjectLegalHold permission."

And they are independent of retention periods: "if you place a legal hold on an object version and that object version is also protected by a retention period. If the retention period expires, the object doesn't lose its WORM protection. Rather, the legal hold continues to protect the object until an authorized user explicitly removes the legal hold."

Retention period mechanics

• A retention period can be set per object version or as a bucket default applying to everything written afterwards. An object's explicit settings "override any bucket property retention settings."
• You can extend a retention period — "submit a new Object Lock request for the object version with a Retain Until Date that is later than the one currently configured" — but you cannot shorten one in compliance mode.
• You can bound what people may set, with the s3:object-lock-remaining-retention-days condition key in the bucket policy.
• Protection is per version, not per key. "Retention periods and legal holds don't prevent new versions of the object from being created, or delete markers to be added on top of the object."

⚠️ The delete behaviour is asymmetric and it confuses people. With a protected object:

So a naive delete appears to succeed. The data is still there and still locked — a delete marker just became the current version. If a question describes "the object disappeared from the listing but compliance say it can't be deleted", that's a delete marker on a locked version, and both statements are true.

The fact that contradicts lesson 1

From Managing the lifecycle of objects, verified 2026-09-21, in a boxed Important:

"General purpose buckets — You can't use a bucket policy to prevent deletions or transitions by an S3 Lifecycle rule. For example, even if your bucket policy denies all actions for all principals, your S3 Lifecycle configuration still functions as normal."

Stop and appreciate that. Lesson 1's rule — an explicit deny overrides everything — is a rule about principals making requests. A lifecycle rule is not a principal making a request. It is the service acting on its own configuration, and no bucket policy touches it.

Design consequence: if the requirement is "this data must not be deleted", a Deny on s3:DeleteObject is not sufficient. A misconfigured lifecycle expiration will delete it anyway. The control that actually stops deletion is Object Lock. This is the highest-value single fact in the lesson, and it is the kind of thing that shows up as a real incident rather than only as an exam question.

Lifecycle: the two action types

Facts that matter for design:

• Rules apply to existing objects too. "When you add a Lifecycle configuration to a bucket, the configuration rules apply to both existing objects and objects that you add later … Amazon S3 will queue for removal any existing objects that are more than 30 days old." This is the opposite of the encryption behaviour in lesson 5 — worth contrasting explicitly, because the asymmetry is easy to get backwards.
• Billing changes on eligibility, not on action. "billing changes are applied as soon as the object becomes eligible for the lifecycle action." The exception: a transition to S3 Intelligent-Tiering, where "billing changes don't occur until the object has transitioned."
• Transitions cost money. "There are costs associated with lifecycle transition requests" and "there are per-request ingestion charges when using PUT, COPY, or lifecycle rules to move data into any S3 storage class." Moving many small objects to a cheaper class can cost more than it saves.
• Expiration can cost money too — "only when you expire objects in a storage class with a minimum storage duration."
• There are no data retrieval charges for lifecycle transitions.

Replication: which flavour, and the SLA

From Replicating objects within and across Regions, verified 2026-09-21. Replication is "automatic, asynchronous copying of objects across Amazon S3 buckets" — note asynchronous, which is why it has an SLA rather than a guarantee.

Live vs on-demand is the distinction the exam tests:

Live replication — "To automatically replicate new and updated objects as they are written to the source bucket, use live replication. Live replication doesn't replicate any objects that existed in the bucket before you set up replication."

On-demand replication — "To replicate existing objects from the source bucket to one or more destination buckets on demand, use S3 Batch Replication."

⚠️ Turning on replication does nothing to the data already in the bucket. Same shape as the encryption default in lesson 5 and the reverse of lifecycle. The fix is S3 Batch Replication, which also handles "objects that previously failed to replicate" (filter on replication status FAILED) and replicas of replicas — "Replicas of objects can be replicated only with Batch Replication."

CRR vs SRR, and what each is documented as being for:

For Domain 1, SRR's log-aggregation and sovereignty cases are the security-relevant ones: "You might be required to store multiple copies of your data in separate AWS accounts within a certain Region. Same-Region Replication can help you automatically replicate critical data when compliance regulations don't allow the data to leave your country."

S3 Replication Time Control (RTC) — the number to know:

"S3 RTC replicates 99.99 percent of new objects stored in Amazon S3 within 15 minutes (backed by a service-level agreement)."

The workload table AWS publishes, verbatim in the numbers:

⚠️ The page states the RTC figure as 99.99 percent in its prose and 99.9 percent in the workload table — on the same page, verified 2026-09-21. That is a live documentation inconsistency, not a transcription error on my part. If you need the contractual number, read the S3 SLA itself rather than the user guide.

⚠️ RTC does not apply to Batch Replication: "Batch Replication is an on-demand replication job, and can be tracked with S3 Batch Operations."

Other verified capabilities worth a line each: replication preserves metadata ("the original object creation times and version IDs"); it can replicate directly into S3 Glacier Flexible Retrieval or Deep Archive; the owner override option changes replica ownership to the destination bucket's account, "to restrict access to object replicas" — which is the pattern for a locked-down backup account; and two-way (bi-directional) replication with replica modification sync is what keeps metadata changes — "object access control lists (ACLs), object tags, or object locks" — in sync for failover designs.

AWS Backup: one place for everything else

S3 Object Lock only protects S3. From What is AWS Backup?, verified 2026-09-21:

"AWS Backup is a fully-managed service that makes it easy to centralize and automate data protection across AWS services, in the cloud, and on premises. … It allows you to automate and consolidate backup tasks that were previously performed service-by-service, and removes the need to create custom scripts and manual processes."

⚠️ The scoping sentence that decides audit questions: "AWS Backup does not govern backups you take in your AWS environment outside of AWS Backup." An EBS snapshot you took by hand is invisible to AWS Backup's policies and reports.

The concepts, verbatim:

• Backup plans — "you can create backup policies known as backup plans. Use these backup plans to define your backup requirements and then apply them to the AWS resources that you want to protect."
• Tag-based assignment — "Integration with AWS tags enables you to quickly apply a backup plan to a group of AWS resources." This is the low-overhead answer to "ensure every new resource is backed up" — tag-based selection, rather than a list of resource IDs.
• Backup vaults — "The content of each AWS Backup backup is immutable, meaning that no one can alter that content. AWS Backup further secures your backups in backup vaults, which separates them safely from their source instances." Vaults have "encryption and resource-based access policies".
• Vault Lock — "You can use AWS Backup Vault Lock to prevent anyone (including you) from deleting backups or altering their retention period. AWS Backup Vault Lock helps you enforce a write-once-read-many (WORM) model."

Vault Lock is the Object Lock of AWS Backup, and that parallel is the clean way to hold both: "immutable S3 objects" → Object Lock; "immutable backups of everything else" → Vault Lock.

⚠️ I did not verify Vault Lock's governance vs compliance mode distinction, or its cooling-off period, from a fetched page in this pass. Read vault-lock.html before answering a question that hinges on whether a locked vault can be unlocked.

Cross-Region and cross-account are both supported, and the phrasing is useful:

"Using AWS Backup, you can copy backups to multiple different AWS Regions on demand or automatically as part of a scheduled backup plan. Cross-Region backup is particularly valuable if you have business continuity or compliance requirements to store backups a minimum distance away from your production data."

"You can also copy backups to multiple different AWS accounts inside your AWS Organizations management structure. This way, you can 'fan in' backups to a single repository account, then 'fan out' backups for greater resilience."

Fan-in to a repository account is the answer to "protect backups from a compromised production account". Note the prerequisite: "Before you can use the cross-account management and cross-account backup features, you must have an existing organization structure configured in AWS Organizations."

Two more features that answer specific requirement phrasings:

• Full AWS Backup management gives "Independent encryption. AWS Backup automatically encrypts your backups with the KMS key of your AWS Backup vault, instead of using the same encryption key as your source resource. This increases your layers of defense." Backups also get arn:aws:backup ARNs, "allowing you to create access policies that apply specifically to backups and not the source resources". That's defence in depth against a compromised source key — a good Domain 1 answer.
• AWS Backup Audit Manager "provides built-in, customizable controls", helps "locate specific activities and resources that are not yet compliant", and "generates daily reports that you can use to demonstrate evidence of compliance". If the requirement is "prove to the auditor that every resource is backed up per policy", that's Audit Manager, not the dashboard.

Supported resources include EC2 (EBS-backed instances), S3, EBS, DynamoDB, RDS (all engines, plus Multi-AZ clusters), Aurora, Aurora DSQL, EFS, all four FSx variants, Storage Gateway volumes, DocumentDB, Neptune, Redshift and Redshift Serverless, Timestream for LiveAnalytics, VMware Cloud on AWS, CloudFormation stacks, SAP HANA on EC2, and EKS.

⚠️ Not everything is incremental. "Not all resource types support incremental backups. For resources that do not support incremental backups, each backup is a full copy, which can result in higher storage costs."

Check yourself

1. A regulator requires that records cannot be deleted by anyone for seven years. Which control, which mode, and what must you enable first?
2. Your bucket policy denies s3:DeleteObject for all principals. Is the data safe from deletion?
3. You enable CRR on a bucket holding 2 PB of existing data. What replicates?
4. A user runs aws s3 rm s3://bucket/key on a compliance-locked object and gets no error. What happened?
5. Production is compromised and the attacker has admin in that account. Which backup design survives?

Answers

1. S3 Object Lock in compliance mode, and you must enable S3 Versioning first — "Object Lock works only in buckets that have S3 Versioning enabled." Compliance mode is the only one root can't override; be sure, because "the only way to delete an object under the compliance mode before its retention date expires is to delete the associated AWS account."
2. No. "even if your bucket policy denies all actions for all principals, your S3 Lifecycle configuration still functions as normal." A lifecycle expiration rule will still delete it. Only Object Lock actually prevents deletion.
3. Nothing, yet. "Live replication doesn't replicate any objects that existed in the bucket before you set up replication." Run an S3 Batch Replication job for the existing 2 PB.
4. A simple DELETE (no version ID) returned 200 OK and inserted a delete marker. The locked version is untouched. A permanent delete specifying the version ID would have returned 403.
5. Cross-account backup copies fanned in to a separate repository account, ideally with Backup Vault Lock, and with full AWS Backup management so the backups are encrypted under the vault's KMS key rather than the compromised account's source key. Requires an Organizations structure.

Teaching this section

• Open with the lifecycle-versus-bucket-policy quote. It is the one fact in this module that contradicts what you taught in lesson 1, and stating the contradiction out loud is what makes both facts stick. "Deny beats everything — for principals. Lifecycle isn't a principal."
• Demo: put an object under governance-mode retention, delete it from the console (it works, because the console sends the bypass header), then try the same thing with the CLI without the header and watch the 403. Two minutes, and the governance/compliance distinction stops being abstract.
• Best discussion prompt: "Should we use compliance mode?" Read them the delete-the-account sentence and let the room get uncomfortable. That discomfort is the correct engineering response and it's what the exam is testing when it asks which mode.
• Watch for: the assumption that enabling replication or changing encryption retroactively affects existing data. Build the table with them: lifecycle does apply retroactively; replication and encryption defaults do not. Same question, three different answers.
• Timing: 30 min presented, 20 for the requirement-mapping exercise — give them six regulatory sentences and have them name the control for each.