SLA-Constrained Carbon-Aware Routing in Geo-Distributed Serverless Clouds

# SLA-Constrained Carbon-Aware Routing in Geo-Distributed Serverless Clouds
Source: [https://arxiv.org/html/2607.22806](https://arxiv.org/html/2607.22806)
Anmol ChaudharyandRahul MishraNational Institute of Advanced Manufacturing TechnologyRanchiIndia[rmishra@niamt\.ac\.in](https://arxiv.org/html/2607.22806v1/mailto:[email protected])

###### Abstract\.

Modern cloud deployments distribute applications across multiple geographic regions, yet standard routing mechanisms prioritize latency while ignoring the fluctuating carbon intensity of local power grids\. Latency\-driven routing incurs avoidable carbon emissions, particularly when cleaner regions are within acceptable latency bounds\. The proposed model formulates the carbon\-aware serverless routing problem as a constrained optimization over geo\-distributed cloud regions and introduces an SLA\-constrained carbon\-aware routing policy that achieves optimal carbon reduction within the SLA\-feasible region, evaluated using real carbon intensity measurements across 5 primary AWS deployments\. Experimental results show that the proposed policy achieves up to 46\.8% carbon reduction while maintaining zero SLA violations across all evaluated thresholds\. The system reduces carbon by an average of 27\.4% under mixed workloads, and the routing overhead is very low \(less than 0\.02% of total request latency\)\. A scalability study across 12 AWS regions spanning 6 continents demonstrates that average carbon savings increase from 27\.4% to 47\.5% as routing flexibility expands under mixed workloads\. The proposed work contributes to SDG 13 \(Climate Action\) and SDG 7 \(Affordable and Clean Energy\) by enabling low\-carbon routing decisions\. These results indicate that cloud systems can achieve significant carbon savings without compromising user experience\.

Carbon\-aware routing, Multi\-region cloud systems, Serverless Computing, Carbon footprint reduction\.

††copyright:none## 1\.Introduction

Cloud computing platforms are progressively relying on geographically distributed data centers and edge servers to reduce latency, improve performance, and meet the demands of global, real\-time applications\. Currently, the request routing decisions are primarily determined based on the latency requirements, which generally maps to the region closest to the users\. While the current approach provides the optimal end\-to\-end latency, it entirely ignores the carbon footprint of the selected region, i\.e\., the carbon intensity \(gCO2/kWh\) of the electricity grid powering that region’s data center at the time of execution\. As carbon intensity varies significantly across locations and time, latency\-only routing can result in avoidable carbon emissions even when cleaner alternatives exist within acceptable latency bounds\. Recently, researchers have explored the concept of green computing, which aims to reduce the carbon footprint of data centers\(Acun et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib2); Beloglazov and Buyya,[2010](https://arxiv.org/html/2607.22806#bib.bib6)\)\. While prior work has begun incorporating carbon awareness into serverless scheduling\(Qi et al\.,[2024](https://arxiv.org/html/2607.22806#bib.bib13); Chadha et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib7)\)and spatial shifting across VM and microservice infrastructure\(Souza et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib16); Christofidi et al\.,[2026](https://arxiv.org/html/2607.22806#bib.bib8); Maji et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib12)\), none of these systems simultaneously enforce per\-request SLA constraints as a hard feasibility boundary, operate on managed serverless platforms without infrastructure modification, and demonstrate deployment on real cloud infrastructure\.

### 1\.1\.Motivation & Contributions

The rapid growth of cloud\-native and serverless computing has created a significant impact on the carbon footprint of distributed computing\. Serverless computing has emerged as a dominant paradigm\. Scalability, cost\-effectiveness, and ease of development are major features of serverless computing\. Although technological and financial aspects are well understood, environmental implications are less explored\(Awwad et al\.,[2025](https://arxiv.org/html/2607.22806#bib.bib5)\)\. The increased need for computing and its infrastructure may lead to an increased carbon footprint\(Akour and Alenezi,[2025](https://arxiv.org/html/2607.22806#bib.bib3); Asadov et al\.,[2025](https://arxiv.org/html/2607.22806#bib.bib4)\)\.

Moreover, the carbon footprint of the electrical supply system varies significantly over different regions, depending on the diversity of the mix, penetration levels of renewable energy sources, and time\-of\-use patterns\. The variability in grid carbon intensity creates an opportunity to reduce the carbon footprint through intelligent request routing to regions with a smaller carbon footprint, while the latency requirements are satisfied properly to avoid the deterioration of the quality of service\.

The carbon footprint of cloud applications is not limited to compute; recent advancements have even begun exploring dynamic frequency scaling on network switches coupled with carbon\-aware routing to mitigate the emissions of wide\-area data transit itself\(Wang and Zilberman,[2025](https://arxiv.org/html/2607.22806#bib.bib18)\)\.

While carbon\-aware spatial shifting has been explored for persistent virtual machine and microservice infrastructure\(Souza et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib16); Christofidi et al\.,[2026](https://arxiv.org/html/2607.22806#bib.bib8)\), these systems are designed around long\-running, migratable workloads and treat latency as one term in a jointly weighted objective rather than as a hard service guarantee\. Serverless functions, by contrast, are short\-lived, stateless, and typically governed by strict per\-request latency SLAs that cannot be relaxed without directly degrading user\-facing quality of service\. The underlying distinction motivates a routing formulation in which the SLA is enforced as a hard feasibility constraint, and carbon is minimized only within the resulting feasible region, rather than traded off against latency through weighting\.

In the proposed work, the gap is addressed by proposing an SLA\-constrained carbon routing framework for serverless applications\. The core design principle is that, instead of routing to the closest region or the region with the lowest carbon footprint, the system first routes to the region that meets the latency requirement, then to the region with the lowest carbon intensity among them\. The approach ensures that carbon reduction is achieved only when it does not compromise user experience\(Sharma,[2023](https://arxiv.org/html/2607.22806#bib.bib15)\)\.

The proposed model is implemented and evaluated across 5 primary AWS regions, and a scalability study was performed up to 12 regions across 6 continents using real\-world carbon intensity data obtained from Electricity Maps and empirically measured network latencies\.

The 5 primary regions are selected to cover a wide range of carbon intensities and physical distances from the request’s source, and the additional 7 regions used in the scalability study are selected to provide coverage over all 6 populated continents, ensuring the evaluation is not limited to a geographically or climatically narrow subset\.

To systematically analyze the trade\-offs, five routing policies are compared:

1. \(1\)A baseline latency\-driven policy selecting the nearest region\.
2. \(2\)A carbon\-optimal policy that ignores latency constraints\.
3. \(3\)The proposed SLA\-aware carbon routing policy\.
4. \(4\)A cold start\-aware variant incorporating first\-invocation penalties\.
5. \(5\)A weighted\-scoring ablation baseline inspired by spatial\-shifting approaches such as CASPER\(Souza et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib16)\), used to isolate the effect of hard versus soft SLA enforcement\.

The proposed work contributes to Sustainable Development Goal \(SDG\) 13: Climate Action by reducing the carbon footprint of cloud applications through smart routing decisions\. Furthermore, it supports SDG 7: Affordable and Clean Energy by promoting the utilization of low\-carbon regions\.

The contributions of the proposed work are as follows:

1. \(1\)We formulate serverless request routing as an SLA constrained carbon minimization problem\. We propose an SLA\-constrained carbon\-aware routing policy that achieves up to 46\.8% carbon reduction with zero SLA violations\.
2. \(2\)The proposed work demonstrates that managed serverless platforms can achieve significant carbon savings without requiring modifications to application logic or cloud infrastructure\. It enables real\-world, deployment\-transparent sustainability\.
3. \(3\)Unlike prior spatial\-shifting systems targeting VM or microservice infrastructure, the proposed work enforces per\-request SLA feasibility as a hard constraint rather than as a weighted objective, as empirically demonstrated through a controlled ablation study\.
4. \(4\)We introduce an experimentally derived cold\-start penalty model \(α\\alpha= 0\.8\) based on real AWS Lambda first\-invocation measurements and show that the proposed policy remains robust under worst\-case cold\-start conditions\.
5. \(5\)Using a soft\-weighted baseline inspired by spatial\-shifting methods like CASPER\(Souza et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib16)\), we show that shifting to hard SLA filtering boosts carbon savings by up to 12\.8% while completely wiping out the high SLA violations caused by soft optimization\.

## 2\.Related Work

Carbon\-aware computing techniques for cloud infrastructure can be broadly organized along two axes: when a workload is executed \(temporal shifting\) and where it is executed \(spatial shifting\), with a more recent line of work addressing the distinct challenges posed by serverless execution\. Temporal approaches, including GREEN\(Xu et al\.,[2025](https://arxiv.org/html/2607.22806#bib.bib20)\), CarbonScaler\(Hanafy et al\.,[2024](https://arxiv.org/html/2607.22806#bib.bib10)\), and the limitations analysis by T\. Sukprasert et al\.\(Sukprasert et al\.,[2024](https://arxiv.org/html/2607.22806#bib.bib17)\)reduce carbon emissions by delaying batch workloads until low\-carbon periods\. However, such delay\-based strategies are fundamentally incompatible with latency\-sensitive applications governed by strict SLAs\.

Where temporal approaches are unsuitable, spatial shifting offers an alternative for latency\-sensitive workloads by relocating execution rather than delaying it\. Spatial shifting routes workloads to regions with lower carbon intensity, and systems such as CASPER\(Souza et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib16)\), Aceso\(Christofidi et al\.,[2026](https://arxiv.org/html/2607.22806#bib.bib8)\), and Caribou\(Gsteiger et al\.,[2024](https://arxiv.org/html/2607.22806#bib.bib9)\)model it as a multi\-objective optimization problem balancing carbon emissions and performance\. CASPER further incorporates service\-level objectives \(SLOs\) and maximum\-latency thresholds as constraints within its optimization\. However, recent work on multi\-cloud carbon\-aware routing operates at the level of virtual machines or microservices and does not address per\-request routing for serverless workloads under strict SLA constraints\(Maji et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib12)\)\.

Moreover, for carbon\-aware systems, geo\-distributed scheduling has generally addressed similar placement decisions for both performance and cost, but without considering carbon\-emissions objectives\. Geo\-distributed scheduling has been examined for performance, cost, and resource optimization, including approaches based on Lyapunov optimization\(Zhou et al\.,[2013](https://arxiv.org/html/2607.22806#bib.bib21)\)and reinforcement learning\. However, none of the mentioned work focuses on serverless computing and assumes that carbon emissions are a competing objective of latency in their models\.

Serverless computing introduces new challenges due to its event\-driven nature, i\.e\. cold start\. Existing work primarily focuses on mitigating cold starts and improving resource allocation\. Systems such as StepConf\(Wen et al\.,[2022](https://arxiv.org/html/2607.22806#bib.bib19)\), CASA\(Qi et al\.,[2024](https://arxiv.org/html/2607.22806#bib.bib13)\), and EcoLife\(Jiang et al\.,[2024](https://arxiv.org/html/2607.22806#bib.bib11)\)focus on performance and carbon\-aware scheduling, while GreenCourier\(Chadha et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib7)\)and GreenWhisk\(Serenari et al\.,[2024](https://arxiv.org/html/2607.22806#bib.bib14)\)explore carbon\-aware execution\. However, these systems are largely intra\-regional and often require modifications to underlying platforms, limiting their applicability to managed services such as AWS Lambda\. Also, the recent work explores multi\-objective optimization frameworks incorporating carbon, latency, and cost, often using reinforcement learning or microservice placement strategies such as Aceso\(Christofidi et al\.,[2026](https://arxiv.org/html/2607.22806#bib.bib8)\)\. However, none of these support per\-request routing in real\-world deployments\.

Thus, from the above, the significant key gaps can be identified: \(i\) reliance of existing systems on temporal shifting or relaxed latency constraints; \(ii\) geo\-distributed scheduling is tailored to persistent infrastructure; and \(iii\) lack of inter\-region, per\-request routing for serverless workloads\. The proposed work directly addresses these gaps by enabling SLA\-aware, per\-request, carbon\-efficient routing across regions for serverless workloads\. Unlike prior approaches, we enforce the SLA as a hard feasibility constraint rather than incorporating it as a weighted term in the optimization objective\. Furthermore, the proposed approach requires no modifications to the underlying infrastructure and is evaluated on real\-world latency and carbon\-intensity traces\.

Table[1](https://arxiv.org/html/2607.22806#S2.T1)compares existing work with the proposed system across six parameters: carbon awareness, SLA conformance, deployment realism, serverless support, per\-request routing, and infrastructure independence\. Among these, CASPER\(Souza et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib16)\)and Aceso\(Christofidi et al\.,[2026](https://arxiv.org/html/2607.22806#bib.bib8)\)are the prior systems that are simultaneously carbon\- and SLA\-aware\. However, neither targets the serverless execution model nor supports per\-request routing, and both require modifications to the underlying scheduling infrastructure\.

Table 1\.Comparison of Existing Carbon\-Aware Systems with the Proposed Framework across Key Architectural Dimensions
## 3\.System Design

The proposed framework enables carbon\-aware serverless request routing by combining latency\-aware region selection with real\-time carbon intensity data\. This section presents the system architecture, routing workflow, optimization model, and implementation details\.

### 3\.1\.System Overview

The proposed work introduces a carbon\-aware routing system for serverless applications across different cloud regions\. A request from the client is received at the API Gateway, which forwards it to a carbon\-aware router, implemented as an AWS Lambda function\. The router does not execute the actual computation\. Instead, it decides the best region for the execution of the function based on the latency requirements and carbon intensity\. If no region is found that meets the SLA \(Service Level Agreement\) requirements, the request is routed to the nearest region as a fallback\. The router is based on two key inputs: \(i\) a precomputed latency profile that includes the round\-trip time \(RTT\) from the client to each cloud region, and \(ii\) a carbon intensity dataset with an hourly update frequency\. Based on the above inputs, the router determines the target region and routes the request to an identical Lambda function running in that region\.

The end\-to\-end architecture of the proposed system is outlined in Figure[1](https://arxiv.org/html/2607.22806#S3.F1)\. Incoming client requests are routed through AWS API Gateway and then forwarded to the Carbon Aware Router Lambda function\. The routing decision is made based on the carbon intensity and the P95 latency profile in less than 0\.036ms\. The request is forwarded to one of the 5 geographically distributed AWS Lambda regions: Mumbai, Singapore, Sydney, Ireland, or Virginia, with a scalability study extended to 12 regions across 6 continents\. The response is returned directly to the client, bypassing the router entirely\.

![Refer to caption](https://arxiv.org/html/2607.22806v1/x1.png)Figure 1\.Architecture of the Proposed SLA\-Aware Carbon Routing Framework
### 3\.2\.Routing Decision

For each incoming request, the router extracts the SLA requirement and performs a constant\-time lookup on both the latency and carbon datasets\. LetRRdenote the set of all regions\. The router computes a feasible subset:

RS​L​A=\{r∈R∣L​\(r\)≤S​L​A\}R\_\{SLA\}=\\\{r\\in R\\mid L\(r\)\\leq SLA\\\}
Further, the selected regionr∗r^\{\*\}is computed as

r∗=arg⁡minr∈RS​L​A⁡C​\(r,t\)r^\{\*\}=\\arg\\min\_\{r\\in R\_\{SLA\}\}C\(r,t\)
The routing decision can be formally expressed as:

r∗≡\{arg⁡minr∈RS​L​A⁡C​\(r,t\)if​RS​L​A≠∅,arg⁡minr∈R⁡L​\(r\)otherwise\.r^\{\*\}\\equiv\\begin\{cases\}\\arg\\min\_\{r\\in R\_\{SLA\}\}C\(r,t\)&\\text\{if \}R\_\{SLA\}\\neq\\emptyset,\\\\ \\arg\\min\_\{r\\in R\}L\(r\)&\\text\{otherwise\.\}\\end\{cases\}
![Refer to caption](https://arxiv.org/html/2607.22806v1/x2.png)Figure 2\.SLA\-Aware Carbon Routing Decision WorkflowFigure[2](https://arxiv.org/html/2607.22806#S3.F2)describes the workflow of routing decisions of the proposed SLA\-aware carbon routing policy\. First, the router evaluates all candidate regions for each incoming request and creates a feasible set of regions with an SLA latency constraint based on P95 latency measurements\. If the feasible set is non\-empty, the router selects the region with the lowest carbon intensity at the current time\. In case where there is no feasible set, the fallback mechanism is employed for choosing the closest region to ensure the SLA is fulfilled\. The selected region will perform the request and reply back to the client\. The decision process is formally described in Algorithm[1](https://arxiv.org/html/2607.22806#algorithm1)\.

Input:Regions

RR, latency

L​\(r\)L\(r\), carbon intensity

C​\(r,t\)C\(r,t\), SLA

Output:Selected region

r∗r^\{\*\}
RS​L​A←\{r∈R∣L​\(r\)≤S​L​A\}R\_\{SLA\}\\leftarrow\\\{r\\in R\\mid L\(r\)\\leq SLA\\\};

if*RS​L​A=∅R\_\{SLA\}=\\emptyset*then

return

arg⁡minr∈R⁡L​\(r\)\\arg\\min\_\{r\\in R\}L\(r\);

//Fallback to nearest region

return

arg⁡minr∈RS​L​A⁡C​\(r,t\)\\arg\\min\_\{r\\in R\_\{SLA\}\}C\(r,t\);

Algorithm 1SLA\-Aware Carbon RoutingThe routing decision involves a single pass over the set of regions, resulting in a time complexity ofO​\(\|R\|\)O\(\|R\|\)\. As\|R\|\|R\|is small and bounded in our scenario, the decision process runs in constant time with negligible overhead\.

### 3\.3\.Problem Formulation

The routing decision is treated as a constrained optimization problem on a set of regionsRR\. For each incoming request, the goal is to minimize the carbon intensity under a constraint on the latency requirement\.

Let:

- •L​\(r\)L\(r\)denote the P95 latency to regionrr
- •C​\(r,t\)C\(r,t\)denote the carbon intensity of regionrrat timett
- •S​L​ASLAdenote the latency constraint for the request

The routing decision is formulated as:

\(1\)minr∈R⁡C​\(r,t\)\\min\_\{r\\in R\}\\;C\(r,t\)
subject to:

\(2\)L​\(r\)≤S​L​AL\(r\)\\leq SLA
If no region satisfies the SLA constraint, the system falls back to selecting the region with minimum latency:

\(3\)r∗=arg⁡minr∈R⁡L​\(r\)r^\{\*\}=\\arg\\min\_\{r\\in R\}L\(r\)
The formulation ensures that carbon optimization is performed only within the feasible latency region, preserving user experience\.

By treating the SLA as a hard feasibility boundary rather than a weighted objective, the formulation guarantees zero SLA violations by construction whenever a feasible region exists\.

### 3\.4\.Implementation Details

The Carbon Aware Router is implemented as a lightweight AWS Lambda function running in the Mumbai region\. The carbon intensity data is locally cached from a precomputed dataset from Electricity Maps \(January 2025\), eliminating runtime API dependency and enabling low\-latency routing\. Real\-time carbon feed integration is identified as a direction for future work\.

The routing decision is implemented using a lightweight, in\-memory evaluation over precomputed latency and carbon profiles, enabling efficient per\-request carbon optimization with negligible routing overhead\.

As shown in section[5](https://arxiv.org/html/2607.22806#S5), the latency of decision remains below 0\.036 ms \(P99\) and represents less than 0\.02% of the end\-to\-end latency\. The same workload function is used across all regions to ensure consistent execution and fair comparison\. The deployed function performs a fixed\-cost JSON echo to verify the measured differences across policies reflect routing decisions rather than workload variance\.

To simulate the realistic traffic, a mixed workload across 5 SLA categories is evaluated: real\-time \(300 ms\), interactive \(500 ms\), moderate \(800 ms\), relaxed \(1000 ms\), and batch \(3000 ms\), each routed independently based on latency constraints and carbon intensity\.

## 4\.Experimental Setup

The evaluation of the proposed routing framework utilizes geographically distributed AWS regions, real\-world carbon intensity data, and p95 latency profiles\. The section outlines the deployment infrastructure, latency measurement methodology, workload configuration, and the various routing policies implemented to evaluate the effectiveness of the proposed approach\.

### 4\.1\.Deployment Infrastructure and Carbon Intensity Data

Experiments have been performed on Amazon Web Services \(AWS\) leveraging 5 geographic regions: ap\-south\-1 \(Mumbai\), ap\-southeast\-1 \(Singapore\), ap\-southeast\-2 \(Sydney\), eu\-west\-1 \(Ireland\), and us\-east\-1 \(Virginia\)\. These 5 regions were selected to cover a wide range of network distances and grid carbon intensities relative to the request origin\. In all of these regions, the same serverless function has been instantiated using AWS Lambda with Python 3\.13 and 128 MB memory\. The function performs a lightweight task, ensuring consistent execution across regions\. For the scalability study, the same function was additionally deployed across seven more regions: eu\-north\-1 \(Stockholm\), ap\-northeast\-2 \(Seoul\), af\-south\-1 \(Cape Town\), eu\-central\-1 \(Frankfurt\), sa\-east\-1 \(São Paulo\), ap\-northeast\-1 \(Tokyo\), and us\-west\-2 \(Oregon\), spanning 6 continents in total\. These additional regions were chosen to extend continental coverage rather than to further refine carbon\-intensity granularity within any single region already represented\.

Table 2\.Experimental SetupTable[2](https://arxiv.org/html/2607.22806#S4.T2)highlights the experimental setup, including the cloud architecture, dataset properties, simulation settings, and Scalability Study\. The carbon intensity values for each region have been obtained from the Electricity Maps Dataset\. The dataset comprises hourly carbon intensity measurements \(gCO2/kWh\) for January 2025, yielding a total of 744 data points for each region\.

### 4\.2\.Latency Measurement

For each region, the latency between the client and server was calculated by directly invoking the AWS Lambda function using the boto3 library\. Instead of the mean value, the P95 value of the round\-trip\-time distribution is used throughout the study for SLA filtering, as it captures tail latency and provides a more conservative basis for ensuring SLA compliance\. For each region, 20 invocations were made, and their RTTs were recorded after excluding the cold\-start effect\. The measured P95 round\-trip latencies for the 5 primary AWS regions were: Mumbai \(ap\-south\-1\) 196 ms, Singapore \(ap\-southeast\-1\) 367 ms, Sydney \(ap\-southeast\-2\) 634 ms, Ireland \(eu\-west\-1\) 979 ms, and Virginia \(us\-east\-1\) 1491 ms\. These values reflect significant geographical variation and form the basis for SLA filtering in the routing decision\.

For the 7 additional regions, P95 latency values were rounded to the nearest 10 ms, as these regions were included solely for routing\-pool scalability analysis rather than fine\-grained SLA\-threshold sensitivity evaluation\. The corresponding P95 latencies were: Tokyo \(ap\-northeast\-1\) 600 ms, Seoul \(ap\-northeast\-2\) 620 ms, Frankfurt \(eu\-central\-1\) 720 ms, Stockholm \(eu\-north\-1\) 780 ms, Cape Town \(af\-south\-1\) 950 ms, Oregon \(us\-west\-2\) 1050 ms, and São Paulo \(sa\-east\-1\) 1150 ms\.

Cold\-start exclusion was performed by discarding the first invocation of each measurement session and computing the P95 RTT over the remaining 19 invocations\. The discarded first\-invocation values were retained separately as cold\-start penalty measurements for Policy C\+, rather than being excluded from the dataset entirely\. The measured first\-invocation latencies were: Mumbai 423ms, Singapore 391ms, Sydney 952ms, Ireland 1108ms, and Virginia 1626ms\. Similarly, first\-invocation latencies for the seven scalability regions were measured using the same methodology and, where applicable, incorporated into the cold\-start penalty model\. Across all five regions and 20 invocations per region, cold start overhead was observed in 78–83% of first\-invocation attempts following a period of inactivity, yielding a mean cold start occurrence rate of 0\.80\. The mean cold\-start occurrence rate of 0\.80 is used as the conservatism parameterα=0\.8\\alpha=0\.8in Policy C\+, ensuring that effective latency is never underestimated during region transitions\.

### 4\.3\.Workload and Simulation

Routing performance is evaluated using simulated request workloads derived from the collected carbon and latency datasets\. For each SLA threshold \(300 ms, 500 ms, 800 ms, 1000 ms, and 3000 ms\), 1000 requests were generated per run, and each experiment was repeated 30 times \(n = 30,000 routing decisions per SLA threshold per policy\) to ensure statistical reliability\. Additionally, a mixed workload scenario consisting of 5000 requests per run was evaluated over 30 repetitions \(n = 150,000 routing decisions\), with requests distributed across SLA categories to reflect realistic traffic patterns\.

### 4\.4\.Routing Policies

To assess the performance of the carbon\-aware routing, five different routing policies are evaluated as comparators against the proposed approach:

1. \(1\)Policy A \(Latency\-Optimal Baseline\):In Policy A, the requests are routed to the region that is nearest to the source \(Mumbai in our case\)\. Here, requests are minimizing latency but ignoring variations in carbon intensity across regions\.
2. \(2\)Policy B \(Carbon\-Optimal\):In Policy B, the requests are routed to the region with the lowest carbon intensity\. The requests are directed to the region that minimizes the carbon intensity, irrespective of the latency constraint\. It achieves maximum carbon savings but may lead to SLA violations\.
3. \(3\)Policy C \(SLA\-Aware Carbon Routing, Proposed\):Requests are routed to the carbon\-minimizing region only within the SLA\-feasible subset, in two phases: \(1\)SLA Feasibility Filtering:candidate regions with P95 latency exceeding the per\-request SLA threshold are eliminated, restricting routing to the latency\-feasible set; \(2\)Carbon\-Optimal Selection:among feasible regions, the one with minimum instantaneous carbon intensityC​\(r,t\)C\(r,t\)is selected, ensuring carbon reduction without violating service\-level guarantees\.
4. \(4\)Policy C\+ \(Cold Start\-Aware Carbon Routing\):Policy C\+ builds on Policy C by incorporating cold start penalties derived from measured first\-invocation latencies\. The effective latency is calculated as: \(4\)Leff​\(r\)=Lmeasured​\(r\)\+α⋅Tcold​\(r\)L\_\{\\text\{eff\}\}\(r\)=L\_\{\\text\{measured\}\}\(r\)\+\\alpha\\cdot T\_\{\\text\{cold\}\}\(r\)whereTcold​\(r\)T\_\{\\text\{cold\}\}\(r\)is the empirically measured first\-invocation latency for regionrr, andα∈\[0,1\]\\alpha\\in\[0,1\]is a conservatism parameter set to0\.80\.8, derived from the observed cold start occurrence rate of 78–83% across first\-invocation measurements in all 5 AWS regions\. The conservative fixed value prevents the system from underestimating latency during region changes\. It also prevents temporary increases in latency from causing SLA violations\.
5. \(5\)Policy D \(Soft Weighted\-Scoring Ablation\):Policy D implements a weighted scoring method based on carbon and latency\. It is inspired by spatial\-shifting framework such as CASPER\(Souza et al\.,[2023](https://arxiv.org/html/2607.22806#bib.bib16)\), but intentionally avoids strict SLA enforcement to isolate the effect of constraint enforcement against soft weighting, serving as a controlled ablation rather than a baseline comparison\. The routing score is computed as: \(5\)Score​\(r\)=w⋅Cnorm​\(r\)\+\(1−w\)⋅Lnorm​\(r\)\\text\{Score\}\(r\)=w\\cdot C\_\{\\text\{norm\}\}\(r\)\+\(1\-w\)\\cdot L\_\{\\text\{norm\}\}\(r\)wherew=0\.5w=0\.5, andCnorm​\(r\)C\_\{\\text\{norm\}\}\(r\)andLnorm​\(r\)L\_\{\\text\{norm\}\}\(r\)are normalized carbon and latency values\. The region with the minimum score is selected\.

The primary evaluation metric is carbon intensity \(gCO2/kWh\) associated with each routed request\. Secondary metrics are the SLA violation rate and routing overhead\. Statistical analysis is performed using the Mann\-Whitney U test \(p<0\.05p<0\.05\), which is applicable to non\-normally distributed data \(latency and carbon footprint\)\. Results are reported as mean values over 30 independent runs per condition\.

## 5\.Results and Evaluation

To experimentally evaluate the proposed SLA\-aware carbon routing framework, real\-world carbon intensity data and p95 latency profiles are used\. The analysis covers carbon intensity, carbon savings across different SLA thresholds, routing behavior, statistical validation, mixed workload performance, scalability, and routing overhead\.

### 5\.1\.Carbon Intensity Variation

![Refer to caption](https://arxiv.org/html/2607.22806v1/images/graph1_without_title.png)Figure 3\.Carbon Intensity Heatmap Across Five AWS Regions for January 2025 \(Hourly\)![Refer to caption](https://arxiv.org/html/2607.22806v1/images/graph2_24h_profile_without_title.png)Figure 4\.Average Carbon Intensity by Hour of Day, Averaged Across January 2025 — A Condensed View of the Daily Pattern\.Analysis of carbon intensity variation across regions reveals significant regional and temporal differences\. Figures[3](https://arxiv.org/html/2607.22806#S5.F3)and[4](https://arxiv.org/html/2607.22806#S5.F4)both illustrate temporal and geographical variability in carbon intensity across AWS regions for January 2025\. Where Figure[3](https://arxiv.org/html/2607.22806#S5.F3)presents the full hourly dataset across all 744 hours, while Figure[4](https://arxiv.org/html/2607.22806#S5.F4)condenses it into a daily\-averaged profile to make the relative regional ranking easier to compare at a glance\. Ireland consistently maintains the lowest carbon intensity due to higher renewable energy contributions, while Mumbai records the highest values\. Sydney exhibits noticeable variability, whereas Virginia and Singapore remain relatively stable\. These observations confirm that carbon intensity varies significantly across both regions and time, reinforcing the need for carbon\-aware routing over static nearest\-region selection\.

### 5\.2\.Carbon Savings vs SLA Threshold

As the SLA threshold increases, the carbon savings in the proposed policy C increase gradually\. At stringent latency requirements \(300 ms\), there is no substantial gain in carbon savings because the Mumbai area is the only one that satisfies the SLA requirement\. With relaxed SLA constraints, more regions meet the requirement, enabling more carbon savings through carbon\-aware routing decisions\.

![Refer to caption](https://arxiv.org/html/2607.22806v1/images/graph9_pareto_curve.png)Figure 5\.Pareto Analysis: Trade\-off Between Latency and Carbon Saving Across Five Routing Policies for five primary AWS regionsFigure[5](https://arxiv.org/html/2607.22806#S5.F5)represents a Pareto analysis of the carbon saving vs effective latency tradeoff across all five policies\. A point is Pareto\-optimal if no alternative achieves higher carbon savings at equal or lower latency without SLA violations\. Policy C occupies positions on the Pareto frontier at two distinct operating points as \(308 ms, 30\.3%\) and \(615 ms, 46\.5%\)\. It demonstrates that no other evaluated policy achieves a superior carbon\-latency tradeoff within SLA bounds\. Policy D, despite achieving 33\.7% carbon savings, lies strictly below the frontier\. Policy C achieves comparable or higher savings at both lower and higher latency points while guaranteeing zero SLA violations\.

For example, at an SLA level of 1000 ms, Policy C achieves a reduction of 46\.5% in carbon, while at 3000 ms, Policy C’s reduction reaches 46\.8%, approaching the theoretical maximum\. Across all SLA thresholds, Policy C maintains 0% SLA violations, reflecting that carbon savings can be achieved without compromising user experience\.

To ensure robustness with realistic deployment considerations, Policy C\+ uses empirical measurements of cold start penalties as inputs to the latency model\. In Figure[6](https://arxiv.org/html/2607.22806#S5.F6), it can be seen that Policy C\+ is the same as Policy C when the latency threshold is either 300 ms or 3000 ms\. For other values of the threshold, cold start penalties limit routing options\. For instance, with an SLA of 1000 ms, Ireland experiences latency greater than the SLA with a cold start, thus making 81\.3% of requests go to Singapore\. Consequently, Policy C\+ achieves 24\.3% carbon savings at 1000 ms compared to 46\.5% for Policy C, while maintaining zero SLA violations across all thresholds\. These results represent a conservative lower bound, as the fixedα\\alpha= 0\.8 assumption intentionally overestimates cold start penalty to guarantee zero SLA violations even during worst\-case region transitions\. In production deployments where target regions receive sustained traffic and remain warm, actual C\+ savings would exceed those reported here\.

![Refer to caption](https://arxiv.org/html/2607.22806v1/images/graph3_savings_curve_updated.png)Figure 6\.Carbon Savings Trend Across SLA Thresholds, Illustrating the Divergence Between Hard\-Constraint \(Policy C\) and Soft\-Scoring \(Policy D\) Strategies as Latency Tolerance IncreasesFigure[6](https://arxiv.org/html/2607.22806#S5.F6)represents carbon footprint savings from each policy with respect to the baseline policy \(Policy A\) that always has the nearest constraint applied\. In case of policy C, savings increase with the reduction of SLA constraints, whereas policy C\+ denotes the impact of cold start penalties at intermediate thresholds\. Policy D yields constant savings of about 33\.7%; however, it incurs significant SLA violations \(81\.9% at 300 ms, 24\.3% at 500 ms, and 21\.9% at 800 ms\), indicating that weighted scoring without strict latency constraints is unsuitable for latency\-sensitive applications\. In contrast to Policy D, which violates SLA constraints under stricter thresholds, Policy C ensures zero SLA violations while achieving higher carbon savings at relaxed SLA levels\.

Table 3\.Carbon Savings and SLA Compliance Across Five Routing Policies \(Mean±\\pmStd over 30 runs,n=n=30,000 routing decisions per SLA threshold per policy\)SLARequestPolicy APolicy CSaving CPolicy C\+Saving C\+Policy DSaving DD Violationp\-value\(ms\)Type\(gCO2/kWh\)\(gCO2/kWh\)\(%\)\(gCO2/kWh\)\(%\)\(gCO2/kWh\)\(%\)\(%\)\(C vs A\)300Real\-Time485\.9485\.90\.0±0\.000\.0\\pm 0\.00485\.90\.00\.0322\.733\.781\.920\.5030 \(N/S\)500Interactive486\.3368\.224\.1±0\.2824\.1\\pm 0\.28373\.623\.423\.4323\.033\.624\.33<<0\.0001800Moderate485\.9339\.130\.3±0\.3530\.3\\pm 0\.35369\.824\.224\.2322\.433\.621\.87<<0\.00011000Relaxed485\.9260\.246\.5±0\.4146\.5\\pm 0\.41368\.824\.324\.3322\.733\.70\.00<<0\.00013000Batch485\.5258\.346\.8±0\.5646\.8\\pm 0\.56258\.346\.846\.8321\.933\.70\.00<<0\.0001Table[3](https://arxiv.org/html/2607.22806#S5.T3)presents carbon savings and SLA compliance across all routing policies relative to the always\-nearest baseline \(Policy A\)\. The results show that Policy C achieves substantial carbon reductions while maintaining zero SLA violations across all thresholds, whereas Policy D attains moderate savings at the cost of significant SLA violations under stricter latency constraints\. Policy C\+ reflects the impact of cold start penalties, particularly at intermediate SLA levels\. Overall, the table highlights the trade\-off between carbon efficiency and SLA guarantees\. Standard deviation is reported for Policy C as the primary evaluation metric, whereas Policy C\+ represents a deterministic worst\-case bound under cold start assumptions \(α=0\.8\\alpha=0\.8\) and thus exhibits negligible variance by construction\.

Stricter SLA requirements limit the flexibility of routing, necessitating a selection of geographically closer but more carbon\-intensive regions\. With relaxed SLA requirements, less carbon\-intensive regions are now feasible, enabling greater emission reductions\.

### 5\.3\.Statistical Validation

Consistency across multiple runs is evaluated, and the results show low variance in carbon savings, indicating high stability\. The Mann–Whitney U test validates the significant improvement for all thresholds greater than 300 ms \(p<0\.0001p<0\.0001\), computed overn=30n=30independent runs per policy per SLA threshold \(30,000 routed requests per condition\. For 300 ms, no significant difference is observed \(p=0\.5030p=0\.5030\), since there is only one region that meets the SLA requirement\.

![Refer to caption](https://arxiv.org/html/2607.22806v1/images/graph4_cdf_without_title.png)Figure 7\.Cumulative Distribution Functions of Carbon Saving and SLA Violation RateFigure[7](https://arxiv.org/html/2607.22806#S5.F7)displays the CDF of carbon savings and SLA violation\. Policy C shows highly consistent savings with zero SLA violations across all runs, while Policy B exhibits non\-zero violations\.

### 5\.4\.Routing Behavior Across Regions

Routing decisions depend on the SLA threshold\. Under a strict SLA, routing will be done for regions close to the user\. As the SLA constraints relax, routing will take place from lower\-carbon\-emitting regions like Singapore and Ireland, reflecting adaptive behavior\.

![Refer to caption](https://arxiv.org/html/2607.22806v1/images/graph5_routing_distribution.png)Figure 8\.Routing Distribution Across AWS Regions Under Policy C \(SLA\-Aware Routing\)Figure[8](https://arxiv.org/html/2607.22806#S5.F8)depicts the region\-wise distribution of requests\. When the delay is 300 ms, routing will be done only to Mumbai\. For a less strict SLA, routing will go to Singapore and Ireland, reflecting dynamic adaptation to latency and carbon conditions\.

### 5\.5\.Mixed Workload Evaluation

To evaluate real\-world robustness, mixed workloads with heterogeneous SLA requirements are simulated\. Under the scenario, the proposed Policy C mitigates carbon emissions by an average of 27\.4% ± 0\.27% while ensuring zero SLA violations\. It indicates a weighted aggregation of savings across different SLA classes and effectiveness under realistic traffic conditions\.

![Refer to caption](https://arxiv.org/html/2607.22806v1/images/graph7_requests_per_zone_without_titl_reduced.jpeg)Figure 9\.Request Distribution per AWS Region Under Mixed Traffic Workload, Stacked by SLA TypeAs illustrated in Figure[9](https://arxiv.org/html/2607.22806#S5.F9), real\-time requests are directed to Mumbai, interactive and moderate loads to Singapore, and relaxed and batch requests primarily to Ireland, yielding 27\.4% ± 0\.27% carbon reduction with zero SLA violations across 150,000 requests\.

Table 4\.Mixed Workload Routing Distribution and Carbon SavingsSLA TypeTrafficReqsPrimary RegionSavingReal\-Time \(300ms\)20%990Mumbai \(100%\)0\.0%Interactive \(500ms\)30%1,497Singapore \(96\.1%\)24\.3%Moderate \(800ms\)20%1,006Singapore \(61\.8%\)\+ Sydney \(34\.4%\)24\.3–30\.2%Relaxed \(1000ms\)20%1,005Ireland \(67\.0%\)46\.8%Batch \(3000ms\)10%503Ireland \(63\.5%\)46\.8%Overall100%5,000Dynamic27\.4%±\\pm0\.27%

Table[4](https://arxiv.org/html/2607.22806#S5.T4)shows the routing distribution and carbon savings across mixed workload conditions\. It illustrates how the proposed approach adapts to heterogeneous SLA requirements while maintaining consistent performance\.

### 5\.6\.Routing Overhead

Finally, the computational overhead introduced by the routing decision process is evaluated\. The routing decision leverages a lightweight, in\-memory evaluation over precomputed latency and carbon profiles, resulting in negligible overhead\. The maximum decision\-observed time was just 0\.036 ms \(P99\), accounting for less than 0\.02% of the entire latency of each request\. It confirms that the proposed approach is lightweight and practical for real\-world deployment\.

### 5\.7\.Comparative Analysis Against CASPER Baseline

The proposed method is benchmarked against Policy D, a weighted\-scoring ablation structurally inspired by spatial\-shifting approaches such as CASPER, which optimizes carbon emissions without applying hard SLA constraints\. The comparison is intended to isolate the effect of constraint enforcement rather than to serve as a faithful reimplementation of CASPER, which incorporates SLO and latency constraints as a first\-class part of its own optimization\. As shown in Table[3](https://arxiv.org/html/2607.22806#S5.T3), Policy D achieves a consistent carbon reduction of 33\.7% across all SLA thresholds but incurs SLA violations under strict latency constraints\. Policy C, in contrast, achieves zero SLA violations at all thresholds\.

One limitation of soft optimization techniques is that routing decisions may violate latency requirements without explicit constraints, whereas Policy C provides hard SLA guarantees at all levels\. Policy C outperforms Policy D in carbon reduction while service reliability is maintained for looser SLA demands \(1000 ms and higher\) which shows the strength of filter\-then\-minimize strategy for latency\-sensitive applications against weighted scoring methods\.

### 5\.8\.Scalability Analysis

To evaluate scalability, the deployment is extended from 5 to 12 AWS regions spanning 6 continents under mixed workload conditions\. The AWS regions augmentations improves mean carbon savings from 27\.4% ± 0\.27% to 47\.5% ± 0\.11% \(a 20\.1 percentage point gain\) while maintaining zero SLA violations\. The observed improvement results from enhanced routing flexibility, which allows access to geographically distant, low\-carbon regions under relaxed latency constraints\. Conversely, performance under strict service\-level agreement \(SLA\) thresholds remains unchanged due to inherent latency limitations, indicating that scalability does not compromise strict SLA guarantees\. Stockholm \[eu\-north\-1\], with an approximate carbon intensity of 15 \(gCO2/kWh\), is a significant contributor to these gains\. The analysis expands the routing pool rather than evaluating algorithmic scalability; the routing decision remainsO​\(\|R\|\)O\(\|R\|\)and completes in under 0\.036 ms regardless of the number of regions\.

![Refer to caption](https://arxiv.org/html/2607.22806v1/images/graph10_scaling_analysis.png)Figure 10\.Scalability Analysis: Mixed Workload Carbon Saving as AWS Regions Scale from 5 to 12 Across 6 Continents\.Figure[10](https://arxiv.org/html/2607.22806#S5.F10)shows the distribution of mixed workload carbon savings over 30 runs\. Increasing the number of AWS regions from 5 to 12, augmenting the mean carbon saving from 27\.4% ± 0\.27% to 47\.5% ± 0\.11%, reflecting the consistent gains with low variance and zero SLA violations\. At strict SLAs \(300\-500 ms\), the improvements are small due to the latency constraints, but at relaxed thresholds \(800\-3000 ms\), the improvements grow significantly as more low\-carbon regions, like Stockholm, become eligible\. These results confirm that the proposed framework scales efficiently with infrastructure expansion while ensuring SLA guarantees for all latency thresholds\.

## 6\.Conclusion and Future Directions

The proposed work focuses on an SLA\-aware carbon\-routing framework for serverless applications deployed across geographically distributed cloud regions\. Unlike conventional latency\-aware routing, the proposed model treats SLA constraints as a hard feasibility boundary rather than a weighted objective function\. The proposed model selects the least carbon\-intensive region within the feasible set while satisfying per\-request SLA constraints\. The framework is evaluated across 5 AWS regions and further extended to 12 regions using real\-world carbon and latency data, spanning 6 continents\. It achieves carbon savings of up to 46\.8% with an average of 27\.4% under mixed workloads, with zero SLA violations and negligible overhead\. Additionally, it achieves up to 47\.5% carbon savings with expanded routing flexibility\. A cold start\-aware variant \(Policy C\+\) maintains zero SLA violations while maintaining substantial carbon savings\. These results show that significant carbon savings can be achieved without modifying application or infrastructure logic\. However, the current evaluation relies on static carbon datasets and fixed workload intensity\. It provides per\-decision feasibility guarantees but does not establish formal bounds on long\-term carbon optimality\.

Future work includes introducing real\-time carbon and latency measurements, performance analysis under dynamic workloads, cost\-carbon analysis, improvement in cold\-start management, deployment of the proposed framework to multi\-cloud and edge computing environments, and validation of the approach across geographically diverse client locations\.

## References

- \(1\)
- Acun et al\.\(2023\)Bilge Acun, Benjamin Lee, Fiodar Kazhamiaka, Kiwan Maeng, Udit Gupta, Manoj Chakkaravarthy, David Brooks, and Carole\-Jean Wu\. 2023\.Carbon explorer: A holistic framework for designing carbon aware datacenters\. In*Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2*\. 118–132\.
- Akour and Alenezi \(2025\)Mohammed Akour and Mamdouh Alenezi\. 2025\.Reducing environmental impact with sustainable serverless computing\.*Sustainability*17, 7 \(2025\), 2999\.
- Asadov et al\.\(2025\)Nasir Asadov, Vlad C Coroamă, Matteo Franzil, Stefano Galantino, and Matthias Finkbeiner\. 2025\.Carbon\-aware spatio\-temporal workload shifting in edge–cloud environments: A review and novel algorithm\.*Sustainability*17, 14 \(2025\), 6433\.
- Awwad et al\.\(2025\)Hanan Awwad, Changyuan Lin, Rabab Ward, and Mohammad Shahrad\. 2025\.Estimating the Carbon Footprint of Serverless Functions on a Public Cloud Platform\. In*Proceedings of the 3rd Workshop on SErverless Systems, Applications and MEthodologies*\. 12–20\.
- Beloglazov and Buyya \(2010\)Anton Beloglazov and Rajkumar Buyya\. 2010\.Energy efficient resource management in virtualized cloud data centers\. In*2010 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing*\. IEEE, 826–831\.
- Chadha et al\.\(2023\)Mohak Chadha, Thandayuthapani Subramanian, Eishi Arima, Michael Gerndt, Martin Schulz, and Osama Abboud\. 2023\.Greencourier: Carbon\-aware scheduling for serverless functions\. In*Proceedings of the 9th International Workshop on Serverless Computing*\. 18–23\.
- Christofidi et al\.\(2026\)Georgia Christofidi, Francisco Álvarez\-Terribas, Ioannis Roumpos, Nicolas Kourtellis, Jesus Omaña Iglesias, and Thaleia Dimitra Doudali\. 2026\.Aceso: Carbon\-Aware and Cost\-Effective Microservice Placement for Small and Medium\-sized Enterprises\.*arXiv preprint arXiv:2603\.10768*\(2026\)\.
- Gsteiger et al\.\(2024\)Viktor Urban Gsteiger, Pin Hong Long, Yiran Sun, Parshan Javanrood, and Mohammad Shahrad\. 2024\.Caribou: Fine\-grained geospatial shifting of serverless applications for sustainability\. In*Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles*\. 403–420\.
- Hanafy et al\.\(2024\)Walid A Hanafy, Qianlin Liang, Noman Bashir, David Irwin, and Prashant Shenoy\. 2024\.CarbonScaler: leveraging cloud workload elasticity for optimizing carbon\-efficiency\. In*Abstracts of the 2024 ACM SIGMETRICS/IFIP PERFORMANCE Joint International Conference on Measurement and Modeling of Computer Systems*\. 49–50\.
- Jiang et al\.\(2024\)Yankai Jiang, Rohan Basu Roy, Baolin Li, and Devesh Tiwari\. 2024\.Ecolife: Carbon\-aware serverless function scheduling for sustainable computing\. In*SC24: International Conference for High Performance Computing, Networking, Storage and Analysis*\. IEEE, 1–15\.
- Maji et al\.\(2023\)Diptyaroop Maji, Ben Pfaff, Vipin PR, Rajagopal Sreenivasan, Victor Firoiu, Sreeram Iyer, Colleen Josephson, Zhelong Pan, and Ramesh K Sitaraman\. 2023\.Bringing carbon awareness to multi\-cloud application delivery\. In*Proceedings of the 2nd Workshop on Sustainable Computer Systems*\. 1–6\.
- Qi et al\.\(2024\)Sirui Qi, Hayden Moore, Ninad Hogade, Dejan Milojicic, Cullen Bash, and Sudeep Pasricha\. 2024\.Casa: A framework for slo\-and carbon\-aware autoscaling and scheduling in serverless cloud computing\. In*2024 IEEE 15th International Green and Sustainable Computing Conference \(IGSC\)*\. IEEE, 1–6\.
- Serenari et al\.\(2024\)Jayden Serenari, Sreekanth Sreekumar, Kaiwen Zhao, Saurabh Sarkar, and Stephen Lee\. 2024\.GreenWhisk: Emission\-aware computing for serverless platform\. In*2024 IEEE International Conference on Cloud Engineering \(IC2E\)*\. IEEE, 44–54\.
- Sharma \(2023\)Prateek Sharma\. 2023\.Challenges and opportunities in sustainable serverless computing\.*ACM SIGENERGY Energy Informatics Review*3, 3 \(2023\), 53–58\.
- Souza et al\.\(2023\)Abel Souza, Shruti Jasoria, Basundhara Chakrabarty, Alexander Bridgwater, Axel Lundberg, Filip Skogh, Ahmed Ali\-Eldin, David Irwin, and Prashant Shenoy\. 2023\.Casper: Carbon\-aware scheduling and provisioning for distributed web services\. In*Proceedings of the 14th International Green and Sustainable Computing Conference*\. 67–73\.
- Sukprasert et al\.\(2024\)Thanathorn Sukprasert, Abel Souza, Noman Bashir, David Irwin, and Prashant Shenoy\. 2024\.On the limitations of carbon\-aware temporal and spatial workload shifting in the cloud\. In*Proceedings of the Nineteenth European Conference on Computer Systems*\. 924–941\.
- Wang and Zilberman \(2025\)Zhukun Wang and Noa Zilberman\. 2025\.NetFridgeS: Enabling Dynamic Frequency Scaling on Network Switches through Carbon\-Aware Routing\.*Proceedings of the ACM on Networking*3, CoNEXT4 \(2025\), 1–20\.
- Wen et al\.\(2022\)Zhaojie Wen, Yishuo Wang, and Fangming Liu\. 2022\.StepConf: SLO\-aware dynamic resource configuration for serverless function workflows\. In*IEEE INFOCOM 2022\-IEEE conference on computer communications*\. IEEE, 1868–1877\.
- Xu et al\.\(2025\)Kaiqiang Xu, Decang Sun, Han Tian, Junxue Zhang, and Kai Chen\. 2025\.\{\\\{GREEN\}\\\}: Carbon\-efficient Resource Scheduling for Machine Learning Clusters\. In*22nd USENIX Symposium on Networked Systems Design and Implementation \(NSDI 25\)*\. 999–1014\.
- Zhou et al\.\(2013\)Zhi Zhou, Fangming Liu, Yong Xu, Ruolan Zou, Hong Xu, John CS Lui, and Hai Jin\. 2013\.Carbon\-aware load balancing for geo\-distributed cloud services\. In*2013 IEEE 21st International Symposium on Modelling, Analysis and Simulation of Computer and Telecommunication Systems*\. IEEE, 232–241\.