The cloud is something most businesses have started to embrace, often with initial goals of simplifying operations or reducing costs. After all, the great promise of the cloud is to only pay for what you use, and being able to scale resources up and down as needed. No longer do you need to plan months in advance with hardware purchases to support future growth, now you can press a button and scale your loads as needed. So why is it that so many people have started to ask why their cloud bills have become so high? Here we'll see some of the reasons behind it and what you can do about it.
While most cloud platforms like AWS and Azure can provide very cheap services, part of the issue is that they offer so many services, doing so many useful things. This can be both good and bad, because while you have access to so much capabilities, you must also keep track of the cost. As an example of how a simple workload can drive costs up in unexpected ways, let's take a look at a simple use case. Let's say you need to deploy a few containers running an internal app. It's an app that only a few users need to access, so you don't expect to need a lot of resources, and because it's a container, you rightfully assume that running a few such instances should be cheaper than deploying a bunch of servers. But reality can be quite different.
To deploy containers using Kubernetes on AWS, if you follow any online tutorial, you'll probably end up running this command:
aws eks update-kubeconfig --region us-east-1 --name my-app
This command creates a cluster so you can run your container, but what does it mean exactly to run a cluster? What this actually does is create a CloudFormation stack which in turn will create some resources in your AWS account. How many resources? Here's a sample:
As you can see, the command created 35 different resources, including a scaling group of EC2 instances, a NAT gateway, a load balancer, networking resources, roles, and so on. Some of these have no associated cost, but many do. The reality is that running this cluster over a month will cost you several hundreds of dollars. In contrast, if you were to create a small EC2 instance, you could get by with $15 per month. Even running multiple instances for redundancy, you would end up at a much lower cost. The convenience of using the recommended AWS approach is that you end up with a much costlier setup.
This is the same story with any modern cloud setup. If you do a Google search for any sort of deployment in AWS, Azure or Google Cloud, you will likely come up with a diagram that has dozens of components, all managed services that have a monthly cost attached to them. It's no longer a matter of running a Linux server with a specific workload, now the best practices include having several instances in a private subnet, a load balancer in front of them, Internet gateways to provide routing, an application firewall, logs going to a central logging service, security monitoring, and so on.
That isn't to say that this modern way of doing cloud deployments is a bad thing. Each of these services have a reason for existing, and they provide value, but it's incredibly easy to deploy services without even realizing, driving up your monthly bill. So how can you avoid this and keep a handle on your budget?
The most important aspect is to keep track of your costs. Whichever cloud provider you use, they will provide a detailed breakdown of costs. Make sure you know where your money is going, and whether the services you pay for are needed. Then, try to avoid the easier, more managed services when you don't need to use them, especially for production workloads. Even though it's easier to use AWS Beanstalk or the automated EKS deployment scripts, they will deploy very standardized resources. You should instead take the time to design deployments that meet your needs.
The cloud can definitively be cheaper than on-premise deployments. However that just isn't the case for most organizations, especially as they grow their footprint. Without a strict control over costs, they can easily balloon out of control.