Automate EC2 Backups with Snapshots

At 3 a.m., when your EC2 instance’s disk fails, the first question is: do you have a reliable backup that actually restores? Manually snapshotting EC2 volumes—clicking the AWS console every night—is brittle, easy to forget, and leaves your most critical workloads exposed to data loss. That’s the problem this lesson solves: making automate ec2 backups with snapshots a background process you set once, and then trust to run on schedule, retain what matters, and clean up what doesn’t.

The problem this lesson solves

Backup automation is not a nice-to-have; it’s the difference between a small blip and a regional disaster. Without it, you face:

• Human error: You forget to take a snapshot before a risky update, and you lose a day of work.
• Inconsistent backups: Snapshots at random times may miss the most recent changes.
• Rising storage costs: Manual snapshots pile up forever, and you pay for every GB every month.
• No retention policy: You either keep everything (expensive) or delete everything (dangerous).

By automating EC2 backup snapshots, you solve each of these. Your backups happen on schedule, with predictable retention, and you can restore a volume in minutes.

Pro tip: If your instance is part of an Auto Scaling group or ephemeral, back up the data volume—not just the root volume. Automating snapshots of both ensures you can rebuild an entire server state.

This lesson builds directly on your earlier AWS work: if you’ve created EC2 instances and volumes, you already know the basics. Now we add the automation layer that turns backups from a manual chore into a self-healing safety net.

Core concept / mental model

Think of an EBS snapshot as a photograph of your volume at a moment in time. A single photograph is useful, but a camera that takes a photo every night and automatically keeps only the last 30 is far more practical for a business.

Automating EC2 backups with snapshots is that camera: a scheduled process that snaps the volume, tags it with a timestamp, and applies a retention policy. Instead of you manually creating snapshots, a service does it for you on a fixed schedule.

There are three main building blocks in AWS:

• EBS snapshots: Point-in-time copies of your volumes, stored in S3, that you can use to create a new volume. They are incremental: after the first snapshot, only changed blocks are stored, which keeps costs low.
• Scheduled automation: You can use AWS Backup, Data Lifecycle Manager (DLM), or a Lambda function triggered by EventBridge. Each approach works, but they differ in control and complexity.
• Retention policy: Define how long to keep snapshots. Old snapshots are automatically deleted, preventing cost creep.

Here’s a simplified flow:

1. A schedule (e.g., nightly at 1:00 AM) triggers the backup process.
2. The process selects the target EC2 volumes (by tags like Backup: Daily=true).
3. It creates a snapshot, tagging it with a timestamp and a retention date.
4. The service periodically deletes snapshots older than the retention period.

Key insight: Automation isn’t just about creating snapshots—it’s also about managing their lifecycle. The best automation deletes old snapshots automatically, so your backup strategy stays cost-effective.

How it works step by step

We’ll use AWS Data Lifecycle Manager (DLM) as the primary method because it’s a native AWS service designed for this exact job—no custom code involved. Here’s the step-by-step process:

Step 1: Tag your volumes

Decide which volumes to back up. A common pattern is to tag instances and volumes with Backup: true. DLM can select volumes by tag, which makes it easy to add new volumes later without touching the policy.

Step 2: Create a DLM policy

In the EC2 console, go to Elastic Block Store → Lifecycle Manager. Create a policy with the following parameters:

1. Policy type: EBS snapshot policy.
2. Resource type: Volume.
3. Target tags: Backup: true (or your chosen tag).
4. Schedule: e.g., daily at 01:00 UTC. You can also use hourly or weekly.
5. Retention: Keep for 7 days (or your choice). Keep at least one to ensure nightly coverage.
6. Tag policy: Automatically add Backup: CreatedBy=DLM and a timestamp tag.

Step 3: Let DLM create and delete snapshots

DLM creates snapshots according to the schedule. It also deletes snapshots that exceed the retention rule. You can monitor its activity through CloudWatch metrics and logs.

Step 4: Verify a restore

Periodically test restoring from a snapshot to a new volume to ensure your backups are valid. This is the only way to be confident in your DR readiness.

That’s it—no cron, no EC2 instance to keep running, no custom Lambda. DLM does it natively.

Hands-on walkthrough

Let’s put this into practice. We’ll use the AWS CLI to simulate what the DLM policy does, so you understand the underlying API calls. Then we’ll create a DLM policy from the console to automate it.

Create a snapshot manually (baseline)

First, find your volume ID and create a snapshot:

# List your volumes and note the VolumeId
export VOLUME_ID=vol-0abc123def4567890

# Create a snapshot with a name tag
SNAPSHOT_ID=$(aws ec2 create-snapshot \
  --volume-id $VOLUME_ID \
  --description "Manual snapshot backup" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=backup-manual}]' \
  --query 'SnapshotId' --output text)
echo "Created snapshot: $SNAPSHOT_ID"

Expected output (ID will differ): Created snapshot: snap-0fedcba9876543210

Automate with a Lambda function (alternative to DLM)

If you need more flexibility (e.g., custom logic, cross-region copy), use Lambda. Here’s a minimal daily backup function:

import boto3
import os
from datetime import datetime, timedelta

ec2 = boto3.client('ec2')

def lambda_handler(event, context):
    # Define which volumes to back up via tag
    volumes = ec2.describe_volumes(
        Filters=[{'Name': 'tag:Backup', 'Values': ['true']}]
    )['Volumes']

    today = datetime.utcnow().isoformat()
    for vol in volumes:
        ec2.create_snapshot(
            VolumeId=vol['VolumeId'],
            Description=f'Auto snapshot {today}',
            TagSpecifications=[{
                'ResourceType': 'snapshot',
                'Tags': [
                    {'Key': 'Name', 'Value': 'Auto-Snapshot'},
                    {'Key': 'CreatedBy', 'Value': 'LambdaBackup'}
                ]
            }]
        )

    # Optionally: clean up snapshots older than 7 days
    retention_days = 7
    old_snapshots = ec2.describe_snapshots(
        OwnerIds=['self'],
        Filters=[{'Name': 'tag:CreatedBy', 'Values': ['LambdaBackup']}]
    )['Snapshots']

    cutoff = datetime.utcnow() - timedelta(days=retention_days)
    for snap in old_snapshots:
        snap_time = snap['StartTime'].replace(tzinfo=None)
        if snap_time < cutoff:
            ec2.delete_snapshot(SnapshotId=snap['SnapshotId'])
            print(f"Deleted old snapshot {snap['SnapshotId']}")

    return {'status': 'success', 'created': len(volumes)}

Trigger: Connect it to an Amazon EventBridge rule that fires every day at a fixed time (e.g., 1:00 AM).

Create a DLM policy via AWS CLI

Here’s how to create a DLM policy from the command line (note the JSON syntax):

aws dlm create-lifecycle-policy \
  --description "Daily backup daily retention 7d" \
  --state ENABLED \
  --execution-role-arn arn:aws:iam::123456789012:role/AWSDataLifecycleManagerDefaultRole \
  --policy-details file://policy.json

And the policy.json content (simplified):

{
  "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
  "ResourceTypes": ["VOLUME"],
  "TargetTags": [{"Key": "Backup", "Value": "true"}],
  "Schedules": [{
    "Name": "Daily",
    "Interval": 24,
    "IntervalUnit": "HOURS",
    "Times": ["01:00"],
    "TagsToAdd": [{"Key": "BackupSchedule", "Value": "Daily"}],
    "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS", "Times": ["01:00"]},
    "RetainRule": {"Count": 7},
    "CopyTags": true
  }]
}

Expected outcome: DLM will create a snapshot of every volume tagged Backup=true every 24 hours and keep 7 snapshots. It will also auto-delete older ones.

Compare options / when to choose what

You have multiple ways to automate EC2 snapshots. Here’s a quick comparison:

When to choose what:

• Start with DLM if your goal is simply “back up these tagged volumes every night and keep 7.” It’s the fastest and most reliable.
• Use AWS Backup if you need a company-wide backup policy that includes RDS, DynamoDB, and EC2 together.
• Go with Lambda if you need custom behavior—like snapshotting only volumes that changed significantly, or sending Slack alerts—that DLM can’t express.

Troubleshooting & edge cases

• Snapshots fail with Error: Volume not attached: DLM can still snapshot a detached volume, but if you manually snapshot a volume that is in-use and you want consistency, consider a crash-consistent snapshot. For file-system consistency, you may need to freeze writes (e.g., with xfs_freeze) before snapshotting.
• DLM policy not creating snapshots: Check the target tag. Make sure the volume has the exact tag key/value. Also verify the IAM role (AWSDataLifecycleManagerDefaultRole) exists and is correctly attached.
• Snapshots are not deleted as expected: Review the retention rule. If you set Count to 7, DLM keeps the most recent 7 snapshots. If you see more, check for any custom tags that might be causing the policy to skip deletion.
• Costs growing: Remember that EBS snapshots are incremental—they only store changed blocks. But long retention times still add up. Set a sensible retention like 7 or 30 days depending on your compliance needs.
• Restore fails: Always test restore before you actually need it. Create a volume from the snapshot and mount it to a new instance; verify your data.

Pro tip: Always implement a tagging strategy before automating. A consistent tag like Backup: true makes it trivial to add new volumes to your backup plan—just tag and forget.

What you learned & what's next

You now know how to automate EC2 backups with snapshots: the core idea, the steps, and how to choose between DLM, AWS Backup, and Lambda. You can explain that snapshots are incremental, how retention works, and why testing restores is crucial. In the next lesson, we’ll dive into S3 lifecycle policies, where you’ll apply similar automation to object storage—so you can manage data retention and cost across both block storage and buckets. Before moving on, try these next steps:

• Add tags to all your EC2 volumes and create a DLM policy for daily snapshots.
• Simulate a failure by stopping an instance, creating a new volume from a snapshot, and mounting it.
• Set up a CloudWatch alarm to alert you if a snapshot fails.

You’re building a robust backup strategy—one step at a time.