Data Protection and Backup Strategy

One control per threat, classification by two dials, and lifecycle tiers that run themselves

One mechanism, one threatencryption does nothing about deletion
Backups belong in another accountimmutable, unreachable from production
Sensitivity and availability differtwo independent dials, two sets of controls
Lifecycle rules, not intentionsnobody tiers data by hand

1.Backups, Retention, Immutability, and Recovery Testing

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.

Key features

AWS Backup centralizes configuration, scheduling, and monitoring across EBS, EC2, RDS, DynamoDB, EFS, Storage Gateway, and FSx, and supports copying backups across Regions and accounts
Cross-account backup copies specifically help protect against disaster events that include insider threats or account compromise
S3 object versioning retains the original version before a deletion or modification, which AWS calls a useful mitigation for human-error disasters
By default an S3 delete in a replicated source bucket adds a delete marker in the source bucket only, protecting the destination Region from malicious deletions in the source
Continuous replication gives near-zero backup time but may not protect against corruption or malicious deletion as well as point-in-time backups
AWS Backup offers restore but does not currently schedule or automate it, so restore testing has to be built with the SDK; for EC2 it also stores instance type, VPC, security group, IAM role, monitoring configuration, and tags, though that metadata is only used when restoring into the same Region

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

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.

Signature

encryption (read) · backups (corruption) · replication (location) · versioning + immutability (deletion) · testing (all)

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.

2.Classifying Data by Sensitivity and Availability

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.

Key features

Sensitivity drives encryption key choice, access scope, logging, and whether the data may be replicated or exported at all
Availability need drives replication, backup frequency, and the RPO and RTO for that data specifically
The two are independent: high-sensitivity data is often low-availability, and the most available data is often the least sensitive
Classification has to be visible at runtime to be useful — a tag on the resource, a bucket prefix convention, or separate accounts
Derived data inherits the classification of its inputs, which is how PII ends up in an analytics store that was never classified
Logs, backups, and analytics copies carry the same classification as the source, and are the three places it is most often forgotten

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

Command

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?

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.

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

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.

Key features

Storage classes trade retrieval latency and per-request cost against storage price — colder is cheaper to keep and more expensive or slower to read
Lifecycle rules act on age or on tags, and can transition, expire, or both, without anyone running anything
Colder classes usually carry a minimum storage duration, so moving short-lived objects down can cost more than leaving them
Expiring noncurrent versions matters as much as expiring current ones — versioning without expiry grows without limit
Retrieval cost is the part people forget: archival storage is cheap to hold and can be expensive and slow to read in bulk
A lifecycle policy is also a data-protection control — expiring data on schedule is how "we do not keep it longer than we need" becomes true rather than aspirational

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

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

Signature

hot → warm (IA) → cold (archive) → expire · plus NoncurrentVersionExpiration whenever versioning is on

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.

Spotted a mistake on this page? Tell us.

Read Sheet