AWS Elastic Disaster Recovery Reviews

I have been using AWS Elastic Disaster Recovery to replicate our production servers between regions. Our initial setup was straightforward, involving installing the replication agent and configuring the staging resources. The main advantage is that it took very few minutes to get started.

We are implementing this service to mainly replicate our critical servers to another AWS region for disaster recovery. Over this period, we have used it for continuous replication and a few DR drills, and it has been reliable and fairly easy to manage. In a real-time scenario where a data center in Iran was demolished due to war, we currently have AWS Elastic Disaster Recovery in two regions: Hyderabad and Mumbai. With this setup, we are able to replicate our infrastructure accordingly.

During a region migration project, we are using continuous block-level replication, which keeps the RPO very low. Even if anything happens, the data loss is minimal. We regularly run DR drills using the Test Launch feature, which helps us validate the recovery process without affecting the production servers. Fast recovery time is particularly important for us. During our testing process, the recovery instance launches within a few minutes based on our server size, whether it is small, large, or medium. We also used AWS Elastic Disaster Recovery during our region migration activity to replicate the servers from one region to another, which made the migration process much smoother and easier. Our AWS console provides us clear visibility into what is happening, whether it is success or failure. It gives us clear visibility of the replication status, recovery points, and lag time, making it easy for us to monitor whether everything is healthy or not.

The best features that AWS Elastic Disaster Recovery offers is continuous block-level replication with a very low RPO. It keeps replicating the changes from the source servers to the DR region almost in real-time. Even if any failure happens, we can recover the servers with minimal data loss, which is one of the best features. The other thing which I really value is the Test Launch feature; we can perform DR drills anytime without affecting the production environment. Overall, the best combination of AWS Elastic Disaster Recovery is its near real-time replication and quick recovery testing, and this makes the service very useful in real-world scenarios.

AWS Elastic Disaster Recovery has impacted my organization positively by significantly reducing our recovery time, which is our RTO, and also the data loss risk. Because the servers are continuously replicating to the DR region with minimal downtime, in case of any major issue in the primary environment, we can launch the recovery instance within minutes. Another positive impact was during the DR drills and audits. Since AWS Elastic Disaster Recovery allows non-disruptive test launches, we were able to demonstrate our DR capabilities more confidently to the internal teams and management. Overall, it gave the organization more confidence in handling any outages and also improved the overall resilience of our infrastructure.

Some features that I personally feel can be improved are more simplified monitoring and reporting. As I previously mentioned, the console shows the replication status. If it had more detailed dashboards or built-in reports for DR readiness, it would make it easier for the teams to track everything in one place. Another improvement would be cost visibility and optimization guidance in optimizing the cost and also giving us visibility of it. Because the staging resources and replication storage are running continuously, it would be very helpful for organizations and users if AWS provided clearer cost insights, recommendations, and remediations to optimize the DR environment. It would also be useful if AWS added more automation options for application-level recovery, such as easier ways to handle IP changes, domain name system (DNS) updates, or application dependencies during failover.

Additionally, we can simplify the setup and configuration process. For someone new to the service, understanding the staging settings, launch templates, and networking configurations can take some time. Setup simplicity and more detailed monitoring and alerting features would be beneficial. If we could add that, we can easily track the replication health, lag, and potential issues. Instead of relying on other additional tools for monitoring and alerting features, we can rely on AWS Elastic Disaster Recovery itself.

I have been using AWS Elastic Disaster Recovery for approximately 1.5 years.

AWS Elastic Disaster Recovery is actually stable.

The customer support has been very interactive. If we are struggling in any part, it has been generally good because they respond within a reasonable time and have been helping us in troubleshooting each and every step if we face any issues. The quality of the support is good overall.

Positive

Previously, I have not used any disaster recovery solution, but I have heard about manual solutions. I know the manual process of how they were used in the organization previously, but I have not used it, such as the traditional backup methods.

Before this, my organization was relying on the traditional backup-based recovery method, such as using snapshots and manual server restoration. I have heard about this and gotten opinions on the aspects of these methods.

