How to Reduce Cloud Costs: 10 Practical Optimization Tips

Why does the cloud bill keep growing?

A cloud bill rarely grows because of one spectacular mistake. It is usually a pile of quiet costs: unattached disks, test machines running overnight, oversized databases, and data crossing regions. The dashboard looks ordinary. The invoice does not.

I have made the same mistake myself. Low CPU usage on a VPS once tempted me to reduce its size, but memory pressure, disk behaviour, and the application’s cache told a different story. I changed the caching and query behaviour instead. The machine size was not the real problem.

Cost control starts with visibility. Then I look for capacity that is running at the wrong time, data stored in the wrong place, and changes that have no owner. The cheapest service is not always the cheapest system to operate.

1. Break the bill down by service

The first step is not deleting anything. It is finding where the money goes. A total monthly amount is useful as an alarm, but it cannot explain the alarm. Without service, project, environment, and owner information, you can easily cut the wrong resource.

At minimum, I want these dimensions in the provider’s cost dashboard:

• Service type: virtual machines, disks, object storage, databases, and network egress.
• Resource or project tag.
• Production, staging, and development environment.
• Region and availability zone.
• Daily and monthly cost changes.

If tagging was missing during the original setup, classifying old resources later is tedious. Do it anyway. I usually start with project, environment, owner, and expires_at.

Resource age is useful too. A test disk that has not changed for 60 days or an unused public IP address that has received no traffic for 90 days belongs near the top of my review queue. These are review signals, not automatic deletion rules.

2. Remove resources nobody uses

Deleting a virtual machine while leaving its attached disk behind takes very little effort. Snapshots, old images, reserved IP addresses, and forgotten load balancers can keep charging you in much the same way.

I do not begin cleanup with a delete command. First I build an inventory, find an owner, check the last access date, and set a holding period. A resource that looks empty may belong to a report system that runs once a month.

I nearly learned this the hard way during an overnight cleanup. I was in the shell for what I thought was a disposable host and had built an rm -rf command with tab completion. The hostname in my prompt appeared just before I pressed Enter. It was a customer server, not the test machine. I stopped, closed the session, and started putting hostnames in my terminal title and prompt. Two seconds of verification saved a very long night.

find /srv/backups -type f -mtime +30 -printf '%TY-%Tm-%Td %s %pn' | sort

This lists local Linux backup files older than 30 days, ordered by the output of find. The -mtime +30 condition uses modification time, so it is not proof that a backup is no longer needed. For cloud object storage, I prefer the provider’s lifecycle rules; a hand-written deletion script is another thing that can silently go wrong.

Before deleting anything, answer this: if I need it again, where will I recreate it from? If the answer is unclear, archive it or add an approval step first.

3. Choose VM sizes from actual usage

A large machine feels comfortable when you create a new server. You buy extra RAM and CPU because the application might grow. Sometimes it does not grow. The bill does.

For rightsizing, I review at least two to four weeks of CPU, memory, disk latency, disk IOPS, network traffic, and busy-period spikes. A machine averaging 8 percent CPU can still saturate its processor for several minutes every morning.

For a rough check on Linux VPSs, I use:

uptime
free -h
vmstat 5 6
iostat -xz 5 3

free -h gives a readable memory view. vmstat helps me inspect waiting and swap activity, while iostat shows storage pressure. The -xz flags matter here: they make the device statistics more useful and hide devices with no activity. On Debian, iostat normally comes from the sysstat package.

CPU alone is a poor sizing guide. Measure first, change one variable, and watch the same workload after the change. A smaller server that swaps during the morning peak is not a saving.

4. Schedule development and staging resources

Most development environments are quiet at night. Virtual machines, managed databases, and test clusters still run seven days a week because nobody scheduled them to stop.

Define working hours and stop non-production resources automatically. A test server running from 08:00 to 20:00 on weekdays may cost much less than one running continuously, depending on the provider and workload. Define the timezone explicitly. If the account uses UTC while the team works in İzmir, a schedule can start and stop at surprising hours.

Before shutdown, send a proper termination signal to the application and database. Cutting power while a database is writing can cause a long recovery or, in the worst case, data loss.

For temporary resources, require an expires_at tag. Notify the owner when the date passes, stop the resource next, and delete it only as the final step. A server that nobody uses overnight can still spend money perfectly efficiently.

5. Match storage classes and disk types to the data

Not every byte needs fast SSD storage. Active database files and log archives from six months ago should not automatically share the same storage class.

I separate data by access pattern:

• Active databases and application files: low-latency disks.
• Daily backups: standard object storage.
• Long-term archives: cold or archive storage classes.
• Temporary build and cache data: storage that can be recreated.

Before moving data to an archive class, check retrieval fees and access latency. A file can be cheap to store and expensive to retrieve during an incident.

On my local servers, ncdu is the first tool I open when I investigate disk usage. I stopped wasting time with repeated du -sh commands years ago. The same habit applies to cloud disks: expanding a disk before finding which directory consumed the space only postpones the problem.

6. Simplify snapshot and backup retention

