Horses for Courses
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.
What about backup and disaster recovery infrastructure solutions?
The fact that all of them on AWS Marketplace are deployed as EC2 instances does not make it right. Backup solutions in fact spends most of their time doing … nothing.
Except for a brief initial configuration — what instances for which you want to take a snapshot both locally and remotely and at what interval — and then the brief API call to AWS cloud to perform the snapshot and replication, the software itself probably spends 99% of its time waiting. If deployed as an EC2 instance, you are paying 24/7 usage fees for something that is actually working, what, a few minutes a day.
Backup and DR belong in an AWS Lambda function, because you should only pay for CPU cycles that do something useful. Waiting around for the next snapshot cycle is not useful. Waiting around for corruption or disaster recovery is not useful. A sophisticated user interface that is used rarely by one administrator is not useful, and is a troublesome attack surface as well.
Add to the fact that many of these solutions host their software in relatively large (read: expensive) instances is an indication that such solutions may be reinventing many wheels. Why host a custom scheduler and logger when there is CloudWatch? Why host a web server when you can configure through CloudFormation’s UI and view information through CloudFront? Why build anything for which there is already an AWS service?
Our upcoming backup and DR solution Thunder for EC2 Serverless protects your mission-critical EC2 instances, like CRM, databases, etc. that must run in EC2. It is implemented though as an AWS Lambda function instead of an EC2 AMI precisely because with backup you should only be billed for CPU cycles that do useful work, and with backup useful work is only done infrequently.
Add to this 100% cloud-native infrastructure to complete the solution — CloudFormation for configuration, CloudWatch for scheduling and logging, CloudFront to view the logs, SNS for notification, and Secrets for securely storing passwords — our solution is the lightest-weight, easiest to use, most inexpensive to run and maintain backup and recovery solution.
If you are looking for a simple yet robust backup and DR solution for your mission critical AWS infrastructure and you don’t want to waste a lot of money paying for idle CPU cycles, contact us at email@example.com or check out our hands-on demo .