What Is AWS Backup? Centralized, Automated Backups for Every AWS Service (Vaults, Cross-Region & Compliance Explained)

AWS Backup is a fully managed, policy-driven service that centralizes and automates data protection across more than 20 AWS services and on-premises VMware workloads, all from one console and one API. The part almost everyone gets wrong: AWS Backup itself costs nothing to run — there is no minimum fee and there are no setup charges. You pay only for the backup storage it consumes, the data you restore, and any optional advanced features. The scheduling engine, the policy enforcement, the centralized monitoring, the cross-account governance — those are all free. If you are currently managing snapshots per-service with scattered Lambda scripts and hoping nothing falls through the cracks, AWS Backup replaces that entire mess with a single backup plan you write once and apply everywhere.

Jake runs a phone shop that has slowly grown into a hybrid operation — repairs, sales, a small e-commerce backend on EC2, an RDS database for inventory, and an S3 bucket full of customer photos from data recovery jobs. Every service had its own backup story, none of them talked to each other, and when a drive failed last quarter, he spent an entire Saturday piecing together recovery points from three different consoles. Ethan, his longtime friend and the person he calls before touching anything in the AWS console, sat him down afterward. "You don't have a backup problem," Ethan said. "You have a backup management problem. And AWS built a service specifically for that."

That service is AWS Backup. Not another snapshot tool — a management layer that sits above the snapshots and enforces one policy across everything. In the sections that follow, we'll go through what it actually does, what it costs (down to the per-GB numbers by service), which services it protects, the security features that make auditors happy, how it compares to every alternative on the market, the failure modes nobody warns you about, the exact quotas and limits you'll hit, worked cost examples you can plug your own numbers into, and when you should skip it entirely.

