Field notes · Cloud costs ·
We cut a customer’s cloud costs by 28% in one week. Without migrating the environment.
Our customer runs their applications in Oracle Cloud. An annual bill of around €3,000, stable operations and no surprises on the invoice. At first glance, there was nothing to fix.
That is why we took a closer look. Application availability does not answer a simple question: what exactly are you paying for – and do you still need it?
After a week of review and changes, daily costs fell from €8.35 to €6.04. The applications stayed in the same cloud and European region. No data transfers or new environment were needed.
A quarter of the bill went on backups. Some no longer served a purpose.
We started with a Cost Analysis export and a breakdown by service. Backups accounted for around a quarter of the total bill – approximately €63 per month.
A review of volumes and backup policies showed where those costs came from:
- A less critical server had daily, weekly, monthly and annual backups. It retained about twenty recovery points, even though the system could be rebuilt in roughly an hour if needed.
- Two other volumes had monthly backups with long retention: monthly copies for twelve months and annual copies for five years. This is the predefined Bronze policy in OCI. After a year of operation, these backups occupied approximately 1.5 TB. Oracle backup policies.
- An approximately 2 TB volume backup remained from a migration cancelled two years earlier. It was no longer useful for restoring the current environment, but it continued to incur charges.
- Orphaned boot volumes remained after servers had been removed. When terminating an instance through the OCI Console, its boot volume is preserved by default unless deletion is selected. Oracle documentation.
In total, approximately 5 TB of backups were retained. Some belonged to retired systems; others provided a longer history than needed to be kept directly in OCI.
Cleaning up and improving the server configuration
We removed unnecessary backups and orphaned volumes. Production volumes kept their automated backups with four weeks of retention. A second backup layer outside OCI already provided long-term history.
We changed one lightly loaded server to a newer processor generation with half the allocated cores. In this environment, the new configuration delivered higher performance at a lower cost. The change required one short reboot, without redeploying applications.
Newer OCI generations offer different processors and specifications. Core counts alone are therefore not enough for a comparison: the workload and hardware generation also matter. Oracle compute shapes.
We kept the backups. Each has a purpose.
The customer still has two backup layers after optimisation.
OCI backups provide fast recovery. Every production volume has automated backups with four weeks of retention. We removed unnecessary historical copies and backups of retired systems.
A second provider supplies geographically separate data and long-term history. The customer already used backup storage outside the primary cloud. Encrypted copies are stored in a different location with a different provider. They also provide the basis for building a copy of the environment.
Data protection follows each system’s needs. Daily backups are the baseline; additional mechanisms cover more recent changes where required. For MySQL, for example, backups combined with binary logs enable point-in-time recovery.
We also tested recovery. In the MySQL test, we restored the state before a selected change to a single data item. Recovery took approximately two minutes, and the system then worked as before. This result applies to that specific data recovery test.
The RTO – the required time to restore operations – did not change. The responsibilities were clarified: OCI provides fast volume recovery, while the second provider supplies geographical separation, long-term history and the ability to reconstruct a copy of the environment.
The customer had already been using the external storage for other systems before the optimisation. The changes therefore introduced no additional costs for this backup layer.
The result: approximately €843 per year
| Metric | Before | After |
|---|---|---|
| Daily costs | €8.35 | €6.04 |
| Annual projection | €3,048 | €2,205 |
| Monthly OCI backup costs* | approximately €63 | approximately €1 (after the changes) |
*Monthly values reflect the observed consumption before and immediately after the changes. Backup costs may vary with data volume, changes to the data and the accumulation of backups within the retention period.
Daily costs fell by 27.7%. If consumption stays at the new level, this represents annual savings of approximately €843. Annual figures are projections from daily consumption, rather than a completed annual bill.
The customer stayed on the same platform, with the same SLA and in the same region. The ongoing rollout of new application versions continued unchanged.
Five things you can check today
- A stable bill does not prove efficiency. Even a regular monthly amount may include resources you no longer need.
- Track backup retention and storage volume. Infrequent backups are not necessarily cheap if copies are kept for years.
- Removing a server does not remove all its costs. Check boot volumes, detached data volumes, backups and reserved IP addresses.
- Set budget alerts. They do not stop consumption, but they flag unexpected changes. OCI tracks both actual and forecast budget overruns. Budget documentation.
- Review the existing environment before planning a migration. In this case, cleaning up and adjusting the configuration saved almost a third of the bill.
Want to know what you are paying for in your cloud?
We will review your cost export with you and identify items worth investigating during an initial one-hour review. Potential savings depend on your environment.