The cloud makes an attractive promise: you pay only for what you use. The flip side is that you pay for everything you use, including forgotten resources, data transferred without noticing and machines oversized "just in case". Many companies discover at the end of the month a bill much higher than expected and don't know where it comes from. Understanding the cost structure is the first step to controlling it.
How the bill is made up
The main items, named differently depending on the provider, are almost always these:
- compute: virtual machines, containers, functions, billed by the hour, second or invocation;
- storage: disks, snapshots, object storage, billed per gigabyte per month;
- managed databases: often among the highest items, because they include compute, storage and backups;
- network: above all outbound traffic to the Internet and between different regions;
- ancillary services: public IP addresses, load balancers, NAT gateways, logs and metrics.
The first two are easy to predict. The last two are the ones that surprise.
The most common hidden costs
Outbound traffic
Many providers don't charge for inbound data, but do charge for outbound data. A site serving heavy files, an application that copies backups to another provider or a service communicating between two regions can generate network costs higher than those of the servers.
Orphaned resources
When you delete a virtual machine, the attached disks, snapshots and reserved IP addresses are not always deleted with it. They keep being billed silently, month after month. The same goes for test environments created for an experiment and never shut down.
Logs and metrics
Collecting everything, keeping everything forever and indexing every log line has a cost that grows with traffic.
NAT gateways
Machines in private networks that access the Internet often go through a managed NAT gateway, billed both by the hour and per gigabyte processed. Servers that download many updates or container images through the NAT can generate unexpected costs.
Techniques for reducing spending
Size on measurements, not on fears
The most frequent cause of waste is oversizing. A large machine is chosen at launch and never reviewed. Looking at real CPU and memory usage for a few weeks, you often find that a smaller size is enough. Going down one size in many cases halves the cost of that resource.
Switch off what isn't needed
Development and test environments rarely need to be on at night and at weekends. A scheduled shutdown outside working hours cuts billed hours by about two thirds: a week has 168 hours, while a ten-hour working day for five days amounts to 50.
Long-term commitments
For stable workloads, running all day every day, almost all providers offer significant discounts in exchange for a one- or three-year commitment, in the form of reserved instances or savings plans. It is wise, however, to commit only to the certain baseline usage, not to the peaks.
Interruptible capacity
Spot or preemptible instances cost much less, but the provider can take them back with little notice. They are suitable for work that can be interrupted and resumed: batch processing, builds, rendering, data analysis. They should not be used for a production database.
Storage classes
Rarely accessed data, such as old backups or archives, can move to cheaper storage classes. Lifecycle rules automatically move objects after a certain number of days and delete them when they expire. Be careful, though: colder classes have retrieval costs and minimum storage durations.
Caches and CDNs
Serving static content from a CDN reduces outbound traffic from the servers and often costs less per gigabyte. A cache in front of the database reduces the load and, as a result, the size needed.
Making costs visible
You can't optimize what you can't see. A few habits make the difference:
- Tag every resource with project, environment and owner. That way the bill can be broken down and every item has a name.
- Set budget alerts that warn you when the month's forecast spending exceeds a threshold.
- Review the bill every month, not just when it grows: new items should be understood straight away.
- Make costs visible to the teams that create resources. Those who see what a choice costs tend to make better ones.
This approach, which combines technical and financial responsibility, is often called FinOps.
The balance to keep
Saving money must not compromise reliability. Removing redundancy from a production database, cutting backups or removing monitoring makes the bill go down and the risk go up. In my work the first optimizations almost always concern what brings no value at all, such as orphaned resources, environments left on at night and oversized machines, before touching anything that protects the service.
In short
- The bill is made up of compute, storage, databases, network and ancillary services; network and ancillary services are the items that surprise.
- Outbound traffic, orphaned resources, excessive logs and NAT gateways are the most common hidden costs.
- Size on real measurements, switch off unused environments and commit long term only on the stable baseline.
- Use interruptible instances for repeatable work and lifecycle rules for cold data.
- Tags, budget alerts and monthly reviews make costs visible and controllable.
