There are two very different ways of providing data backup services in the cloud, and which method your vendor uses can drastically affect your service and maintenance costs. Any vendor that says differently is simply doing nothing but obfuscation. Let’s take a look.
Lift-and-shift vs cloud-native backup approaches
The two methods of creating a service in the cloud are called lift-and-shift and cloud native. Lift-and-shift is quick and easy to implement, but much more expensive in the long run. A cloud-native approach requires a lot of upfront development, but drastically reduces everyone’s cost in the end.
The most common way to run backups in the cloud is to take a traditional on-premises backup solution and perform what the industry calls a “lift-and-shift operation.” Your on-premises physical servers or VMs become AWS/Azure/GCP VMs and your on-premises storage array becomes one or more block storage volumes in the cloud (e.g., AWS EBS). Little to no attempts are made to make this configuration more “cloud friendly” — you simply exchange VMs and storage you own for VMs and storage you rent.
The challenge with this method is that you are renting the most expensive infrastructure the cloud has to offer (VMs and block storage), and you’re paying for it 24×7 — even though you’re only using it for a few hours per day. This is true whether you lift-and-shift backup software into your cloud account or into the vendor’s account. The infrastructure costs will vastly outweigh any perceived benefits of the solution. This is why lift-and-shift is universally panned as a long-term cloud implementation method. This is especially true for backups, due to the many hours per day that your rented infrastructure will go unused.
The better way to do this is to design your backup software to realize it is running in the cloud, and to leverage how the cloud works. Avoid as much as possible using services like VMs and high-end block storage due to their cost. For example, the least expensive version of AWS EBS is twice the cost of the most expensive version of AWS S3. Use serverless computing (e.g., AWS Lambda functions) and containers whenever possible. If a process must run longer than the 15 minutes a Lambda function will allow, either write it to accommodate that or use a VM or container – but automatically spawn it only when you need it. There is no reason to be running VMs while they are not performing a function. Amazon even has a service that will automatically spawn as many VMs as your service needs, and spin them down when you no longer need them.
If you need a database service – but only need it a few minutes or hours a day – do not run a VM running SQL Server, MySQL, or some custom database! Use a database service like RDS or DynamoDB. Pay only for the database while you are using it, and pay for how much you’re using it – rather than paying to run a VM all day simply to run a database.
Designing your backup software to understand the architecture and cost aspects of the cloud will save you enormous amounts of money over the years. This is true whether the service is running in your cloud account or your vendor’s account. If they lower their costs (referred to in the industry as the cost of goods sold, or COGS), they can pass those savings onto you in their service offerings. (One vendor claimed that our cloud-native architecture only helped us lower our costs as if that had no bearing on what we would charge our customer. Incidentally, that vendor’s total service cost to their customer is at least twice what ours is.)
Don’t forget other data backup costs
When looking at different ways of running backup systems in the cloud, remember to differentiate between complete data backup services (managed by the backup vendor) and software that will run in your AWS account (managed by you). The cost difference between these methods can be significant.
Data protection as-a-service (DPaaS) vendors like Druva run the backup system in its cloud account and charge you for how much of their service you consume. Different vendors and different products do this in different ways. Some price per user, others per terabyte of stored data, and others charge per VM. Some that charge by terabyte charge by the backend terabyte (i.e. how much backup storage you use, others charge by frontend terabyte (i.e. how big the servers are you’re backing up, and still others combine these and charge for both front and backend pricing! Make sure to be aware of all costs a particular service might charge before comparing it to a similar service. The difference in TCO between these different pricing methods can be 2X or more!
If you’re looking at a product that will run in your cloud account, you will have a harder time determining your costs up front. This is because your eventual cost will be based on how many of the cloud vendor’s services you end up using. It may include VM and storage charges, GETs and PUTs from/to object storage, as well as egress charges if you perform any restores.
Some vendors allow you to “bring your own storage,” or use your cloud storage account with their data backup service. Since backups stored there are useless without the backup system, it’s important to realize that this is simply a freedom of billing. It doesn’t grant you any freedom from the backup vendor in question. But what it does do is make your storage costs more variable. Instead of a predictable price of $X/mth for your entire environment, you’ll have two bills. One that is $X/mth (from the backup vendor) and another that will vary each month based on how many backups and restores you do.
Cost of management between lift-and-shift vs cloud-native solutions
Whether it’s offered as-a-service or is sold to you via subscription, how a vendor implements its software in the cloud also impacts your management costs. It may appear to be less expensive to buy a particular company’s product and lift-and-shift it into your cloud account — versus using an all-inclusive service that runs its product in the vendors’ cloud account. However, you must take into account the other costs you will incur.
In addition to the cost of VMs and block storage, you are also responsible for maintaining and upgrading these systems. You will have to protect them and monitor them for cyber attacks and ransomware, immediately patching them when vulnerabilities are addressed. If and when a patch for such things impacts the performance of your VMs, you will be responsible for figuring out how to address that performance difference.
You will also be responsible for maintaining the block volumes associated with your backup server. Your two choices are to vastly over-provision your block storage so you don’t have to worry about that too much, or to monitor and grow the storage over time. The first method means you’re always paying for a lot of storage you’re not using, and the latter method means you’re wasting a lot of time maintaining your storage. All of this cost should be taken into consideration.
Final thoughts on lift-and-shift vs cloud-native approaches
When I was interviewing at Druva in 2017, I remember talking to one of our senior sales engineers and asking him why Druva would be successful at offering data backup and recovery-as-a-service, versus so many other companies that had tried and failed. In addition to having a service that simply runs without anyone having to maintain it, he said that we had “figured out the COGs,” meaning that we had lowered our cost of goods sold (COGS) enough to be able to sell the service at a competitive price and still make a profit. We have over 10 years of experience doing just that, and the maturity of our offering and its cost show it. Feel free to put us to the test.
Discover the benefits of the cloud without the burden of maintaining infrastructure.