Cloud FinOps in Practice: Slashing 35% of Unnecessary AWS and GCP Infrastructure Waste

We inherited a cloud estate where the monthly bill was visible to everyone and owned by nobody. AWS carried production workloads, GCP hosted data pipelines and experiments, Kubernetes ran several services, and every team had a reasonable explanation for its own resources. The waste sat between those explanations: idle non-production environments, oversized node pools, backups retained by default, cross-region traffic, and commitments purchased without a workload owner.

The target was a 35% reduction in unnecessary infrastructure waste. That target did not mean cutting 35% from the bill by switching off production capacity. It meant separating business-serving consumption from avoidable consumption, protecting SLOs, and making the person who can change a workload accountable for its cost.

This is how we run cloud cost optimization in practice across AWS and GCP. The method applies to multi-site operators, funded scale-ups, fintech teams, and businesses modernizing systems while their internal engineers are already carrying operational work.

Where a 35% waste-reduction programme fails

Cloud FinOps fails when it becomes a finance report with engineering copied on the email. A report can identify an idle load balancer or an underused database. It cannot safely decide whether the resource is idle, whether its deletion affects a recovery objective, or whether a traffic pattern will return during a regional trading window.

We also reject the opposite mistake: treating every cloud cost as waste. A fintech may need duplicated environments for testing controls. A logistics operator may need spare capacity before a seasonal peak. A multi-site retailer may accept higher availability costs because an outage affects every location. The right question is not “How do we make the bill smaller?” It is “Which consumption has no defensible relationship to a product, service level, recovery requirement, or engineering experiment?”

The 35% figure is a programme target, not a universal promise. It is credible only after the estate has been measured and the waste categories have been verified. If a workload is already rightsized, tagged, scheduled, and tied to a service objective, aggressive cuts can turn optimization into an availability incident.

Our position is direct: cloud cost optimization belongs inside delivery ownership. A dedicated pod with engineering, QA, UX where needed, a technical lead, and DevOps capability can carry the remediation backlog as part of the product roadmap. That is different from renting headcount, assigning a developer a list of tickets, and leaving architecture and outcomes with the client.

Target, not guarantee: Reduce unnecessary waste, not capacity that protects service objectives.

• Validate the 35% target against measured, verified waste.
• Protect service levels, recovery requirements, and justified spare capacity.
• Make workload owners accountable for cost changes.

Where the waste actually appears in a live AWS and GCP estate

Cloud waste usually appears as a pattern in operations, not as one spectacular line item. The clearest symptom is a bill that rises while traffic, orders, active users, or processed records remain broadly stable. Teams explain the increase through growth, but the underlying change is often a new environment, a larger default instance, a retained snapshot policy, or a Kubernetes cluster that was scaled for a peak and never returned to its normal shape.

We look for the moment the infrastructure stopped reflecting the product. A staging database has the same class as production because the original template made that choice. A GCP data pipeline writes intermediate files to a high-cost storage tier and never expires them. An AWS NAT gateway carries traffic between services that could have stayed inside the same network path. A Kubernetes namespace requests the capacity it once needed during a migration, so the scheduler reserves resources that workloads rarely use.

In APAC businesses, the ownership problem is amplified by distributed teams and operating hours. Singapore, Australia, and Hong Kong teams may maintain separate environments, accounts, projects, and support rotations. A resource can be “temporary” for months because the person who created it is working in another time zone or has moved to another initiative.

Our first audit question is therefore not “Which provider is cheaper?” AWS and GCP both expose enough billing and utilization data to find waste. The question is “Which product, team, environment, and operational obligation does this resource serve?” If nobody can answer, the resource is a candidate for action, not an automatic deletion.

For teams also carrying migration risk, cloud migration and infrastructure modernization should be planned alongside cost controls. Moving an inefficient architecture without changing its ownership model simply relocates the waste.

Root causes: what breaks and why

Most avoidable spend comes from a small set of control failures. The table below separates the visible cost signal from the engineering cause and the corrective action we would put into the backlog.

