Cutting cloud infrastructure costs

Why Do Cloud Costs Get Out of Control?

Most technical teams are surprised when they see the monthly cloud service bill and wonder why the final amount is several times the initial estimate. The answer is almost always the same: resources that have been purchased but are not being used, services that have been sized larger than actual needs, and the lack of a system for continuous usage monitoring. In this article, instead of general recommendations, we provide three concrete actions for reducing cloud costs that you can implement today.

The important point is that reducing costs does not mean sacrificing performance. On the contrary, by eliminating unused resources and right-sizing, you usually get better performance as well. Let's go step by step.

Step One: Identifying Unused Resources

The biggest cost waste in the cloud is related to resources that have been left running for days or weeks without being used. These resources include virtual machines that haven't been shut down, old snapshots, and unused public IPs.

Virtual Machines Left Running

In many teams, a developer spins up a test server and forgets to shut it down after finishing. This small server might cost $5 to $10 per month, but if you have several of these, the amount becomes significant.

To identify these resources, if you use OpenStack or services based on it, you can use the following command to see the list of all instances along with their status and creation time:

openstack server list --all-projects --long -c ID -c Name -c Status -c Created

The output of this command shows you which instances were created weeks ago and are still in ACTIVE status. For instances that have been unchanged for more than 30 days, check whether you really need them.

Old Snapshots and Unused Disks

Snapshots are useful tools, but if you take a snapshot of a server every day and only keep the latest ones, storage costs quickly add up. A snapshot of a 100 GB disk costs about $2 per month. Ten of these become $20 per month, just for something nobody is using.

To view the list of snapshots in OpenStack:

openstack image list --private -c ID -c Name -c Created

Suggested rule: keep only the last 3 snapshots of each server and delete the rest. To automate this, you can write a cron script that automatically deletes snapshots older than 7 days.

Unused Public IPs

Every public IP that is not attached to any resource incurs a monthly cost. To find these IPs:

openstack floating ip list --status DOWN

This command shows IPs that are not attached to any instance. If you've kept a specific IP for future use, it's better to release it and get a new IP later when needed. The cost of keeping an unused IP is usually higher than the hassle of getting a new one.

Step Two: Right-Sizing Services

After removing unused resources, it's time to resize services that are active but have been sized larger than actual needs. This problem often arises from the fear of running out of resources: someone gets a server with 8 cores and 16 GB RAM, while the average CPU usage is below 20%.

Monitoring Usage for One Week

Before making any changes, you need to collect real usage data. If you use Prometheus and Grafana, you can check the following metrics for each server:

• Average CPU usage in 5-minute intervals
• Maximum RAM usage during the day
• Disk I/O and network bandwidth usage

If you don't have a monitoring system, you can use the sar command in Linux. First, you need to enable it:

sudo apt install sysstat
sudo systemctl enable sysstat
sudo systemctl start sysstat

After one week, view the collected data with the following command:

sar -u -f /var/log/sysstat/sa$(date +%d --date='7 days ago')

This command shows the average CPU usage for each day. If CPU usage has been below 30% all week, it means your server can run at least one size smaller.

Choosing the Right Size

Once you have the data, follow a simple rule: choose a size where your actual maximum usage is about 70-80% of its capacity. This headroom is sufficient for sudden fluctuations, without paying extra costs.

Example: If your current server has 4 cores and 8 GB RAM, with an average CPU usage of 15% and maximum RAM usage of 2 GB, an instance with 2 cores and 4 GB RAM is a suitable choice. This change usually reduces costs by 40-50%.

Using Auto Scaling for Fluctuations

If your usage fluctuates during the day (e.g., busy working hours and quiet nights), instead of buying a large server permanently, use the Auto Scaling feature. This feature allows you to spin up more instances during peak hours and shut them down during off-peak hours.

In OpenStack, you can use Heat to define scaling policies. A simple example:

heat stack-create -f autoscaling.yaml -P image=ubuntu-22.04 -P flavor=m1.small my-stack

The autoscaling.yaml file should include the definition of the instance group and scaling policies based on CPU metrics. This ensures that costs are minimized during off-peak hours.

Step Three: Continuous Monitoring and Budgeting

One-time optimization is not enough. If you don't have a monitoring and alerting system, costs will return to their previous state after a few months. Continuous monitoring is an integral part of reducing cloud costs.

Setting Budget Alerts

Most cloud services offer the ability to set cost limits and alerts. If you use OpenStack, you can use the Ceilometer service to collect usage data and define alerts:

ceilometer alarm-threshold-create --name cpu-high --description "CPU usage high" --meter-name cpu_util --threshold 80 --comparison-operator gt --period 600 --statistic avg --evaluation-periods 3 --alarm-action 'log://'

This command defines an alert that logs an event if the average CPU usage exceeds 80% over three 10-minute intervals. You can replace log:// with a webhook URL to send notifications to Telegram or email.

Weekly Reporting

Prepare a weekly report of resource usage and review it in the technical team meeting. This report should include the following:

• List of active instances and the cost of each
• Average CPU and RAM usage for each instance
• Number of snapshots and their total size
• Unused public IPs

To automate this report, you can use the OpenStack CLI and a simple bash script that runs weekly and sends the output as an HTML or text file via email.

Periodic Team Reviews

At least once a month, hold a 30-minute meeting to review costs. In this meeting, each team member should explain why each server they are responsible for is still active. This simple practice has a remarkable impact on cost reduction, as people are forced to think about the necessity of each resource.

Summary and Immediate Actions

To start reducing cloud costs in your infrastructure, take these three actions today:

1. Get a list of all active instances and review and delete those that have been unchanged for more than 30 days.
2. Monitor the usage of your 5 main servers for one week and choose a size that matches actual maximum usage.
3. Set up a budget alert and send a weekly usage report to the technical team's email.

These three actions alone can reduce your infrastructure's monthly costs by 30-50%, without any impact on service performance. Remember that optimization is an ongoing process, not a one-time project. Spend 30 minutes each month reviewing your resources.

If you're looking for infrastructure that provides integrated monitoring and usage management tools, ServerNet's cloud services can be a suitable option. But regardless of the service provider you choose, the principles discussed in this article are applicable on any cloud platform.