Apples to Oranges
As a proud AWS partner it pains me somewhat to have to compete with one of their services. However, this article is less a competitive analysis and more so an attempt to clarify the rather different uses cases our two products address.
Our product Thunder for EC2 automates the provisioning of duplicate EC2 instances across regions, the ongoing replication of volume snapshots, and the regular testing of backup instances for a robust, verifiable disaster recovery protection of your mission-critical workload. Implemented as a Lambda function using 100% cloud-native support infrastructure, our product is the easiest and most cost-effective solution on the market.
AWS Elastic Disaster Recovery supports replicating data from physical, on-premises services to cloud backups. It does so by placing an agent on each host and performing differential filesystem copies to EC2 proxy servers in the cloud.
The confusion arises with the fact that AWS Elastic Disaster Recovery also supports purely cloud workload across regions, however it uses the same agent-based/proxy replication infrastructure as the physical-to-virtual support. This makes it much more cumbersome and expensive than our model, which simply uses AWS API calls through a periodic Lambda function to achieve the same result. It is somewhat akin to an apples to oranges comparison.
But this is not where I would start any competitive analysis. My loyal readers hopefully can predict where I would start any list of criteria for a disaster recovery solution, and if you are not a regular reader hopefully you would feel the same way: testing.
Disaster recovery failover absolutely must work perfectly the first and possibly only time you use it; it is perhaps the only software discipline yoked with that requirement. If you test your DR solution once per year, the resulting quality is the same as if you tested your code once per year.
Thunder for EC2 automates deep testing of application failover by providing test scripts implemented as Lambda functions, that securely connect to your backup application through Security Groups enabled on an instance’s private network. The test is performed at every replication job, and failures are notified through AWS SNS, meaning you are aware of any problems in your environment the moment, rather than learning about it too late on a failover.
AWS Elastic Disaster Recovery testing is completely manual; while detailed steps are documented to perform a fire drill they leave it up to you to regularly ssh into your backup instances and somehow confirm the application is up-to-date. Any site reliability engineer will tell you that manual DR processes are frequently deprioritized over day-to-day workload.
In addition, our product does not use any host-based agents or proxy servers but instead uses documented AWS APIs to replicate EBS snapshots across regions and attach them the backup instances. This means we support any OS, any instance, any application between any two regions because the data replication occurs at the storage level.
AWS Elastic Disaster Recovery like many host-based software solutions, has a lengthy compatibility list for what versions of Windows or Linux are supported, what patches are necessary, what regions are supported. In the odd chance that your workload matches their compatibility matrix, your guarantee that future workload still fits the matrix is at risk.
While AWS does not charge a license fee for their product, the cost is borne by the requirement to set up the replication servers in your EC2 account. At one replication server per instance, the AWS Calculator estimates a 10-instance environment at
Roughly $2500 per year.
Thunder for EC2 as a Lambda function is essentially free, and our license fee is far less than the $2500 you would pay to AWS, and is constant regardless of workload. Who wants to spend so much money on DR?
Finally, by using the same physical-to-cloud architecture for cloud-to-cloud DR, AWS perhaps makes their product more complicated in an pure-cloud environment than it should be. Compare the fact that you can run through our hands-on demo in roughly 15 minutes, and their introductory video is 90 minutes long.
For physical-to-virtual disaster recovery AWS Elastic Disaster Recovery is certainly a solution that should be investigated. But for purely cloud workloads, using that same product increases cost and complexity, narrows application support, and does not benefit from automated testing, I’m not so sure that it is the appropriate solution.
Thunder for EC2 is the lowest cost solution, is quickly and easily configured, supports all EC2 workload anywhere, and tests, tests, and tests some more your DR solution, automatically. The choice is clear to me, and as a happy AWS user like me you might be muse that AWS who wants the best for their users, might possibly find strength in our arguments.
Try it out yourself in your own environment, or if you want to try it in our environment at no cost or risk to you please reach out to me and I can give you login details.
Originally published at https://www.linkedin.com.
