Sustainable cloud: cutting compute costs and carbon

By Marco Lopes · September 20, 2026 · Cloud & DevOps

At Kordspace, we build across software, AI, Web3, hardware and design as a remote collaborative studio. Cloud infrastructure connects much of that work, and Google Cloud is usually our starting point, alongside AWS and Azure where they fit the project.

Sustainable cloud engineering starts with a practical question: how much infrastructure do we need to deliver a useful outcome reliably? Answering it often reveals opportunities to lower both spending and emissions. Idle environments, oversized databases and repeated processing rarely make a product better.

But cost and carbon are not interchangeable. A cheaper contract does not make a workload more efficient, and a lower-carbon region may introduce unacceptable latency or data-residency problems. We need a method that treats financial efficiency, environmental impact and service quality as related but distinct goals.

Start with useful work, not a smaller bill

We begin by defining what the system produces. Depending on the product, that might be a completed checkout, a processed document, a successful inference or a synchronised device reading.

We then track cost and resource consumption against those outcomes. Cost per successful job is more informative than a monthly bill alone: total spending can rise while efficiency improves as a service grows. Conversely, a falling bill can hide fewer customers or failed requests.

Our baseline includes compute utilisation, memory pressure, storage growth, network transfer and reliability indicators. Where carbon estimates are available, we record their scope and methodology alongside them.

The goal is not maximum utilisation at all times. We retain headroom for traffic bursts, maintenance and failures. Sustainability that makes a service unreliable simply moves waste into retries, incidents and recovery work.

Make ownership and measurement visible

Before changing infrastructure, we make its purpose legible. Every meaningful resource should have an owner, environment, service identifier and, for temporary work, an expiry date.

On Google Cloud, we can combine billing exports to BigQuery with monitoring data and resource inventory. Equivalent billing exports and observability tools support the same approach on AWS and Azure. Consistent labels or tags make the resulting analysis useful.

We look for resources that nobody can explain: unattached disks, forgotten development clusters, duplicate data pipelines and test databases kept indefinitely. We verify dependencies before removing anything, then turn those discoveries into repeatable policies.

Provider carbon reporting adds another perspective, but it is not a live electricity meter for each request. We treat it as an estimate, check reporting delays and boundaries, and avoid comparing figures from different methodologies as though they were directly equivalent.

Right-size before buying commitments

Right-sizing means matching resources to observed demand rather than to the largest machine a deployment template once selected.

We inspect representative usage windows, including peaks and scheduled jobs. CPU averages alone are insufficient: a database may be constrained by memory, storage throughput or connection count. For virtual machines and containers, we reduce capacity incrementally and check latency, errors, throttling and recovery behaviour after each change.

Kubernetes deserves particular attention. Inflated resource requests can force extra nodes even when actual consumption is modest. We tune requests using workload evidence and apply limits with care, especially where CPU throttling or out-of-memory termination would harm service quality.

Only after establishing a stable baseline do we consider committed-use discounts, reservations or savings plans. Those can lower prices for predictable usage. They do not, by themselves, reduce compute consumption or carbon emissions, and premature commitments can lock in waste.

Stop paying for work that is not happening

Non-production environments are often the simplest place to start. We schedule development systems around the hours they are needed, with an explicit override for distributed teams and exceptional work.

Preview environments should expire automatically. Batch workers should stop when their queues are empty. Temporary databases and disks need deletion policies that account for retention requirements and recovery needs.

For suitable HTTP and event-driven workloads, services such as Cloud Run can reduce idle capacity and support scaling to zero when configured appropriately. We still examine cold starts, concurrency, minimum instances and downstream connection limits. Moving an application to serverless does not make an always-on database disappear.

We also check whether autoscaling actually releases underlying capacity. Fewer pods on the same permanently running nodes may improve scheduling without reducing the infrastructure footprint. Savings require the whole scaling chain to work.

Match workload timing and location to constraints

Some workloads must run immediately. Others can wait. Report generation, media processing, model evaluation and certain data transformations may have scheduling flexibility.

We make that flexibility explicit through deadlines, queue priorities and interruption tolerance. Where credible electricity-carbon signals are available, we can test shifting eligible work toward lower-carbon periods. We distinguish forecasts from measurements and verify that scheduling changes have not increased total resource use.

Region selection requires similar care. We consider electricity characteristics alongside latency, residency, service availability, resilience and data-transfer costs. Moving compute while repeatedly fetching a large dataset from another region can undermine the benefit.

We also distinguish location-based emissions accounting from market-based accounting and contractual renewable-energy claims. These answer different questions. We document the basis for our decisions rather than describing any cloud region as impact-free.

Design applications to do less work

Infrastructure tuning cannot compensate indefinitely for inefficient application behaviour. We profile the busiest paths and look for avoidable database queries, repeated transformations, excessive polling and oversized payloads.