What AWS Backup Actually Is (and What It Isn't)

At its core, AWS Backup is a centralized backup orchestration service. Think of it as a policy engine that tells every supported AWS service when to take a backup, where to store it, how long to keep it, who can delete it, and whether it needs a copy in another region or account. The actual backup artifacts — EBS snapshots, RDS snapshots, S3 backup objects, DynamoDB on-demand backups — still exist underneath, but they are now created, tagged, retained, and deleted according to rules you define in one place.

The distinction matters because it changes how you think about cost and control. You are not replacing your existing backup infrastructure; you are adding a governance layer on top of it. That layer brings features that individual services cannot offer on their own: Vault Lock for write-once-read-many immutability, cross-account backup copies for ransomware protection, legal holds that survive retention policies, and an audit framework that proves to compliance teams that backups actually happened on schedule.

What AWS Backup is not: it is not a file-level backup agent you install on servers (though it does support VMware VMs through a gateway), it is not a replacement for database-native features like RDS point-in-time recovery (though it can manage continuous backups that enable PITR), and it is not a disaster recovery service that spins up infrastructure in a healthy region (that is AWS Elastic Disaster Recovery). It is specifically the backup layer — creating, storing, copying, retaining, and restoring recovery points.

Ethan put it in shop terms for Jake: "Your EBS snapshots are like the individual tools in your repair bench drawers. AWS Backup is the pegboard, the labeling system, and the checklist that makes sure every tool goes back where it belongs and you can find the right one at 2 AM when a customer's phone is bricked."

How AWS Backup Works: The Four Building Blocks

Everything in AWS Backup is built from four concepts. Once you understand these, the rest of the service is just configuration.

1. Backup Plans

A backup plan is the schedule and retention policy. It defines: how often backups run (every 12 hours, daily, weekly, monthly, or custom cron expressions), which backup vault they go into, how long they are retained (from 1 day to 100 years), when they transition to cold storage, whether copies go to other regions, and whether Windows VSS (Volume Shadow Copy Service) is enabled for consistent application backups. You attach resources to a plan either by tagging them or by selecting specific resource IDs.

Snapshot backups can be taken as frequently as every hour. The minimum supported frequency of a backup schedule is once every 12 hours. If you need more frequent protection than that, you need continuous backup (covered in a dedicated section below).

2. Backup Vaults

A backup vault is the container that stores your recovery points. Each vault has its own encryption key (AWS managed KMS key by default, or your own customer-managed key), its own access policy, and optionally its own Vault Lock configuration. When you need to segregate backups by environment, compliance requirement, or team, you use separate vaults. There is also a specialized type called a logically air-gapped vault, which adds compliance-mode Vault Lock and restricted access controls for high-security scenarios.

3. Backup Policies (AWS Organizations)

For multi-account environments, backup policies are a type of AWS Organizations policy that lets a central team define backup rules that apply automatically across all accounts in the organization. This is how large enterprises enforce "every production RDS instance must have a backup plan with 35-day retention and cross-region copy" without manually configuring each account. A delegated administrator account manages the policies; member accounts inherit them.

4. Recovery Points

A recovery point is a single backup artifact — the result of one backup job run. For EBS, it is an EBS snapshot. For RDS, it is an RDS snapshot. For S3, it is a continuous backup or a point-in-time snapshot. Recovery points live in vaults, can be copied across regions and accounts, can have legal holds placed on them, and are what you restore from.

Every Service AWS Backup Supports (and What Features Each Gets)

This is where the "one place for every snapshot" claim gets tested. AWS Backup does not support every AWS service, and the services it does support get different levels of functionality. Verify feature support for your Region before committing to a backup strategy — a missing capability in the feature availability table means it is not available for that resource type in any scenario.

*DynamoDB cross-region copy, cross-account copy, and cold storage require opting in to AWS Backup advanced features for DynamoDB.

A few things jump out from this table. First, cold storage is supported for seven resource types: EBS, EFS, Aurora DSQL, DynamoDB (with advanced features enabled), Timestream, SAP HANA on EC2, and VMware. If you are backing up RDS or Aurora and want long-term archival, you are limited to warm storage pricing for those recovery points. Second, EKS backup is about cluster state, not the persistent volumes — for EBS, S3, and EFS attached to EKS, you use the standard per-service backup pricing and features. Third, not every service supports every feature: if you need continuous backup with point-in-time recovery, your options are S3, RDS, Aurora, and SAP HANA — check the table before designing your strategy.

One more thing the table does not show: some services support features beyond the columns here. Amazon S3 backups support backup tiering (automatically moving older backup objects to a lower-cost warm tier at $0.035 per GB-month after 60 days), access points (reading backup data directly without a full restore), and backup search (finding specific objects across recovery points). EC2 supports malware protection through GuardDuty integration. These are powerful additions that go beyond simple snapshot management.

For Amazon Redshift, backup storage is supported (the pricing page lists Redshift Cluster Snapshot storage at $0.023 per GB-month for the first 50 TB), but the feature availability table does not show cross-region or cross-account support for Redshift. Only Amazon Redshift Serverless appears in the feature table, and it does not support copy operations. Verify current feature support for your specific Redshift deployment before relying on cross-region or cross-account copies.

AWS Backup Pricing: The Complete Breakdown

Pricing is where most people either overpay or underestimate. The model is straightforward once you see it, but there are five separate charge types, and only two of them (storage and restore) apply to basic usage.

Charge 1: Backup Storage (per GB-month)

This is the ongoing cost of storing your recovery points. The storage amount billed in a month is based on the average storage space used throughout the month, billed as GB-Month. Pricing varies significantly by service:

The spread is enormous: Aurora and Neptune snapshots cost $0.021 per GB-month, while DynamoDB and Timestream cost $0.10 — nearly five times as much for the same storage volume. Backing up 1 TB of Aurora data costs $21 per month in warm storage; backing up the same volume of DynamoDB data costs $100. Neither number includes the cost of the underlying resource itself, nor does it include restore charges.

One important note on cold storage: backups transitioned to cold must be retained for a minimum of 90 days. If you delete them before that, you pay a pro-rated charge for the remaining days. This is not a penalty — it is the pricing model that makes cold storage cheaper in exchange for a commitment.

Also note that backups of EFS, S3, VMware, SAP HANA on EC2, and Amazon Timestream are billed on a GB-day basis instead of a GB-hour basis — your backup storage for these resources is billed for the whole day, regardless of when during the day the backup was created or deleted.

For logically air-gapped vaults, storage costs are slightly higher — the premium is roughly 15% over standard vault storage. All billed charges for storage in logically air-gapped vaults show under the "Backup" service in your bill. Also, backup storage free tiers for Amazon EBS, Amazon DocumentDB, and Amazon Neptune are not applied when the storage is in a logically air-gapped vault.

Charge 2: Restore (per GB restored)

When you restore data, you pay for the amount of data restored, not the amount of time it takes. The restore amount billed in a month is based on the amount of data restored for the month, measured in GB. Restore pricing varies by resource type and whether you are restoring from warm or cold storage. For example, restoring warm EFS storage is billed at $0.02 per GB in US East, while restoring from cold storage carries a higher per-GB rate ($0.03 per GB for EFS). Cold storage restore pricing applies when cold recovery points are selected and restored — it is always higher than warm storage restore pricing.

You will also incur warm storage restore charges for EFS, S3, EKS Cluster, and VMware backups. For restores of backups of persistent storage attached to your EKS cluster (EBS, S3, EFS), you incur the standard restore charges for those resource types.

Charge 3: Cross-Region Data Transfer

If you copy backups to another region (for disaster recovery or compliance), you pay standard AWS data transfer charges for moving the data out of the source region. The destination account pays the backup storage charges in the destination region. The pricing page groups resources into three categories for cross-region transfer: Group 1 (EFS, DynamoDB, Timestream, and VMware Backup), Group 2 (S3, Aurora DSQL, and EKS), and Group 3 (EBS, FSx, Storage Gateway, DocumentDB, Neptune, Aurora, and RDS). Each group has different per-GB transfer rates. You only incur data transfer charges when transferring data out of an AWS Region — there are no charges for transfers within the same AWS Region.

Charges 4 and 5: Optional Advanced Features

Several optional features carry additional costs. Restore testing costs $1.50 per recovery point evaluation plus the standard restore charges for the data restored during testing. AWS Backup Audit Manager costs $0.00125 per backup evaluation (prorated), plus AWS Config configuration item charges (each backup evaluation records one configuration item, and configuration items are also recorded when underlying backup resources change). Malware protection (through GuardDuty) is billed based on total GB scanned per month. Backup search is billed based on number of objects scanned, plus index storage. None of these are required for basic backup operation — they are add-ons for teams that need automated compliance validation or security scanning.

Real-World Cost Examples: Plug In Your Own Numbers

Abstract pricing tables are fine for comparison, but nothing makes backup costs real like working through actual numbers. Here are three scenarios Jake and Ethan worked through, based on the pricing above.

Scenario 1: Small E-Commerce Shop (Jake's Setup)

Jake has: one EC2 instance with a 100 GB EBS root volume, one 500 GB EBS data volume, one RDS MySQL database at 50 GB, and one S3 bucket with 200 GB of customer photos. Daily backups, 35-day retention, all warm storage.

The math: EBS backups at $0.05 per GB-month for 600 GB total (both volumes), retained for 35 days, incrementally deduplicated — assuming roughly 30% of data changes daily and unique stored data is about 800 GB across all recovery points at steady state. That's 800 × $0.05 = $40/month for EBS. RDS at $0.095 per GB-month for 50 GB with 35 daily snapshots, assuming roughly 60 GB unique stored: 60 × $0.095 = $5.70/month for RDS. S3 at $0.05 per GB-month for 200 GB: $10/month for S3. Total: approximately $55.70 per month for Jake's entire backup estate, with zero restore charges until he actually needs to restore.

Scenario 2: S3-Heavy Workload with Tiering

Assume you have 500 TB of Amazon S3 data with 100 million objects of 5 MB each, and you want a backup copy using AWS Backup in US East (N. Virginia). The pricing page gives this exact example: total monthly storage charge at $0.05 per GB-month for warm storage = 500,000 GB × $0.05 = $25,000 per month. In addition, you incur charges for S3 GET API requests (approximately $320 assuming 8 GET APIs per new object) and S3 LIST API requests (approximately $1). If your S3 bucket has more than 300 million objects, you also incur charges for S3 inventory reports.

Now, if you enable tiering to move backup data older than 60 days to the low-cost warm tier: those objects cost $0.035 per GB-month instead of $0.05 — a 30% reduction for everything in the low-cost tier. You also pay a one-time transition fee of $0.01 per 1,000 objects moved. For 100 million objects transitioning, that is a one-time cost of $1,000, but ongoing monthly savings on tiered data of $0.015 per GB-month.

Scenario 3: Restore Testing EBS and EFS

Assume you restore-test 10 EBS snapshots (each 64 GB) and 15 EFS recovery points (each 50 GB from warm storage) in a month in US East (N. Virginia). The pricing page calculates: restore testing evaluation charge for EBS at $1.50 per recovery point = 10 × $1.50 = $15. Restore testing evaluation charge for EFS at $1.50 per recovery point = 15 × $1.50 = $22.50. Charges for restored warm storage for EFS at $0.02 per GB = 750 GB × $0.02 = $15. Total: $37.50 (restore testing evaluations) + $15 (restored storage) = $52.50 per month.

Ethan's comment: "Fifty bucks a month to know your restores actually work? That's the cheapest insurance in the building."

AWS Backup vs Native Snapshots: When to Use Which

This is the question Jake asked first, and it deserves a straight answer. Every AWS service that AWS Backup supports already has some native backup mechanism — EBS has snapshots, RDS has automated backups, DynamoDB has on-demand backups, S3 has versioning and replication. So why add another layer?

The honest answer: for small deployments, native is fine. For anything with more than a handful of resources across multiple services, or anything with compliance requirements, AWS Backup wins.

Ethan framed it for Jake: "If you have one EC2 instance and one EBS volume, just set up a Data Lifecycle Manager policy for the snapshot and move on. The moment you add RDS, EFS, and a couple of S3 buckets, you're either writing custom scripts or you're using AWS Backup. And custom scripts are a liability — they break silently, nobody updates them, and they don't come with an audit trail."

Here is what AWS Backup adds that native mechanisms do not have:

• Vault Lock (WORM) — Once locked, a vault cannot have its recovery points deleted or modified, even by the account root user. This is ransomware protection and compliance enforcement that no native snapshot feature offers.
• Cross-account backup — Copy backups to a completely separate AWS account. Even if your primary account is compromised, the backups in the secondary account are safe (provided you also use Vault Lock there).
• Centralized policy — One backup plan applied by tag across dozens of resources, or via Organizations across dozens of accounts. No per-service configuration drift.
• Legal hold — Place individual recovery points on indefinite hold for litigation or investigation, regardless of their retention policy. The hold survives until explicitly released.
• Audit Manager — Automated compliance reports proving backups occurred on schedule, are encrypted, and meet retention requirements.
• Unified restore — One API and console for restoring any supported resource type, instead of learning each service's restore workflow.
• Cold storage tiering — Automatically transition old backups to cheaper storage tiers based on age. EBS, EFS, DynamoDB, Timestream, SAP HANA, VMware, and Aurora DSQL support this.
• Restore testing — Automatically verify that your backups can actually be restored, on a schedule you define.

What you give up: granularity. Native backup features sometimes offer options that AWS Backup does not expose. If you depend on a specific native feature, check whether AWS Backup supports it before migrating. Some services offer both cross-region and cross-account copies natively, but AWS Backup supports only one at a time for certain databases — for example, RDS, Aurora, Neptune, and DocumentDB support cross-region backups or cross-account backups, but not both in the same backup plan.

AWS Backup vs Third-Party Backup Tools: The Honest Comparison

AWS is not the only company that makes backup software for AWS workloads. Veeam, Rubrik, Commvault, Cohesity, and N2WS all compete in this space, and each has genuine strengths. The honest answer to "which should I use" depends on what you are protecting and what your requirements are.

The pattern is clear: AWS Backup wins on simplicity, cost (no license fee), and AWS-native integration. Third-party tools win on breadth (multi-cloud), granularity of restore, and application-awareness for complex enterprise applications. If you are all-in on AWS and your workloads are the services AWS Backup supports, the native tool is almost always the right first choice. If you have a hybrid multi-cloud estate or need file-level restore from VM backups, a third-party tool earns its license fee.

Ethan's take: "I've seen shops buy Veeam to back up three EC2 instances and an RDS database. That's like buying a freight truck to deliver pizzas. Start with AWS Backup, and if you outgrow it — you'll know when — then look at the bigger tools."

Setting Up Your First Backup Plan: Step by Step

Enough theory. Here is how to actually set it up, from zero to a working backup plan protecting an EC2 instance and an EBS volume. The steps are the same whether you are protecting one resource or one hundred — the only thing that changes is how you assign resources to the plan.

Step 1: Opt In to the Services You Want to Manage

AWS Backup does not automatically take over backup management for any service. You must explicitly opt in, per service, per region. Open the AWS Backup console, go to Settings, and enable the resource types you want AWS Backup to manage. If you do not opt in, AWS Backup will not see those resources even if you create a backup plan that matches them. This catches people off guard constantly — they create a plan, nothing gets backed up, and they spend an hour debugging permissions when the actual problem is that the service was never opted in.

Step 2: Create a Backup Vault

1. In the AWS Backup console, choose Backup vaults, then Create backup vault.
2. Give it a name that reflects its purpose (e.g., "production-daily" or "finance-compliance-7yr").
3. Choose an encryption key — the default AWS managed key works, or select a customer-managed KMS key if you need specific key policies or want the key to be usable across accounts for cross-account copies.
4. Optionally add tags for cost allocation.
5. Choose Create backup vault.

Step 3: Create a Backup Plan

1. In the console, choose Backup plans, then Create backup plan.
2. Choose Build a new plan (or start from a template if one fits your needs).
3. Name the plan something meaningful — "prod-ec2-daily-35d" is more useful than "plan1" six months from now.
4. Under Backup rule, set the schedule: frequency (every 12 hours, daily, weekly, monthly, or custom cron), backup window (start time and duration), and timezone.
5. Choose the backup vault you created in Step 2.
6. Set the retention period — how long each recovery point lives before automatic deletion. Anywhere from 1 day to 100 years.
7. If the service supports cold storage and you want it, set the transition period (e.g., "move to cold after 30 days"). Remember the 90-day minimum retention once in cold.
8. If you need cross-region copies, add a copy rule with the destination region, destination vault, and retention period.
9. Choose Create plan.

Step 4: Assign Resources to the Plan

There are two ways to attach resources: by resource ID (specific instances, volumes, databases) or by tag (everything with tag backup=production, for example). Tag-based assignment is more maintainable at scale — new resources pick up the backup plan automatically if they carry the right tag. Choose your method in the plan's Resource assignments section, define the scope (entire account, specific resource types, or specific IDs), and save.

Step 5: Verify It Works

After the first scheduled run, go to Backup jobs in the console and confirm the job status is Completed. Then go to Protected resources and confirm your resources appear with recovery points. If a job fails, the error message will tell you why — common causes are missing IAM permissions, a resource in a stopped state, or the service not being opted in for that region.

A quick sanity check Ethan recommends: after the first successful backup, do a test restore of a small, non-critical resource. If you cannot restore it, your backup is worthless regardless of what the dashboard says. Better to find out now than at 2 AM during an actual incident.

Backup Vaults and Vault Lock: The Security Layer That Changes Everything

Vaults are where your recovery points live, and Vault Lock is the feature that makes AWS Backup genuinely different from a pile of unmanaged snapshots. Vault Lock enforces write-once-read-many (WORM) retention — once a recovery point enters a locked vault, it cannot be deleted before its retention period expires, no matter who asks or what permissions they have.

Vault Lock operates in two modes. In governance mode, a vault can be managed only by users with sufficient IAM privileges — useful while you are still tuning your policy, because you can adjust settings without permanently locking yourself in. In compliance mode, the lock becomes immutable and permanent once the cooling-off (grace) period ends: nobody, not even AWS support or the root account, can shorten the retention period or delete recovery points before they expire. This is the mode you use for regulatory compliance, legal requirements, or ransomware protection where the threat model includes an attacker gaining administrative access to your AWS account.

Jake's reaction was immediate: "So if someone hacks my AWS account and tries to delete my backups, they can't?" Ethan nodded. "That's the whole point. Vault Lock in compliance mode means your backups survive even if the production account is fully compromised. You store them in a separate account, lock the vault, and the attacker can rage all they want — those recovery points are not going anywhere until their retention expires."

There are trade-offs, and you need to understand them before enabling compliance mode. Once you lock a vault in compliance mode and the grace period expires, you cannot unlock it. You cannot shorten retention periods. You cannot delete recovery points early, even if they are consuming storage you no longer want to pay for. The lock is permanent for the life of the vault. This is by design — the value comes precisely from the fact that it cannot be circumvented. If you lock a vault with a 10-year retention period and your compliance requirement drops to 2 years after a policy change, you are still paying for 10 years of storage on that vault.

A logically air-gapped vault takes this further. It is a vault type that automatically includes compliance-mode Vault Lock, restricted access controls, and the ability to share vault access with other accounts for faster recovery in incident scenarios. Each vault is encrypted with either an AWS owned key (default) or a customer-managed KMS key. Storage costs are slightly higher (roughly 15% premium), but for high-value data, the additional isolation is worth considering.

One edge case worth knowing: when you close an AWS account that contains a backup vault, AWS and AWS Backup suspend your account for 90 days with your backups intact. If you do not reopen the account during those 90 days, AWS deletes the contents of your backup vault, even if AWS Backup Vault Lock was in place. Vault Lock protects against deletion within an active account, but it cannot prevent data loss when the account itself is closed and abandoned.

Cross-Region and Cross-Account Backup: Surviving Regional Disasters and Account Compromise

A backup that lives in the same region as your production data is not a disaster recovery strategy — it is a convenience. If the region goes down, your backups go down with it. AWS Backup addresses this with cross-region copy rules, which can be part of any backup plan or triggered on demand.

Cross-region copies are straightforward: add a copy rule to your backup plan, specify the destination region, and optionally a different vault and retention period in that region. The copy happens after the initial backup completes, and you pay standard data transfer charges for moving the data between regions, plus backup storage charges in the destination region.

Cross-account copies are where the real security value lies. By copying backups to a separate AWS account — one with different IAM policies, different access keys, and ideally no other production workloads — you create a recovery path that survives full compromise of the primary account. The destination account can be in the same AWS Organization (managed via Organizations backup policies) or a completely separate organization.

One limitation to know: cross-region and cross-account copies are not available for every resource type. The feature availability table shows which services support which copy types. For some — like RDS, Aurora, Neptune, and DocumentDB — you can do cross-region or cross-account but not both in the same backup plan. If you need both, you need separate plans. Also, for some services, when a cross-region or cross-account copy of a continuous backup is made, the copied recovery point becomes a snapshot (periodic) backup, and PITR is not available for these copies.

A practical note on cross-account copies with vaults using AWS managed keys: you cannot do cross-account copies if your vaults are using AWS managed keys. You need to use customer-managed KMS keys for cross-account backup copies to work.

Multi-Account Strategy with AWS Organizations

If you manage more than a handful of AWS accounts, per-account backup configuration is a losing game. You will miss accounts, policies will drift, and compliance reporting becomes a nightmare of cross-account console hopping. This is where backup policies — a policy type within AWS Organizations — become essential.

The setup: you designate one account in your AWS Organization as the delegated administrator for AWS Backup. That account creates backup policies that define backup plans (schedule, retention, vault, copy rules) and target them at specific accounts, OUs (organizational units), or the entire organization. Member accounts inherit the policies automatically — resources in those accounts get backed up according to the central policy without anyone logging into the member accounts to configure anything.

The power here is enforcement. A central security or platform team can guarantee that every RDS instance in every account has a backup plan meeting minimum retention requirements, with copies to a designated recovery account. Team members cannot opt out, cannot reduce retention below the policy floor, and cannot send backups to unauthorized vaults. For regulated environments, this transforms backup compliance from "we asked everyone nicely" to "it is technically enforced."

Combined with cross-account backup copies to a dedicated backup account (with Vault Lock in compliance mode on the destination vaults), you get a genuinely robust ransomware-resistant architecture: even if an attacker compromises a production account completely, the backups in the separate locked account are beyond their reach.

Cold Storage and Tiering: Cutting Long-Term Backup Costs by 70–80%

If you are keeping backups for months or years (compliance, legal, or just paranoia), cold storage is where the savings live. The concept is simple: backups you are unlikely to restore from soon go to a cheaper tier, and you accept slower restore times and a higher retrieval cost in exchange for a 70–80% reduction in storage charges.

Currently, cold storage is supported for seven resource types: Amazon EBS, Amazon EFS, Amazon Aurora DSQL, Amazon DynamoDB (when advanced features are enabled), Amazon Timestream, SAP HANA on EC2, and VMware Backup. For everything else — RDS, Aurora, S3, DocumentDB, Neptune, FSx, Redshift — you are limited to warm storage. This is a significant limitation if your long-retention backups are primarily RDS or Aurora databases.

The mechanics: in your backup plan's lifecycle settings, you specify a transition period (e.g., "move to cold after 90 days"). After that period, recovery points automatically transition to the cold tier. There is a 90-day minimum retention once in cold storage — delete before that and you pay a pro-rated charge for the remaining days. Restores from cold storage take longer and cost more per GB than restores from warm storage.

For S3 backups specifically, there is an additional tiering option called the low-cost warm storage tier ($0.035 per GB-month versus $0.05 for standard warm). Objects must be retained in the standard warm tier for a minimum of 60 days before transitioning to the low-cost tier, and there is a one-time transition charge of $0.01 per 1,000 objects. This reduces long-term storage costs by up to 30% while maintaining the same performance and features as the warm storage tier. It is specifically designed for S3 backups retained for extended periods due to regulatory compliance, disaster readiness, and ransomware protection strategies.

EBS cold storage works differently from the others — it transitions EBS snapshots to the EBS Snapshots Archive tier, which has its own pricing ($0.0125 per GB-month). Archived snapshots take longer to restore because they must be temporarily restored to the standard tier first. When an archived EBS snapshot is restored, AWS Backup sets the number of days to temporarily restore it to the standard (warm) tier to 1 day, and you are charged for the storage of the EBS snapshot in the standard tier for that 1 day.

Continuous Backup and Point-in-Time Recovery: Getting to 1-Second Precision

Snapshot backups — even hourly ones — leave gaps. If a database corruption happens at 2:47 PM and your last snapshot was at 2:00 PM, you lose 47 minutes of data. Continuous backup closes that gap by constantly backing up transaction logs, letting you restore to any point in time within 1 second of precision, going back up to 35 days.

AWS Backup supports continuous backup (and therefore point-in-time recovery, or PITR) for a subset of services: Amazon S3, Amazon RDS, Amazon Aurora, and SAP HANA on EC2. For these services, enabling continuous backup in your backup plan means AWS Backup first takes a full backup, then continuously captures transaction logs. When you need to restore, you specify a timestamp, and AWS Backup replays the logs from the full backup to that exact moment.

There are operational differences from snapshot backups worth knowing. Continuous backups are retained for a maximum of 35 days — you cannot extend this. If you need longer retention, you also need snapshot backups in the same plan. Deleting the only continuous backup rule from a plan will stop continuous protection for those resources. And copying continuous backups across regions or accounts has limitations: when a cross-region or cross-account copy of a continuous backup is made, the copied recovery point becomes a snapshot (periodic) backup, and PITR is not available for these copies.

AWS Backup supports continuous backups and point-in-time recovery for all Amazon RDS instances and Aurora that are supported by the native Amazon RDS service — including both single-AZ and Multi-AZ instance deployments. However, AWS Backup does not support continuous backups or point-in-time recovery for Amazon RDS Multi-AZ clusters.

The cost model for continuous backups also differs: you pay for the storage of the continuous backup data (which includes the transaction logs), and when you perform a PITR restore, you pay for the amount of data restored, same as a snapshot restore. The pricing is not dramatically different from snapshot backups for the same data volume, but the storage can grow larger because you are retaining log data in addition to the full backup.

Database Backup Deep Dive: RDS, Aurora, DynamoDB, and the Others

Databases are where backup strategies get complicated, because the stakes are highest and the feature matrix is most uneven. Here is the honest breakdown for each major database service.

Amazon RDS

RDS backup storage through AWS Backup costs $0.095 per GB-month — significantly more than EBS or EFS. RDS backups do not currently support cold storage, so if you have long-retention requirements, you are paying warm rates for the entire retention period. On the plus side, RDS supports continuous backup with PITR, and RDS also supports simultaneous cross-region and cross-account snapshot copying in a single action. RDS Multi-AZ database instances can be copied, but Multi-AZ clusters do not currently support any copy operations. RDS DB instances include both single-AZ and Multi-AZ instance deployments for continuous backup support.

Amazon Aurora

Aurora cluster snapshots cost $0.021 per GB-month — the cheapest database backup storage in the lineup. Aurora supports cross-region and cross-account copy from full backups, and also supports simultaneous cross-region and cross-account snapshot copying in a single action. Aurora supports continuous backup with PITR. However, Aurora does not support cold storage, so long-term archival is expensive at warm rates.

Amazon DynamoDB

DynamoDB is the complicated one. Standard DynamoDB table backups cost $0.10 per GB-month, and the feature availability table shows that basic DynamoDB backup does not support cross-region copy, cross-account copy, or cold storage. However, if you opt in to AWS Backup advanced features for DynamoDB, you get all three: cross-region copy, cross-account copy, and cold storage at $0.03 per GB-month. This is a significant unlock for anyone with DynamoDB workloads and compliance requirements — without advanced features, you are paying premium warm rates with no copy options.

Amazon Aurora DSQL

Amazon DocumentDB and Amazon Neptune

DocumentDB and Neptune cluster snapshots both cost $0.021 per GB-month (same as Aurora). Both support cross-region and cross-account copy, and both now support cross-Region and cross-account snapshot copying in a single action. Neither supports cold storage or continuous backup. DocumentDB and Neptune can be copied only to those AWS Regions where the services are available.

SAP HANA on EC2

SAP HANA databases on Amazon EC2 instances cost $0.06 per GB-month for warm storage and $0.01 for cold storage. SAP HANA supports cross-account and cross-region copy from full backups, continuous backup with PITR, and full management. Snapshots are full, and incremental backup is offered through PITR.

AWS Backup Audit Manager: Proving Compliance Without Manual Audits

If you work in any regulated industry — finance, healthcare, government, anything with an audit trail requirement — AWS Backup Audit Manager is the feature that turns "we think we have backups" into "here is the evidence." It evaluates your backup resources against controls you define, and generates reports showing compliance status.

A control is a procedure designed to audit the compliance of a backup requirement. Audit Manager comes with predefined controls covering common requirements, and you can create custom controls for organization-specific rules. It helps answer questions like: "Am I backing up all my resources?", "Are all my backups encrypted?", "Are my backups taking place daily?", and "Are there resources that should be protected but are not?"

One important detail: only active resources are included when controls evaluate resources for compliance. An Amazon EC2 instance in a running state will be evaluated; an EC2 instance in a stopped state will not be included. This is worth knowing if you have resources that are intermittently stopped — they will not appear as non-compliant, but they also will not appear as compliant, which can create blind spots in your audit coverage.

Pricing for Audit Manager has two components: backup evaluations ($0.00125 per evaluation, prorated) and AWS Config configuration items (charged separately by AWS Config). Each backup evaluation records one configuration item in AWS Config, and configuration items are also recorded when underlying backup resources change. For most deployments, the Config charges will be the larger component.

Audit Manager integrates with AWS Audit Manager (the broader compliance service), allowing you to include backup compliance data in your overall audit frameworks. The data source for AWS Backup controls is AWS Config, which is required for these evaluations.

Restore Testing: Because a Backup You Never Tested Is a Hope, Not a Plan

The dirty secret of backup strategies everywhere: most backups are never restore-tested. Teams set up backup plans, watch the jobs complete, and assume that because the backup succeeded, the restore will too. Then the day comes when they actually need to restore, and something is broken — the AMI is deprecated, the security group no longer exists, the KMS key was rotated, the instance type is unavailable in that Availability Zone.

AWS Backup restore testing addresses this by automating periodic evaluation of restore viability. You create a restore testing plan where you provide a name, the frequency for restore tests, and the target start time. Then you assign the resources you want to include. AWS Backup periodically performs actual restores and reports on whether they succeeded, how long they took, and whether the restored resources pass validation.

Restore testing is not free — you pay $1.50 per recovery point evaluation, plus the standard restore charges for the data restored during testing, plus any charges for running the restored resources during the test period. There can also be additional charges if the restored resource is retained after the restore completes. But compared to the cost of discovering during an actual incident that your backups are useless, it is inexpensive insurance.

Cold storage restore pricing will apply if cold recovery points, for supported resources, are selected and restored by restore testing — which is higher than warm storage restore pricing. And if an archived EBS snapshot is restored, AWS Backup sets the number of days to temporarily restore it to the standard (warm) tier to 1 day, and you are charged for the storage of the EBS snapshot in the standard tier for that 1 day.

Restore testing also supports inferred metadata — the ability to infer metadata about resources that may not exist at restore time — and restore testing validation to verify that restored resources meet specific criteria beyond just "it started."

Malware Protection and Legal Hold: The Features Nobody Expects

Two features that go beyond traditional backup management: malware scanning and legal holds. Both address real problems that backup administrators face, and both are underused because most people do not know they exist.

Malware Protection (via GuardDuty)

Malware protection for AWS Backup is provided by Amazon GuardDuty Malware Protection. It scans your recovery points for malware — either automatically as part of your backup workflow or on demand for previously created backups. The idea is simple: if your production environment is infected and you restore from a backup that is also infected, you have accomplished nothing. Scanning backups before restore ensures you are recovering clean data.

Not every resource type is supported for malware scanning — check the feature availability page for the current list. Pricing is based on the total GB of data scanned per month, billed through GuardDuty. For teams concerned about ransomware (where attackers specifically target backup systems to prevent recovery), adding malware scanning to the backup pipeline is a meaningful defense layer. This AWS native solution helps ensure your backups are clean from potential malware, allowing you to meet compliance requirements and respond to malicious incidents faster by ensuring the recovery of clean data.

Legal Hold

A legal hold prevents deletion of individual recovery points, regardless of their retention policy or vault settings. Unlike Vault Lock (which operates at the vault level), a legal hold applies to specific recovery points and does not expire — it remains active until explicitly released by a user with sufficient permissions.

Legal holds and backups have a many-to-many relationship: a backup can have multiple legal holds, and a legal hold can cover multiple backups. A backup cannot be deleted as long as it has at least one legal hold. After all legal holds on a backup are removed, the backup becomes subject to its normal retention lifecycle again.

The use case is litigation or investigation: when you receive a preservation order, you place legal holds on the relevant recovery points to ensure they are not deleted by routine retention policies while the legal process plays out. This is distinct from Vault Lock, which is a blanket policy that prevents any deletion within the vault. Legal hold is surgical — it protects specific recovery points without locking the entire vault.

It is worth noting the interaction between legal holds and Vault Lock: while AWS Backup Vault Lock provides additional protections and immutability to a vault, a legal hold provides additional protection against deletion of individual backups (recovery points). They are complementary, not redundant.

AWS Backup CLI and API: Automation for Teams That Script Everything

Everything you can do in the AWS Backup console, you can do from the AWS CLI, the SDKs (including boto3 for Python), CloudFormation, Terraform, or the CDK. The API surface is consistent, which makes automation straightforward once you understand the object model.

Key CLI commands you will use frequently:

• aws backup list-backup-plans — enumerate all backup plans in the region
• aws backup list-backup-jobs — see recent and in-progress backup jobs
• aws backup start-backup-job — trigger an on-demand backup
• aws backup list-recovery-points-by-backup-vault — see all recovery points in a specific vault
• aws backup start-restore-job — initiate a restore from a recovery point
• aws backup describe-backup-job — get details about a specific backup job
• aws backup get-backup-plan — retrieve the configuration of a backup plan
• aws backup update-backup-plan — modify an existing plan
• aws backup delete-recovery-point — delete a specific recovery point (subject to Vault Lock)
• aws backup list-protected-resources — see which resources are being managed by AWS Backup
• aws backup update-backup-vault — modify vault settings
• aws backup put-backup-vault-access-policy — set the access policy on a vault
• aws backup list-copy-jobs — see copy job status
• aws backup list-restore-jobs — see restore job status

For infrastructure-as-code teams, AWS Backup is fully supported in Terraform (via the aws_backup_plan, aws_backup_vault, aws_backup_selection, aws_backup_vault_lock_configuration, and aws_backup_logically_air_gapped_vault resources), CloudFormation, and CDK. The Terraform module for AWS Backup is community-maintained but widely used and covers the full API surface.

For Python automation, the boto3 client for AWS Backup mirrors the CLI commands — client.list_backup_plans(), client.start_backup_job(), client.start_restore_job(), and so on. The API is consistent, which makes it easy to integrate backup operations into existing automation workflows.

Monitoring, Failure Alerts, and Troubleshooting: What to Do When Backups Fail

Backups fail. Not often, but when they do, you need to know quickly and you need to know why. AWS Backup integrates with three monitoring services to make this possible, and the failure modes have distinct signatures once you know what to look for.

Amazon EventBridge receives events for every backup job state change: BACKUP_JOB_STARTED, BACKUP_JOB_COMPLETED, BACKUP_JOB_FAILED, BACKUP_JOB_EXPIRED, COPY_JOB_STARTED, COPY_JOB_COMPLETED, COPY_JOB_FAILED, RESTORE_JOB_STARTED, RESTORE_JOB_COMPLETED, RESTORE_JOB_FAILED. You can create EventBridge rules that trigger SNS notifications, Lambda functions, or other automations when specific events occur. A common pattern is an EventBridge rule that sends an SNS notification (or Slack message via Lambda) whenever a backup job fails.

Amazon CloudWatch provides metrics for backup jobs, copy jobs, and restore jobs, including counts of successful, failed, and expired jobs. You can set CloudWatch alarms on these metrics — for example, alert if the number of failed backup jobs in the past hour exceeds zero.

AWS CloudTrail logs all AWS Backup API calls, giving you an audit trail of who did what and when. This is essential for compliance and for post-incident investigation.

Common Failure Modes and What They Mean

Backup job expired. AWS Backup attempted the backup within the scheduled window but could not complete it before the window closed. If the backup cannot complete inside its scheduled window, it expires. Very large volumes, network constraints, or resource contention can all cause this. Solutions: increase the backup window, reduce the size of the resource being backed up, or investigate why the backup is taking so long.

Backup job not starting. The scheduled time arrived but no job was created. Common causes: the resource is in a stopped state (EC2 instance stopped, RDS instance stopped), the resource does not match the backup plan's selection criteria, the service is not opted in for that region, or IAM permissions are insufficient. Check the backup plan's resource assignments and the service opt-in settings. This is where most people waste debugging time — always check opt-in settings first.

VSS backup failures on Windows. If you are using Windows VSS (Volume Shadow Copy Service) for application-consistent backups of EC2 instances, VSS errors are common. The prerequisites are specific: the SSM agent must be installed and configured on the instance, the instance must have an IAM role with the correct permissions attached before the backup, and the VSS provider must be properly registered. For VSS Windows backups, the only supported resource type is Amazon EC2. The error messages are often cryptic — look for the specific VSS error code in the job details.

Network failures during VMware backup. If you are using AWS Backup gateway to back up on-premises VMware VMs, network connectivity between the gateway and the AWS region is critical. A single gateway can run up to 4 concurrent backup or restore jobs — if you need more, deploy additional gateways and associate them with your hypervisors. Network interruptions mid-backup will cause job failures that may require investigation at the hypervisor level.

Cross-region copy failures. These often relate to the destination vault not existing in the target region, the KMS key in the destination region not being accessible, or the resource type not supporting cross-region copy. When setting up cross-region copies, verify that the destination vault and encryption key are configured before the first copy attempt.

Backup completed with issues. This status can appear when a backup succeeds but with warnings — for example, a VSS backup where some components failed to quiesce. The backup is usable but may not be fully application-consistent. Investigate the specific warning in the job details.

AWS Backup Gateway: Extending Protection to On-Premises VMware

One of AWS Backup's most underappreciated capabilities is protecting workloads that do not run in AWS at all. Through AWS Backup gateway, you can back up on-premises VMware virtual machines to AWS, manage them with the same backup plans and vaults as your cloud resources, and restore them either to on-premises VMware or to VMware Cloud on AWS.

AWS Backup supports centralized and automated data protection for on-premises VMware virtual machines along with VMs in VMware Cloud on AWS and VMware Cloud on AWS Outposts. This means you can manage your entire hybrid estate — cloud and on-premises — from a single backup console with a single policy framework.

How the Gateway Works

The gateway is software in the form of an OVF (Open Virtualization Format) template that you deploy in your VMware environment. It connects AWS Backup to your hypervisor, automatically discovers your virtual machines, and handles the backup and restore data flow between your on-premises infrastructure and AWS.

A single gateway can run up to 4 concurrent backup or restore jobs. For larger environments, you create more gateways and associate them with your hypervisors. You can create a backup gateway using two approaches: the console method (standard, creates gateways through the AWS Backup console with automatic activation) or the manual method (download the OVF and activate it yourself).

VMware Backup Features

VMware backups through AWS Backup support the full feature set: cross-region copy, cross-account copy, Vault Lock, cold storage tiering, retention policies, and centralized monitoring. VM backups include VM discovery, backup scheduling, retention management, a low-cost storage tier, and item-level restore (VMware items are disks). Pricing is $0.05 per GB-month for warm storage and $0.01 per GB-month for cold storage.

Supported restore targets are on-premises VMware, VMware Cloud on AWS, and VMware Cloud on AWS Outposts. When restoring data from your source AWS Region to an on-premises gateway or a gateway in a different Region, you pay for standard AWS Data Transfer OUT charges in addition to the restore prices.

AWS Backup Quotas and Limits: What You Will Hit and When

Every AWS service has limits, and hitting them mid-incident is the worst possible time to learn about them. Here are the key constraints to plan around.

The quota that catches most teams by surprise is the continuous backup 35-day limit. If your compliance requirement is "90 days of PITR capability," you cannot achieve that with AWS Backup continuous backup alone — you need snapshot backups for the extended window, accepting that you lose second-level precision beyond day 35.

AWS Backup Best Practices: What Experienced Teams Do Differently

After going through the architecture, pricing, and failure modes, a set of practices emerges that separates teams who use AWS Backup well from teams who fight it. These are not rules — they are patterns that have proven effective across deployments of every size.

1. Use tags, not resource IDs, for plan assignment. Tag-based assignment means new resources automatically pick up backup protection if they carry the right tags. Resource-ID-based assignment requires manual updates every time you add or remove resources. Tags scale; IDs do not. Establish a tagging convention (e.g., backup-tier=production, backup-tier=archive, backup-tier=dev) before you create your first plan.

2. Use separate vaults for different retention requirements. A vault with 7-day retention and a vault with 7-year retention serve different purposes and should have different access policies. Do not mix them in one vault and try to manage retention per-recovery-point — that is fragile and hard to audit. Separate vaults also let you apply Vault Lock selectively: lock the compliance vault, leave the operational vault flexible.

3. Enable Vault Lock for anything you cannot afford to lose. The cost of Vault Lock is essentially zero (it is a configuration, not a priced feature). The cost of not having it when you need it is everything. Enable governance mode while tuning your retention and policies, then switch to compliance mode when you are confident. Just remember: compliance mode is irreversible.

4. Set up EventBridge alerts for job failures. The default behavior is that failed backup jobs are visible in the console but do not notify anyone. An EventBridge rule that sends an SNS notification on BACKUP_JOB_FAILED costs nothing and ensures you know within minutes when something breaks. Without this, a silent backup failure can go unnoticed for weeks — until you need the backup that does not exist.

5. Use cold storage for anything retained over 90 days. The cost difference is substantial — 70–80% savings for supported resource types. The trade-off (slower restores, higher retrieval cost) is acceptable for backups you are unlikely to restore from frequently. For S3 specifically, use the low-cost warm tier for anything retained over 60 days.

6. Restore-test your critical backups. The $1.50 per evaluation fee for restore testing is trivial compared to the cost of a failed restore during an actual incident. Set up a restore testing plan for your most critical resources and run it monthly. This is the difference between "we have backups" and "we can recover."

7. Use cross-account backup for production workloads. Even if you are a small team, a separate AWS account for backups costs nothing extra (you are already paying for the storage) and provides meaningful protection against account-level compromise. Combine with Vault Lock in compliance mode on the destination vault for maximum protection.

8. Do not enable AWS Backup for services where native backup is sufficient. If you have a single EBS volume that you snapshot weekly via Data Lifecycle Manager, adding AWS Backup adds complexity without proportional benefit. Use AWS Backup when you need centralization, not as a reflex. The right question is not "should I use AWS Backup?" but "am I managing backups across enough services that centralization pays for itself?"

9. Classify workloads and set backup frequency accordingly. Backup costs are directly related to how frequently you back up your data. Classify workloads by their recovery time and recovery point objectives, then configure backup frequencies accordingly. A mission-critical database needs more frequent backups than a static archive bucket. Not everything needs daily backups.

10. Use customer-managed KMS keys for cross-account copies. You cannot do cross-account copies if your vaults are using AWS managed keys. Plan for customer-managed keys from the start if cross-account backup is in your roadmap, even if you are not using it yet.

Cost Optimization Strategies: Paying Less Without Losing Protection

Backup costs can spiral quickly if you are not paying attention. Here are the specific levers you can pull, in order of impact.

Lever 1: Control backup frequency. This is the single biggest cost lever. Backing up daily costs roughly 30 times more than backing up monthly (in storage terms, before deduplication). Not every workload needs daily backups — classify by RPO (recovery point objective, the maximum data loss you can tolerate) and set frequency accordingly.

Lever 2: Dictate retention policies. Similarly, classify workloads by retention requirements. Not everything needs 7-year retention. A development database might need 7 days; a production financial database might need 7 years. Retention directly drives storage cost — a 35-day retention policy costs roughly one-sixth of a 210-day policy for the same backup frequency.

Lever 3: Use lifecycle management for cold storage transitions. For supported resource types, automatically transition backups to cold storage after a defined period. Cold storage is 70-80% cheaper than warm. The 90-day minimum in cold is usually not a problem for compliance-driven retention.

Lever 4: Use S3 backup tiering for S3 workloads. The low-cost warm tier ($0.035 vs $0.05) provides up to 30% savings on S3 backup storage retained for extended periods. Objects need 60 days in warm first, but for long-retention S3 backups, the savings are meaningful.

Lever 5: Monitor cross-region copy volumes. Cross-region copies double your storage cost (you pay for storage in both regions) plus data transfer. Only copy what you actually need to the secondary region — not every backup needs a cross-region copy. Consider copying only weekly or monthly backups cross-region, leaving daily backups regional.

Lever 6: Delete expired backups promptly. AWS Backup handles this automatically via retention policies, but if you have manually created on-demand backups outside a plan, they may not have a retention policy and will accumulate indefinitely. Audit your vaults periodically for orphaned recovery points.

When to Skip AWS Backup Entirely (and What to Do Instead)

Honesty time: AWS Backup is not always the right answer. Here are the situations where you should look elsewhere, and what to use instead.

Situation 1: You have one EBS volume and nothing else. Data Lifecycle Manager (DLM) is simpler, purpose-built for EBS snapshot lifecycle management, and does exactly what you need without the conceptual overhead of vaults, plans, and opt-ins. AWS Backup adds complexity without proportional benefit at this scale.

Situation 2: You need file-level restore from VM backups on a regular basis. AWS Backup supports item-level restore for VMware (items are disks), but if you need to restore individual files from within VM disks frequently, a third-party tool with native file-level recovery is less painful. AWS Backup is not designed to be a file-recovery tool.

Situation 3: You have a multi-cloud estate. AWS Backup only protects AWS resources (plus on-prem VMware via gateway). If you are running workloads in Azure and GCP alongside AWS, a multi-cloud backup tool will give you unified management across all three. AWS Backup cannot help you with the non-AWS portions.

Situation 4: You need application-aware backup for complex enterprise applications. AWS Backup handles VSS for Windows and has native SAP HANA integration, but if you are running Exchange, Oracle, or other complex applications that require application-consistent backups with specialized processing, a dedicated backup tool with application agents is more appropriate.

Situation 5: Your service is not supported. AWS Backup does not support every AWS service. Notably absent: ElastiCache (Redis/Memcached), SQS, SNS, Lambda, API Gateway, and many others. If your critical data lives in an unsupported service, you need that service's native backup mechanism or a custom solution. Check the supported services table before designing your strategy around AWS Backup.

Frequently Asked Questions

Is AWS Backup free?

The orchestration layer — backup plans, scheduling, policy enforcement, centralized monitoring — is free. There is no minimum fee and there are no setup charges. You pay for backup storage (per GB-month, varying by service), data restored (per GB), cross-region data transfer, and optional features like restore testing, Audit Manager, and malware protection. For many small deployments, the total AWS Backup bill is just the storage cost, which starts at $0.01–$0.10 per GB-month depending on the service and storage tier.

Does AWS Backup replace EBS snapshots and RDS automated backups?

AWS Backup does not automatically replace them — you must opt in per service. Once you do, AWS Backup creates and manages the same underlying snapshot types but governs them with your centralized policy. For RDS, if you enable AWS Backup management, it works alongside RDS automated backups (which provide PITR). You can choose to let AWS Backup manage continuous backups for PITR, or keep RDS's native automated backups and use AWS Backup only for snapshot copies. Be aware that if both run, you may pay for overlapping recovery points.

Does AWS Backup support Amazon S3?

Yes, AWS Backup supports Amazon S3 data, including continuous backup with point-in-time recovery (restore to any point within the last 35 days) and snapshot backups. S3 backups have their own pricing: $0.05 per GB-month for warm storage, $0.035 per GB-month for the low-cost warm tier (for backups retained longer than 60 days), plus charges for S3 GET/LIST requests and EventBridge events during backup. For S3 objects smaller than 128 KB, the backups are priced as a 128-KB backup. S3 backups also support access points (reading backup data directly without full restore) and backup search (finding specific objects across recovery points).

Does AWS Backup support Amazon EKS?

AWS Backup supports Amazon EKS cluster backups, but this covers cluster state (Kubernetes objects, configurations), not persistent volumes. For EBS, S3, and EFS attached to EKS clusters, you use the standard per-service backup. EKS backup pricing includes a one-time creation fee of $0.10 per namespace backed up, plus $0.01 per GB-month for cluster state storage. EKS backup supports cross-region and cross-account copy but not cold storage or continuous backup. EKS cluster state storage in a logically air-gapped vault costs $0.0115 per GB-month.

Does AWS Backup support Amazon ElastiCache?

No, AWS Backup does not currently support Amazon ElastiCache (Redis or Memcached). For ElastiCache backup, you use the native ElastiCache snapshot feature. Check the feature availability page for the current list of supported services, as AWS periodically adds new ones.

What is the difference between AWS Backup and Data Lifecycle Manager (DLM)?

Data Lifecycle Manager is specifically for EBS snapshot lifecycle management — it automates the creation, retention, and deletion of EBS snapshots based on tags. AWS Backup is a much broader service that manages backups across many AWS services, with features like Vault Lock, cross-account copies, audit trails, and centralized monitoring that DLM does not offer. If you only need EBS snapshot management, DLM is simpler. If you need multi-service backup with compliance features, AWS Backup is the right tool.

What is AWS Backup Vault Lock?

Vault Lock enforces write-once-read-many (WORM) retention on a backup vault. Once locked in compliance mode, recovery points in that vault cannot be deleted before their retention period expires, regardless of who attempts the deletion or what IAM permissions they have. This provides ransomware protection and helps meet regulatory retention requirements. Governance mode allows privileged users to alter settings, while compliance mode becomes immutable and permanent once the grace period ends.

Are AWS Backup backups encrypted?

Yes, all backups in AWS Backup are encrypted. By default, they use an AWS managed KMS key, but you can specify a customer-managed KMS key per vault for more control over key policies and access. Encryption is applied at rest and in transit (for cross-region and cross-account copies). You cannot disable encryption for AWS Backup vaults.

How much does AWS Backup cost for EC2?

For EC2 instance backups, AWS Backup creates EBS snapshots of the attached volumes (including the root volume). Storage costs are $0.05 per GB-month for warm storage (the same as native EBS snapshot pricing). EC2 backup does not currently support cold storage or continuous backup. Restores are charged per GB of data restored. There is no additional charge for the EC2 instance metadata that AWS Backup captures alongside the volume snapshots.

How much does AWS Backup cost for RDS?

RDS backup storage through AWS Backup costs $0.095 per GB-month in US East, which is higher than EBS or EFS. RDS backups do not currently support cold storage. If you need point-in-time recovery, you can enable continuous backup, which captures transaction logs for restore to any second within the last 35 days. Aurora cluster snapshots cost $0.021 per GB-month, significantly less than RDS.

Is AWS Backup incremental?

Yes, for most supported services. After the initial full backup, subsequent backups capture only the data that has changed since the last backup. This applies to EBS, EFS, RDS, Aurora, S3, and most other services. However, the storage billing may not feel incremental because you are billed for total stored data across all recovery points. For SAP HANA, snapshots are full, and incremental backup is offered through PITR.

Can AWS Backup do cross-region backup?

Yes, cross-region backup copy is supported for most resource types. You add a copy rule to your backup plan specifying the destination region, and AWS Backup automatically copies recovery points after the initial backup completes. You pay standard cross-region data transfer charges (billed to the sending account) plus backup storage charges in the destination region (billed to the receiving account). Cross-region copies can also go to logically air-gapped vaults in the destination region.

What is AWS Backup Audit Manager?

AWS Backup Audit Manager is a compliance feature that evaluates your backup resources against controls you define — such as backup frequency, encryption requirements, and retention periods — and generates reports showing compliance status. It helps answer questions like "Am I backing up all my resources?" and "Are all my backups encrypted?" Pricing is $0.00125 per backup evaluation (prorated), plus AWS Config configuration item charges.

What is a logically air-gapped vault in AWS Backup?

A logically air-gapped vault is a specialized vault type that provides enhanced security beyond a standard backup vault. It includes compliance-mode Vault Lock automatically, restricted access controls, and the ability to share vault access with other accounts for faster recovery. Each vault is encrypted with either an AWS owned key (default) or a customer-managed KMS key. Storage costs are approximately 15% higher than standard vault storage.

What happens when I close an AWS account that has AWS Backup vaults?

When you close an AWS account containing backup vaults, AWS suspends the account for 90 days with the backups intact. If you do not reopen the account within those 90 days, AWS deletes the contents of the backup vaults, even if Vault Lock was in place. This is a fundamental limitation of Vault Lock — it protects against deletion within an active account, but it cannot prevent data loss when the account itself is closed and abandoned.

Can I use AWS Backup with Terraform?

Yes, AWS Backup is fully supported in Terraform through resources like aws_backup_plan, aws_backup_vault, aws_backup_selection, aws_backup_vault_lock_configuration, and aws_backup_logically_air_gapped_vault. There is also a community-maintained Terraform module for AWS Backup that covers the full API surface. CloudFormation and AWS CDK are also supported for infrastructure-as-code deployments.

Revision note. Written September 2026 — always check the current AWS Backup documentation and pricing page before making architectural decisions. If you have been piecing together backup strategies across half a dozen AWS consoles and hoping nothing falls through the cracks, you are not alone, and there is a better way.