Cloud spending hit $723 billion in 2025. Organizations waste 32% of it, over $200 billion annually, on unused resources.
That’s not just a financial problem. It’s an environmental one.
Data centers consume roughly 2% of the world’s electricity, about as much as some entire countries. That consumption doubled between 2015 and 2022. By 2030, data center electricity demand is expected to double again, exceeding Japan’s total electricity consumption.
Every idle server, every oversized instance, every forgotten dev environment isn’t just burning money. It’s burning carbon.
This is where GreenOps enters the picture.
What Is GreenOps?
GreenOps integrates environmental sustainability into cloud financial management. It’s not a separate discipline from FinOps, it’s the same remediation playbook with an additional metric: carbon.
The insight is simple: cloud waste and carbon emissions share a common source. Unused compute cycles. Oversized infrastructure. Data stored inefficiently. Resources left running when nobody needs them.
Fix the waste, and you fix both problems simultaneously.
The good news? If you’re already practicing FinOps, you’re already practicing GreenOps. You just haven’t been measuring the environmental return.
The GreenOps Remediation Playbook
Here are the standard remediations that deliver both cost savings and carbon reduction. These aren’t theoretical. They’re the same optimizations FinOps practitioners have been implementing for years, now with a sustainability lens.
1. Oversized Compute Instances
The most common form of cloud waste. Teams provision for peak capacity, then run at 10-20% utilization around the clock.
An m5.4xlarge running at 15% utilization costs the same as one running at 85%. But it’s consuming electricity, generating heat, and requiring cooling infrastructure for capacity it never uses.
The fix: Right-size instances based on actual utilization data. Most cloud providers offer recommendations. Third-party tools can automate the process. A typical right-sizing exercise reduces compute costs, and associated emissions, by 20-40%.
2. Orphaned Instances Left Running
The classic “zombie” resource. Someone spun up an instance for a test three months ago. The test ended. The instance didn’t.
A 2025 cloud statistics review found that roughly 32% of cloud budgets go to unused resources. That includes instances nobody remembers launching, load balancers pointing to nothing, and elastic IPs attached to terminated servers.
The fix: Implement automated resource discovery and lifecycle policies. Tag resources with owners and expiration dates. Run weekly reports on resources with zero traffic or CPU utilization. Terminate what’s not needed.
3. Services Running on Aged, Inefficient Instance Types
Cloud providers continuously release new instance generations. Each generation typically delivers 15-40% better performance per watt than its predecessor.
That m4.large you launched in 2019? It’s still running, still billing, and consuming significantly more energy per unit of compute than its m6i equivalent.
The fix: Audit instance generations quarterly. Migrate workloads to current-generation instances. The performance-per-dollar improvement usually covers migration effort within months. The performance-per-watt improvement is a bonus.
4. Incorrectly Sized Microservices
Container orchestration makes it easy to over-provision. Set CPU and memory limits too high, and Kubernetes schedules pods on more nodes than necessary. Each additional node draws power whether the capacity is used or not.
The problem compounds at scale. A thousand microservices each over-provisioned by 20% means 200 extra nodes worth of infrastructure running idle.
The fix: Implement vertical pod autoscaling. Monitor actual resource consumption versus requests. Right-size container resource limits based on real usage patterns, not developer guesses.
5. Dev Environments Left Running
Development and test environments often mirror production, full infrastructure stacks running 24/7. But developers work 8 hours a day, 5 days a week. That’s 76% of the time when dev infrastructure sits idle.
The fix: Automated scheduling. Shut down non-production environments outside business hours. Spin them up on demand. Some teams save 60-70% on dev environment costs with simple start/stop automation, and eliminate 60-70% of the associated carbon emissions.
6. Excessive Retention of Storage Snapshots
Snapshots accumulate. Daily backups from three years ago. Snapshots of instances that no longer exist. Point-in-time copies nobody will ever restore.
Storage might seem environmentally benign compared to compute. It’s not. Storage infrastructure requires power, cooling, and physical hardware that eventually becomes e-waste.
The fix: Implement snapshot lifecycle policies. Define retention periods by environment (production vs. dev) and data classification. Automatically delete snapshots that exceed their retention window. Most organizations can reduce snapshot storage by 40-60% with basic lifecycle management.
7. Data Stored on the Wrong Tier
Hot storage costs 10-20x more than archive storage. It also consumes more energy, SSDs require power to maintain data integrity, and hot storage tiers run on higher-performance hardware with greater energy demands.
Yet organizations routinely store cold data on hot tiers. Log files from 2021 sitting on premium SSD storage. Compliance archives that nobody accesses paying real-time retrieval prices.
The fix: Implement intelligent tiering. Most cloud providers offer automated tiering based on access patterns. Configure lifecycle policies to move data through tiers: hot to warm to cold to archive. The cost savings are substantial. The energy reduction follows automatically.
8. Services Running in the Wrong Region
Region selection affects both latency and carbon intensity. A workload running in a region powered by coal generates more emissions than the same workload in a region powered by renewables, even if the compute cost is identical.
Additionally, services running far from their users incur data transfer costs and latency penalties that often lead to over-provisioning to compensate.
The fix: Audit workload placement. For latency-sensitive applications, run close to users. For batch processing and background jobs, consider regions with cleaner energy grids. Tools like the Google Cloud Carbon Footprint dashboard and AWS Customer Carbon Footprint Tool provide visibility into regional carbon intensity.
Beyond Remediation: Carbon-Aware Computing
The remediations above eliminate waste. Carbon-aware computing goes further: scheduling workloads to run when and where the grid is cleanest.
The concept is straightforward. Renewable energy generation fluctuates, solar peaks at midday, wind varies by weather. Background tasks that don’t require immediate execution can be scheduled for high-renewable periods.
Some organizations are implementing this now:
- Time-shifting batch jobs to run when local grid carbon intensity is lowest
- Region-shifting workloads to data centers with higher renewable energy percentages
- Demand-shaping to reduce compute intensity during grid stress periods
This isn’t mainstream yet. But as carbon reporting requirements tighten and sustainability becomes a board-level metric, expect carbon-aware scheduling to move from innovation to standard practice.
Getting Started
If you’re already doing FinOps, GreenOps is a measurement exercise, not a new program.
Start with visibility. The same tools that show you cloud spend can show you cloud waste. Unused resources, oversized instances, storage inefficiencies, these are already in your dashboards. You just need to look.
Pick the quick wins. Zombie instances and idle dev environments are low-hanging fruit. They require no architectural changes, deliver immediate savings, and eliminate carbon emissions that served no business purpose.
Add carbon metrics. AWS, Azure, and Google Cloud all offer carbon footprint dashboards now. Enable them. Start including carbon alongside cost in your optimization reports. What gets measured gets managed.
Build the business case. GreenOps delivers two returns: financial and environmental. For CFOs focused on margins, lead with cost savings. For boards focused on ESG commitments, lead with carbon reduction. The remediations are the same either way.
Every Optimization Counts Twice
The beauty of GreenOps is that it doesn’t require choosing between financial and environmental outcomes. The same actions deliver both.
Kill a zombie instance: save money and carbon. Right-size an oversized server: save money and carbon. Move cold data to archive storage: save money and carbon.
In 2026, GreenOps is becoming a KPI alongside DevOps and FinOps. The organizations building these practices now, measuring carbon, optimizing for efficiency, eliminating waste, will have advantages as sustainability reporting requirements expand and carbon costs become explicit.
The cloud promised efficiency. GreenOps is how you actually deliver it.
Sources
- Medium/Cloud FinOps 2026 Report - Cloud spending at $723.4B, 32% waste (~$200B annually)
- Flexera/ParkMyCloud Studies - 30-40% cloud waste from overprovisioning
- Seedling.Earth Cloud Emissions Guide - Data centers consume 2% of world’s electricity, doubled 2015-2022
- International Energy Agency - Data center electricity to reach 1000 TWh by 2030 (3% of global electricity)
- The Register/Data4 Lifecycle Study - Comprehensive LCA of datacenter environmental impact
- Intelegain 2026 Software Trends - GreenOps combining financial management with eco-friendly practices
- LinkedIn/Louis Ekpo - Carbon-aware computing scheduling for renewable capacity
- Holori Azure Cost Optimization - GreenOps + AI cost visibility becoming core requirement