Taking snapshots is easy. Deleting them is where the policy usually disappears. Snapshots made before every change can become dozens of nearly identical copies. Some providers also charge according to changed blocks rather than only the visible disk size.

Write a retention policy and automate it. Daily backups may stay for a short period, weekly backups longer, and monthly archives as long as regulations or business needs require. The exact periods belong to the workload. An undocumented policy belongs to nobody.

Test a restore before deleting old backups. An untested backup is an assumption about the future, whether it lives in borgbackup or in a provider-managed service.

borg list /backup/repository
borg check --verify-data /backup/repository

borg check verifies that the repository and archive data can be read, but it does not prove that the whole service can be recovered. I still restore files or a service on a separate machine and confirm that the application starts.

7. Reduce network egress and data transfer

Data transfer is one of the harder cloud charges to predict. Traffic between services in the same region may be priced differently from traffic between regions, while internet egress can quietly become a large line on the invoice.

Keep an application and its database in the same region unless there is a clear reason not to. Serve user-facing static files through a CDN. Large downloads should usually come from object storage and a cache instead of passing through the application server on every request.

Monitoring can consume network budget too. Review log sampling, retention, compression, and destination region. Leaving production logging at debug increases disk usage and can increase transfer costs as well.

iftop -i eth0

This shows current traffic on eth0; it is not a monthly billing report. It is still a useful first screen when I want to see which connections are moving unexpected data. Check package availability and permissions before installing or running it on production.

8. Consider committed discounts carefully

If you know that the same capacity will run for a long time, reserved capacity, savings plans, and similar commitment-based pricing can reduce the bill. A one-year or three-year commitment can also make a badly sized resource cheaper without making it right.

Start with baseline usage from the last few months. An always-on production database or a worker group that will not change soon may be a sensible candidate. Staging, campaign traffic, and rapidly changing projects are safer with flexible pricing.

Check these terms in writing:

• Which service and region does the commitment cover?
• Can you change the size or machine family?
• What are the terms for early cancellation, selling, or transferring it?
• Are taxes, licenses, and data transfer included in the discount?

List price is only one part of the decision. The flexibility you give up has a cost too.

9. Ask whether the architecture fits the cloud

Splitting every workload across dozens of managed services does not automatically make it cheaper. A small application with a permanently running cluster, separate load balancer, managed database, and high-volume observability service may cost more than a VPS while requiring more operational attention.

Look at the workload’s rhythm. Irregular, short-lived traffic may suit an event-driven or serverless design. My post, What Is Serverless Computing? Benefits and Use Cases, compares situations where request-based pricing is useful.

For steady traffic and only a few components, one VPS or a small group of simple virtual machines can be more predictable. As I discuss in Cloud Server vs VPS: Pick the Right Hosting Model, the decision includes management effort, backups, networking, and operations time, not just CPU and RAM prices.

To measure architectural cost, divide the monthly total by requests, customers, processed files, or completed jobs. A flat invoice with a falling unit cost can still be a meaningful improvement.

10. Set cost alerts and ownership boundaries

Checking the invoice at the end of the month is a late control. Set budget warnings, daily cost reports, and alerts for sudden increases. Send them to finance, the resource owner, and the technical contact.

If alerts are too sensitive, someone will mute them. If they are too broad, you will notice the increase days later. Set thresholds around each project’s normal variation and include the resource identity in the notification.

A small report can record when and where it was generated:

#!/usr/bin/env bash
set -euo pipefail

printf 'Report date: '
date -u +%F
printf 'Host: '
hostname

This does not calculate costs. It makes the report’s date and source machine clear. If you later retrieve billing data through a provider API, keep credentials out of the script. Use an IAM role, short-lived credentials, and read-only permissions.

I once added an extra asterisk to a cron entry for a backup script. It ran every minute and eventually left roughly 40,000 messages in the mail queue. That was my mistake, not a capacity problem. Cost alerts are much more useful when every resource also has an owner, purpose, and shutdown date.

A small working plan for cloud cost optimization

I would not apply all ten changes on the same day. In the first week, make costs visible by service and tag. In the second, review idle disks, IP addresses, and old snapshots. In the third, adjust staging hours. In the fourth, measure machine sizes and storage classes.

Record current cost and performance before each change. Then change one thing and observe it for several days. If you change the disk type, machine family, and network topology together, you will not know which decision made the difference.

Count operational effort too. A service that looks cheaper may require more maintenance, monitoring, and troubleshooting. Growing the night shift to save a small monthly amount is not optimization.

Choosing between a VPS and the cloud

For a website, small API, or personal project with predictable traffic, a VPS’s fixed monthly price can make budgeting easier. Cloud services may fit better when traffic changes sharply, users are spread across regions, or automatic scaling creates real business value.

Choosing a VPS does not end cost control. Add backups, traffic, disk growth, monitoring, and management time to the budget. My post, Launch a Secure VPS in 30 Minutes | Pro Admin Guide, covers a standardized setup that reduces repetitive manual work and configuration mistakes.

There is no universal winner. Workload rhythm, team skills, and tolerance for downtime decide the answer. My first question is simple: will I still run this system in roughly the same way a few months from now?

Frequently asked questions