The Problem With DIY Backup Scripts
Imagine you own a chain of restaurants and each location keeps its own safety records in a different filing system — some in binders, some in spreadsheets, some in a manager's head. When a health inspector arrives and asks "prove every location is compliant," you have no single answer. That is exactly what AWS backup looked like before AWS Backup existed.
Before AWS Backup, protecting data meant writing custom Lambda functions, CloudWatch Events, and shell scripts — one per resource type. A typical setup looked like this:
- A Lambda function to snapshot EBS volumes every night
- A separate Lambda for RDS automated snapshots
- Another script to purge snapshots older than 30 days
- A DynamoDB table to track what was backed up and when
Each script was a liability. If a new RDS instance was created and someone forgot to add it to the script, it would go unprotected indefinitely. You would only discover the gap when you needed to restore — the worst possible moment.
What AWS Backup Actually Is
AWS Backup is a fully managed, policy-driven service that centralizes backup management across AWS resources. Instead of writing per-resource scripts, you define a Backup Plan — a policy that says "back up daily, retain for 30 days, copy to another region" — and then apply it to resources using tags.
The three core concepts are:
| Concept | What It Is | Analogy |
|---|---|---|
| Backup Plan | The policy (schedule + retention + copy rules) | An insurance policy document |
| Backup Vault | The encrypted storage container for recovery points | A fireproof safe |
| Recovery Point | A single backup snapshot of a resource | A photo of your data at a point in time |
Tag-based assignment is the key operational insight. You tag any resource — an EBS volume, an RDS database, an EFS file system, a DynamoDB table, an S3 bucket — with something like Backup: Daily, and AWS Backup automatically discovers and protects it. New resources that get the tag are automatically enrolled. Resources that lose the tag stop being backed up.
Resource Tags:
Backup: Daily → enrolled in the "Daily" plan
Backup: Hourly → enrolled in the "Hourly" plan
(no Backup tag) → not protected
Supported Resource Types
AWS Backup supports a broad and growing set of services:
- Compute & Storage: EC2 instances, EBS volumes, EFS file systems, FSx file systems, S3 buckets
- Databases: RDS instances, Aurora clusters, DynamoDB tables, DocumentDB, Neptune
- Hybrid: VMware workloads on-premises via AWS Backup Gateway
This breadth matters architecturally: a single Backup Plan can protect your entire application stack — database, file system, and block storage — under one consistent policy.
Audit and Compliance Reporting
AWS Backup integrates with AWS Backup Audit Manager, which continuously evaluates your backup posture against compliance controls. It can answer questions like:
- "Are all production resources covered by a backup plan?"
- "Were any backups deleted in the last 30 days?"
- "Do all vaults have encryption enabled?"
These reports can be exported to S3 and fed into compliance dashboards, replacing the manual evidence-gathering that used to consume days before an audit.
Interviewers often ask: "How would you ensure every new database in your AWS account is automatically backed up?" The answer is tag-based assignment with AWS Config rules. You create a Backup Plan that selects resources by tag, enforce the tag on all RDS instances using an AWS Config rule with auto-remediation, and use Backup Audit Manager to detect any gaps. This is a defense-in-depth answer that shows operational maturity.
Key Point: The shift from scripts to policies is not just about convenience — it is about eliminating the class of failure where a resource is silently unprotected. Tag-based enrollment means the default is "opt in by tagging" rather than "opt in by remembering to update a script." For large organizations with hundreds of accounts, this difference is the gap between a defensible backup posture and a compliance disaster.