When I started working with AWS Elastic Disaster Recovery, one of the major issues I faced during my learning phase was understanding the initial setup and replication process. Installing the replication agent was straightforward, but configuring the staging area, the IAM roles needed for it, and the launch settings actually took time. Another challenge was during my initial replication; for servers with large volumes, the first sync actually took quite a long time. We had to plan it properly to avoid the network impact since it took a long time. We also faced a small issue during the first test launch where the recovery instance came up, but some application configuration and private IP settings needed adjustment before the application worked properly.

My ROI in this case has been quite good in my organization. Instead of maintaining a full secondary DR infrastructure with a running EC2 instance, we only pay for the replication storage and staging resources, which keeps the overall cost lower. Because of AWS Elastic Disaster Recovery, most of the process is automated. During DR testing or failover, we can launch the recovery instance in just a few clicks. The recovery process requires fewer people and much less time, which has saved my organization engineering effort and operational time.

My experience with the pricing, setup cost, and licensing is that it has been a reasonable cost. Compared to maintaining a full standby disaster recovery environment, it is actually reasonable. In my case, since the cloud is basically a pay-as-you-go model, we only pay for the replication storage, data transfer, and small staging instances. We don't need to keep the EC2 instance running all the time in the DR region, which helps us reduce our overall DR cost. In my perspective, it is more cost-effective.

We have not purchased AWS Elastic Disaster Recovery in the AWS Marketplace; we are using the in-built AWS Elastic Disaster Recovery.

I would give advice to be strong in the initial setup. Because for anyone new to AWS Elastic Disaster Recovery, the initial setup may take time. They need to plan their DR architecture properly. I would also recommend testing the DR setup regularly using the Test Launch feature so that the team can be very familiar with the recovery process. I have shared my thought process on AWS Elastic Disaster Recovery, and I have given my overall thought process and views on this service. I would rate this solution an 8 out of 10.

Our main use case for AWS Elastic Disaster Recovery is to ensure business continuity by replicating critical workloads on AWS. It allows us to continuously replicate on-premises cloud servers and quickly recover them in AWS in case of system failures or any outages. This helps minimize downtime and data loss while providing a reliable disaster recovery solution.

In addition to disaster recovery, AWS Elastic Disaster Recovery plays an important role in our overall architecture and operational resilience strategy. It allows us to continuously replicate critical workloads to AWS and perform regular recovery testing without disrupting production systems. This helps us ensure that our recovery procedures are reliable and that we can quickly restore services during unexpected failures, infrastructure outages, and cyber incidents. Overall, it provides a scalable and cost-effective way to maintain business continuity.

In our setup, we used AWS Elastic Disaster Recovery to replicate a critical web application server and its database from our on-premises environment to Amazon AWS. During a planned maintenance window, we simulated a failure scenario where the primary server became unavailable. Using AWS Elastic Disaster Recovery, we quickly launched the replicated server in AWS, which restored the application within minutes. This ensured users could still access the service without significant downtime and prevented any data loss because the replication was continuous.

AWS Elastic Disaster Recovery offers many best features including continuous data replication, fast failover and recovery, non-disruptive testing and disaster recovery drills, automated failover and orchestration, cost-efficient staging environment, and integration with AWS ecosystem.

The automated failover and orchestration features of AWS Elastic Disaster Recovery have made our recovery process much more efficient. Instead of manually rebuilding servers or configuring environments during a failure, the platform allows us to quickly launch recovery instances with predefined settings. This automation reduces the chance of human error and significantly shortens our recovery time. It has also made disaster recovery testing easier because we can simulate failure scenarios and verify that our system can be restored quickly without disrupting production workloads.

The features of AWS Elastic Disaster Recovery reduce manual work, lower human error, enable faster recovery, and allow for better disaster recovery testing.

AWS Elastic Disaster Recovery has positively impacted our organization by improving our overall resilience and reducing downtime risk. With continuous data replication and fast system recovery, it reduces downtime risk and simplifies disaster recovery operations through automation and easy testing. The key positive impacts include reduced downtime, improved business continuity, and simplified recovery operations.

