AWS Backup turns a scattered mess of service-specific snapshot schedules into one policy engine that covers EC2, EBS, RDS, DynamoDB, EFS, FSx, S3, Storage Gateway, Redshift, Neptune, DocumentDB, Timestream, CloudFormation stacks, and even SAP HANA on EC2 and VMware virtual machines. Instead of babysitting eight different backup consoles, you build one backup plan, attach resources by tag, and let AWS Backup handle the scheduling, lifecycle transitions, cross-region copies, and retention enforcement. This tutorial walks through a real deployment: creating a backup vault, writing a tag-based backup plan, locking it down with Vault Lock for compliance, running a restore test, and reading the actual bill afterward.
By the end you will have a working backup plan protecting EBS volumes and an RDS database, a second vault in another region receiving encrypted copies, a legal hold demonstration, and a cost breakdown based on AWS’s published September 2026 pricing. Every number below comes from AWS’s own pricing and documentation pages, cited inline, so you can sanity-check the math before you commit a production workload to it.
What AWS Backup actually replaces
Before AWS Backup existed, teams wired together EBS Lifecycle Manager for volume snapshots, RDS automated backups for databases, a Lambda cron job for DynamoDB on-demand backups, and a separate script for EFS. Each tool had its own retention syntax, its own IAM permissions model, and its own audit trail — or no audit trail at all. AWS Backup consolidates that into a single service with backup vaults (encrypted, access-controlled storage containers for recovery points), backup plans (the schedule plus lifecycle rules), and resource assignments (which resources a plan protects, usually by tag).
As of September 2026, AWS Backup officially supports Amazon EC2, EBS, RDS, Aurora, DynamoDB, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS, FSx for NetApp ONTAP, AWS Storage Gateway, Amazon S3, Redshift, Neptune, DocumentDB, Timestream, CloudFormation stacks, SAP HANA databases running on EC2, and VMware virtual machines through the gateway-based virtual machine feature, according to AWS’s feature availability documentation. That is a wider surface than most teams realize exists in a single backup product, and it is the reason AWS Backup keeps showing up in cloud disaster-recovery audits: one IAM policy, one CloudTrail trail, one place to prove compliance.
This guide targets an account running a typical web app stack: EC2 instances behind an ALB, EBS-backed root volumes, and an RDS PostgreSQL database. The same backup plan structure extends to DynamoDB tables and EFS file systems with one extra resource-selection rule, which the guide covers in Step 7.
Prerequisites and versions
Confirm you have the following before starting. None of this requires an Enterprise support plan — AWS Backup is available on every AWS account tier.
- An AWS account with administrator access, or an IAM role with
backup:*,backup-storage:*, and read/write access to the resources you plan to protect (EC2, RDS, DynamoDB, etc.) - AWS CLI v2 (build 2.31 or later recommended) installed and configured with
aws configure - At least one EBS volume and one RDS instance already running in your account — this tutorial protects existing resources rather than provisioning new ones
- A second AWS region enabled in your account for the cross-region copy steps (this tutorial uses us-east-1 as primary and us-west-2 as the copy destination)
- Resources tagged consistently — this tutorial uses the tag
backup-tier=productionto drive resource assignment - Roughly 90 minutes: 45 minutes for the initial plan and vault setup, 30 minutes waiting on the first backup job, 15 minutes for the restore test
You do not need to pre-create an IAM role for AWS Backup itself — the console offers to create the default service role (AWSBackupDefaultServiceRole) automatically during vault or plan creation, and this tutorial uses that default role rather than a hand-rolled one, since AWS maintains its permission set as new resource types are added.
Step 1: Create your primary backup vault
A backup vault is the encrypted container that holds recovery points. Every backup plan writes into a vault, and every vault is tied to a single AWS KMS key. Start in the AWS Backup console, or from the CLI:
aws backup create-backup-vault
--backup-vault-name production-vault
--encryption-key-arn arn:aws:kms:us-east-1:123456789012:key/abcd1234-a123-456a-a12b-a123b4cd56ef
--backup-vault-tags Environment=production,Team=platform
--region us-east-1If you skip --encryption-key-arn, AWS Backup creates and uses an AWS-managed KMS key scoped to the service. For compliance workloads, use a customer-managed key so you control the key policy and rotation schedule independently. Verify the vault exists:
aws backup describe-backup-vault --backup-vault-name production-vault --region us-east-1Example output:
{
"BackupVaultName": "production-vault",
"BackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:production-vault",
"EncryptionKeyArn": "arn:aws:kms:us-east-1:123456789012:key/abcd1234-a123-456a-a12b-a123b4cd56ef",
"CreationDate": "2026-09-23T14:02:11.000Z",
"NumberOfRecoveryPoints": 0,
"Locked": false
}Per AWS’s published quotas, an account can hold up to 300 backup and logically air-gapped vaults per Region, and each vault can hold up to 1,000,000 recovery points, according to the AWS Backup quotas documentation. For most teams, three or four vaults (production, staging, compliance-locked, and a cross-region copy target) is plenty — don’t create a vault per resource type unless you have a specific access-control reason to isolate them.
Step 2: Create a second vault in your copy-destination region
Cross-region copy needs a destination vault before you can reference it in a backup plan. Switch regions and repeat:
aws backup create-backup-vault
--backup-vault-name production-vault-dr
--backup-vault-tags Environment=production,Purpose=disaster-recovery
--region us-west-2Note the vault’s ARN — you’ll reference it in the backup plan’s copy action in Step 5. Cross-region data transfer is billed to the account moving the data out, and there is no inter-region charge for copies that stay within the same Region, per AWS Backup’s pricing page.
Step 3: Write a backup plan with the CLI or a JSON template
A backup plan defines when backups run, where they go, how long they’re kept, and when they transition to cold storage. AWS Backup plans are easiest to version-control as JSON. Save this as backup-plan.json:
{
"BackupPlan": {
"BackupPlanName": "production-daily-plan",
"Rules": [
{
"RuleName": "daily-7am-utc",
"TargetBackupVaultName": "production-vault",
"ScheduleExpression": "cron(0 7 * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 180,
"Lifecycle": {
"MoveToColdStorageAfterDays": 30,
"DeleteAfterDays": 120
},
"CopyActions": [
{
"DestinationBackupVaultArn": "arn:aws:backup:us-west-2:123456789012:backup-vault:production-vault-dr",
"Lifecycle": {
"MoveToColdStorageAfterDays": 30,
"DeleteAfterDays": 120
}
}
]
}
]
}
}Two lifecycle rules matter here. First, AWS Backup enforces a minimum 90-day cold storage residency — the gap between MoveToColdStorageAfterDays and DeleteAfterDays must be at least 90 days, or the API rejects the plan, per the AWS Backup plan configuration documentation. Second, snapshot retention can range anywhere from 1 day to 100 years (or indefinitely if left unset), while continuous-backup retention for point-in-time recovery tops out at 35 days. Create the plan:
aws backup create-backup-plan --backup-plan file://backup-plan.json --region us-east-1The response returns a BackupPlanId and VersionId — save both. Backup plans are versioned in AWS Backup, so every edit creates a new version rather than overwriting history, which is useful when an auditor asks what the retention policy was six months ago.
Step 4: Assign resources to the plan by tag
Tag-based assignment is the difference between AWS Backup being a chore and being invisible infrastructure. Instead of listing individual EBS volume IDs or RDS instance ARNs, you assign the plan to anything carrying a specific tag, and new resources inherit protection automatically the moment someone applies the tag.
aws backup create-backup-selection
--backup-plan-id 8f3c2b1a-4d5e-6f70-8192-a3b4c5d6e7f8
--backup-selection '{
"SelectionName": "tag-based-production",
"IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
"ListOfTags": [
{
"ConditionType": "STRINGEQUALS",
"ConditionKey": "backup-tier",
"ConditionValue": "production"
}
]
}'
--region us-east-1Now tag your EBS volume and RDS instance:
aws ec2 create-tags --resources vol-0abcd1234efgh5678 --tags Key=backup-tier,Value=production
aws rds add-tags-to-resource
--resource-name arn:aws:rds:us-east-1:123456789012:db:prod-postgres
--tags Key=backup-tier,Value=productionWithin a few minutes, both resources appear under the plan’s protected resources list in the console. If a resource doesn’t show up, check that the resource type is actually supported by AWS Backup in your Region — coverage varies slightly by Region, and the feature availability table is the definitive source rather than assuming parity across Regions.
Step 5: Verify the first on-demand backup job before waiting on the schedule
Don’t wait until 7am UTC to find out your IAM role is missing a permission. Trigger an on-demand backup against one tagged resource immediately:
aws backup start-backup-job
--backup-vault-name production-vault
--resource-arn arn:aws:ec2:us-east-1:123456789012:volume/vol-0abcd1234efgh5678
--iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole
--region us-east-1Poll the job status:
aws backup list-backup-jobs --by-resource-arn arn:aws:ec2:us-east-1:123456789012:volume/vol-0abcd1234efgh5678 --region us-east-1Expect a state transition from CREATED to RUNNING to COMPLETED within a few minutes for a small EBS volume. If it lands on FAILED, the StatusMessage field almost always points directly at the missing IAM permission or an unsupported resource state (for example, an EBS volume mid-modification cannot be backed up until the modification finishes).
Step 6: Lock the vault with AWS Backup Vault Lock for compliance retention
Vault Lock adds write-once-read-many (WORM) protection: once locked in compliance mode, nobody — including the account root user — can delete a protected recovery point before its retention period expires. This is the feature auditors ask about by name when a SOC 2 or HIPAA review touches backup integrity.
aws backup put-backup-vault-lock-configuration
--backup-vault-name production-vault
--min-retention-days 30
--max-retention-days 365
--changeable-for-days 3
--region us-east-1The --changeable-for-days parameter is the safety valve: for that many days after you run this command, the lock is still in “governance mode” and can be removed or loosened. After the grace period expires, the lock moves to compliance mode and becomes effectively permanent, according to AWS’s Vault Lock documentation. Use the grace period to confirm your retention math is right — a three-day window is long enough to test the plan against real backup jobs before it becomes irreversible. Do not lock a vault you’re still actively testing plan changes against.
Step 7: Extend the plan to DynamoDB and EFS resources
The same backup plan covers additional resource types without a separate schedule. Add a second selection rule scoped to a different tag if you want DynamoDB tables on a different retention window than EBS volumes — for example, DynamoDB tables holding transactional data might need 35-day continuous point-in-time recovery, while EBS root volumes only need weekly cold-storage snapshots:
aws backup create-backup-selection
--backup-plan-id 8f3c2b1a-4d5e-6f70-8192-a3b4c5d6e7f8
--backup-selection '{
"SelectionName": "dynamodb-continuous",
"IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
"ListOfTags": [
{
"ConditionType": "STRINGEQUALS",
"ConditionKey": "backup-tier",
"ConditionValue": "dynamodb-critical"
}
]
}'
--region us-east-1Tag your DynamoDB table and EFS file system the same way as the EC2/RDS examples in Step 4. This is the core value proposition: one plan, one vault, one audit trail, regardless of how many AWS services your application actually touches.
Step 8: Enable AWS Backup Audit Manager
Audit Manager continuously evaluates your backup activity against controls you define — backup frequency, retention length, recovery point age, cross-region copy presence, and resource coverage — and produces a report you can hand to a compliance team instead of manually screenshotting the console. Teams that already run Amazon Macie for sensitive data discovery often plug Audit Manager’s reports into the same compliance dashboard, since both services feed the same kind of evidence trail auditors ask for.
aws backup create-framework
--framework-name production-backup-controls
--framework-controls '[
{
"ControlName": "BACKUP_RESOURCES_PROTECTED_BY_BACKUP_PLAN",
"ControlScope": {"Tags": {"backup-tier": "production"}}
},
{
"ControlName": "BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK",
"ControlInputParameters": [
{"ParameterName": "requiredFrequencyValue", "ParameterValue": "1"},
{"ParameterName": "requiredFrequencyUnit", "ParameterValue": "days"},
{"ParameterName": "requiredRetentionDays", "ParameterValue": "30"}
]
}
]'
--region us-east-1Once the framework is active, AWS Backup Audit Manager evaluates each control on a rolling basis and flags any protected resource that drifts out of compliance — for instance, a database that stops getting daily backups because someone removed its tag. This is documented behavior per AWS’s Audit Manager guide.
Step 9: Run a restore test before you need it for real
Restore Testing schedules automated restore attempts against your recovery points and records whether they actually succeeded — catching the scenario where backups have been “completing successfully” for months but the underlying data is corrupted or unrestorable.
aws backup create-restore-testing-plan
--restore-testing-plan '{
"RestoreTestingPlanName": "weekly-restore-validation",
"ScheduleExpression": "cron(0 9 ? * MON *)",
"RecoveryPointSelection": {
"Algorithm": "LATEST_WITHIN_WINDOW",
"RecoveryPointTypes": ["SNAPSHOT"],
"IncludeVaults": ["production-vault"],
"SelectionWindowDays": 7
}
}'
--region us-east-1Restore Testing restores into a temporary, isolated resource, validates the restore completed, and then cleans up. If the tested recovery point happens to be in cold storage, the restore incurs cold-storage restore pricing rather than warm-storage pricing — a detail worth knowing before you schedule weekly tests against a vault where most recovery points have already transitioned to cold, per AWS’s pricing page.
Step 10: Apply a legal hold when you need indefinite retention
Legal holds override normal lifecycle deletion — a recovery point under legal hold cannot be deleted even after its retention period expires, until the hold is explicitly released. This matters during litigation, active security incidents, or regulatory investigations where you cannot risk evidence rotating out on schedule.
aws backup create-legal-hold
--title "incident-2026-09-litigation-hold"
--description "Preserving all production recovery points pending legal review"
--recovery-point-selection '{"VaultNames": ["production-vault"]}'
--region us-east-1Release it explicitly once the hold is no longer needed — legal holds do not expire on their own, and forgetting an active hold is a common cause of unexpectedly high storage bills months later.
Step 11: Read the actual invoice
AWS Backup pricing is per resource type, per storage tier, in US East (N. Virginia) as of September 2026. This is the number most tutorials skip and the number that actually matters when you’re deciding retention windows.
| Resource type | Warm storage (per GB-month) | Cold storage (per GB-month) | Restore cost |
|---|---|---|---|
| Amazon EBS | $0.05 | $0.0125 | Warm restores free for EBS/RDS in most cases |
| Amazon RDS / Aurora | $0.095 | Varies by engine | Billed per GB restored |
| Amazon DynamoDB | $0.10 | Not applicable (continuous backup) | Billed per GB restored |
| Amazon EFS | $0.05 | $0.01 | $0.02/GB warm, $0.03/GB cold |
Sources: AWS Backup pricing and AWS’s EFS backup cost-optimization blog post. Note the 90-day minimum cold storage residency covered in Step 3 — moving data to cold storage and deleting it 30 days later is not permitted; the lifecycle transition and delete-after settings must respect that floor.
Cross-region copy is billed as standard inter-region data transfer, charged to the account initiating the copy, with the destination account paying separately for storage once the copy lands. A failed copy job that produces no recovery point is not billed at all — AWS explicitly does not charge for copy attempts that don’t complete, according to the AWS Backup metering and billing documentation.
Step 12: Set a budget alert before you forget about this vault
Backup storage costs creep. A 500 GB RDS database backed up daily with 120-day retention accumulates roughly 60 TB of recovery point storage over its lifetime if nothing ever transitions to cold storage — that’s the kind of bill that shows up as a surprise three months in. Set an AWS Budgets alert scoped to AWS Backup specifically:
aws budgets create-budget
--account-id 123456789012
--budget '{
"BudgetName": "aws-backup-monthly",
"BudgetLimit": {"Amount": "150", "Unit": "USD"},
"TimeUnit": "MONTHLY",
"BudgetType": "COST",
"CostFilters": {"Service": ["AWS Backup"]}
}'
--notifications-with-subscribers '[{
"Notification": {"NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN", "Threshold": 80},
"Subscribers": [{"SubscriptionType": "EMAIL", "Address": "platform-team@example.com"}]
}]'This catches the two most common cost surprises: a backup plan accidentally applied to a much larger resource than intended, and cold storage transitions that never happen because the lifecycle rule was misconfigured.
Common pitfalls
These mistakes account for the majority of AWS Backup support tickets and forum threads.
- Setting a retention window shorter than 90 days after enabling cold storage. The API rejects any plan where
DeleteAfterDaysminusMoveToColdStorageAfterDaysis less than 90 — plan retention windows around this floor from the start rather than discovering it at deploy time. - Locking a vault before testing the plan against it. Vault Lock in compliance mode is effectively irreversible once the grace period expires. Test your backup plan against an unlocked vault first, confirm jobs complete successfully, then lock it.
- Assuming all resource types support the same restore pricing. EFS restores are billed separately at $0.02/GB warm and $0.03/GB cold, while EBS and RDS restores are frequently free from warm storage. Check the resource-specific line item, not a blanket assumption.
- Forgetting that a released legal hold doesn’t retroactively delete anything. Recovery points that would have expired during the hold period are still there after release — they follow the original lifecycle schedule from that point forward, they don’t disappear immediately.
- Tagging inconsistently across resource types. A typo like
backup-tier=Productionversusbackup-tier=production(case matters) silently excludes a resource from the plan with no error message — the resource simply never appears in the protected list. - Not accounting for cross-region storage as a second, full-price cost. A copy action doesn’t discount destination storage — the copied recovery point in us-west-2 is billed at that region’s warm or cold storage rate, on top of the primary region’s storage cost and the one-time transfer fee.
- Running restore tests against mostly-cold vaults on a tight schedule. Weekly restore tests against a vault where most recovery points have already moved to cold storage rack up cold-storage restore charges every week. Scope the restore testing plan’s selection window to catch only recently created, still-warm recovery points if cost is a concern.
Troubleshooting
Eight issues that come up repeatedly when standing up AWS Backup in a new account.
- Backup job stuck in CREATED for more than 10 minutes. Usually means the target resource is in a state that blocks snapshotting — an EBS volume mid-modification, or an RDS instance undergoing a maintenance window. Wait for the resource state to clear, or check
describe-backup-jobfor a specific status message. - Resource doesn’t appear under the tag-based selection. Confirm the tag key and value match exactly, including case. Also confirm the resource type is supported in your specific Region — check the feature availability table rather than assuming.
- AccessDenied on create-backup-job. The IAM role referenced in the backup selection needs both AWS Backup permissions and permissions on the underlying resource type (for example,
ec2:CreateSnapshotfor EBS). The default service role covers this, but custom roles frequently miss the resource-specific permission. - Cross-region copy job fails silently. Verify the destination vault actually exists in the target region before referencing its ARN in the copy action — a typo’d region in the ARN produces a copy failure with a vague error rather than a clear “vault not found” message.
- Vault Lock command rejected with a retention mismatch error. The
min-retention-daysandmax-retention-daysyou set on the lock must be compatible with every backup plan currently targeting that vault. Audit existing plan lifecycle rules before locking. - Restore test reports success but the restored resource is empty. Check that the recovery point selection algorithm actually picked a recovery point with data —
LATEST_WITHIN_WINDOWagainst a freshly created resource with no completed backups yet will restore an empty or minimal snapshot. - Audit Manager framework shows resources as non-compliant despite backups running. Frequency and retention control parameters are strict — a control requiring daily backups with 30-day retention flags a resource on a 36-hour schedule as non-compliant even if backups are completing successfully.
- Bill is higher than the pricing calculator estimated. Check whether Restore Testing or Audit Manager evaluations are running more often than expected, and confirm resources haven’t grown significantly since the estimate — storage costs scale with actual protected data volume, not with the plan configuration alone.
AWS Backup vs. rolling your own snapshot scripts
Teams that built custom snapshot automation before AWS Backup existed sometimes ask whether it’s worth migrating. The honest answer depends on how many resource types you’re protecting. A single EC2 fleet with a Lambda-triggered EBS Lifecycle Manager policy works fine on its own and doesn’t need AWS Backup’s overhead. The moment you’re protecting three or more resource types — EBS, RDS, and DynamoDB, say — the combined audit trail, single IAM surface, and Vault Lock compliance features start paying for themselves in reduced operational risk, even before counting the engineering hours saved from not maintaining custom scripts.
| Factor | Custom scripts | AWS Backup |
|---|---|---|
| Resource types covered by one policy | Usually one (whatever the script targets) | 18+ resource types natively |
| Compliance-grade immutability | Requires custom S3 Object Lock implementation | Vault Lock built in |
| Audit trail | Custom CloudWatch Logs parsing | Audit Manager with prebuilt controls |
| Cross-region copy | Manual scripting per resource type | Declarative copy actions in the plan |
| Maintenance burden | Ongoing (Lambda runtime updates, new resource types) | AWS-managed |
Advanced tip: scope IAM permissions with ABAC instead of resource ARNs
Rather than listing individual resource ARNs in IAM policies attached to your backup role, use attribute-based access control tied to the same tags driving your backup selections. This keeps the IAM policy static even as resources are created and destroyed, since the policy evaluates the tag on the resource at request time rather than a hardcoded ARN list:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["ec2:CreateSnapshot", "rds:CreateDBSnapshot"],
"Resource": "*",
"Condition": {
"StringEquals": {"aws:ResourceTag/backup-tier": "production"}
}
}
]
}This pairs naturally with the tag-based backup selection from Step 4 — the same tag drives both what gets backed up and what the backup role is authorized to touch, closing the gap where an overly broad IAM role could theoretically snapshot resources outside the intended scope.
Advanced tip: stagger backup windows to avoid restore testing collisions
If your backup plan runs at 7am UTC and your restore testing plan also targets the “latest within window” recovery point at the same hour, you risk testing against a recovery point that’s still mid-creation. Offset restore testing by at least the plan’s CompletionWindowMinutes value plus a buffer — in the example plan above, that’s 180 minutes, so schedule restore tests no earlier than 3 hours after the backup window starts.
Centralize backup policies across accounts with AWS Organizations
Everything up to this point assumes a single AWS account. Most real companies run dozens of accounts through AWS Organizations — one per team, one per environment, or one per product line — and manually replicating a backup plan into each account does not scale past a handful of teams. AWS Backup solves this with backup policies, a separate concept from backup plans that lives at the Organizations level and cascades down to member accounts automatically.
A backup policy is written once at the Organizations management account (or a delegated administrator account) and attached to an organizational unit. Every account inside that OU inherits the policy, including accounts created after the policy was attached. This is the mechanism platform teams use to guarantee that no engineer can spin up a new AWS account without production backup coverage already active on day one.
aws organizations enable-policy-type
--root-id r-a1b2
--policy-type BACKUP_POLICY
aws organizations create-policy
--name org-wide-production-backup
--type BACKUP_POLICY
--content file://org-backup-policy.json
--description "Mandatory daily backups for all production OU accounts"
aws organizations attach-policy
--policy-id p-abc123xyz
--target-id ou-a1b2-productionouThe policy document itself uses the same plan and rule structure as a regular backup plan, wrapped in an Organizations policy schema that lets you reference account-specific variables like $account in vault names, so each member account gets its own isolated vault rather than accidentally sharing one. This matters for blast-radius containment — a compromised IAM role in one account should not be able to touch another account’s recovery points.
One operational detail worth flagging: backup policies attached through Organizations cannot be edited or deleted from inside the member account. A developer with full admin rights on their own sandbox account still cannot weaken or remove the org-mandated backup schedule — only someone with permissions in the management or delegated administrator account can do that. This is by design and is exactly the control most compliance frameworks are looking for when they ask “can an individual engineer disable backups.”
Monitor backup health with EventBridge and CloudWatch
A backup plan that silently stops running is worse than no backup plan at all, because the team assumes protection exists when it doesn’t. AWS Backup emits events to Amazon EventBridge for every state change — job started, job completed, job failed, recovery point created, copy job failed — and wiring these into an alert channel closes that gap.
aws events put-rule
--name backup-job-failures
--event-pattern '{
"source": ["aws.backup"],
"detail-type": ["Backup Job State Change"],
"detail": {"state": ["FAILED", "EXPIRED"]}
}'
aws events put-targets
--rule backup-job-failures
--targets '[{
"Id": "notify-platform-team",
"Arn": "arn:aws:sns:us-east-1:123456789012:backup-alerts"
}]'Pair the EventBridge rule with a CloudWatch dashboard tracking the metrics AWS Backup publishes natively — NumberOfBackupJobsCompleted, NumberOfBackupJobsFailed, and NumberOfCopyJobsFailed are the three worth alarming on directly. A CloudWatch alarm on NumberOfBackupJobsFailed greater than zero over a 24-hour period catches the specific failure mode that tag-based assignment mistakes tend to cause: a resource silently drops out of coverage and nobody notices until a restore is actually needed.
| Metric | What it tells you | Recommended alarm threshold |
|---|---|---|
| NumberOfBackupJobsFailed | Individual backup attempts that errored out | > 0 over 24 hours |
| NumberOfCopyJobsFailed | Cross-region or cross-account copies that didn’t complete | > 0 over 24 hours |
| NumberOfRecoveryPointsCreated | Sanity check that jobs are actually producing recovery points, not just completing | Alarm if this drops to 0 on a day a job was expected |
| NumberOfRestoreJobsFailed | Failed restores, most relevant during restore testing runs | > 0 immediately, page on-call |
Route the SNS topic in the EventBridge target to whatever your team already uses for paging — Slack via a Lambda subscriber, PagerDuty, or plain email for lower-urgency environments like staging. The point is that a failed backup job should generate the same kind of signal as a failed deploy, not a line item buried in a console nobody checks.
Cost optimization strategies beyond the basic lifecycle rule
The lifecycle transition covered in Step 3 is the obvious cost lever, but it’s not the only one. Four additional strategies consistently show up in teams’ AWS Backup bills once they’ve been running the service for six months or more.
First, separate retention windows by resource criticality rather than applying one blanket policy account-wide. A staging database rarely needs the same 120-day retention as production — a 14-day warm-only retention with no cold storage transition (since the 90-day cold storage minimum makes cold storage pointless for short-lived retention) is both cheaper and operationally simpler for non-production resources. Use a second backup plan with a different tag scope, exactly as demonstrated for DynamoDB in Step 7.
Second, audit cross-region copies for resources that don’t actually need disaster-recovery coverage. Not every S3 bucket or EBS volume justifies the doubled storage cost of a full copy in a second region — reserve cross-region copy actions for resources genuinely part of your disaster recovery plan, and skip them for ephemeral or easily-regenerated data.
Third, watch continuous backup retention on DynamoDB and any resource type that supports point-in-time recovery. Continuous backups (the 1-to-35-day PITR window) are billed differently from periodic snapshot-based recovery points, and running both simultaneously on the same table without a clear reason for each is a common source of duplicate charges that a monthly Cost Explorer review by service (filtered to AWS Backup) will surface quickly. Teams running Aurora DSQL or another distributed SQL engine alongside standard RDS should check which resources actually need AWS Backup coverage versus the database engine’s own built-in replication, since duplicating both can be redundant for data that’s already multi-region by design.
Fourth, review Audit Manager framework evaluation frequency. Frameworks with many controls evaluated across a large resource fleet on a tight schedule generate proportionally more evaluation activity. This is rarely the dominant cost driver compared to storage, but it’s worth checking against the Cost Explorer breakdown before assuming storage is the only variable that moved.
Complete working project: production-ready backup stack
Putting every step together, here’s the full sequence for a production deployment protecting EC2/EBS, RDS, and DynamoDB with cross-region disaster recovery and compliance locking:
#!/bin/bash
set -e
REGION_PRIMARY="us-east-1"
REGION_DR="us-west-2"
ACCOUNT_ID="123456789012"
# 1. Create vaults
aws backup create-backup-vault --backup-vault-name production-vault --region $REGION_PRIMARY
aws backup create-backup-vault --backup-vault-name production-vault-dr --region $REGION_DR
# 2. Create the backup plan
PLAN_ID=$(aws backup create-backup-plan --backup-plan file://backup-plan.json
--region $REGION_PRIMARY --query 'BackupPlanId' --output text)
# 3. Assign production-tagged resources
aws backup create-backup-selection --backup-plan-id $PLAN_ID
--backup-selection '{
"SelectionName": "tag-based-production",
"IamRoleArn": "arn:aws:iam::'"$ACCOUNT_ID"':role/service-role/AWSBackupDefaultServiceRole",
"ListOfTags": [{"ConditionType": "STRINGEQUALS", "ConditionKey": "backup-tier", "ConditionValue": "production"}]
}' --region $REGION_PRIMARY
# 4. Verify with a manual trigger before trusting the schedule
aws backup start-backup-job
--backup-vault-name production-vault
--resource-arn arn:aws:ec2:$REGION_PRIMARY:$ACCOUNT_ID:volume/vol-0abcd1234efgh5678
--iam-role-arn arn:aws:iam::$ACCOUNT_ID:role/service-role/AWSBackupDefaultServiceRole
--region $REGION_PRIMARY
echo "Backup stack deployed. Monitor with: aws backup list-backup-jobs --region $REGION_PRIMARY"Save this as deploy-backup-stack.sh alongside your backup-plan.json from Step 3, and check both into version control. Treating backup configuration as code — reviewed in pull requests like any other infrastructure change — is the single biggest improvement most teams can make over clicking through the console once and forgetting about it.
Frequently asked questions
Is there a free tier for AWS Backup?
No. AWS Backup has no dedicated unlimited free tier for storage, restores, cross-region transfer, or Audit Manager evaluations as of September 2026. You pay for what you store and restore from the first gigabyte, per AWS’s published pricing.
Does AWS Backup replace RDS automated backups entirely?
It can, but many teams run both — RDS automated backups for short-term point-in-time recovery (up to 35 days) alongside AWS Backup for longer retention, cross-region copies, and compliance locking. They aren’t mutually exclusive and can coexist on the same database.
Can I use AWS Backup for on-premises data?
Yes, through AWS Storage Gateway, which is one of the natively supported resource types. This lets hybrid environments funnel on-premises volumes into the same centralized backup plans as cloud-native resources.
What happens if I try to delete a recovery point under Vault Lock compliance mode?
The API call fails outright. Compliance mode is designed specifically to prevent deletion, including by the account root user, until the configured retention period has elapsed. This is intentional and there is no override.
How is AWS Backup different from AWS Elastic Disaster Recovery?
They solve different problems. AWS Backup creates point-in-time recovery points you restore on demand, typically for data loss, corruption, or compliance retention. AWS Elastic Disaster Recovery continuously replicates entire servers for fast failover during a regional outage, targeting minutes of recovery time rather than a manual restore process.
Can I restore a recovery point into a different AWS account?
Yes, if you’ve configured cross-account copy to a vault in the destination account and granted the appropriate resource-based vault access policy. The destination account then restores from its own copy of the recovery point.
Does moving data to cold storage happen automatically?
Only if your backup plan’s lifecycle rule includes a MoveToColdStorageAfterDays value. Without it, recovery points remain in warm storage for their entire retention period, which costs significantly more for long-term retention.
What’s the maximum number of backup plans I can run in one account?
300 backup plans per Region per account, with up to 10 rules per plan and up to 5 copy actions per rule, according to AWS’s published service quotas. Most production setups need far fewer — two or three plans covering different resource tiers is typical.