beginnerintermediateadvanced

AWS · Section 54

Data Protection and Backup Strategy

Level: advanced
Read: 30 min
Concepts: 3

Data protection is several independent mechanisms that are easy to mistake for one. Encryption stops the data being read and does nothing about losing it. Backups and snapshots are point-in-time and are the only defence against corruption. Replication defends against losing a location and copies corruption faithfully. Versioning and immutability defend against deletion, including deliberate deletion by an authorized principal — which is why copies belong in a separate backup account, with a retention period nobody can shorten, and why AWS names cross-account backup copies as protection against insider threats and account compromise. None of it counts until a restore has actually been performed. Which controls a given data store deserves comes from two independent questions: how bad is a leak, and how bad is unavailability. The answers usually differ, they drive different controls, and derived data — logs, exports, analytics copies — inherits both, which is where classification is most often lost. Finally, data cools with age, and lifecycle policies are what move it between hot, warm, cold, and archival tiers automatically, including expiring noncurrent versions; the traps are minimum storage durations, per-object transition charges, and retrieval cost, all of which scale with object count rather than with bytes.

AWS overview

AWS Full Course 2026 | AWS Cloud Computing Tutorial for Beginners | AWS Training | SimplilearnSimplilearn

What is true here

Each control defends against exactly one threat — list the threat beside it to find the gap.
Backups belong in a separate account, immutable, unreachable from the workload's roles.
Replication is not backup: corruption propagates within seconds.
Sensitivity and availability are independent dials, and copies inherit both.
Lifecycle rules run themselves; expire noncurrent versions or the bucket grows unbounded.

What you will be able to do

Map each data-protection control to the specific threat it addresses, and find what is uncovered
Design a backup posture that survives a compromised administrator
Set a retention period from how late a problem can be discovered
Classify a data store on both dials and carry that classification to its copies
Write lifecycle rules that tier and expire without costing more than they save

From one control per threat to data that ages on schedule

Backups, retention, immutability

Sensitivity and availability

Hot, warm, cold, archival

Data Protection and Backup Strategy

One mechanism per threat and where the gaps are, classifying data on sensitivity and availability, and lifecycle policies that move and expire data on schedule.

Backups, Retention, Immutability, and Recovery Testing

coreadvanced

Data protection is several independent mechanisms that people often treat as one. Encryption protects data from being read. Backups and snapshots protect against loss and corruption. Replication protects against losing a location. Versioning and immutability protect against deletion — including deliberate deletion. Only recovery testing tells you whether any of it works.

Think of it as

Each mechanism defends against exactly one thing. Encryption does not help if the data is deleted; replication does not help if the data is wrong; a backup does not help if nobody can restore it. Listing the threat next to each control is what exposes the gap.

What we're doing: Design a backup posture that survives a compromised administrator.

ransomware-posture.txttext

Threat: an attacker with administrator credentials in the production
account, deliberately deleting data and its backups.

Encryption: no help. The attacker is authorized.
Same-account snapshots: no help. They can be deleted.
Cross-Region replication: no help. Deletions and corruption propagate.

What does help:
  - copies in a separate backup account the production role cannot reach
  - immutability (Object Lock / vault lock) so even that account's
    administrator cannot delete within the retention period
  - S3 versioning, and delete markers not replicated by default
  - an alarm on deletion attempts against the backup account

1: This is the threat model that separates a real backup strategy from a collection of snapshots.
5: Three controls, all correctly configured, none of which addresses this threat — the point of listing the threat next to each control.
9: AWS names the cross-account copy capability as helping specifically against insider threats and account compromise.

Why this works: Most backup setups defend against accident and hardware failure, which is right and incomplete. Deliberate deletion by an authorized principal is defeated only by separation (another account) plus immutability (a retention period nobody can shorten), and both have to be decided in advance.

Keeping backups in the account they back up

Wrong

text

# Daily snapshots, in the same account, deletable by the same roles

Better

text