AWS Elastic Disaster Recovery could be improved by simplifying the management interface, enhancing monitoring and reporting features, and providing clear documentation and setup guidance for new users.

AWS Elastic Disaster Recovery provides reliable continuous replication, fast recovery times, and strong integration with AWS. The platform significantly simplifies disaster recovery planning and testing. However, the user interface and monitoring features could be improved to make the overall experience better.

I have been using AWS Elastic Disaster Recovery for approximately one year, and over the past few months, we have been working on cloud infrastructure and disaster recovery setups.

AWS Elastic Disaster Recovery is generally considered stable and reliable for enterprise disaster recovery environments because it provides reliable continuous replication and automated failover.

AWS Elastic Disaster Recovery is scalable because it can protect and replicate multiple servers and workloads, and it runs on AWS infrastructure. We can easily scale recovery environments as our workload grows.

Customer support is the same as with AWS since we actually use this in our AWS account. AWS provides support through the AWS support plan, which includes basic plan, developer plan, business plan, and enterprise plan, with higher tiers offering faster response time and more direct technical help.

We previously used traditional backup and snapshot-based recovery methods through AWS, but we switched to AWS Elastic Disaster Recovery because it offers continuous replication, faster recovery, and more automated disaster recovery processes.

Pricing is pay-as-you-go and generally cost-effective since most costs come from replication, storage, and staging resources. Setup costs were minimal because it integrates directly with AWS. The licensing model is simple and usage-based.

Although I cannot give a specific example, we have seen a return on investment mainly through reduced infrastructure costs and faster recovery times. Instead of maintaining a full secondary disaster recovery site, we rely on AWS replication, and recovery testing that used to take hours now takes approximately 15 to 20 minutes.

With AWS Elastic Disaster Recovery, we were able to reduce recovery time from several hours to around 10 to 15 minutes during testing. Continuous replication minimizes data loss and the cost-efficient staging environment helps reduce infrastructure expenses compared to maintaining a full secondary disaster recovery site.

We chose AWS Elastic Disaster Recovery because we previously were using the snapshot process. We evaluated solutions including site recovery and Veeam backup and replication. We selected AWS Elastic Disaster Recovery because of its native AWS integration, continuous replication, and simpler disaster recovery management. The main factor is that our application is hosted on AWS, so AWS Elastic Disaster Recovery suited us best.

My advice would be to clearly define your RTO and RPO goals (recovery time objective and recovery point objective) before implementing AWS Elastic Disaster Recovery and to regularly test your recovery process. Proper planning of networking, security, and recovery scenarios will help ensure a smooth disaster recovery strategy. AWS Elastic Disaster Recovery helps with disaster recovery in a better way than any other solutions. I would rate this product an 8 out of 10.

AWS Elastic Disaster Recovery is a fully managed service that enables fast, reliable recovery of on-premises or cloud-based applications to AWS. We use it for minimizing downtime and data loss. There have been multiple situations where our production servers hosted on AWS went down, and we were able to shift to different servers, thereby minimizing the downtime with no data loss.

This service is very handy in terms of using affordable storage, minimal compute resources, and point-in-time recovery to ensure business continuity during outages or disasters.

Continuous block-level replication stands out for me the most. AWS Elastic Disaster Recovery continuously replicates block-level data from the source environment to a staging area in AWS, ensuring that data is always up to date and minimizing data loss during a disaster. Other valuable features include automated failover and recovery as well as non-disruptive testing.

AWS Elastic Disaster Recovery supports a wide range of source environments, including VMware, Hyper-V, physical servers, and other cloud providers, making it versatile for different IT infrastructures. The flexible recovery options allow recovery of applications to their original environment or to a new instance in AWS while retaining the existing metadata and security parameters. The cost-effective staging area design reduces costs by utilizing affordable storage and minimal compute resources, making it economical for ongoing replication.

