Automate Amazon EC2 AMI backup and retention

Decide whether an AMI is the right recovery artifact

An AMI can capture the root volume and selected attached EBS volumes for an EC2 instance. It can help recreate the machine image and block-device mapping. It does not prove that application data is transactionally consistent or that dependent systems can recover to a common point. Map each recovery requirement to the artifact that satisfies it. Use database-native backup or a managed database recovery feature for databases. Use object versioning or backups for object data. Store infrastructure configuration and deployment code in a controlled repository. Keep secrets outside the image. Record the recovery point objective, recovery time objective, retention period, copy locations, and restoration owner. An AMI schedule without these requirements is only image creation automation.

Prefer Amazon Data Lifecycle Manager when it fits

Amazon Data Lifecycle Manager supports policies for creating, retaining, deprecating, copying, and deregistering EBS-backed AMIs. A policy can target instances by tags and can use age-based or count-based retention. Use this managed path when its policy model covers the selection and retention requirement. A managed policy reduces custom code and makes the schedule easier to inspect. It also has documented behavior that the owner must understand. For example, tag changes can stop future management, terminated instances can affect retention of earlier images, and a policy in an error or disabled state can stop deregistration depending on the configuration. Tag-based targeting: Built in; You build and test discovery. Age or count retention: Built in; You implement the calculation. Cross-Region and cross-account copy: Policy-driven; You handle keys, permissions, and retries. Approval or evidence steps: Limited; Fully customizable. Behavior reference: Documented service semantics; Your code is the documentation. Maintenance owner: AWS service team plus your policy owner; Your team owns every edge case. Use custom automation only when the managed service cannot express a required selection rule, approval, integration, or evidence step. Document that reason in the design. Each gap costs code, tests, and an on-call path, and many programs discover that the gap was a preference rather than a requirement.

Define target selection

Use dedicated, case-sensitive tags to select instances. Separate environment, service, owner, recovery class, and policy identifier. Avoid broad selectors that can include test machines or omit a critical machine after an unrelated tag edit. Tags are editable by anyone with the right permissions. Restrict who can modify the selection tags, and alert on changes to them. A well-meaning tag cleanup can silently remove a critical instance from its recovery coverage. Review the target set before enabling a policy. Produce an inventory that shows each selected instance, attached volume, encryption key, application owner, and required copy destination. Alert when an expected instance leaves the target set or a new instance enters it. Do not rely on a mutable display name as the only identity. Keep the instance identifier and policy identifier in the evidence record.

Choose schedule and retention behavior

Select a schedule from the recovery point objective and the rate of meaningful change. More frequent image creation can add cost and API activity without improving application recovery if the important data is stored elsewhere. Translate the objective into numbers before choosing. If the recovery point objective is 24 hours, a daily image with 14 days of retention provides two weeks of recovery points that each lose at most a day of machine state. If the application changes hourly but its data lives in a managed database, more frequent images buy little and cost snapshot storage and API activity. Choose count-based or age-based retention deliberately. Count-based retention gives a predictable number of recent images. Age-based retention aligns with a time window. Read the service behavior for the last retained AMI, policy errors, terminated instances, cross-Region copies, and delayed deregistration. Deprecation and deregistration are different. A deprecated AMI is hidden from some discovery paths but still exists and still incurs snapshot storage cost. Deregistration removes the AMI registration and can delete backing snapshots when the lifecycle policy manages them. Confirm the behavior for shared images and protected snapshots before release.

Decide whether the instance can reboot

Creating an EBS-backed AMI from a running instance can reboot it by default to improve file-system consistency. A no-reboot creation avoids that restart, but AWS states that file-system integrity cannot be guaranteed. Choose the option with the application owner. For a no-reboot path, quiesce writes when the application supports it and validate recovery. For a reboot path, include the restart in the maintenance and availability design. Neither option replaces an application-consistent backup for data stores that require one.

Configure encryption and copies

Confirm encryption for every included volume and every copied AMI. A cross-Region or cross-account copy needs access to the relevant AWS Key Management Service (KMS) keys and an ownership model in the destination. Test the destination launch path, identity, network, and key permissions. Test the copy as a recovery artifact, not a file transfer. Launch from the copied AMI in the destination account, with the destination's keys, network, and identity. Many copy failures surface only at launch time, when a key policy or service role is missing. Copy only when the recovery design needs another Region or account. Track the storage and transfer cost. A copy that cannot be launched because of missing permissions is not a recovery point. Use tags that identify the source, policy, creation time, recovery class, and owner. Do not copy sensitive or misleading tags without review.