# AWS Backup copying to a dedicated backup account, with immutability
# and no path from production roles

What you see: A single compromised or mistaken administrator can destroy both the data and every copy of it, in one account, with the permissions they legitimately hold.

Why: A backup in the same trust boundary as the data shares its fate. AWS provides cross-account copy specifically for this, and the separation only works if no production role can reach the destination — otherwise the second account is a copy of the first account's risk.

One mechanism per threat

Encryption

Threat: someone reads the data. Does nothing about loss.

Backups / snapshots

Threat: corruption or loss. Point-in-time, unlike replication.

Replication

Threat: losing a Region. Copies corruption faithfully.

Versioning + immutability

Threat: deletion, including deliberate. Protects the copies themselves.

Recovery testing

Threat: all of the above being broken and nobody knowing.

Control, threat, and what it does not cover

Control, threat, and what it does not cover
Control	Protects against	Does not protect against
Encryption at rest	Data being read from the underlying media	Deletion, corruption, or an authorized principal reading it
Snapshot / backup	Corruption and accidental loss, at a point in time	Anything after the last snapshot
Cross-Region replication	Losing a Region	Corruption — it replicates faithfully
S3 versioning	Overwrite and delete, including by mistake	A principal who can also delete versions
Object Lock / immutable backups	Deletion by anyone, including an administrator	Storage cost, which it makes unavoidable
Cross-account backup copy	Account compromise and insider threat	A compromise of the destination account
Deletion protection	Accidental `delete-db-instance` and stack deletion	A deliberate two-step deletion

Together

text

# The gap this table exposes, in one sentence
We have encryption, replication, and daily snapshots — and an attacker
with the backup role can delete every snapshot, because nothing here is
immutable and nothing is in another account.

Remember: One mechanism per threat: encryption for reading, backups for corruption, replication for losing a location, versioning and immutability for deletion, testing for all of it. Copies belong in another account with immutability, and retention should be set by how late a problem can be discovered.

Classifying Data by Sensitivity and Availability

standardintermediate

Not all data deserves the same protection, and treating it uniformly means either overspending on everything or under-protecting the part that matters. Classification asks two separate questions: how bad is it if this leaks, and how bad is it if this is unavailable. The answers rarely match, and each drives different controls.

Think of it as

Two dials, not one. A public product catalogue is low sensitivity and high availability — losing it is an outage, leaking it is nothing. An old payroll export is high sensitivity and low availability. Controls follow the dials, and a single "important" label collapses them into a guess.

text

# The two questions, per data store
1. If this leaked, what happens?     -> sensitivity controls
2. If this were unavailable, what?   -> availability controls
# Then check: do the logs, backups, and analytics copies match?

Classifying the primary store and forgetting its copies

Wrong

text

# The customer table is "restricted". The nightly export to the
# analytics bucket is untagged.

Better

text

# Derived data inherits the source's classification — and so do logs,
# backups, and anything a pipeline writes downstream

What you see: Access to the primary database is tightly controlled and the same fields are readable by anyone with analytics access, in a bucket nobody classified.

Why: Classification is applied to stores people think of as "the data", while copies are created by pipelines and operational tooling that nobody reviews for sensitivity. Since a copy is as readable as the original, the effective protection of a classified store is the weakest of all its copies.

Two dials, and the controls each one drives

Two dials, and the controls each one drives
Data	Sensitivity	Availability need
Public product catalogue	Low — encryption at rest, broad read	High — replicated, cached, CDN-fronted
Customer PII	High — customer-managed KMS key, scoped access, access logging	High — multi-AZ, tested restores
Payment card data	Highest — tokenized or never stored, strict scope	Medium — availability matters less than not holding it
Application logs	Medium — inherits whatever the app logged	Low — recent matters, old rarely read
Old analytics exports	Inherited from the source, usually high	Low — archival storage is fine
Build artifacts	Low	Medium — rebuildable, but not during an incident

Together

text

