Why policy beats per-resource settings
In a typical account, backups are enabled one resource at a time. An engineer ticks a box on a database, another sets a snapshot schedule on a volume, and a third forgets. Six months later nobody can say which resources are protected, and the only way to find out is to click through the console.
AWS Backup and Azure Backup solve this by letting you describe protection as a policy and attach it to resources by rule. The design work is deciding the rules, protecting the vaults and making the whole setup visible. That is the core of our backup and disaster recovery service once the strategy is agreed.
What good looks like
- Resources are included by tag, so a new database is protected from the day it exists.
- A small number of plans map to your recovery tiers, not dozens of one-off schedules.
- Vaults are encrypted, access is restricted and deletion is controlled.
- Policies are in version control and applied by a pipeline.
- Failures alert a human, and coverage is reported regularly.
How it works in practice on AWS
An AWS Backup setup has three parts: a vault that stores recovery points, a plan that defines schedule and lifecycle, and a selection that decides which resources the plan covers. In Terraform:
resource "aws_backup_vault" "primary" {
name = "prod-primary"
kms_key_arn = aws_kms_key.backup.arn
}
resource "aws_backup_plan" "tier1" {
name = "tier1-daily"
rule {
rule_name = "daily"
target_vault_name = aws_backup_vault.primary.name
schedule = "cron(0 3 * * ? *)"
start_window = 60
completion_window = 360
lifecycle {
delete_after = 35
}
}
}
resource "aws_backup_selection" "tier1" {
name = "tier1-by-tag"
plan_id = aws_backup_plan.tier1.id
iam_role_arn = aws_iam_role.backup.arn
selection_tag {
type = "STRINGEQUALS"
key = "backup-tier"
value = "tier1"
}
}
Anything tagged backup-tier = tier1 is now covered. The tag becomes part of your standard for new resources, and a policy-as-code check in the pipeline can reject production resources that carry no tier tag.
For several accounts, AWS Organizations backup policies let you define plans centrally and deploy them to member accounts, and Backup Audit Manager can report on whether resources meet your rules. Not every resource type supports every feature, such as continuous backup, so we check the support matrix for the services you actually run.
How it works in practice on Azure
Azure Backup uses a Recovery Services vault or a Backup vault, depending on the workload, with policies that define schedule and retention. Protection is assigned per resource, so tag-driven coverage is usually achieved with Azure Policy, which can automatically configure backup for virtual machines or other supported resources that match a rule. Redundancy of the vault (locally redundant, zone redundant or geo redundant storage) is chosen at creation and affects both cost and what you can survive. We confirm current limits for your resource types before committing to a design.
Vault protection is the point
A backup that an attacker or a mistaken script can delete is a liability. Vault configuration matters as much as the schedule:
- AWS: use a customer-managed KMS key, a restrictive vault access policy, and Backup Vault Lock where policy requires write-once behaviour. Copy to a separate account, covered in cross-account replication.
- Azure: enable soft delete, consider immutability, and use a Resource Guard for multi-user authorisation on critical operations.
We treat Vault Lock and immutability carefully. A compliance-mode lock cannot be removed once it takes effect, so we test the configuration in a non-production account first and agree the retention that is locked in. Key and access design is covered in backup encryption and access control.
Decisions and trade-offs
Central service or native per-service backups. Central policy gives consistency and reporting. Native settings sometimes give finer control, for example database point-in-time recovery windows. We often combine them: AWS Backup for the baseline, native features where the database needs them.
One plan or many. Fewer plans are easier to reason about. Add a plan only when a tier genuinely needs a different schedule or retention.
Terraform modules. A small internal module that creates a vault, a plan and a selection keeps accounts consistent. See our Terraform and infrastructure as code work for how modules and state are organised.
When this is overkill. If you run a single managed database with automated backups and nothing else stateful, enabling its built-in retention and one copy elsewhere may be enough. Central policy pays off as accounts and resource types multiply.
Common failure modes
- Tags that drift. Resources lose or never get the tag, so they quietly fall out of coverage. A scheduled report of untagged resources catches this.
- Missing IAM permissions. The backup role cannot read a resource or key, and jobs fail. We test a backup and a restore for each resource type.
- Retention shorter than the recovery window. A bug found after 40 days cannot be rolled back to a 35 day backup.
- Vault in the same account as production. One compromised credential reaches both.
- Alerts routed nowhere. Failure events must reach a monitored channel.
Restore paths you should check per resource type
A policy is only as good as the restore behind it, and each resource type restores differently. Before sign-off we walk through the restore for every type in scope and record what it produces.
- Databases and volumes usually restore to a new resource, so connection strings, security groups and parameter settings must be re-applied. We document which settings carry over and which do not.
- File systems and object storage often allow partial or item-level restore, which is faster for accidental deletion than a full recovery.
- Virtual machines restore as new instances or disks, and attached identities, extensions and network interfaces may need rebuilding.
Recording this per type turns a vague promise of “we have backups” into a concrete answer about what recovery looks like and who does what. It also shows early which resource types need extra scripting, and those become candidates for the validation work in our database backup automation approach.
Delivery and handover
All policies are code in your repositories, applied by your pipeline, with a short guide to tagging and adding a new resource type. We configure notifications through EventBridge and SNS or Azure Monitor alerts, and leave a coverage report. The next step is proving the policies work through automated restore testing.
How to tell it is working
Coverage reports show no unprotected production resources, failed jobs are rare and acknowledged quickly, and a new resource with the right tag appears in the next backup run without human action. To plan a rollout across your accounts, book a consultation.