It has greatly impacted our company's specific outcomes and improved production failures. For customers, it has been quite beneficial in terms of providing automated failover and recovery options as well as flexible recovery options, which allows recovery of applications to the original environment or to a new instance in AWS while retaining the existing metadata and security parameters, which is quite useful. Encryption and security is also one of the best features. Data is encrypted during transit and at rest, ensuring information remains secure throughout the disaster recovery process.

There has definitely been a lot of improvements in recovery time with very less downtime because we already understand how to recover using the clear process that AWS Elastic Disaster Recovery provides. There has been approximately a thirty percent improvement in terms of recovery time.

AWS Elastic Disaster Recovery can be improved through regular drills to ensure that all resources are properly prepared for disasters with scheduled drills. This includes testing and understanding failback, which is crucial for a comprehensive disaster recovery plan.

Monitoring and health checks are important to continuously monitor the health of the ongoing replication using the AWS Elastic Disaster Recovery console or programmatically. This helps identify any servers that may require attention and ensures that the application is functioning correctly. Creating a CloudFormation template that can create the necessary network resources on demand is useful for disaster recovery.

There should be documentation and best practices guidance so that teams can follow best practices for implementation and maintenance of disaster recovery from on-premises using AWS. This includes a written recovery plan as well as regularly updating it with findings and required changes.

Within the scope of improvements, there are many possibilities, but it is currently providing some great results. The scope of improvements can include monitoring and health checks as well as documentation with best practices for documentations, and conducting regular drills.

I have been using AWS Elastic Disaster Recovery for around two years.

AWS Elastic Disaster Recovery has been quite stable.

The scalability is quite good and we were able to scale this service to many of the services that our company uses. It has been quite fast with reliable recovery of on-premises as well as our private cloud.

Customer support has been quite good and has definitely solved many issues we have faced.

Positive

Previously, we were using Azure Elastic Disaster Recovery, but now we are using AWS Elastic Disaster Recovery, which is doing a great job.

In terms of time saved, it has greatly improved because of production failures, and that time is definitely saved because of the great documentation and plans that everyone understands. There are also fewer employees needed now because of the good structured planning for AWS Elastic Disaster Recovery, so fewer site reliability engineers are required.

The pricing has been fine, and regarding the setup cost as well, it is quite fine. There is definitely a scope of improvement, and for year-end licensing, they should definitely improve the cost.

We evaluated other alternatives, but they were not providing good cost options. Commvault Cloud, Rubrik, and OpenText Recover were evaluated, but the number of features in AWS Elastic Disaster Recovery is quite huge and they cannot match that.

The features that really make AWS Elastic Disaster Recovery a ten out of ten include continuous block-level replication, automated failover and recovery, non-disruptive testing, support for various environments, flexible recovery options, integration with AWS services, cost-effective staging area, encryption and security, customizable launch settings, and post-launch actions.

There are a lot of features that should make AWS Elastic Disaster Recovery appealing to potential users because of the huge market capture by AWS and the fact that most companies are using AWS, so that option should be considered.

We have been a customer only. I give this product a rating of ten out of ten. AWS Elastic Disaster Recovery has been doing quite a good job overall.

My main use case for AWS Elastic Disaster Recovery is for any databases or applications when they go down on a cross-region. For instance, when an application is spinning up into multiple regions, we lost one, and AWS Elastic Disaster Recovery helped us recover. In that situation, when there was an event that happened in the cloud stack, AWS Elastic Disaster Recovery helped us get things back up and running. Although this happened only once, we would like to have this multi-region, multi-data center level recovery for disaster recovery, so we are incorporating this technology.

AWS Elastic Disaster Recovery has positively impacted my organization. We have a priority one application that was recently deployed, and it was important for us to recover the data when the cloud stack went down. Since deploying AWS Elastic Disaster Recovery, we have mostly seen an improvement in uptime, which contributes to reducing downtime.

The best features AWS Elastic Disaster Recovery offers are the insights and alerting, which inform developers or application developers about what's going on and how the system is running.

The insights and alerting features help my team day-to-day by allowing SREs to know when an event has happened and how we are supposed to be doing recovery. They provide alerts to the SREs and groups that are subscribed, and they are alerted early. I am currently exploring the features, but for now, I find it very useful in the event of the disaster that happened.

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.

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

