I have worked with AWS Elastic Disaster Recovery for the past year. My feedback is that when we compare it, it's a good thing to have a centralized backup. When your stack is on AWS, it is very helpful, but I think when you have multi-cloud, that's where it may not be a great product.

Also, from the cost side, it is good. The best use case for this would be if you're in AWS and you want to try things quickly without the actual disaster recovery cost that you usually have to incur.

However, the challenge is the EBS snapshot. At the end of the day, they have snapshots, and they do have EBS snapshots which they capture. We ended up not using it, but we explored it for our own disaster recovery solutions that we were evaluating.

I appreciate the automated orchestration of recovery processes in this solution. That's a good thing, especially once you are able to configure something with this tool. I haven't tested the automated recovery, but they do support it. It is beneficial, especially integration with Route 53 and automatically using Route 53 to switch to a different region directly.

Because it has native integrations with all the Route 53 features, that's a good aspect. The part I really appreciated about it was they're not just AWS Backup; along with that, they give you an option to quickly do the drills. If you want to conduct DR drills, it's very useful.

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.

I have experience working with AWS Elastic Disaster Recovery for about six or seven months.

Being an enterprise customer, I find the technical support from AWS very supportive.

Regarding the security features, including encryption provided by AWS Elastic Disaster Recovery, security is dependent on the user's needs. Encryption is something you need to enable based on your data and where you're storing it. I don't remember if they have an option where, by default, whatever backup you have is secured, since what you're storing is still in your own S3 or something. I think they charge you based on the amount of data. It's a shared responsibility model, but I believe they do offer a feature where you can enable encryption at rest and encryption in transit for your data, but it's our responsibility as customers; I don't think AWS does it for you.

For AWS Elastic Disaster Recovery, regarding the deployment model, we mostly tried the backup restore option. We typically haven't explored the other deployment options they offer yet. We start with a very simple backup restore and chose it for specific use cases, MongoDB backup, but as of right now, we haven't looked at it more holistically. Overall, we felt that it doesn't support all the types of backup that we have.

On a scale of one to ten, I would rate AWS Elastic Disaster Recovery an eight.

I use the solution to deploy a Docker image application. It is hosted on GitHub, and the servers we run on are not ECR.

What I like about ECR AWS is that it is a fully managed service, so I don't need to manage the underlying infrastructure or worry about scalability in AWS concerning building, maintenance, security, and high availability. 

It offers seamless integration with services like ACL, EKS, and Fargate for deploying containerized applications. It works great with AWS, and it is flexible to use a public repository for open-source projects or a private repository for secure storage.

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.

I have used it for about seven months now.

Since the time I have been using ECL, my application on AWS has not broken down. I have not had any issues with it for now. It is working well. It is very good and very reliable.

I never had to contact the support team.

I didn't really use Azure. However, that was in my last organization before I joined this new one. 

I would rate AWS nine out of ten.

Our human resources solution is used by higher management competency. This is critical to the organization since it is used by higher management. ITM is really essential for the organization.

For the past year, I have been using AWS, as there was previously no native replication service available. Initially, they offered services like CloudEndure, which was a third-party service. This caused problems with integrations with existing servers. However, with AWS Elastic Disaster Recovery Service being a native service, integration is seamless. Moreover, since it is a managed service, I reduce my time to manage infrastructure and applications, which adds another benefit.

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.

I have been using it since 2019.

AWS is not difficult, but the cost associated with replicating data to another region can be significant. This is due to services like the duplication server, which continuously runs in AWS. I have more than 200 hosts, including email solutions and others, which contribute to the high cost. Cost is a concern. Otherwise, the service is reliable.

Customer service is quite helpful. I have AWS enterprise-level support, which is very beneficial. In case of any issue, they are ready to provide support within the defined SLA timeline.

Positive

Earlier, I worked with IBM Sonavi. I stopped using it since we moved from on-premise to cloud. It's not in use right now.

There were no issues during the initial setup.

The implementation is actually managed by our partner. I have taken a rate per user storage. The licensing part is completely managed by the partner.

For the past year, I have been using AWS, as there was previously no native replication service available. Initially, they offered services like CloudEndure, which was a third-party service. This caused problems with integrations with existing servers. However, with AWS Elastic Disaster Recovery Service being a native service, integration is seamless, highlighting the return on investment.

The setup is actually managed by our partner. I have taken a rate of per user. Licensing is completely managed by the partner. I am paying per user and per GB storage cost, while the infrastructure cost is separate.

Although no financial benefit from using it has been observed, I recommend the solution. The overall product rating is eight out of ten.

If there is a data leak, incident, or compliance issue, auditors may want to verify whether there is a policy and plan in place for utilizing AWS Elastic Disaster Recovery. 

