Good presentation One thing was missed: When workloads are migrated to the DR site, that location becomes the new primary, correct? Since this is a warm standby strategy, we cannot operate at full capacity for an extended period, as fewer compute resources are allocated to the DR site. Our goal is to eventually return to the original primary location. To achieve this, we need to reverse the migration process back to the primary site. In essence, for every disaster recovery scenario, there would be two instances of downtime: the first for migrating to the DR site, and the second for transitioning back to the original primary site. Could you kindly confirm if my understanding is accurate?
Hi! Based on this document, you would scale your DR environment up after the event: go.aws/4h4fD5a. You can pose more questions about DR on our re:Post platform, where a large community engages on technical and non-technical topics: go.aws/aws-repost. ^NR
That is probably correct theoretically, since you do have some of the same challenges failing back --> data replication lag etc. The main difference, IMO, is that YOU control the fail back and as such can design it in a way that minimizes the disruption - from simple things like using seasonality to determine when to fail back, to making the fail back gradual, in combination with ramping up the compute in (what now is) the warm standby.
@Satish1012, your understanding is correct, and Dmitry is correct in saying although you will have another downtime when you fail back to primary, you have control over it, and you can plan it accordingly.
Good presentation
One thing was missed:
When workloads are migrated to the DR site, that location becomes the new primary, correct?
Since this is a warm standby strategy, we cannot operate at full capacity for an extended period, as fewer compute resources are allocated to the DR site. Our goal is to eventually return to the original primary location. To achieve this, we need to reverse the migration process back to the primary site.
In essence, for every disaster recovery scenario, there would be two instances of downtime: the first for migrating to the DR site, and the second for transitioning back to the original primary site.
Could you kindly confirm if my understanding is accurate?
Hi! Based on this document, you would scale your DR environment up after the event: go.aws/4h4fD5a. You can pose more questions about DR on our re:Post platform, where a large community engages on technical and non-technical topics: go.aws/aws-repost. ^NR
That is probably correct theoretically, since you do have some of the same challenges failing back --> data replication lag etc. The main difference, IMO, is that YOU control the fail back and as such can design it in a way that minimizes the disruption - from simple things like using seasonality to determine when to fail back, to making the fail back gradual, in combination with ramping up the compute in (what now is) the warm standby.
@Satish1012, your understanding is correct, and Dmitry is correct in saying although you will have another downtime when you fail back to primary, you have control over it, and you can plan it accordingly.