- Newest
- Most votes
- Most comments
The following questions for customer interviews—essential for formulating a DR strategy—have been organized in alignment with the Reliability pillar of the Well-Architected Framework.
- Confirming Business Requirements and Priorities
- What is the maximum acceptable time to resume operations if the system goes down? (RTO: Recovery Time Objective)
- What is the maximum acceptable amount of data loss? (RPO: Recovery Point Objective)
- What is the estimated business loss per hour resulting from a system outage?
- Which systems or functions are the most business-critical?
- Are there any systems that can tolerate downtime ranging from a few hours to a few days?
- Are there any regulatory or compliance requirements regarding data retention or system availability?
- Understanding the Current State
- How are backups currently performed? (Frequency, retention period, storage location)
- Have there been any system failures or outages in the past? If so, what was the impact and how long did recovery take?
- DR Strategy Direction
- Is it necessary to prepare for a region-wide failure, or is handling a single Availability Zone (AZ) failure sufficient?
- Regarding the trade-off between cost and recovery speed, what is your expected budget range for the following approaches?
- Backup & Restore (Lowest cost; RTO: hours)
- Pilot Light (Minimal always-on infrastructure; RTO: tens of minutes)
- Warm Standby (Scaled-down always-on infrastructure; RTO: minutes)
- Multi-Site Active/Active (Highest cost; RTO: near-zero)
- Operations and Organization
- Who decides when to initiate DR procedures in the event of a failure? Is there a 24/7 support structure in place?
- What is the envisioned approval workflow for initiating DR?
- How frequently do you wish to conduct DR plan testing (e.g., Game Days)?
- Do you prefer to perform the DR failover process manually or via automation?
- Data and Security
- Does the data include personal or confidential information? Are equivalent security requirements needed for the DR site?
- Are there any restrictions regarding the geographic location where data is stored? (e.g., restrictions to specific regions)
Hello.
I believe that by initially asking customers about the information provided in AWS re:Post Agent's AI-generated responses, you can cover a significant portion of their disaster recovery requirements.
I think it's best to confirm the system configuration the client envisions before the project starts.
Based on that structure, I think it will be easier to proceed with the project if you consider which parts require disaster recovery measures and which do not.
By the way, if you're designing a disaster recovery (DR) on AWS, I recommend reading the Well-Architected Framework documentation.
https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html
https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html
One example from my past work experience is conducting an AWS disaster recovery (DR) lab with a client, which allowed both the client and myself to deepen our understanding of DR. https://disaster-recovery.workshop.aws/en/intro.html
Thank you for the valuable insights, @Riku,I will check the guide.
Hello Team,
Would you please help to suggest some practical suggestions to interact with customer and ask questions before starting this project?
When starting DR planning with a customer, structure your discovery like this: Business Requirements (start here): What are your RTO and RPO targets per workload? How did you arrive at those numbers? Formal BIA or technical estimate? What are the consequences of downtime? (fines, revenue loss, customer trust) How do you tier applications by criticality? Current State: What is your current DR strategy? (backup/restore, pilot light, warm standby, active-active) When did you last test a full restore or failover? Did business stakeholders participate in that test? Architecture: Is the workload statically stable (can survive an AZ loss without launching new infrastructure)? How is data replicated? What consistency model do you need? Any third-party or cross-region dependencies? Operational Readiness: Do you have documented failover runbooks? What observability detects issues before customers report them? Who decides to fail over, and have they practiced that decision? Key principle: Match the DR strategy to the business requirement. A 24-hour RTO may only need backup/restore. Near-zero RTO likely needs warm standby or active-active. AWS Resilience Hub can validate whether your architecture actually meets your stated targets. Reference: https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html
When planning and implementing a disaster recovery (DR) strategy for a customer, you should ask questions that help you understand their recovery requirements and constraints. Here are the key questions to align expectations:
Recovery Objectives:
- What is your maximum acceptable downtime (Recovery Time Objective - RTO)?
- What is your maximum acceptable data loss (Recovery Point Objective - RPO)?
- Are these objectives consistent across all workloads, or do different workloads have different requirements?
Business and Cost Considerations:
- What is your budget or cost limit for implementing the DR solution?
- What are the business impacts of downtime and data loss for each workload?
- Do you have a Business Continuity Plan (BCP) that defines these requirements?
Current Architecture:
- What are the critical components and resources of your workload?
- What data needs to be protected and replicated?
- Are you currently using multiple Availability Zones within your AWS Region?
- What dependencies exist between different components of your workload?
Recovery Region Preferences:
- Which AWS Region would you prefer as your recovery region?
- Do you have any compliance or data residency requirements that affect region selection?
Operational Capabilities:
- Do you prefer automated or manual failover procedures?
- What is your team's experience with DR testing and execution?
- How frequently can you test your DR procedures?
Understanding these factors will help you recommend the appropriate DR strategy—whether backup and restore, pilot light, warm standby, or multi-region active-active—that balances their RTO/RPO requirements with cost and complexity constraints.
Sources
REL13-BP02 Use defined recovery strategies to meet the recovery objectives - AWS Well-Architected Framework (2022-03-31)
REL13-BP02 Use defined recovery strategies to meet the recovery objectives - AWS Well-Architected Framework
REL13-BP02 Use defined recovery strategies to meet the recovery objectives - Reliability Pillar
Relevant content
asked 3 years ago
asked 2 years ago
asked a year ago

Thanks fir stating the answer