I think insights are an area for improvement. It would be beneficial to get some insights when a disaster happens, including identification and probable solutions to ensure effective recovery. That insight and solution suggestion area is the main thing I would want to see improved. We believe that customer support for AWS Elastic Disaster Recovery needs to be improved because although we do raise tickets, the response can take some time.
AWS Elastic Disaster Recovery performs well at this moment. However, some points can be mentioned for further improvement. It may benefit from optimizing replication settings, right-sizing different instances, and conducting frequent recovery drills. Improving performance and resilience also involves automatic recovery processes, leveraging multi-account strategies for isolation, and using tools such as AWS CDK for automated deployments. Monitoring logs with tools such as CloudWatch Log Insights and creating cross-region replications are additional strategies for enhancement. Small improvements pertain to right-sizing instances, enabling features, and choosing instance types for the recovery environment that match our source server requirements to avoid unnecessary costs while ensuring performance during recovery events. The rest functions well.
I don't think there is any bad feature in AWS Elastic Disaster Recovery as such. It's more of when you do disaster recovery, you think of it more holistically. You want flexibility in terms of options. I would say it did not provide enough flexibility for all our backup needs. It had one single way of just supporting the EBS backup, or you can say volume-level backup. But let's say you want to integrate with your current backup solution; that kind of flexibility is what I would say is missing. In terms of improvements for AWS Elastic Disaster Recovery, for any backup and disaster products, I would want it when companies are trying to evaluate these products, the biggest challenge is you want the most cost-optimal way because it's insurance. AWS is already highly available, and you can have your infrastructure just in multiple AZs, and your life will be fine, considering the low probability of an AZ going down because of AWS's scale. You do disaster recovery basically for insurance and compliance, so it's crucial to ensure that it's very cost-optimal. There are different models that balance cost and recovery time objectives, but I have not seen any innovation; these are very old practices. Additionally, while the storage side is key because you want your data to be there on both sides, the speed at which you can build your infrastructure also matters. It's mostly about data storage. For data storage, if you architect your storage properly, you can actually bring it up faster. For example, with a database cluster, if your database size doesn't exceed certain limits, it will significantly improve recovery time. However, these guidelines aren't offered by backup tools, as they sort of work against them. Still, to make backup cost-optimal, it is not just about the tool; it's also about how you architect your infrastructure.
In its current state, ECL integrates with CloudWatch for basic logging and monitoring, yet improvements could include more detailed logs for specific actions, like when I perform actions such as push or pull. This would detail user activity directly in the ACL console for easier debugging and auditing. Additionally, an improved AWS pricing model is needed. AWS charges for storage and data transfer, which can add up, especially with large images or frequent pulls. Improvement should focus on offering more storage or better volume discounts for long-term use. It would also be beneficial to allow free pulls within the AWS account and vision. Moreover, image scanning for vulnerabilities can sometimes be slow, especially for large images. Speeding up the scanning process or providing optimized scanning for critical workflows would be welcome advancements.
Since I have to view everything on the console, the previous application solutions like IBM and Sanavi showed the RPO and RTO status directly. In AWS Disaster Recovery Service, these details are not available, making it difficult to check my replication status. I have to calculate whether my data is replicated to the Adarabad region or not. These features, if available in AWS, would be beneficial.
Learn what your peers think about AWS Elastic Disaster Recovery. Get advice and tips from experienced pros sharing their opinions. Updated: December 2025.
The product could be improved by incorporating more AI-driven automation for deployment and additional security features. These enhancements would make the solution even more user-friendly and secure.
Systems Administrator at a educational organization with 5,001-10,000 employees
Real User
Top 10
Feb 23, 2024
The solution never reduced our system's downtime. It would take us about a day to get the network configured properly for even doing a network failover test. The solution's orchestration capabilities did not simplify our disaster recovery process. The solution's network setup and a lot of the control tower setup could be improved. The solution should provide more ease of use for the creation of cloud appliances for firewalls.
AWS Solution Engineer at a tech services company with 51-200 employees
Real User
Apr 11, 2023
When I tested a failover, it didn't work. I set up a test, deleted the source, and went to fail it back, and it didn't work. The solution doesn't need any new features. AWS is no longer using the solution anymore.
I would like to see better support for creating and working with archives. Right now, it is difficult and painful to do. When you are working with multiple terabytes, there are no good solutions.
Director, IT Operations & Information Systems at a media company with 501-1,000 employees
Real User
Jul 23, 2018
One item that they did fix was, and this was when we first started, they had only one type of license. Then they did come out with a Tier 2 type of license, which costs a little less money. It updated a little less frequently, which seems to fit our needs. That was definitely helpful. There are some servers where we do get failures with the CloudEndure client. I don't know necessarily if it's the CloudEndure issue, but it's something that my engineers fixed on our end. It's always something that's easily repairable, though. There is a constant update of the servers. It's a fairly simple product once the infrastructure's in place. We did hire a third-party to help us build the AWS infrastructure to work with CloudEndure, but once it was up and running, it pretty much runs on its own now.
CloudEndure Disaster Recovery enables real-time replication and rapid recovery to enhance organizational resilience. Key features include block-level data replication, ease of use, cost-effectiveness, and automated recovery orchestration. Users benefit from increased efficiency, improved workflows, and enhanced data management, significantly improving organizational performance and business continuity.
I think insights are an area for improvement. It would be beneficial to get some insights when a disaster happens, including identification and probable solutions to ensure effective recovery. That insight and solution suggestion area is the main thing I would want to see improved. We believe that customer support for AWS Elastic Disaster Recovery needs to be improved because although we do raise tickets, the response can take some time.
AWS Elastic Disaster Recovery performs well at this moment. However, some points can be mentioned for further improvement. It may benefit from optimizing replication settings, right-sizing different instances, and conducting frequent recovery drills. Improving performance and resilience also involves automatic recovery processes, leveraging multi-account strategies for isolation, and using tools such as AWS CDK for automated deployments. Monitoring logs with tools such as CloudWatch Log Insights and creating cross-region replications are additional strategies for enhancement. Small improvements pertain to right-sizing instances, enabling features, and choosing instance types for the recovery environment that match our source server requirements to avoid unnecessary costs while ensuring performance during recovery events. The rest functions well.
I don't think there is any bad feature in AWS Elastic Disaster Recovery as such. It's more of when you do disaster recovery, you think of it more holistically. You want flexibility in terms of options. I would say it did not provide enough flexibility for all our backup needs. It had one single way of just supporting the EBS backup, or you can say volume-level backup. But let's say you want to integrate with your current backup solution; that kind of flexibility is what I would say is missing. In terms of improvements for AWS Elastic Disaster Recovery, for any backup and disaster products, I would want it when companies are trying to evaluate these products, the biggest challenge is you want the most cost-optimal way because it's insurance. AWS is already highly available, and you can have your infrastructure just in multiple AZs, and your life will be fine, considering the low probability of an AZ going down because of AWS's scale. You do disaster recovery basically for insurance and compliance, so it's crucial to ensure that it's very cost-optimal. There are different models that balance cost and recovery time objectives, but I have not seen any innovation; these are very old practices. Additionally, while the storage side is key because you want your data to be there on both sides, the speed at which you can build your infrastructure also matters. It's mostly about data storage. For data storage, if you architect your storage properly, you can actually bring it up faster. For example, with a database cluster, if your database size doesn't exceed certain limits, it will significantly improve recovery time. However, these guidelines aren't offered by backup tools, as they sort of work against them. Still, to make backup cost-optimal, it is not just about the tool; it's also about how you architect your infrastructure.
In its current state, ECL integrates with CloudWatch for basic logging and monitoring, yet improvements could include more detailed logs for specific actions, like when I perform actions such as push or pull. This would detail user activity directly in the ACL console for easier debugging and auditing. Additionally, an improved AWS pricing model is needed. AWS charges for storage and data transfer, which can add up, especially with large images or frequent pulls. Improvement should focus on offering more storage or better volume discounts for long-term use. It would also be beneficial to allow free pulls within the AWS account and vision. Moreover, image scanning for vulnerabilities can sometimes be slow, especially for large images. Speeding up the scanning process or providing optimized scanning for critical workflows would be welcome advancements.
Since I have to view everything on the console, the previous application solutions like IBM and Sanavi showed the RPO and RTO status directly. In AWS Disaster Recovery Service, these details are not available, making it difficult to check my replication status. I have to calculate whether my data is replicated to the Adarabad region or not. These features, if available in AWS, would be beneficial.
Pricing could be improved.
The product could be improved by incorporating more AI-driven automation for deployment and additional security features. These enhancements would make the solution even more user-friendly and secure.
The cost of AWS Elastic Disaster Recovery is seen as expensive.
The solution never reduced our system's downtime. It would take us about a day to get the network configured properly for even doing a network failover test. The solution's orchestration capabilities did not simplify our disaster recovery process. The solution's network setup and a lot of the control tower setup could be improved. The solution should provide more ease of use for the creation of cloud appliances for firewalls.
When I tested a failover, it didn't work. I set up a test, deleted the source, and went to fail it back, and it didn't work. The solution doesn't need any new features. AWS is no longer using the solution anymore.
The failback could be improved. It should be more intuitive.
I have not seen any areas that need improvement at this time.
I would like to see better support for creating and working with archives. Right now, it is difficult and painful to do. When you are working with multiple terabytes, there are no good solutions.
The three things that could improvement are: * The user interface * Customer support * Recovery time for the current customer query
One item that they did fix was, and this was when we first started, they had only one type of license. Then they did come out with a Tier 2 type of license, which costs a little less money. It updated a little less frequently, which seems to fit our needs. That was definitely helpful. There are some servers where we do get failures with the CloudEndure client. I don't know necessarily if it's the CloudEndure issue, but it's something that my engineers fixed on our end. It's always something that's easily repairable, though. There is a constant update of the servers. It's a fairly simple product once the infrastructure's in place. We did hire a third-party to help us build the AWS infrastructure to work with CloudEndure, but once it was up and running, it pretty much runs on its own now.