The common failure is to address the symptom at the wrong layer. An engineer may reduce an instance size while a retry storm keeps increasing database work. A finance team may challenge a Kubernetes bill while platform defaults force every service to request a full node. A migration team may move storage to a cheaper class while retention remains unlimited.

We treat each recommendation as a change to a system. The change needs an owner, a safety condition, a measurement window, and a rollback path. That is the difference between FinOps practices in 2026 and a monthly list of recommendations nobody trusts.

The operating model: one weekly loop, with engineering authority

Verdict: run FinOps as a weekly engineering control loop, not a quarterly cost review. The loop is simple: alert, triage, act, verify. Its value comes from putting the action with the team that owns the workload and making the result visible to the people responsible for product and operational outcomes.

We start with allocation. Every production resource needs an application, environment, owner, cost centre or product, and data classification where relevant. AWS accounts and tags should map to product boundaries. GCP projects, labels, folders, and billing exports should support the same view. Shared platforms need an allocation rule rather than a permanent “unallocated” bucket.

We set policy at deployment time. Untagged resources, missing expiry dates for non-production assets, unrestricted public exposure, and unapproved regions should fail a pipeline or require an explicit exception. Infrastructure as code modules should make the compliant path the easiest path. A developer should not need to remember a dozen billing conventions when the module can apply them automatically.

We create a weekly review with four questions:

• Which anomaly changed the expected cost of a product or environment?
• Which recommendation has a verified owner and a safe implementation window?
• Which action changed utilization, performance, resilience, or cost?
• Which exception is still valid, and when will it be reviewed?

The review should include engineering, finance or operations, and the product owner for material workloads. It should not become a meeting where finance negotiates with engineers over every line item. The decision record belongs with the service owner because that person can test the effect on latency, throughput, recovery, and customer behavior.

Related:cloud cost control for SaaS operating models, useful when cost allocation needs to follow products, tenants, and delivery teams.

FinOps inside delivery ownership

• cost allocation — Map resources and shared spend to products and owners.
• deployment policy — Enforce resource controls through pipelines and infrastructure code.
• weekly review — Review anomalies, recommendations, results, and exceptions.
• service owner authority — Keep change decisions with the owner who can verify workload effects.

Cost decisions stay with the team that can safely change the workload.

Rightsizing, autoscaling, and scheduled environments

Rightsizing is the act of matching provisioned capacity to observed workload demand while preserving the service objective. It is not the act of choosing the smallest available instance. We use utilization, p95 latency, queue depth, error rate, concurrency, memory pressure, and scaling behavior together because CPU alone can produce a false saving.

• Compute: compare sustained and peak demand before changing instance families or node sizes.
• Databases: inspect connections, I/O, storage growth, lock time, cache behavior, and replica use.
• Serverless: review invocation duration, memory allocation, concurrency, retry behavior, and downstream cost.
• Non-production: schedule resources around actual working patterns and attach a TTL to temporary environments.
• Autoscaling: tune scale-out and scale-in thresholds against customer-facing SLOs, not a generic utilization target.

Scheduled environments create some of the safest early wins because the business usually knows when a development or test system is needed. The control must include exceptions. A staging environment used for overnight integration testing should not be shut down because a calendar assumed office hours. The schedule must be visible, owned, and tested against deployment pipelines.

We also separate “idle” from “quiet.” A low-traffic production service may be deliberately overprovisioned for a recovery objective or a sudden site-wide event. A quiet development instance with no deployment, test, or access activity may be idle. That distinction belongs in the service runbook.

When performance is the hidden driver of waste, performance and scalability optimization is the relevant engineering track. A slow query can make teams add compute to compensate, leaving the underlying cost per transaction untouched.

Commitments without lock-in regret

Commitments reduce unit cost by exchanging flexibility for a usage obligation. They are useful only when the underlying workload has a stable owner, a credible forecast, and a plan for changes. A commitment purchased against an unstable migration can turn an optimization decision into a stranded obligation.

We manage AWS Savings Plans, Reserved Instances, and comparable GCP commitments as a portfolio. The review should cover:

• baseline usage by service and account or project;
• forecast changes from migrations, decommissions, and product launches;
• coverage and utilization of existing commitments;
• region, family, tenancy, and platform constraints;
• the owner responsible for reviewing the position after architecture changes.

