What is cloud cost optimization?
Cloud cost optimization is the ongoing work of adjusting how you use cloud resources so that each unit of spend delivers matching business value. It is not simply cutting the bill. AWS describes a cost-optimized workload as one that fully utilizes its resources and achieves an outcome at the lowest possible price point while meeting functional requirements. The most effective approach combines two things: clear visibility into where money goes, and accountability placed with the people who make the decisions.
This guide gathers 12 actions organisations can start now, based on the FinOps Foundation's FinOps Framework, the cost optimization pillars of the AWS and Google Cloud Well-Architected Frameworks, and Microsoft's Azure Cost Management documentation. It gives no prices or discount rates, because they vary by provider, region and time; always check official pricing pages.
Foundations: FinOps and the Well-Architected frameworks
According to the FinOps Foundation, the FinOps journey has three phases: Inform (understand the current state), Optimize (identify and document ways to improve) and Operate (empower people to make the changes that drive the most value). Teams cycle through them rapidly and repeatedly rather than once. Optimization has two kinds: usage optimization (using fewer resources for an acceptable outcome) and rate optimization (paying an appropriate amount for the resources you must use).
The AWS Well-Architected cost optimization pillar sets out principles such as investing in cloud financial management, adopting a consumption model (pay only for what you use), stopping spending on undifferentiated heavy lifting by using managed services, and analysing and attributing expenditure to workloads and owners. Google Cloud groups its recommendations around aligning spend with business value, fostering a culture of cost awareness, optimizing resource usage and optimizing continuously, and notes that these align closely with FinOps.
If you are still choosing an architecture, see choosing a cloud architecture, because many of the largest cost decisions are made at design time.
12 cloud cost optimization actions to take now
The order runs from foundations (visibility and ownership) to technical optimization, closing with a review cadence. Skip steps 1–2 and you will struggle to measure the rest.
1. Tagging and ownership
Every resource needs minimum labels such as environment, project, owning team and cost centre. AWS stresses attributing cost to workloads and owners so you can measure return and give owners the chance to optimize. Google Cloud says the ideal is allocating 100% of cloud cost to its source, but acknowledges you may start lower because building the metadata structure is complex. Azure Cost Management supports tag inheritance and allocation rules to split shared costs.
2. Budgets and alerts
Create budgets per project, environment or team and turn on alerts before thresholds are reached. On Azure, forecasted alerts warn early when spending trends are likely to exceed a budget, and subscription or resource-group budgets can call an action group to automate a response. Azure also offers anomaly alerts for unexpected changes in daily usage. Just as important: decide who receives each alert and what they must do.
3. Rightsizing
Compare actual CPU and memory use with what you pay for and downsize over-provisioned resources. Google Cloud notes that over-provisioning wastes money while under-provisioning creates performance bottlenecks, so rightsizing should be proactive and based on monitoring data; provider recommendation tools (such as Azure Advisor or Google Cloud Recommender) are a good starting point.
4. Schedule non-production environments
AWS gives the example that development and test environments are typically used only about eight hours a day during the working week. Scheduling dev/test shutdowns for evenings and weekends is one of the lowest-risk actions available. Azure documents a sample scenario where a budget threshold triggers a runbook that stops virtual machines.
5. Understand commitment discounts
Providers lower unit rates when you commit to a level of usage over a period (for example Savings Plans, Reserved Instances or committed use discounts). This is rate optimization: commit only to a stable baseline you have measured over several months, after rightsizing. A commitment is a financial obligation, so involve finance and read each provider's terms carefully. Note that, per AWS, Spot Instances are not covered by Savings Plans.
6. Spot / preemptible capacity for interruptible work
Spot capacity uses a provider's spare capacity at a significantly lower price, in exchange for possible reclamation. AWS says Spot Instances can be interrupted with two minutes' notice and suit stateless, fault-tolerant workloads such as big data, containers, CI/CD and rendering. Google Cloud says Spot VMs can be preempted at any time and recommends them for batch jobs or stateless applications. Do not run primary databases or always-on services on spot.
7. Storage lifecycle
Move rarely accessed data to cheaper storage classes or delete it by policy; old snapshots and backups and unattached disks are common sources of waste. Use automated lifecycle rules rather than manual clean-ups, and agree retention periods with legal and data governance (see data governance basics).
8. Egress and data transfer
Data transfer charges are often overlooked at design time. AWS recommends data transfer modelling: understand where data moves within your workload, what the transfer costs and what it is worth, so you can decide whether to change or accept the architecture, for example when replicating data between Availability Zones. Keep resources close together, use caching and CDNs, and avoid unnecessary cross-region traffic.
9. Managed versus self-hosted
Google Cloud notes that virtual machines may look cheaper on unit price, but once you add maintenance, patching and scaling, total cost of ownership (TCO) can rise; serverless or managed services can deliver more value by reducing operational overhead. Compare on TCO, including your team's time, not just the invoice.
10. Log and monitoring data retention
Logs and metrics grow quietly. Google Cloud recommends tailoring data collection to avoid unnecessary storage costs and setting retention policies by role and regulatory need: developers may need detailed logs only briefly, while some industries must retain data longer. Reduce debug logging in production and sample high-volume data.
11. Autoscaling
For variable load, autoscaling avoids paying for idle capacity when demand is low while keeping enough capacity at peak. Google Cloud notes autoscaling can be configured for Compute Engine, GKE and Cloud Run; other providers have equivalents. Combine it with rightsizing: scaling out in small units is often more flexible than one large machine running all day.
12. Monthly review
FinOps is a loop, not a project. Each month, project owners and finance review cost against budget, anomalies, open optimization recommendations and cost per business unit (for example cost per order or per active user). Google Cloud recommends unit costing to understand cost drivers. Record decisions and owners so you can check them next month.
Prioritisation table: effort and impact
The table is EYC's qualitative assessment to help with sequencing, not measured data; actual impact depends on each organisation's cost structure.
| Action | Effort | Typical impact | FinOps phase |
|---|---|---|---|
| 1. Tagging and ownership | Medium | Foundation for everything else | Inform |
| 2. Budgets and alerts | Low | Prevents bill surprises | Inform |
| 3. Rightsizing | Medium | High if many resources are oversized | Optimize |
| 4. Non-prod schedules | Low | High when dev/test runs 24/7 | Optimize |
| 5. Commitment discounts | Low–medium | High for stable baseline load | Optimize |
| 6. Spot / preemptible | Medium–high | High for interruptible jobs | Optimize |
| 7. Storage lifecycle | Low | Medium, grows over time | Optimize |
| 8. Egress | Medium–high | Depends on architecture | Optimize |
| 9. Managed vs self-hosted | High | Varies; judge by TCO | Optimize |
| 10. Log retention | Low | Medium | Optimize |
| 11. Autoscaling | Medium | High for variable load | Optimize |
| 12. Monthly review | Low, recurring | Sustains results | Operate |
FinOps roles: who does what?
The FinOps Foundation describes several personas; in a mid-sized organisation one person may hold several. Microsoft also lists allied teams such as IT asset management and security.
- FinOps practitioner: coordinates, builds reporting and runs the review cadence.
- Engineering: owns the cost of the workloads it builds; performs rightsizing, autoscaling and clean-up.
- Finance: budgets, forecasting, allocation and invoice reconciliation.
- Product / business owners: decide trade-offs between cost, speed and quality.
- Procurement: negotiates and manages commitments and vendor contracts.
- Leadership: sets priorities and backs a culture of cost accountability; Google Cloud stresses that senior leaders must actively champion this shift.
Common mistakes
- Buying long-term commitments before rightsizing, locking in oversized configurations.
- Looking only at the total bill, with no tags to show who is accountable.
- Treating cost optimization as a one-off project instead of a monthly loop.
- Cutting in ways that harm reliability; AWS notes that sometimes optimizing for speed to market is wiser than up-front cost optimization.
- Forgetting AI and LLM API spend, a fast-growing line item in many organisations (see controlling LLM and AI API costs).
How EYC can help
EYC's Cloud and data infrastructure practice can work with your team to review the current estate, design tagging and budget standards, prioritise the actions above and set up a review cadence. Scope and commitments are defined under contract. Contact EYC to discuss.
Frequently asked questions
What is FinOps?
FinOps is an operating framework and cultural practice in which engineering, finance and business share accountability for technology spend. According to the FinOps Foundation, it runs through three repeating phases: Inform, Optimize and Operate.
Where should cloud cost optimization start?
Start with visibility: tagging, ownership, budgets and alerts. Then do low-risk actions such as scheduling dev/test environments and rightsizing, and only then consider commitments.
When should I use spot instances?
For interruptible work: batch processing, CI/CD, rendering and stateless applications. AWS can reclaim Spot Instances with two minutes' notice and Google Cloud can preempt Spot VMs at any time, so they are not suitable for primary databases.
Should I buy Reserved Instances or Savings Plans right away?
Only after rightsizing and measuring a stable baseline. A commitment is a financial obligation; read the terms carefully and involve finance.
Does cost optimization reduce reliability?
It can, if cuts are careless. The Well-Architected frameworks advise balancing cost with reliability, performance and speed to market, and judging results by business value rather than by the bill alone.