CloudEndure Disaster Recovery to AWS

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.

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.

Neutral

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.