A couple of things where AWS Elastic Disaster Recovery could improve are the granular testing of OT workloads. It would be helpful to have fully isolated test recoveries for our OT data, such as SCADA or pole telemetry, without impacting replication, to help validate disaster recovery readiness more frequently. Additionally, advanced reporting and analytics would be beneficial. If the tool could provide more built-in dashboards to show replication lag trends, failover readiness, or system dependencies, it would save time and improve transparency for both field teams and regulatory reporting. In terms of integration, tighter integration with our asset management systems and GIS databases would streamline automated recovery of linked OT systems and data relationships, making failover more efficient. There should also be more fine-grained alerts for replication lag or orchestration failures, with customizable thresholds for different types of workloads to improve proactive incident response. My advice would be to start with a clear disaster recovery strategy. Identify which IT and OT systems are critical, calculate the recovery time objective, and which assets need replication first. Keep latency-sensitive or legacy OT systems on-premises while replicating core IT workloads to AWS for fast, reliable failover. It is essential to keep testing failovers regularly, as it builds confidence and uncovers gaps that help ensure smooth operation during real incidents. Actively monitor costs by paying attention to replication storage and compute usage since AWS Elastic Disaster Recovery is pay-as-you-go, which allows us to save thousands of dollars annually. Connecting disaster recovery events with field operations, SCADA systems, and asset management dashboards streamlines operational responses. The AWS team is great, and engaging with their support and architects, along with their documentation and best practices, is very helpful.