Commitment decisions should follow rightsizing, not precede it. Buying a commitment for an oversized workload makes the wrong shape cheaper while preserving the wrong capacity. We also avoid using commitments to hide an allocation problem. If a shared platform cannot show which teams consume it, a lower rate does not make the ownership gap disappear.

For a business modernizing legacy systems, the commitment horizon must match the modernization plan. A database scheduled for migration should not receive a long commitment simply because its current usage looks steady. The correct decision may be to accept a short period of higher unit cost while the architecture changes, then commit against the stable target state.

Kubernetes cost management: requests are financial decisions

Kubernetes cost management begins with resource requests because requests influence scheduling and therefore the number and shape of nodes the platform must run. A service that requests more CPU and memory than it uses can force the cluster to buy capacity that produces no customer value.

We inspect each workload by namespace and service. The useful question is not “What is the cluster utilization?” A cluster can look healthy while one namespace over-requests memory and another creates expensive burst capacity. We need showback that reaches the team responsible for the deployment.

The implementation has several layers:

1. Profile actual demand: capture workload behavior across normal traffic, deployments, batch jobs, and known peaks.
2. Review requests and limits: remove copied defaults and set values that reflect measured behavior.
3. Separate workload classes: keep latency-sensitive services, batch processing, and experiments from competing under one policy.
4. Improve bin-packing: use node pools and scheduling rules that reduce stranded capacity without weakening availability.
5. Expire temporary capacity: attach TTLs to preview environments, migration jobs, and one-off test clusters.
6. Track cost per namespace or product: make shared platform allocation visible through showback before introducing chargeback.

We do not tune requests in isolation. A lower request can improve packing while creating throttling, eviction, or latency problems. The change needs application metrics and a rollback condition. Kubernetes cost management is successful when the platform becomes more efficient without transferring the cost into incidents and engineer time.

For teams running AI or data workloads, the same discipline applies to accelerators, batch windows, object storage, and data movement. A GPU that is technically allocated but waiting on data is not productive capacity. A pipeline that repeatedly moves large datasets between regions has a network design problem, not merely a billing problem.

Storage, backup, and egress: the quiet accumulation problem

Storage waste accumulates because deletion feels risky and retention policies are rarely revisited. The bill grows through snapshots, log archives, build artifacts, database backups, object versions, and intermediate data. Each item looks small until the retention period spans several product cycles.

We assign every data class a purpose and a retention rule. A production backup required for recovery is different from a developer snapshot. A compliance archive is different from a debug log. A data science intermediate file is different from a system-of-record dataset. The policy must state who can delete it, how recovery is tested, and what happens when the owner leaves the project.

Lifecycle controls should be implemented in infrastructure code and verified with reports. We use storage tiers based on access, expiration rules for disposable data, and separate recovery requirements from convenience copies. Deletion tests matter because an untested retention policy creates a different form of risk: teams keep everything because they do not trust recovery.

Egress deserves architectural attention. Cross-region replication, public endpoints, chatty microservices, and centralised observability can create transfer costs that rightsizing will never remove. We map the largest flows and ask whether data can be processed closer to its source, cached, compressed, batched, or retained within the same region.

Cloud modernization services should reduce these structural costs rather than reproduce them in a new account. A migration that keeps unnecessary cross-region calls, unlimited logs, and duplicated data stores has changed the provider boundary without changing the cost model.

What a delivery-owning pod changes

Cloud FinOps needs people who can change code, infrastructure, deployment policy, and operational habits. That is why we distinguish renting headcount from buying delivered capability.

In our model, engineers are on our payroll and on the client roadmap. That continuity matters because cost work is not a single sprint. The same people need to understand why a service was oversized, which SLO protects it, how a migration changes the forecast, and whether a new deployment reintroduced the waste. Delivery risk sits with our team rather than with the client’s hiring pipeline.

The APAC hiring comparison makes the operational distinction visible. A Singapore in-house senior engineer carries base salary, 17 percent CPF, roughly 20 percent recruiting fee, and a three-month ramp before the first shipped increment. A delivery-owning pod is a different procurement decision: the client buys a coordinated capability with technical leadership, QA, DevOps, and continuity rather than one person waiting to be recruited and integrated.