Protect deregistration and snapshot deletion

Delete only resources created and owned by the policy. Require a policy identifier and service-generated ownership evidence. Before deregistration, check that the image is outside retention, is not protected, is not the last required recovery point, and is not referenced by a launch template, launch configuration, autoscaling path, or operational runbook that still matters. Separate selection from deletion in custom automation. First produce a candidate list. Then validate ownership and references. Use a review or delay window for high-risk environments. Make retries idempotent so a partial failure does not repeat unsafe actions. Log the planned action, completed action, resource identifiers, policy version, and reason. Alert on permission errors, quota problems, copy failures, an empty target set, or a policy that creates no successful recovery point.

Use Lambda only for a documented gap

A custom Lambda path needs a scheduler, scoped AWS Identity and Access Management (IAM) role, target discovery, idempotency, pagination, retry handling, concurrency control, retention calculation, reference checks, logging, and alarms. Keep image creation and cleanup as separate operations so one failure does not hide the other. A workable custom flow has six stages: Amazon EventBridge starts the function on a schedule. The function discovers target instances from the selection tags. A creation operation images each target and tags the AMI and its snapshots. A separate cleanup operation lists candidates past retention. Validation confirms policy ownership, references, and protection rules. The function deregisters the AMI and deletes the snapshots it owns. Handle the platform's limits. DescribeImages and related calls paginate; iterate every page. EC2 API calls throttle under load; use exponential backoff with jitter. Prevent overlapping executions with reserved concurrency or a lock, because two concurrent cleanup runs can race on the same candidate. Treat pending, failed, and deprecated images as distinct states with distinct handling. Use a dry-run report before enabling deletion. Limit the function to explicit Regions and accounts. Handle AMIs that are pending, failed, deprecated, shared, protected, or missing expected tags. Do not infer ownership from a name prefix alone. Store configuration outside the function package and version it. Review the IAM policy for the smallest required resource and action scope. Test the code against a non-production account with representative images, copies, launch templates, and failure states.

Test recovery

A successful image creation event is not a recovery test. Launch a representative instance from the retained AMI. Verify boot, file systems, application health, identity, network access, monitoring, configuration retrieval, and the connection to required data services. Record the achieved recovery time and the image used. Time each stage separately: locate the image, launch, boot, application start, and health check pass. The recovery time objective is met by the slowest stage, which is usually application startup or data reconnection rather than the launch call. Test an image from every required destination account and Region. Repeat the test after material operating-system, encryption, network, deployment, or application changes. Include a failure exercise. Test a missing key permission, an unavailable dependency, and a stale configuration reference. The runbook should tell the operator when to stop and choose another recovery path.

Monitor cost and policy health

Track snapshot storage, image count, copy count, cross-Region transfer, failed creations, failed copies, and deregistration lag. Alert when the latest successful image exceeds the recovery point objective. EBS snapshots are incremental: the first snapshot of a volume stores the used blocks, and later snapshots store only changed blocks. Cost therefore tracks data churn, not image count alone. A quiet machine can hold thirty images cheaply while a busy log volume makes three images expensive. Copied AMIs do not share that incrementality across accounts or Regions; each copy is its own storage line item. Review policies after instance termination, service ownership changes, tag-standard changes, and account moves. Managed automation still needs an owner and a periodic control review.

Use a recovery readiness checklist

The AMI role in the recovery design is documented.
Target instances and included volumes are inventoried.
The schedule and retention rule follow recovery requirements.
Reboot or no-reboot behavior has application-owner approval.
Encryption and destination key permissions are tested.
Deletion requires policy ownership and reference checks.
The last required recovery point is protected.
Error, disabled-policy, terminated-instance, and tag-removal behavior is understood.
Custom code handles pagination, throttling, and overlapping executions.
Copied AMIs are launch-tested with destination keys and network.
Snapshot and copy cost is reviewed against churn, not image count.
Recovery tests launch images from every required location.
Alarms cover stale recovery points, failed copies, permission errors, and unexpected scope changes.

Primary AWS documentation

Official references for the tools and services covered in this guide.