As part of a strategic approach, I have been part of a team ensuring compliance with various regulations, including HIPAA compliance. I have contributed to developing strategies to satisfy audits and inspections from various government bodies. These strategies outline the plans and features to be utilized if needed.

AWS, as a cloud platform, helps build trust in its services. There have been incidents where clients using Amazon services faced security breaches, but these stories seem more frequent with Microsoft. This might be a personal bias, and others may have different experiences. AWS proactively protects its reputation by addressing issues and investing heavily in its tools, app tech, and engineers.

Pricing could be improved.

The solution is stable because we haven't had any incidents.

It's scalable because of the value and investment it has made in terms of capacity.

Every business survives because of its reputation. In case of any disaster, AWS cannot guarantee 100% security, but it helps protect the company's reputation. It also assists in providing remedies to solve any particular problems that may arise. AWS is a platform that supports businesses.

It has pay-as-you-go pricing. The cost will be different if you are not utilizing it as often as possible because there are costs beforehand and after an incident.

If you are using AWS for your disaster recovery, it's important to use AWS Elastic Disaster Recovery to ensure continuity in case of any failures. Having a strategic approach means considering the cost of disaster recovery as part of your overall planning. 

Overall, I rate the solution an eight out of ten.

The primary use case for AWS Elastic Disaster Recovery is to ensure data replication and protection across diverse environments without the need for hypervisor integration. 

The product's most valuable features include its ease of deployment, cost-effectiveness due to AWS's pay-as-you-go pricing model, and continuous data protection.

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.

I have been using AWS Elastic Disaster Recovery for several years.

The product is stable. 

The platform offers excellent scalability, allowing it to accommodate the needs of both small-scale environments and large enterprises without significant changes to the setup.

The technical support has been effective, providing necessary assistance and resolving issues promptly.

Positive

We previously used solutions like Double-Take and Carbon. We switched to AWS Elastic Disaster Recovery because of its versatility in deployment across different environments without requiring specific hardware or hypervisor dependencies.

The initial setup can vary in complexity depending on the specific environment and setup requirements. While the deployment process is generally straightforward, detailed planning and configuration are essential to ensure a successful implementation.

The implementation was handled by our in-house team.

The ROI has been substantial, primarily due to its cost-effective pricing model. It reduces downtime and data loss during disaster recovery scenarios.

We evaluated several other options, including traditional on-premises disaster recovery solutions and cloud-based offerings.

AWS Elastic Disaster Recovery is a robust and reliable solution for disaster recovery needs. However, thorough planning and regular monitoring are crucial to maximizing its benefits and ensuring seamless operation.

I rate it a nine. 

We are using AWS Elastic Disaster Recovery for backup purposes in our company.

AWS Elastic Disaster Recovery is convenient because it is cloud-based technology.

The strong points are the stability and scalability of the solution, as well as the convenience of it being cloud-based.

The cost of AWS Elastic Disaster Recovery is seen as expensive.

We have been using AWS Elastic Disaster Recovery for five or six years.

I rate the stability of AWS Elastic Disaster Recovery as nine out of ten.

I rate the scalability of AWS Elastic Disaster Recovery as nine out of ten.

The customer service and technical support for AWS are very good and helpful. I rate it ten out of ten.

Positive

We did not work with any other products before AWS.

We use a third-party consultant company to help with integration.

The pricing of AWS is considered expensive compared to other options.

We have also used Microsoft Azure as an alternate solution.

I would recommend AWS Elastic Disaster Recovery to other users.

We were using CloudEndure Disaster Recovery as a backup for websites when we had a double ISP outage.

CloudEndure Disaster Recovery is a fairly stable solution.

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.

I have been using CloudEndure Disaster Recovery for three years.

I rate the solution an eight out of ten for stability.

I rate the solution a five or six out of ten for scalability.

The solution's initial setup was fairly complex, and the company that did the initial setup for us messed up a couple of times.

On a scale from one to ten, where one is difficult and ten is easy, I rate the solution's initial setup a one or two out of ten.

The solution was deployed by three people from my team and two engineers from the company.

On a scale from one to ten, where one is cheap and ten is expensive, I rate the solution's pricing an eight out of ten.

The solution's replication was fine. We faced issues when we actually tried to utilize it. Every time we made a big change to any of the on-premise servers that were being replicated, we'd always have to change our replication engines, sizing, and the disc it's written on. Otherwise, it would end up taking around 30 days for a small monthly Windows update to replicate.

I would not recommend CloudEndure Disaster Recovery to other users because of all the issues we had with the wrong sizing and the fact that there are better solutions in the market.

Overall, I rate the solution a two out of ten.