Hiring in-house is the honest answer when cloud economics is a permanent core competency, the workload has stable long-term ownership, and the company can recruit and retain the full capability around that engineer. A pod is the better answer when an engineering capacity gap is delaying modernization, when the roadmap crosses several specialties, or when the business cannot afford to wait through the hiring pipeline.

Who owns the outcome?

Pods suit capacity gaps and roadmaps spanning several specialties.

Regulated workloads: cost ownership cannot weaken accountability

For Singapore financial services, MAS TRM makes technology risk management and third-party oversight part of the operating obligation. For Australian regulated organisations, APRA CPS 230 places emphasis on operational risk management, service provider management, and the ability to maintain critical operations. Cloud optimization cannot be approved as a cost exercise that obscures who is accountable for code, controls, resilience, or recovery.

The practical consequence is that a delivery partner can own implementation work without becoming a substitute for the regulated entity’s accountability. The client still needs clear approval rights, access controls, evidence, incident processes, change records, data handling rules, and exit arrangements. The pod must work inside that control environment.

We document the following before changing a material workload:

• the service owner and accountable executive;
• the data classification and approved processing location;
• the SLO, recovery objective, and resilience assumptions;
• the change approval and rollback path;
• the evidence required for audit and third-party oversight;
• the dependency and exit plan if a provider, region, or partner changes.

A cheaper storage tier is not an optimization if it breaks retention obligations. A smaller database is not a saving if it undermines recovery. A commitment is not a success if it blocks an approved exit or migration. In regulated environments, the cost decision is valid only when the control decision remains valid.

Quality ownership matters here. Automated tests, infrastructure checks, and deployment evidence must be part of the same backlog as rightsizing and lifecycle changes. AI-driven quality assurance and testing may support coverage and regression work, but it does not remove the need for accountable human approval of material changes.

How we run a five-day cloud infrastructure cost audit

A five-day audit is a decision instrument, not a promise that every saving can be implemented in five days. We use it to identify the largest avoidable categories, validate ownership, and produce a sequenced remediation plan with risk controls.

1. Day one, establish the estate: inventory AWS accounts, GCP projects, regions, clusters, databases, storage, data movement, environments, and billing exports. Record the business owner and service objective where known.
2. Day two, allocate the bill: map tags, labels, accounts, folders, namespaces, shared services, and unallocated spend. Separate production, non-production, platform, data, security, and experimentation.
3. Day three, test utilization and architecture: inspect compute, memory, storage, database behavior, Kubernetes requests, autoscaling, schedules, backups, and egress. Compare demand signals with provisioned capacity.
4. Day four, validate risk: review SLOs, recovery requirements, data classification, change controls, MAS TRM or APRA CPS 230 implications where relevant, and the owners who can approve changes.
5. Day five, present the decision backlog: classify actions as immediate, planned, or architectural; assign owners; define expected measurement; document rollback; and identify the work needed to reach the 35% target without treating it as an unsupported guarantee.

The output should not be a spreadsheet of generic recommendations. It should contain resource-level evidence, a product or service owner, a risk classification, an implementation sequence, and a verification query or dashboard for each material action.

We ask for read-only billing and telemetry access first, then request write access only when the client’s controls and change process support it. The audit should leave the client with a repeatable operating model, not dependence on an external analyst who must rediscover the estate every quarter.

Audit output: A five-day audit produces decisions, not guaranteed implemented savings.

• Require resource-level evidence, ownership, and risk classification.
• Sequence actions with measurement and rollback controls.
• Start with read-only billing and telemetry access.

Metrics that prove the saving is real

A lower invoice alone does not prove optimization. Spend can fall because traffic fell, a launch was delayed, or a service was degraded. We track cost with workload and reliability measures so the programme distinguishes waste removal from business contraction.

