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.