Caching can reduce repeated work, but it needs a clear invalidation strategy and a sensible retention policy. We compare the resources saved against the cache infrastructure added. The same discipline applies to precomputation: generating every possible result is wasteful when most are never requested.

For asynchronous systems, we use bounded retries, exponential backoff, idempotency and dead-letter handling. A failing dependency should not trigger an uncontrolled storm of repeated requests.

Product and design decisions matter here too. Smaller media assets, deliberate refresh behaviour and fewer unnecessary background requests reduce work across servers, networks and user devices. We include these choices in performance reviews rather than treating sustainability as an infrastructure-only concern.

Give AI workloads an efficiency budget

AI systems need their own resource questions. We begin with the smallest model and simplest pipeline that meet an agreed quality threshold, then increase complexity only when evaluation justifies it.

That can mean using a smaller model for classification, routing difficult cases to a larger model, limiting unnecessary context, or caching reusable results where privacy and correctness permit. We measure quality alongside cost, latency and resource consumption so that efficiency does not quietly degrade the product.

For self-hosted inference, we examine accelerator utilisation, batching and the cost of keeping models resident during quiet periods. For training and evaluation, we use checkpointing and interruption-tolerant execution where practical.

With hosted model APIs, detailed energy data may not be available. Token counts and request volumes help us track activity, but they are not universal carbon conversion factors. We report that uncertainty rather than inventing precision.

Reduce storage and data movement deliberately

Storage waste accumulates quietly. We define retention by data category, remove duplicate exports and apply lifecycle policies to logs, artefacts and backups.

Moving older objects to colder storage can reduce cost, but retrieval charges, minimum storage durations and access patterns matter. Lower prices alone do not establish lower emissions. We assess the complete workload rather than assuming one storage class is always greener.

Observability needs the same discipline. We retain enough telemetry to investigate incidents and meet obligations without collecting every payload indefinitely. Sampling and shorter retention for low-value debug data can help, provided security and operational visibility remain intact.

For Web3 services, we evaluate whether full historical data is genuinely required before selecting node configurations. For connected hardware, we consider filtering or aggregating readings at the edge, while checking device energy use and maintainability rather than merely relocating cloud work.

Make delivery pipelines less repetitive

Continuous integration can consume substantial compute without appearing in the production dashboard. We include build runners, test environments, package registries and artefact storage in our baseline.

We avoid rebuilding identical inputs, use dependency-aware test selection where safe, and cache dependencies with clear invalidation and security controls. Cancelling superseded builds can prevent several revisions of the same branch from competing for resources.

Runner size should match the job. A larger runner may finish faster without consuming less total compute, so we measure both duration and resource use. We also check whether self-hosted runners remain idle between jobs.

Infrastructure as code makes these improvements durable. We encode expiry policies, approved configurations and ownership requirements into templates and automated checks. The aim is a paved road for efficient delivery, not another manual approval queue.

Protect reliability and verify the result

Every optimisation needs a success criterion and a rollback path. We record the expected effect, deploy in controlled stages and compare equivalent workloads before and after the change.

Our review includes service-level objectives, queue age, failure rates and incident recovery, not just the invoice. Removing redundancy may lower spending while increasing business risk. Keeping necessary resilience is not waste.

Carbon assessment also requires clear boundaries. Operational electricity is only part of the picture; hardware manufacturing and other lifecycle impacts may be included differently across datasets. We avoid adding overlapping estimates or making unsupported claims about embodied emissions saved by a configuration change.

Finally, we watch for rebound effects. Cheaper processing can encourage more processing. We pair efficiency improvements with budgets and demand reviews so that doing each task more efficiently does not become an excuse to run unlimited low-value tasks.

A short sustainable-cloud checklist

For a first review, we use this checklist:

• Define a useful unit of work and baseline cost, resources and reliability.
• Assign owners and expiry dates to temporary infrastructure.
• Right-size compute before committing to long-term discounts.
• Verify that idle services and their underlying capacity scale down.
• Review flexible jobs for safer scheduling and placement changes.
• Reduce unnecessary queries, AI calls, data retention and rebuilds.
• Document carbon-reporting boundaries and uncertainty.
• Recheck outcomes after deployment and keep a rollback available.

We prioritise changes by expected benefit, confidence, implementation effort and operational risk. Deleting a verified orphaned resource is usually a better first step than redesigning an entire platform around incomplete carbon data.

Build sustainability into normal operations

Sustainable cloud work is most effective when it becomes part of everyday engineering. We review utilisation during capacity planning, retention during feature design, and resource efficiency during performance testing. Cost and carbon reporting then support decisions rather than becoming a separate annual exercise.

At Kordspace, we approach that work across architecture, development, AI, hardware and design, with Google Cloud preferred and AWS or Azure where appropriate. To turn an infrastructure review into a practical delivery plan, we invite readers to start a project or explore our related services pages. Together, we can build systems that do useful work with fewer wasted resources.