We are often asked why our product focuses on disaster recovery across regions and does not also manage traditional local backup. Three words: AWS Lifecycle Manager.

For small and medium businesses with modest cloud infrastructure and requirements, straightforward hourly and daily snapshots should suffice to protect mission-critical instances against corruption or accidental deletion, much like you might backup a Mac laptop with Time Machine.

This is precisely what Lifecycle Manager does, so it would be pointless to compete against a native AWS service. …


Serverless computing customarily means that you do not provision a dedicated cloud virtual server to run your software but instead the cloud periodically provisions one temporarily to run your code.

However there is another important definition of serverless: no web server.

Your typical SaaS Marketplace infrastructure solution for backup, security, disaster recovery, etc. will no doubt be configured through an umpteenth user interface, typically communicating with a back-end web server to execute commands.

This web server can often be a huge security headache. Exposing it to the appropriate users through correct firewall configuration; upgrading stale operating systems and constantly patching…


The transition to serverless for our backup product forced us to jettison much of our custom SaaS infrastructure in favor of native AWS services. The snapshot scheduler (cron) became CloudWatch Events; log4j was removed in favor of CloudWatch Logs; heck, we even discarded our entire JavaScript UI in favor of CloudFormation and CloudFront.

This rethinking opened the opportunity to trim the fat even further on our product. Removing any functionality not deemed absolutely essential would result in an even more robust and low-cost solution than the original SaaS offering.

For example the “big red button” to failover EC2 instances between…


You want to run a cloud-based CRM system for multiple users worldwide in AWS cloud, you would plainly deploy an EC2 instance from an AMI in AWS Marketplace. Though you are billed 24/7 for the running instance, it is also probably busy 24/7.

Conversely you want to forward SNS messages to Slack, you would deploy an AWS Lambda function from the Serverless App Repository. It only runs on demand when messages are published, and you are only billed for each brief instantiation of the function.

Horses for courses.

What about backup and disaster recovery infrastructure solutions?

The fact that all…


In my last article I described how our new serverless-based disaster recovery automation solution for AWS can be summarized with a few videos each lasting just a few seconds.

Now if you have just a few minutes (and a few pennies) you can try it out yourself in your own AWS account. Our hands-on tutorial walks you through the simple steps to create a sample failover environment and then deploy, configure, and use our new solution. …


Is disaster recovery protection for your mission-critical EC2 workload on your to do list, but finding time and budget is difficult?

In my previous article I described how our DR automation product Thunder for EC2 Serverless can provide robust protection for a roughly 1% premium on even a modest monthly cloud spend. In this article I’ll demonstrate how the time investment is equally as small.

Here’s our user guide, roughly the length of this article:

(Compare that to the big guys, just their description on how to register and pay for their product is longer than our entire guide).


How much should you pay to protect your mission-critical cloud workload against catastrophic failure? Given that the chance is almost zero that an AWS region fails, you should probably pay almost zero.

While there are many solutions providing disaster recovery automation for AWS, only one, our upcoming release of Thunder for EC2 Serverless, comes as close to zero as possible, while providing all of the features and extensibility you need to feel confident you have reliably protected your cloud workload against the unthinkable.

Disaster recovery protection is sometimes compared to insurance — you buy it hoping you don’t need it…


Our articles in the past month detailed the transition of our product from an always-on SaaS model hosted in an EC2 instance to a serverless deployment that only uses CPU cycles when necessary. As a result the total cost of ownership is driven to the lowest possible level. For disaster recovery backup solutions like ours — where the risk is low but non-zero — the investment should also be low. Serverless and backup is the perfect marriage.

The previous articles were also heavily laden with details, so in this article it is worth pausing to summarize the journey to serverless…


A robust backup and recovery plan must be easily testable. Testable in a way that closely simulates a true failure situation and without requiring interrupting production workload. It should also not require significant cost in both resources and time. For example in a previous article I outlined my discomfort with multi-availability zone AWS RDS — spanning a database within a region across AZ’s — not because of the underlying software, but because there is no way to verify that it works short of the absurd premise of shutting down the production AZ.

In this series of articles explaining our transition…


Transitioning our disaster recovery solution’s logic to a serverless paradigm occupied the bulk of the content in a previous article. This article features the effect on the supporting infrastructure — namely, how to preserve our product’s simple graphical user interface?

It is impossible to run a web server on AWS Lambda given that a function only runs periodically. How do we preserve our simple and intuitive interface that allows users to click their way through configuring automated disaster recovery protection for the cloud?

Because our UI is used mainly for initial provisioning of duplicate instances in a remote region, we…

Thunder Technologies

Thunder Technologies provides robust, cost-effective disaster recovery automation for the public cloud

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store