AWS Elastic Disaster Recovery is stable. It is definitely a stable application.

The scalability of AWS Elastic Disaster Recovery is good. We can expand it to multiple data centers or different areas such as EMEA and APAC.

I would rate the customer support an eight, as it often takes a lot of time to engage and get a solution. About eighty percent of the time, I think it will be resolved quickly.

Positive

Previously, we were using a homegrown application that tracks these systems before switching to AWS Elastic Disaster Recovery.

We did purchase AWS Elastic Disaster Recovery through the AWS Marketplace, but it's mostly the procurement team that has handled that. The management, particularly the procurement team, looks at pricing and setup costs, so I know a little about pricing, but I'm not directly involved in it.

We are just customers and consume a lot of AWS services, and do not have another business relationship with this vendor.

We have seen a return on investment by needing fewer employees for maintenance and related matters. We no longer have to schedule employees on weekends since the system automatically triggers alerts, allowing engineers to respond as needed.

We did not evaluate other options before choosing AWS Elastic Disaster Recovery.

My advice for others looking into using AWS Elastic Disaster Recovery is to definitely consider it if you are scaling your applications significantly, especially if your applications are spanned across different regions. I would give this product an eight out of ten because it's a fair score. The education of our technology and operations or SRE teams is needed since most people don't know, only a few do. I suggest that improvement in customer service for disaster recovery and the alerting system would be great.

My main use case for AWS Elastic Disaster Recovery is continuous replication.

A specific example of how I use continuous replication with AWS Elastic Disaster Recovery is that we use it for low-cost EBS volumes and smaller replication servers to keep our data synchronized in near real-time.

For us, it results in approximately 50 to 80% cost reduction.

The best features AWS Elastic Disaster Recovery offers, in my opinion, are its RTO and cost-effective replication.

When I say cost-effective for replication, it makes a difference for my team and my operations compared to warm standby or active-active configuration. The RTO is excellent.

AWS Elastic Disaster Recovery has positively impacted my organization by securing and stabilizing our platform. It has improved RPO in seconds and RTO in minutes.

I would like to add a point of improvement about the features, specifically concerning native cyber resilience and air gapping.

AWS Elastic Disaster Recovery can be improved regarding ransomware and insider threats.

Because the replication is continuous and block-level, if a production server is hit by ransomware, the encrypted garbage data is often replicated to the DR site in near-real time. This is an area that needs improvement.

I have been using AWS Elastic Disaster Recovery for almost five years.

AWS Elastic Disaster Recovery is absolutely stable.

The scalability of AWS Elastic Disaster Recovery is 10 out of 10.

The customer support is amazing, and it is the best customer support I have ever had.

I rate the customer support of AWS Elastic Disaster Recovery 10 out of 10.

I did not previously use a different solution.

I purchased AWS Elastic Disaster Recovery through the AWS Marketplace.

I have seen a return on investment, specifically in terms of time saved in case of disaster recovery.

My experience with pricing, setup cost, and licensing is that pricing is fair, and you pay for the use.

Before choosing AWS Elastic Disaster Recovery, I did not evaluate other options because of the pre-existing relationship with AWS.

My advice to others looking into using AWS Elastic Disaster Recovery is that you only pay for the full-scale compute and high-performance storage after you initiate a drill or an actual failover.

I rate this review a 10 out of 10.

Our main use case for AWS Elastic Disaster Recovery was to ensure that if our primary on-premises data center failed, we could quickly launch EC2 instances in AWS to resume production.

The main use case was ensuring business continuity with low RPO and RTO. We use AWS Elastic Disaster Recovery to perform continuous replication of on-premises servers. RPO, which stands for Recovery Point Objective, is the maximum acceptable data loss. If RPO is low, we have minimal data loss, no major business transaction loss, and better consumer trust. If replication happens every few seconds, we do not lose hours of data during a failover. The other benefit is how low RTO improves our operations. If the RTO is low, then we have faster system recovery and reduced loss. If systems are restored in minutes instead of hours, business operations continue smoothly. Low RPO ensures minimal data loss during a disaster and low RTO ensures faster system recovery. Together, they reduce business downtime, protect revenue, and maintain customer trust for our business.