# Classification as a tag, so it can drive policy automatically
DataClassification = public | internal | confidential | restricted
AvailabilityTier   = tier1 | tier2 | tier3
# Config rules, backup plans, and KMS key selection can all read these.

Remember: Ask two independent questions — what if it leaks, and what if it is unavailable — because the answers differ and drive different controls. Make the classification a tag so it can drive policy, and check that logs, backups, and analytics copies carry it too.

Lifecycle Policies for Hot, Warm, Cold, and Archival Data

standardintermediate

Data gets colder with age: read constantly, then occasionally, then almost never, then only if someone asks. Storage classes mirror that, trading retrieval speed and cost for storage price. A lifecycle policy moves objects between them automatically, which is the only mechanism that keeps up — nobody remembers to tier data by hand.

Think of it as

A desk, a drawer, a filing cabinet, and offsite storage. Each step is cheaper to keep and slower to retrieve. The mistake is not choosing wrongly; it is leaving everything on the desk because moving it was never anyone's job.

What we're doing: See why tiering aggressively can cost more, not less.

minimum-duration.txttext

Rule: transition every object to an archival class after 1 day.

The bucket holds build artifacts that are deleted after 5 days.

Colder classes have a minimum storage duration. Objects deleted before
it still incur the charge for the full minimum period — plus the
transition request charge for every object, of which there are millions.

Result: a bucket that cost $40/month now costs several hundred.

1: A rule that looks maximally efficient and is the opposite, because the objects never live long enough to benefit.
5: Two separate charges — the minimum duration and the per-object transition request — and both scale with object count rather than with size.

Why this works: Lifecycle economics depend on object lifetime and object count, not only on total bytes. Tiering pays off for data that is large, long-lived, and rarely read; for small, short-lived, numerous objects, the transition costs can exceed the storage saved.

Enabling versioning without a noncurrent-version expiry

Wrong

text

# Versioning: enabled. Lifecycle: none.

Better

text

# Versioning enabled, plus NoncurrentVersionExpiration (and a
# transition for noncurrent versions if they are large)

What you see: The bucket size grows steadily while the object count stays flat, because every overwrite retains a full previous version that nothing ever removes.

Why: Versioning is a protection mechanism that stores data indefinitely by design — the previous version is kept precisely so a deletion can be undone. Without an expiry rule the retained versions are unbounded, and they are invisible in the ordinary object listing that people check.

The same object, over a year

Day 0–30
Hot
Read constantly — standard storage, immediate access
Day 31–90
Warm
Occasional access — infrequent-access class, lower storage price
Day 91–365
Cold
Rarely read — archival class, retrieval takes minutes to hours
Day 366
Expire or deep archive
Deleted, unless retention or regulation says otherwise

Choosing a tier by access pattern

Choosing a tier by access pattern
Pattern	Tier	Watch out for
Read many times a day	Hot / standard	Nothing — this is what it is for
Read a few times a month	Warm / infrequent access	Per-retrieval charges if access is higher than expected
Read a few times a year	Cold / archive	Minimum storage duration, and retrieval latency
Kept only for compliance	Deep archive, with immutability	Bulk retrieval cost if an audit needs all of it
Unpredictable access	Intelligent tiering	A small per-object monitoring charge
Noncurrent versions	Expire on a shorter schedule than current	Unbounded growth if never expired

Together

json

{
  "Rules": [{
    "ID": "tier-and-expire-exports",
    "Filter": { "Prefix": "exports/" },
    "Status": "Enabled",
    "Transitions": [
      { "Days": 30, "StorageClass": "STANDARD_IA" },
      { "Days": 90, "StorageClass": "GLACIER" }
    ],
    "Expiration": { "Days": 1095 },
    "NoncurrentVersionExpiration": { "NoncurrentDays": 30 }
  }]
}

Remember: Hot, warm, cold, archival — and a lifecycle rule to move data between them, because nobody does it by hand. Watch minimum storage durations, per-object transition charges, and retrieval cost, and always expire noncurrent versions when versioning is on.