Sustainable cloud design sounds abstract until the bill arrives.
The funny thing is that many "green cloud" improvements are also boring cost improvements: fewer idle servers, smaller data transfers, better storage lifecycle rules, and less over-provisioning.
I would not start with a grand sustainability framework.
I would start by finding waste.
The Practical Map
Cloud waste
|
+-- idle compute
+-- oversized databases
+-- forgotten disks/snapshots
+-- cross-region traffic
+-- logs kept forever
+-- build pipelines running too often
That is where the first wins usually hide.
1. Right-Size Before You Re-Architect
If a service uses 8% CPU most of the day, do not call it "resilient." It might just be oversized.
Check:
- CPU utilization
- memory pressure
- request latency
- autoscaling events
- database IOPS
- network egress
The goal is not to run everything at 95%. The goal is to stop paying for capacity that has no job.
2. Autoscale With Guardrails
Autoscaling is not magic. Bad autoscaling can create expensive chaos.
A decent setup includes:
- minimum capacity
- maximum capacity
- scale-out signal
- scale-in delay
- alert when max capacity is reached
Example mental model:
traffic spike
|
v
queue depth grows
|
v
workers scale out
|
v
queue drains
|
v
workers scale in slowly
I prefer scaling on workload signals like queue depth when possible, not only CPU.
3. Stop Keeping Every Log Forever
Logs are useful. Infinite logs are not.
Set retention by value:
| Data | Example retention |
|---|---|
| debug logs | 7-14 days |
| app logs | 30-90 days |
| audit logs | policy-driven |
| metrics | downsample over time |
This is not only a cost issue. Searching through noisy old data makes incidents slower.
4. Use Storage Lifecycle Rules
Storage waste is quiet.
Old exports, snapshots, uploaded files, and generated reports can sit around forever because nobody owns deletion.
Use lifecycle policies:
hot storage -> cool storage -> archive -> delete
Do this especially for:
- object storage
- database snapshots
- CI artifacts
- old build outputs
- user uploads with retention rules
5. Watch Cross-Region Traffic
Cross-region architecture looks impressive in diagrams. It can also burn money and energy quickly.
Before going multi-region, ask:
- Do users need lower latency globally?
- Do we have a real recovery objective?
- Can the database model handle it?
- Who will operate failover?
Multi-region without operational discipline is just expensive uncertainty.
6. Carbon-Aware Scheduling Is Useful, but Not First
Carbon-aware scheduling is becoming more practical in 2026, especially for batch jobs.
Good candidates:
- ML training
- analytics jobs
- image/video processing
- non-urgent data pipelines
Bad candidates:
- checkout
- auth
- customer-facing hot paths
My take: use carbon-aware scheduling after you already fixed obvious waste.
Final Thought
Sustainable cloud design is not only a moral poster. It is operational hygiene.
If you reduce idle compute, noisy logs, wasteful storage, and unnecessary data movement, you usually improve cost, reliability, and environmental impact at the same time.
What is the most surprising cloud waste you have found in a real project?
Top comments (0)