We use AWS Elastic Disaster Recovery because it provides low RPO, RTO, supports failover testing, and eliminates the need for a secondary data center. It is cost-effective and suitable for business continuity planning.

AWS Elastic Disaster Recovery uses continuous block-level replication. Its lightweight agent is installed on a source server, so data replicates to a low-cost staging area in AWS. During a disaster, we launch EC2 instances from replicated data. The low RPO at a seconds-level replication and a fast recovery with a low RTO provide the most cost-effective way, paying mostly for storage until failover.

The best feature that AWS Elastic Disaster Recovery offers is the full server-level replication and near-real-time disaster recovery. The benefits are fast recovery, low RPO, and it is cost-effective.

The fast recovery and low RPO of AWS Elastic Disaster Recovery have made a significant difference for my team and organization by ensuring minimal data loss and quick restoration of services.

Using AWS Elastic Disaster Recovery services, our organization noticed a very positive impact. The first positive impact is that it significantly improved our disaster recovery posture. We minimized data loss, which increased system reliability. It also reduced the need for maintaining a separate DR data center, which lowered infrastructure costs.

After implementing AWS Elastic Disaster Recovery, we significantly improved our disaster recovery metrics. Our RPO improved from approximately three to four hours to less than one minute. While the service is very effective, it could improve in areas such as more granular cost visibility during staging and test launches. Additionally, enhanced automation for large-scale failover orchestration across multiple regions would be beneficial.

I have been using AWS Elastic Disaster Recovery for three years for continuous server replication to AWS.

I used AWS Elastic Disaster Recovery in my previous organization, which is called Andor Communication Private Limited.

We have measured the results of implementing AWS Elastic Disaster Recovery. We improved our RPO from around four hours to less than one minute and our RTO from six to eight hours to under thirty minutes. Maintaining a secondary DR center was costing approximately eight thousand to ten thousand dollars per month, which is around eight to ten lakh per month in Indian rupees.

I will suggest to IT professionals who want to use AWS Elastic Disaster Recovery that if you have clearly defined RPO and RTO objectives before implementing it, proper network bandwidth planning is very important to ensure smooth continuous replication. You should also regularly test failover and failback scenarios. Instead of treating DR as a one-time setup, conducting quarterly DR drills helps validate recovery objectives. My advice would be to clearly define RPO and RTO, plan network bandwidth properly, test failover regularly, and monitor staging costs closely. DR should be continuously tested, not just configured once.

AWS Elastic Disaster Recovery is a reliable and cost-effective solution for business continuity. It simplifies disaster recovery by eliminating the need for maintaining a secondary data center while still providing low RPO. With proper planning and monitoring, it provides excellent business continuity at a lower cost compared to traditional DR setups. I would rate this solution seven out of ten.

This was for the school.

It did help with costs and reduce downtime overall.

Some of the most valuable features of this product include its ability to manage disaster recovery effectively.

There are areas that could be improved beyond the downtime issues mentioned, and AWS Elastic Disaster Recovery could enhance several aspects of its functionality.

I have had experience with it for one year.

The initial setup was complex rather than straightforward. It became more complex in several ways.

AWS provided more scalability compared to CloudEndure.

I would rate the support with AWS for AWS Elastic Disaster Recovery at 4 out of 10.

When comparing AWS Elastic Disaster Recovery with the VMware product, there are several main differences between them.

The initial setup was complex rather than straightforward. It became more complex in several ways.

NetSync was the implementation team, and they performed very well.

The cost rating was assessed on a scale where 10 represented the most expensive.

The cost rating was assessed on a scale where 10 represented the most expensive.

There are a few alternate solutions being reviewed, including Pivotal Cloud Foundry and VeloCloud SD-WAN.

AWS actually bought out CloudEndure. I would rate this product 7 out of 10 overall.

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.

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.