AWS Backup
A centralized backup service covering EBS, RDS, DynamoDB, EFS, and more — one policy instead of configuring backup separately per service.
Want a visual for this topic?
Generate a diagram tailored to AWS Backup — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what problem AWS Backup solves compared to each service's own native backup feature
- •Configure a backup plan with a schedule and retention policy
- •Explain cross-Region and cross-account backup copy for disaster recovery
What is it?
AWS Backup is a centralized, fully managed backup service that lets you define backup policies once and apply them across many different AWS services — EBS, RDS, DynamoDB, EFS, FSx, and more — instead of configuring and managing each service's own native backup feature separately.
Why it exists
Before AWS Backup, achieving a consistent backup policy (schedule, retention, encryption) across a modern application's typically many different data stores (an RDS database, several EBS volumes, a DynamoDB table, an EFS file system) meant configuring each service's own separate backup mechanism individually, with no unified view of overall backup compliance across everything. AWS Backup exists to unify this into one policy-driven service with one place to monitor compliance.
Problem it solves
It solves the backup-fragmentation problem (one consistent policy applied across many services instead of N separately-configured, easy-to-drift-out-of-sync backup mechanisms), the compliance-visibility problem (a single dashboard showing whether every covered resource actually has a compliant backup, rather than checking each service individually), and the DR-copy problem (built-in support for copying backups to a different Region or account, essential for genuine disaster recovery beyond a single-Region backup).
Intuition
Before AWS Backup, managing backups across a modern application was like each department in a company keeping its own separate backup schedule and process — accounting backs up weekly, engineering backs up daily, and nobody has one clear picture of the whole company's actual backup posture. AWS Backup is like a single, company-wide backup policy and dashboard covering every department consistently, with one place to see 'are we actually protected everywhere we need to be.'
Analogy
A company-wide insurance policy covering every office location under one consistent plan and one bill, instead of each individual office manager independently shopping for and managing their own separate insurance policy with potentially inconsistent coverage and no unified visibility for the company as a whole.
Technical explanation
A Backup Plan defines one or more backup rules (schedule via cron expression, lifecycle transitioning to cold storage after a period, and retention duration), and Resource Assignment determines which resources the plan applies to — either explicit resource selection or, more scalably, tag-based assignment (e.g. every resource tagged backup-policy=daily automatically gets covered, including newly created resources matching that tag with no manual per-resource configuration needed). Cross-Region copy and Cross-Account copy let a backup plan automatically replicate recovery points to a different Region or a separate, dedicated backup AWS account — the latter specifically protecting against a scenario where the primary account itself is compromised, since a backup stored only within the same account offers no protection if that account's credentials are compromised and the backups themselves are deleted.
Architecture
A company tags every production resource requiring backup with backup-tier=critical or backup-tier=standard, and defines two AWS Backup plans matching those tags: the critical tier backs up every 4 hours with 90-day retention and cross-Region copy to their DR Region; the standard tier backs up daily with 30-day retention and no cross-Region copy. New resources tagged appropriately are automatically covered with zero manual backup configuration, and the AWS Backup compliance dashboard gives the security team one place to confirm every tagged resource actually has a compliant, recent recovery point.
Workflow
- Define Backup Plans matching your actual retention and frequency requirements (which may differ per data criticality tier, similar to how DR strategy varies by system). 2) Use tag-based resource assignment where possible, so newly created resources are automatically covered without manual per-resource setup. 3) Enable Cross-Region copy for any backup that needs to support a genuine disaster recovery scenario beyond a single-Region failure. 4) Consider Cross-Account copy to a dedicated backup account for the strongest protection against a compromised primary account. 5) Regularly review the AWS Backup compliance dashboard and periodically test actual restores, not just confirm backups are being created.
Example
A healthcare company's compliance requirements mandate that patient data be recoverable even in the event of a full account compromise. They configure AWS Backup with Cross-Account copy, replicating every backup to a separate, tightly access-restricted AWS account used exclusively for backup storage — even if an attacker fully compromised their primary production account (including deleting all backups there), the cross-account copies remain safe and recoverable.
Real-world usage
AWS Backup is increasingly the standard recommendation for centralizing backup policy across multi-service AWS applications, documented in AWS's own reliability and compliance guidance; cross-account backup copy is a common pattern specifically recommended for ransomware/compromise resilience, since it protects backup data even from an attacker who's gained full control of the primary account.
Trade-offs
Centralizing backup policy in AWS Backup provides consistency and unified visibility, but adds a layer of abstraction on top of each service's own native backup capability — teams needing very fine-grained, service-specific backup control might still prefer that service's native mechanism for specific edge cases, using AWS Backup for the broader, consistent baseline. Cross-account copy provides meaningfully stronger protection against a compromised primary account, but adds real setup complexity (managing a separate backup account) compared to same-account backup alone.
Visual explanation
Picture a Backup Plan (a defined schedule and retention rule, e.g. 'daily backup, retain 35 days, weekly backup retained 1 year') applied via tags or explicit resource selection across a mix of resources — some EBS volumes, an RDS instance, a DynamoDB table — all governed by that single plan. AWS Backup automatically creates and manages backups (called 'recovery points') for every covered resource according to that one schedule, visible together in one compliance dashboard.
Advantages
- —
One consistent backup policy applied across many different AWS services instead of configuring each separately
- —
Tag-based resource assignment automatically covers newly created resources with no manual per-resource backup setup
- —
Centralized compliance dashboard gives one clear view of backup coverage across the whole environment
- —
Cross-account copy protects backup data even against a fully compromised primary account, a genuine ransomware-resilience benefit
Disadvantages
- —
AWS Backup itself has a cost (storage plus, in some cases, backup/restore request charges) on top of whatever the underlying resource's own cost already is
- —
Not every AWS service or every specific configuration option is covered by AWS Backup — some services still require their own native backup mechanism for full control
- —
Tag-based assignment requires consistent, disciplined tagging practice across the organization to actually provide the comprehensive coverage it promises
- —
Centralizing backup policy in one service is only valuable if that policy is actually correctly configured and monitored — misconfiguration here affects backup coverage broadly, not just one resource
Common mistakes
- —
Configuring AWS Backup plans but never actually testing a restore, only discovering a configuration gap or corrupted backup during a real, urgent recovery need
- —
Relying on inconsistent, manual tagging for resource assignment, leaving some critical resources accidentally uncovered by any backup plan
- —
Keeping all backups only within the same account as the primary resources, providing no protection if that account itself is compromised or its credentials leaked
- —
Not aligning backup frequency/retention with the actual RPO requirement determined during DR strategy planning — backing up daily when the real RPO requirement is much tighter than that
- —
Ignoring the AWS Backup compliance dashboard's warnings about resources with expired or missing recent recovery points
In the AWS Console
- 1
AWS Console → AWS Backup → Backup plans → Create backup plan
Define backup rules — schedule (cron expression), lifecycle (transition to cold storage timing), and retention period.
Match the schedule and retention to your actual RPO/compliance requirements for that resource tier, not an arbitrary default.
- 2
AWS Backup → [your plan] → Resource assignments → Assign resources
Choose tag-based assignment (recommended for scalability) or explicit resource selection, specifying which resources this plan covers.
Tag-based assignment automatically covers future resources matching the tag — explicit selection requires manually adding every new resource.
- 3
AWS Backup → [your plan] → Copy to another Region / account
Add a copy destination rule specifying a different Region or a separate backup account for cross-Region/cross-account replication of recovery points.
Cross-account copy requires setting up the destination account to accept backup copies via AWS Backup's cross-account management features first.
- 4
AWS Backup → Jobs / Compliance
Review backup job success/failure history and the compliance dashboard for resources missing a compliant recent recovery point.
Periodically perform an actual test restore from a recovery point, not just confirming backup jobs report success — a successful backup job doesn't guarantee the data is actually restorable.
🎤 Interview questions
What problem does AWS Backup solve compared to using each service's own native backup feature separately? (Listen for: unifies backup policy, scheduling, and compliance visibility across many services into one consistent, centrally-managed system instead of N separately configured mechanisms.)
How does tag-based resource assignment in AWS Backup help at scale? (Listen for: newly created resources matching the tag are automatically covered by the backup plan with no manual per-resource configuration needed.)
Why would you configure cross-account backup copy specifically? (Listen for: protects backup data even against a fully compromised primary account — an attacker with full primary-account access still can't delete backups stored in a separate, access-restricted account.)
How should backup frequency and retention be determined for a given resource? (Listen for: driven by that resource's actual RPO requirement from DR strategy planning, not an arbitrary default applied uniformly everywhere.)
What's a common mistake teams make with AWS Backup (or backups generally) that only becomes apparent during an actual disaster? (Listen for: never testing an actual restore — a backup job reporting 'success' doesn't guarantee the data is genuinely recoverable when it's actually needed.)