Johnny Fitrakis, CISO, Vega Cloud, tells a cautionary tale of a seemingly cost-effective tool that became exceedingly expensive.
On the surface, making the build-vs-buy decision – which means choosing between building your own software tools in-house or purchasing solutions from a third-party provider – may seem like it boils down to straightforward math. Either the cost of building and maintaining tools is higher than the cost of purchasing them or it’s not.
But when your tools run in the cloud, the complexity of cloud cost management adds another critical variable to build-vs-buy planning – as I learned recently when the cloud bills generated by a certain monitoring tool my team had deployed surged more than 6,000% with no warning.
Here’s what happened, along with takeaways for businesses trying to decide whether to build or buy software that will run in the cloud.
Context: Container configuration monitoring in a public cloud
Let me begin by explaining what my company needed to do and why we chose to buy a tool instead of building our own.
We deploy containers on a major public cloud platform. To help monitor those containers effectively, we need to be able to detect and alert our team about unexpected network configuration changes, which could impact the performance of containers. The changes could also signal a security issue in some cases – such as if a new networking rule exposes a container to the Internet -but the container should only be accessible from a private network.
One way to identify these events would be to build our own monitoring tools. But because our cloud provider offers a configuration monitoring service that is stable, sophisticated and (initially, at least) cost-effective, we saw little reason to build our own solution. Instead, we “bought” the configuration monitoring tool offered by our cloud vendor.
How our cloud bill surged 6000%
For a while, this setup ran great and we gave it little thought. The monitoring service was costing our company literally pennies per month to track networking configuration changes and it was working effectively.
But then, our cloud cost monitoring tools alerted us to a major anomaly in pricing for the service. Instead of spending pennies per month, our cost shot up to more than $800 – an increase of more than 6000%
All of a sudden, a tool that had been very cost-effective to buy was turning out to be exceedingly expensive. Unless we got the cost under control, I worried we’d soon be forced to build our own configuration monitoring service using free or lower-cost software.
It turned out that the unexpected spike in our cloud bill stemmed from a change in the billing policy of our cloud provider. They changed what they billed against, leading to increased charges even though our service configuration hadn’t changed.
Fortunately, once we detected the billing increase and figured out why it occurred, we were able to update our configuration easily enough to cut our spending back to the original levels. We didn’t have to build our own version of the tool; we were able to keep buying it, with a new configuration in place.
Lessons for cloud buyers
For businesses choosing whether to build or buy software in the cloud, the most obvious takeaway from my experience is that cloud billing practices are subject to change – which is why it’s critical to monitor your cloud bills on an ongoing basis. If we hadn’t had continuous cloud cost monitoring in place capable of alerting us to sudden spending anomalies, our chances of catching the cost increase would have been much lower.
To go even further – and to ensure that tools that are more cost-effective to buy remain cost-effective to operate over the long term – organizations should also establish budget thresholds. This ensures that you’ll receive an alert when your cost for a service surpasses the threshold you set.
Thresholds are important because they protect you against situations where your cost rises slowly over time – and therefore might not appear as an anomaly on any one cloud bill. Setting a threshold ensures that you’ll never pay more than a certain amount without realizing it.
Conclusion: A long-term approach to the right build-vs-buy decision
The bottom line: Determining whether it’s more cost-effective to build or buy a cloud-based tool requires more than just evaluating the upfront costs. You must also ensure that you monitor ongoing cloud costs so that you’ll know if a tool that was originally cost-effective to buy (or build, as the case may be) becomes more expensive due to changes in cloud provider billing practices. Otherwise, a build-vs-buy decision that seems like a safe bet originally may turn out to be the wrong choice over the long term.