• Allocated cloud spend: percentage of spend mapped to a product, service, environment, or shared-platform rule.
• Unallocated spend: amount and age of resources without a confirmed owner.
• Idle resource exposure: resources eligible for scheduling, deletion, or review, with exceptions documented.
• Cost per business unit: cost per order, job, tenant, transaction, or other product measure where the business can define it.
• Kubernetes efficiency: requested versus used CPU and memory by namespace, with throttling, eviction, and latency alongside the result.
• Commitment utilization: whether purchased commitments are serving the workloads they were intended to cover.
• Reliability guardrails: error rate, latency, availability, recovery test result, and incident count after each material change.

We report realized savings separately from avoided future spend. Deleting an idle environment can produce realized savings. Preventing a proposed oversized deployment is avoided spend. Both matter, but combining them creates false confidence about the effect on the invoice.

We also track reintroduction. If a team deletes ten idle resources and new untagged resources appear the next month, the problem is policy and ownership, not execution. A successful FinOps programme reduces the rate at which waste returns.

When this approach is the wrong choice

A dedicated delivery pod is the wrong choice when the client already has a capable platform team with clear ownership, reliable telemetry, an active FinOps operating rhythm, and enough capacity to implement the backlog without delaying product commitments. In that condition, adding another delivery group can create coordination overhead rather than capability.

It is also the wrong choice when leadership wants a vendor to take responsibility for an outcome while withholding access, service decisions, production ownership, or the authority to change infrastructure. No team can own cloud waste if every recommendation waits indefinitely for an internal decision.

Cloud optimization is a poor first move when the underlying product economics are broken. If a service has no viable customer or operational purpose, reducing its infrastructure bill does not make it a good product. If a critical system has undocumented dependencies, the first investment may need to be discovery and modernization rather than immediate rightsizing.

Hire in-house when the organization needs permanent platform ownership, has a stable multi-year roadmap for that capability, and can support recruitment, management, QA, security, and operational coverage. Use a delivery-owning pod when the immediate constraint is delivery capacity across those disciplines and the business needs the same team to carry the work from audit through implementation and verification.

The next decision is ownership, not tooling

Start by naming the five cloud services or environments whose cost rose without a matching change in business demand. For each one, record the owner, workload objective, utilization evidence, retention rule, network path, Kubernetes requests if applicable, and the change that would reduce waste without violating its SLO.

Set a five-day audit boundary. Give the team read-only access, require resource-level evidence, and make the 35% target conditional on validated waste rather than a marketing promise. Decide which actions your existing engineers can own and where the roadmap needs a delivery-owning pod with technical leadership, QA, and DevOps continuity.

The next cloud bill will reflect that decision. If nobody owns the remediation backlog, the estate will keep paying for the architecture you already have.

FAQ

What does cloud FinOps mean in practice?

Cloud FinOps is the operating discipline that connects cloud consumption to business value, engineering ownership, and financial accountability. In practice, it includes allocation, policy at deployment, rightsizing, scheduling, commitment management, Kubernetes controls, lifecycle policies, and a recurring alert-to-action loop.

Can AWS and GCP waste really be reduced by 35%?

A 35% reduction can be a valid programme target when the estate contains verified idle, oversized, unallocated, over-retained, or structurally inefficient resources. It is not a universal benchmark or guaranteed result. The target should be confirmed through a resource-level audit and protected by SLO and compliance controls.

What is the difference between FinOps and cloud cost optimization?

Cloud cost optimization focuses on reducing unnecessary consumption through technical and architectural changes. FinOps adds the operating model: allocation, ownership, forecasting, governance, showback, decision rights, and recurring verification across finance, engineering, and product.

Why is Kubernetes cost management difficult?

Kubernetes cost management is difficult because node capacity is influenced by workload requests, scheduling, scaling, and shared platform design rather than by one service’s invoice. A namespace can over-request resources and force additional nodes even when actual utilization is low. Cost must be shown back to the teams responsible for deployments while latency, throttling, eviction, and availability remain visible.

When should a company hire in-house instead of using a delivery pod?

Hire in-house when permanent platform ownership is a core capability, the roadmap is stable, and the company can support the full surrounding team and operational model. A delivery-owning pod is more suitable when the constraint is immediate capacity across engineering, QA, DevOps, modernization, and product delivery, especially when hiring would delay the remediation roadmap.