Cloud Cost Optimisation: Where the Money Goes

Cloud bills usually grow for a handful of unglamorous reasons: resources that are bigger than the workload needs, resources that run when nobody is using them, resources that nobody remembers owning, data that is stored or moved more than necessary, and paying on-demand rates for steady workloads that could be committed. Reducing the bill rarely means a clever trick. It means making spend visible, assigning ownership and applying a short list of levers in a sensible order.

This article describes where the money typically goes and what you can do about each area. We deliberately give no figures or percentages: savings depend on your architecture and habits, and any universal number would be invented. Treat the levers below as a checklist to test against your own invoice.

Start with visibility, not cuts

You cannot optimise what you cannot attribute. Before touching any resource, make sure you can answer: which team, product and environment is each cost for? Both AWS and Azure provide cost-analysis tools, budgets and alerts, and both support tags or labels that let you break spend down. A basic scheme works well:

• Owner: a team or named person who answers for the resource.
• Environment: production, staging, development, test.
• Product or project: what the spend supports.
• Expiry or review date: for temporary resources.

Enforce tags through infrastructure as code so they are applied automatically rather than remembered. Then set budgets with alerts so a surprise reaches a person within days, not at the month-end invoice.

Where the money usually goes

1. Compute that is too big or always on

Virtual machines and container nodes are typically the largest line. Common patterns:

• Oversized instances. Capacity chosen "to be safe" at launch and never revisited. Look at actual CPU and memory use over a representative period and size to that, with headroom.
• Non-production running around the clock. Development and test environments that nobody uses overnight or at weekends can be scheduled off or scaled down.
• Static fleets for variable load. If demand rises and falls, auto-scaling fits capacity to demand instead of paying for the peak all day.
• Old generations. Newer instance families often give more performance for the same spend; check what your provider recommends.

2. Paying on-demand for steady workloads

On-demand pricing buys flexibility. If a workload runs continuously for a long time, commitment-based options, such as AWS Savings Plans and Reserved Instances or Azure Reservations and savings plans, can lower the rate in exchange for a commitment. The rule of thumb is to commit only to the baseline you are confident will remain, and leave the variable part on-demand. Over-committing is a real way to waste money, so read the terms and the exchange or cancellation rules carefully.

3. Storage that only grows

Object storage, snapshots and backups accumulate quietly:

• Apply lifecycle rules that move older data to cheaper storage tiers and delete what you no longer need.
• Delete orphaned disks left behind after virtual machines were removed, and stale snapshots.
• Check backup retention against what the business and regulation actually require, rather than keeping everything forever. This links to disaster recovery planning, where retention should be a deliberate decision.
• Match storage class to access pattern; frequently read data and archive data deserve different tiers.

4. Data transfer

Moving data out of a cloud provider, across regions or between availability zones is often billed, and it surprises people because it hides in architecture rather than in a resource. Watch for chatty services spread across zones or regions, large downloads served straight from storage instead of through a content delivery network, and backups replicated across regions without a clear need. Keeping tightly coupled components in the same zone or region and using caching or a CDN can reduce it.

5. Managed databases and licences

Databases are convenient and are often over-provisioned. Review instance size against real usage, remove unused read replicas, and check whether non-production databases need the same specification as production. If you run commercial licences, check how the provider's licensing rules apply to your agreement.

6. Idle and forgotten resources

Unattached IP addresses, idle load balancers, unused NAT gateways, test clusters from a past project, and abandoned proofs of concept all keep billing. A monthly review of resources with no traffic, plus an expiry tag on anything temporary, catches most of it.

7. Observability and logging

Logs and metrics can become a major cost on their own. Verbose debug logging left on in production, long retention for low-value logs and high-cardinality metrics all inflate it. Decide what you need for alerting and diagnosis, and set retention accordingly. See what to measure for a lean approach.

8. Over-engineering

Sometimes the expensive part is the architecture: a cluster where a managed container service would do, multi-region active-active for an internal tool, or separate full environments for every developer. Match the design to the business need. Our piece on whether you really need Kubernetes applies the same thinking.

The levers, in a sensible order

Order	Lever	Effort	Risk
1	Tagging, budgets and alerts	Low	None
2	Delete idle and orphaned resources	Low	Low, if ownership is checked first
3	Schedule non-production off-hours	Low to medium	Low
4	Right-size compute and databases	Medium	Medium, test under load
5	Storage lifecycle and retention	Medium	Medium, confirm retention needs
6	Auto-scaling for variable demand	Medium	Medium
7	Commitment-based discounts for the stable baseline	Low once data is clean	Financial, if over-committed
8	Architecture changes and data-transfer redesign	High	Higher, plan carefully

Do commitments after right-sizing, not before. Otherwise you lock in a discount on capacity you did not need.

Build cost into the process

• Review monthly. A short meeting with engineering and finance looking at the biggest movers is more effective than an annual clean-up.
• Estimate before building. Use the provider's calculator when designing a new service, and note assumptions.
• Cost-aware pipelines. Ephemeral test environments that are created and destroyed by your CI/CD pipeline avoid long-lived leftovers.
• Anomaly alerts. Both major providers offer cost anomaly detection; switch it on.
• Define "good". Track cost per customer, per transaction or per environment rather than only the total, so growth is not mistaken for waste.

Common mistakes

• Cutting blindly. Shrinking production without measuring load causes outages that cost more than the saving.
• Ignoring ownership. Deleting an "unused" resource that turns out to be a quarterly job upsets everyone. Ask owners first and snapshot before removing.
• Over-committing. Buying long commitments for workloads that you later migrate or retire.
• Treating it as one-off. Spend drifts upwards again without a routine.
• Optimising the small things. Start with the biggest lines in the invoice before tuning minor services.
• Forgetting people cost. A complicated saving that takes weeks of engineering time may not be worth it.
• Weakening resilience to save money. Removing backups or redundancy without a documented decision just moves the cost to the day something fails.

A first-month plan

1. Turn on billing exports, budgets and anomaly alerts.
2. Apply the four-tag scheme to everything and fix the untagged items.
3. List the top five cost drivers and assign an owner to each.
4. Remove clearly idle resources and schedule non-production off-hours.
5. Right-size the two largest compute or database items after reviewing real usage.
6. Add lifecycle rules to the largest storage locations.
7. Only then evaluate commitments for the stable baseline.

Summary

Cloud cost control is mostly visibility, ownership and routine: tag, review, right-size, schedule, tidy storage and commit only to what is stable. If you would like an independent review of your environment, CloudWiss's cloud and DevOps services include cloud cost optimisation alongside architecture, auto-scaling and monitoring, so savings do not come at the expense of reliability.