[Paper] Spatio-Temporal Shifting to Reduce Carbon, Water, and Land-Use Footprints of Cloud Workloads
Source: arXiv - 2512.08725v1
Overview
The paper explores how moving cloud workloads across different regions (spatial shifting) and different times of day (temporal shifting) can dramatically cut the environmental impact of cloud computing—specifically carbon emissions, water consumption, and land‑use footprints. By simulating real‑world traces from AWS and Azure, the authors show that smart placement and scheduling can slash these footprints by up to 85 % in the best cases.
Key Contributions
- Quantitative assessment of carbon, water, and land‑use savings achievable through spatial and temporal workload migration.
- Simulation framework that ingests real‑world provider data (regional grid mixes, water intensity, land‑use factors) and workload traces for big‑data analytics and Function‑as‑a‑Service (FaaS) apps.
- Empirical evidence that spatial shifting dominates the savings (20‑85 % reduction), while temporal shifting adds a modest but consistent incremental benefit.
- Robustness analysis showing that the savings hold up under grid‑mix prediction errors and seasonal variations.
- Multi‑objective optimization that lets operators prioritize carbon, water, or land‑use reduction according to business or regulatory goals.
Methodology
- Data Collection – Gathered regional sustainability metrics (CO₂ intensity, water withdrawal, land‑use impact) from public grid reports for AWS and Azure data‑center locations.
- Workload Traces – Used publicly available traces for two workload families: (a) batch big‑data analytics jobs, and (b) serverless FaaS functions with bursty request patterns.
- Simulation Engine – Built a discrete‑event simulator that maps each job to a region‑time slot, computes the associated environmental footprint, and enforces realistic constraints (e.g., latency, data‑gravity, SLA deadlines).
- Optimization Scenarios – Ran three sets of experiments: (i) spatial only, (ii) temporal only, and (iii) combined shifting, each optimized for one of the three footprints.
- Sensitivity Tests – Perturbed grid‑mix forecasts (±10 % error) and swapped seasonal profiles to gauge stability of the results.
Results & Findings
| Scenario | Carbon Reduction | Water Reduction | Land‑Use Reduction |
|---|---|---|---|
| Spatial only (carbon‑opt) | 55 % – 85 % | 48 % – 78 % | 42 % – 70 % |
| Temporal only (carbon‑opt) | 12 % – 28 % | 10 % – 25 % | 8 % – 22 % |
| Combined (carbon‑opt) | ≈ 90 % (spatial + temporal) | ≈ 85 % | ≈ 80 % |
- Spatial shifting consistently delivered the bulk of the savings because regional grid mixes vary widely (e.g., a Nordic data centre powered by hydro vs. a US‑South region reliant on coal).
- Temporal shifting helped when a region’s grid became greener during off‑peak hours (e.g., higher solar output at midday).
- The combined approach achieved the highest overall reductions, confirming that the two dimensions are complementary.
- Robustness: Even with 10 % mis‑prediction of grid carbon intensity, the average reduction only dropped by ~3 %, indicating practical resilience.
Practical Implications
- Cloud‑cost vs. sustainability trade‑offs: Many providers already expose “green” regions; this work suggests that integrating real‑time grid data into placement APIs can turn those options into measurable savings.
- Scheduler enhancements: Existing Kubernetes or serverless orchestrators can be extended with a “green‑score” plug‑in that prefers nodes/regions with lower instantaneous carbon/water intensity.
- SLA‑aware migration: For latency‑sensitive apps, the study shows that you can still reap benefits by limiting spatial moves to regions within a defined latency budget and using temporal windows for batch workloads.
- Corporate ESG reporting: Companies can leverage the methodology to generate more accurate carbon accounting for cloud‑based services, supporting sustainability certifications and carbon‑offset budgeting.
- Tooling opportunities: Open‑source libraries that fetch grid‑mix data (e.g., via the Electricity Map API) and expose them to cloud‑native schedulers could become a new class of “green‑ops” utilities.
Limitations & Future Work
- Simulation‑only: The study relies on modeled workloads and does not include live production deployments, so real‑world overheads (e.g., data transfer costs, cold‑start penalties) may differ.
- Data‑gravity constraints were simplified; tighter coupling between data location and compute could reduce the feasible spatial moves for some applications.
- Economic factors (price differentials across regions, spot‑instance availability) were not part of the optimization, yet they heavily influence production decisions.
- Future directions suggested by the authors include:
- Prototyping a live scheduler that integrates real‑time grid data.
- Extending the model to cover edge‑computing nodes.
- Exploring multi‑cloud arbitrage where workloads hop between providers to chase the greenest grid mix.
Authors
- Giulio Attenni
- Youssef Moawad
- Novella Bartolini
- Lauritz Thamsen
Paper Information
- arXiv ID: 2512.08725v1
- Categories: cs.DC
- Published: December 9, 2025
- PDF: Download PDF