Automated EC2 Backups Across AWS Accounts for Disaster Recovery
Automated EC2 Backups Across AWS Accounts for Disaster Recovery
Introduction
A reliable disaster recovery (DR) strategy is essential for production workloads running on AWS. Keeping backups only within the same AWS account can create a significant dependency on that account. Security incidents, accidental resource deletion, credential compromise, or other account-level failures can potentially affect both production resources and their backups.
A stronger approach is to maintain automated backups in an isolated AWS account while retaining operational backups within the primary environment.
This article presents a serverless, automated architecture for backing up Amazon EC2 workloads within the primary AWS environment and replicating backup images to a separate AWS account.
The solution uses native AWS services and is designed to provide:
- Automated EC2 AMI creation
- No planned instance reboot during backup creation
- Rolling backup retention
- Cross-account backup replication
- Isolated disaster recovery storage
- Automated cleanup and retention management
- Operational notifications
- Support for AWS accounts that are not part of the same AWS Organization
1. Architecture Overview
The solution consists of two logical environments:
Primary AWS Account
The primary account hosts the production EC2 workloads and creates local backups using AWS Data Lifecycle Manager (DLM).
Secondary DR Account
The secondary account is isolated from the production environment and stores independently owned copies of the backup AMIs.
The overall workflow is:
┌──────────────────────────┐
│ EC2 Instances │
│ Primary Account │
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ AWS Data Lifecycle │
│ Manager (DLM) │
│ │
│ Automated AMI Creation │
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ Amazon EventBridge │
│ Scheduled Orchestration │
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ AWS Lambda │
│ Replication Orchestrator │
└────────────┬─────────────┘
│
AWS STS AssumeRole
│
▼
┌────────────────────────────────────────────┐
│ Secondary DR Account │
│ │
│ Cross-Account IAM Role │
│ │ │
│ ▼ │
│ EC2 CopyImage │
│ │ │
│ ▼ │
│ Independent DR AMIs │
│ │
│ │ │
│ ▼ │
│ Cleanup Lambda │
└────────────────────────────────────────────┘
The architecture combines:
- AWS Data Lifecycle Manager for local EC2 AMI lifecycle management
- Amazon EventBridge for scheduled automation
- AWS Lambda for cross-account orchestration
- AWS STS for temporary cross-account access
- Amazon EC2 APIs for AMI and snapshot operations
- IAM for controlled access between accounts
2. Why Use a Separate DR Account?
A separate DR account provides an additional security boundary around backup data.
If production resources and backups exist entirely within the same AWS account, an account-level security incident could potentially affect both.
By maintaining backup copies in a separate account, organizations can reduce this dependency.
The DR account can be designed with:
- Restricted administrative access
- Separate IAM roles
- Strong authentication requirements
- Limited network access
- Dedicated monitoring
- Independent backup retention
- Additional security controls
This approach is particularly useful when backup isolation is an important part of the organization's ransomware and business continuity strategy.
3. Local EC2 Backup with AWS Data Lifecycle Manager
AWS Data Lifecycle Manager provides native automation for creating and retaining EBS-backed AMIs.
Instead of manually creating AMIs, backup policies can be associated with EC2 instances through tags.
Example Tagging Strategy
A standardized tagging model makes backup policies easier to manage.
Example:
BackupSchedule = daily DrSync = weekly DrRetention = 4
The exact tag names and values can be customized according to organizational requirements.
BackupSchedule
Defines the local backup frequency.
Examples:
daily weekly monthly
DrSync
Determines whether the backup participates in disaster recovery replication.
DrRetention
Defines how many replicated copies should be retained in the DR environment.
This tag-based approach allows backup policies to be applied consistently without maintaining a large list of individual EC2 instances.
4. DLM Lifecycle Policy
DLM policies can be configured to create EBS-backed AMIs automatically.
A typical policy includes:
- AMI creation schedule
- Retention count
- Target EC2 tags
- AMI tagging
- No-reboot configuration
- Automated deletion of expired backups
For workloads where reboot-free backup creation is required, the policy can use:
{
"NoReboot": true
}
This allows the AMI creation process to be configured without intentionally rebooting the source instance.
The retention configuration ensures that old AMIs are automatically removed after the defined number of backups has been reached.
5. Cross-Account Backup Architecture
The cross-account portion of the architecture uses AWS IAM and STS.
The primary account does not require permanent credentials for the DR account.
Instead, Lambda assumes a role in the destination account when replication is required.
The process is:
Primary Account
│
│ Lambda Execution Role
│
▼
AWS STS AssumeRole
│
│ Temporary Credentials
▼
Secondary DR Account
│
▼
Cross-Account Backup Operations
This provides temporary and controlled access rather than storing long-lived credentials.
6. IAM Trust Relationship
The DR account contains a dedicated cross-account IAM role.
Conceptually, the trust relationship allows the replication Lambda from the primary account to assume the role.
A secure trust relationship should:
- Restrict the trusted principal
- Use an external identifier where appropriate
- Follow least-privilege principles
- Avoid broad account-level trust
- Limit the role to the required AWS services and actions
An external identifier can provide additional protection against confused-deputy scenarios.
The permissions granted to the role should be limited to the operations required for backup replication.
Typical permissions may include:
ec2:CopyImage ec2:DescribeImages ec2:CreateTags ec2:DescribeSnapshots ec2:DeleteSnapshot ec2:DeregisterImage
The exact permissions should be reviewed against the implementation and reduced wherever possible.
7. AMI and EBS Snapshot Permissions
An EC2 AMI consists of more than the AMI metadata itself.
The underlying EBS snapshots also form an important part of the backup.
Therefore, cross-account replication must account for both:
- AMI sharing permissions
- Underlying EBS snapshot permissions
The general replication workflow is:
Source AMI
│
├── AMI permissions
│
└── EBS Snapshot permissions
│
▼
Destination Account
│
▼
CopyImage
│
▼
Independent DR AMI
The replication process should verify that all required storage permissions are available before starting the copy operation.
8. Regional Backup Strategy
For environments operating across multiple AWS Regions, the architecture can maintain a regional mapping between the production environment and the DR environment.
For example:
Primary Region A → DR Region A Primary Region B → DR Region B Primary Region C → DR Region C
Maintaining a consistent regional mapping simplifies:
- Recovery procedures
- Automation
- IAM policies
- Cost management
- Operational troubleshooting
Where the backup is copied within the same AWS Region but to another account, organizations can also avoid introducing unnecessary cross-region data transfer into the replication workflow.
9. Replication Workflow
The replication Lambda acts as the central orchestration component.
A simplified workflow looks like this:
1. EventBridge triggers Lambda
│
▼
2. Identify eligible AMIs
│
▼
3. Validate backup state
│
▼
4. Assume role in DR account
│
▼
5. Grant required AMI/Snapshot access
│
▼
6. Copy AMI into DR account
│
▼
7. Wait for destination AMI
to become available
│
▼
8. Apply standardized tags
│
▼
9. Remove temporary sharing
│
▼
10. Record replication status
The workflow should also be designed to be idempotent.
If the same automation executes more than once, it should recognize an already replicated backup and avoid creating unnecessary duplicate copies.
10. Human-Readable Backup Naming
AWS-generated AMI names can be difficult to interpret when a large number of backups exist.
A replication Lambda can create a standardized naming convention using metadata from the source EC2 instance.
For example:
<InstanceName>-<BackupIdentifier>-dr-<Schedule>
Example:
production-database-backup-dr-weekly application-server-backup-dr-weekly cache-server-backup-dr-monthly
A consistent naming strategy makes it easier for operations teams to:
- Identify the source workload
- Determine the backup schedule
- Search for specific recovery points
- Understand the purpose of an AMI
- Automate cleanup
Tags should also be used because they provide a more reliable mechanism for automation than names alone.
11. Automated Source Cleanup
After the destination account successfully creates an independent copy, temporary sharing permissions can be removed from the source AMI and its underlying snapshots.
This reduces unnecessary exposure of production backup artifacts.
The process can be summarized as:
Source AMI
│
│ Temporary Sharing
▼
DR Account
│
│ CopyImage
▼
Independent DR AMI
│
▼
Remove Temporary Sharing
The destination account then owns its independent copy.
This keeps the source environment cleaner and reduces the amount of time that cross-account access remains active.
12. Backup Retention
Retention should be managed independently in both environments.
Primary Account
DLM manages the lifecycle of source AMIs.
For example:
Create backup
↓
Keep latest N copies
↓
Remove older AMIs
↓
Delete associated snapshots
DR Account
A dedicated cleanup Lambda can manage replicated AMIs.
The Lambda can:
- Discover replicated AMIs
- Group them by source workload
- Sort them by creation time
- Determine the configured retention limit
- Delete expired AMIs
- Remove associated snapshots where appropriate
This prevents unlimited accumulation of backup storage.
13. Idempotency
Idempotency is an important requirement for backup automation.
A replication job should not create another copy if the corresponding backup has already been successfully replicated.
A source AMI identifier can be stored as metadata on the destination AMI.
For example:
SourceAmiId = ami-xxxxxxxx SourceInstance = application-server BackupSchedule = weekly
Before starting a new copy operation, the Lambda can check whether a destination AMI already exists for that source backup.
If it does, the job can mark the backup as:
Already Replicated
and continue processing the remaining backups.
This protects against duplicate copies and unnecessary storage costs.
14. Event-Driven Scheduling
Amazon EventBridge can be used to trigger the replication workflow on a defined schedule.
The important consideration is that backup creation and replication should not necessarily happen at exactly the same time.
DLM backup creation is asynchronous.
Therefore, the replication process should be scheduled with an appropriate buffer after the expected backup creation window.
A generic workflow is:
Backup Window
│
▼
DLM Creates AMI
│
│ Buffer
▼
EventBridge
│
▼
Replication Lambda
The buffer should be sized according to:
- Number of instances
- EBS volume size
- Backup frequency
- Regional workload
- Expected AMI creation duration
This approach reduces the possibility of attempting to replicate an AMI before it has completed.
15. Monitoring and Notifications
Backup automation should provide operational visibility.
Instead of requiring engineers to continuously check the AWS Console, the Lambda can publish execution summaries to an organization's preferred communication platform.
Notifications can include:
Job Started
EC2 DR Backup Status: Started Schedule: Weekly
Job Completed
EC2 DR Backup Summary Successfully Replicated: 8 Already Replicated: 2 Failures: 0
Failure Notification
EC2 DR Backup Alert Status: Failed Component: AMI Replication Action Required: Review replication logs
Notifications can be integrated with platforms such as:
- Slack
- Microsoft Teams
- Zoho Cliq
- Incident management systems
CloudWatch Logs and metrics should also be used to maintain a detailed audit trail.
16. Security Considerations
A disaster recovery architecture should be treated as a security-sensitive system.
Recommended controls include:
Least-Privilege IAM
Only grant the permissions required for backup creation, replication, and cleanup.
Dedicated DR Role
Use a dedicated cross-account IAM role instead of sharing permanent credentials.
External ID
Use an external identifier in cross-account role assumptions where appropriate.
Restricted Administrative Access
Limit access to the DR account to authorized personnel.
MFA
Require strong authentication for privileged users.
Backup Isolation
Keep the DR account operationally separate from the production environment.
Encryption
Where required by organizational security and compliance policies, enable encryption for backup storage and use appropriate KMS key policies.
Audit Logging
Enable CloudTrail and appropriate logging for:
- IAM role assumptions
- AMI operations
- Snapshot operations
- Backup deletion
- Cross-account activity
17. Cost Optimization
The architecture can also be optimized for cost.
Key strategies include:
Retention Policies
Keep only the number of recovery points required by the organization's RPO/RTO requirements.
Automated Cleanup
Automatically remove expired AMIs and unused snapshots.
Regional Strategy
Avoid unnecessary cross-region replication when regional recovery requirements do not require it.
Tag-Based Policies
Use tags to apply different retention periods to different workloads.
For example:
Production → Longer Retention Staging → Shorter Retention Development → Minimal Retention
DR Storage Optimization
Review the number and age of retained AMIs regularly to ensure backup storage remains aligned with business requirements.
18. Operational Schedule
A typical implementation can follow a schedule such as:
FrequencyComponentActivityDailyDLMCreate daily EC2 AMIsWeeklyDLMCreate weekly recovery pointsWeeklyEventBridge + LambdaReplicate eligible AMIs to DRMonthlyDLMCreate monthly recovery pointsMonthlyEventBridge + LambdaReplicate monthly backupsScheduledDR Cleanup LambdaRemove expired DR backups
The exact schedule should be determined by the organization's:
- Recovery Point Objective (RPO)
- Recovery Time Objective (RTO)
- Application criticality
- Storage budget
- Compliance requirements
19. Disaster Recovery Process
During an actual recovery event, the destination AMI can be used to launch replacement EC2 infrastructure.
A simplified recovery process is:
Identify Required Recovery Point
│
▼
Select DR AMI
│
▼
Verify AMI & Snapshot State
│
▼
Launch EC2 Instance
│
▼
Attach Required Configuration
│
▼
Validate Application
│
▼
Restore Production Traffic
The exact recovery process should be documented and tested before a real disaster occurs.
Backups are only useful if they can be successfully restored.
20. Testing and Validation
A DR solution should be tested regularly.
Recommended tests include:
Backup Validation
Verify that expected AMIs are being created.
Replication Validation
Confirm that AMIs are successfully copied to the DR account.
Permission Validation
Verify cross-account IAM access and temporary permissions.
Cleanup Validation
Confirm that expired backups are removed according to retention rules.
Restore Testing
Launch EC2 instances from replicated AMIs and verify application functionality.
Failure Testing
Simulate scenarios such as:
- Replication failure
- Missing permissions
- Incomplete backups
- Lambda execution failure
- Destination account access failure
These tests help identify weaknesses before an actual disaster occurs.
21. Key Benefits
This architecture provides several operational and security benefits.
Automated
Backup creation, replication, cleanup, and notification can be fully automated.
Low Operational Overhead
The architecture relies primarily on managed AWS services and serverless components.
Cross-Account Isolation
Backup copies are stored under a separate AWS account, creating an additional security boundary.
No Planned Instance Reboot
DLM can be configured for AMI creation without intentionally rebooting the source instance.
Scalable
Tag-based policies allow the architecture to support a growing number of EC2 workloads.
Cost-Aware
Retention policies and automated cleanup prevent unnecessary accumulation of backup storage.
Observable
Notifications, CloudWatch Logs, and audit trails provide visibility into backup operations.
Recoverable
Independent AMI copies provide recovery points that can be used to recreate EC2 workloads during a disaster.
Conclusion
A strong EC2 disaster recovery strategy should not depend entirely on backups remaining inside the same AWS account as production workloads.
By combining AWS Data Lifecycle Manager, Amazon EventBridge, AWS Lambda, AWS STS, IAM, and Amazon EC2, organizations can build an automated cross-account backup pipeline using native AWS capabilities.
The architecture provides a structured approach to:
- Create automated EC2 recovery points
- Maintain local rolling backups
- Replicate backups to an isolated AWS account
- Manage cross-account permissions securely
- Maintain independent DR copies
- Automate retention and cleanup
- Monitor backup operations
- Support repeatable disaster recovery procedures
Most importantly, the architecture should be treated as more than a backup mechanism. It should be part of a broader business continuity and disaster recovery strategy, with clearly defined RPO/RTO targets, security controls, monitoring, and regular restore testing.
A backup that has never been tested is only a theoretical recovery mechanism. Regular recovery exercises are what turn the architecture into a dependable disaster recovery capability.