When preparing for the AWS Certified CloudOps Engineer (SOA-C03) exam, data protection isn't just about taking backups—it’s about proving you can restore them seamlessly under pressure in your Disaster Recovery (DR) environment.
A classic exam scenario and real-world hurdle is automating disaster recovery validation for a multi-tier app: ensuring your stateless app servers and your primary database cluster spin back up in their exact, distinct subnets across multiple Availability Zones (AZs) while retaining their strict security group configurations.
Instead of navigating the AWS Management Console or writing custom Lambda scripts to test your recovery points, the most minimalist, infrastructure-as-code approach is leveraging the AWS CLI to configure native AWS Backup Restore Testing Plans.
Here is the operational architecture we are building:
Below is the 3-step operational blueprint to deploy and dry-run this entire application recovery stack strictly from your terminal.
1. Create the Restore Testing Plan via CLI
A Restore Testing Plan automates the evaluation of your backup recovery points. We use the create-restore-testing-plan CLI command to establish an automated cron schedule (e.g., running weekly) to validate our recovery stack without manual intervention.
Run the following command to define your testing window, cron pattern, and specify exactly which types of recovery points should be targeted from your vaults:
aws backup create-restore-testing-plan \
--region us-west-2 \
--restore-testing-plan '{
"RestoreTestingPlanName": "MultiTierApp-Restore-Testing-Plan",
"ScheduleExpression": "cron(0 12 ? * SAT *)",
"StartWindowHours": 4,
"Suffix": "dr-test",
"RecoveryPointSelection": {
"Algorithm": "LATEST_WITHIN_WINDOW",
"IncludeVaults": ["*"],
"RecoveryPointTypes": ["SNAPSHOT"],
"SelectionWindowDays": 7
}
}'
2. Configure Granular Network Overrides per AZ (4 Selections)
Because your architecture involves a Multi-AZ environment—where each of the 3 EC2 instances must be pinned to its own specific Availability Zone (AZ) and subnet, and the Aurora Cluster requires its own Multi-AZ subnet group targeting all 3 AZs to accommodate its 6 distributed storage volumes—a single, flat metadata block will break the deployment.
We must create four separate selections under the plan to apply unique RestoreMetadataOverrides for each distinct component.
⚠️ The Importance of the IamRoleArn
When defining these granular resource selections, explicitly providing a valid service role via the "IamRoleArn" parameter is absolutely critical. AWS Backup cannot use your personal IAM CLI session credentials to execute automated dry-runs in the background. It requires an authoritative, trusted service role that grants the platform explicit, cross-service permissions to interact with EC2, RDS, and your custom network topology to spin up instances and override metadata profiles safely on your behalf.
Execute these 4 commands to bind your target cloud resources and service roles to the testing plan:
Selection A: App Server 1 (AZ1 Mapping)
aws backup create-restore-testing-selection \
--region us-west-2 \
--restore-testing-plan-name "MultiTierApp-Restore-Testing-Plan" \
--restore-testing-selection '{
"SelectionName": "EC2-App-Tier-AZ1-Mapping",
"ProtectedResourceType": "EC2",
"IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
"ProtectedResourceArns": ["arn:aws:ec2:us-west-2:123456789012:instance/i-01111111111111111"],
"RestoreMetadataOverrides": {
"SubnetId": "subnet-dr-app-az1",
"SecurityGroupIds": "[\"sg-dr-app-server\"]",
"InstanceType": "t3.medium"
}
}'
Selection B: App Server 2 (AZ2 Mapping)
aws backup create-restore-testing-selection \
--region us-west-2 \
--restore-testing-plan-name "MultiTierApp-Restore-Testing-Plan" \
--restore-testing-selection '{
"SelectionName": "EC2-App-Tier-AZ2-Mapping",
"ProtectedResourceType": "EC2",
"IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
"ProtectedResourceArns": ["arn:aws:ec2:us-west-2:123456789012:instance/i-02222222222222222"],
"RestoreMetadataOverrides": {
"SubnetId": "subnet-dr-app-az2",
"SecurityGroupIds": "[\"sg-dr-app-server\"]",
"InstanceType": "t3.medium"
}
}'
Selection C: App Server 3 (AZ3 Mapping)
aws backup create-restore-testing-selection \
--region us-west-2 \
--restore-testing-plan-name "MultiTierApp-Restore-Testing-Plan" \
--restore-testing-selection '{
"SelectionName": "EC2-App-Tier-AZ3-Mapping",
"ProtectedResourceType": "EC2",
"IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
"ProtectedResourceArns": ["arn:aws:ec2:us-west-2:123456789012:instance/i-03333333333333333"],
"RestoreMetadataOverrides": {
"SubnetId": "subnet-dr-app-az3",
"SecurityGroupIds": "[\"sg-dr-app-server\"]",
"InstanceType": "t3.medium"
}
}'
Selection D: Aurora Cluster (Multi-AZ DB Subnet Group Mapping)
aws backup create-restore-testing-selection \
--region us-west-2 \
--restore-testing-plan-name "MultiTierApp-Restore-Testing-Plan" \
--restore-testing-selection '{
"SelectionName": "RDS-Aurora-Cluster-Mapping",
"ProtectedResourceType": "RDS",
"IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
"ProtectedResourceArns": ["arn:aws:rds:us-west-2:123456789012:cluster:aurora-app-cluster"],
"RestoreMetadataOverrides": {
"DBSubnetGroupName": "subnet-group-dr-aurora",
"VpcSecurityGroupIds": "[\"sg-dr-aurora-cluster\"]"
}
}'
3. Automated Validation & Cleanup
AWS Backup dynamically orchestrates the restore. It automatically instantiates your 3 app instances and the Aurora Cluster into their isolated production-mirror environments, enforces security configurations, and then tears down the temporary infrastructure after a specified retention window (e.g., 1 hour) so you don't incur trailing cloud costs.
📖 This troubleshooting workflow is a minimalist excerpt from the new print edition of the AWS Certified CloudOps Engineer (SOA-C03) Study Guide, available on Amazon:
👉 https://a.co/d/0gyCgRjc
Top comments (0)