Backup Plans, Schedules, and Lifecycle Rules

Anatomy of a Backup Plan

A Backup Plan is the central configuration object in AWS Backup. It is a JSON document (or a console-configured policy) that defines three things: when to back up, how long to keep the backup, and where to copy it.

A Backup Plan contains one or more rules, and each rule contains:

Backup Rule:
  RuleName: DailyBackup
  TargetBackupVault: prod-vault
  ScheduleExpression: cron(0 2 * * ? *)   # 2:00 AM UTC daily
  StartWindowMinutes: 60                   # Start within 60 min of scheduled time
  CompletionWindowMinutes: 180             # Must complete within 3 hours
  Lifecycle:
    DeleteAfterDays: 35                    # Delete recovery point after 35 days
    MoveToColdStorageAfterDays: 7          # Move to cold storage after 7 days
  CopyActions:
    - DestinationBackupVaultArn: arn:aws:backup:us-west-2:123456789012:backup-vault:dr-vault
      Lifecycle:
        DeleteAfterDays: 35

Lifecycle Transitions: Warm vs. Cold Storage

Recovery points can exist in two storage tiers:

• Warm storage: Standard S3-equivalent storage. Fast restores, higher cost per GB.
• Cold storage: S3 Glacier-equivalent storage. Slower restores (hours), lower cost per GB.

The MoveToColdStorageAfterDays setting automates the transition. A common pattern for compliance workloads:

Day 0:    Backup created → Warm storage (fast restore available)
Day 7:    Moved to Cold storage (cost optimization)
Day 2555: Deleted (7-year retention expires)

This balances cost against recovery speed: recent backups (most likely to be needed) stay in warm storage, while older backups (needed only for compliance or rare DR scenarios) move to cold storage automatically.

Constraint: Not all resource types support cold storage transitions. EFS and DynamoDB support it; EBS snapshots do not (they are always in warm storage). Check the AWS Backup documentation for the current matrix before designing lifecycle rules.

Backup Windows and Job Failures

The StartWindowMinutes and CompletionWindowMinutes settings are often overlooked but operationally important.

• If a backup job does not start within the start window, AWS Backup marks it as EXPIRED and does not attempt it.
• If a backup job does not complete within the completion window, AWS Backup marks it as FAILED.

Both states generate CloudWatch Events that you can route to SNS for alerting. A backup plan without alerting on failed jobs is not a backup plan — it is a false sense of security. Wiring this up is a single CloudWatch alarm watching the AWS/Backup namespace's NumberOfBackupJobsFailed metric, firing when the daily sum is at least 1 and notifying an SNS topic.

Key Point: A backup plan is only as good as its monitoring. The most common real-world backup failure mode is not "the backup service broke" — it is "a backup job silently failed for three weeks and nobody noticed until a restore was needed." Build alerting on NumberOfBackupJobsFailed and NumberOfBackupJobsExpired metrics from day one.