Bridging the sustainability gap in serverless through observability and carbon-aware pricing

Serverless applications can have a significant carbon footprint depending on configurations and underlying infrastructure [41, 64, 65]. Also, the increasing popularity of artificial intelligence and serverless model serving will generally increase the carbon footprint of serverless further [22, 44, 52].

Currently, serverless developers do not have access to meaningful carbon metrics due to the absence of fine-grained observability frameworks. Tools available on public cloud platforms, such as Customer Carbon Footprint Tool [8] and Emissions Impact Dashboard [7], only provide coarse-grained carbon metrics (e.g., per-region and per-service) with limited observability. While recent studies and open-source projects have proposed several models and tools to capture the carbon footprint of software systems [18, 36, 46], they are not effective in capturing and modeling the carbon emissions of serverless functions due to not considering unique serverless characteristics such as event-driven invocation, pay-as-you-go billing model, short execution duration, ephemeral runtime sandbox, and opaque underlying infrastructure. Such a gap hinders fine-grained carbon emission analysis on perfunction and per-request levels.

The power monitoring solutions mentioned above [36, 40, 46] and many existing power models [50, 51, 66] typically leverage a model to calculate the share of power that a monitored application A should bear based on its resource usage, denoted as P A.

While pay-as-you-go billing enables cost-effectiveness, the current serverless billing model fails to reflect a function’s environmental impact in its cost. For instance, consider a CPU-bound function and another with a long, nonbusy wait for remote database transactions to complete. If both functions request identical resources (i.e., memory sizes and #vCPUs) and happen to have similar durations, they would cost the same. When it comes to carbon, however, the latter would have lower emissions. This simple example highlights a gap in the serverless billing model, which fails to align the cost with the carbon emissions of functions.

Table 1: The notion of billable time varies across different serverless platforms.

∗Not billed under the default configuration. Users may customize the keep-alive (KA) policy by configuring provisioned concurrency (1), minimum instances (2), or scale-down delay (3) and pay for idle resources. (4) Billed for functions with AWS Lambda Extensions.

Overview of the mentioned unsustainable practices in serverless:

• P1: Resource wastage due to inflexible allocation (e.g. CPU allocation in proportion to the memory size)
• P2: Ignored memory access patterns (carbon impact of cache-misses is not proportional to the performance impact)
• P3: Minimum billing cutoff and coarse-grained rounding (e.g. Azure: 100 ms)
• P4: Default configuration combined with lack of carbon observability
• P5: Large code base (cold start latency may not be billed and can be mitigated by keep-alive and pre-warming policies)
• P6: Suboptimal lifetime management policy (e.g. fixed keep-alive policies)

The carbon footprint of serverless functions consists of operational and embodied carbon. Operational carbon primarily arises from power consumption and is influenced by the data center power usage effectiveness (PUE) and the carbon intensity (CI) of the used energy. It is crucial that the carbon model for serverless functions is meaningfully defined on a per-request basis. A per-request carbon model aligns with serverless’s pay-as-you-go billing and event-driven nature, and effectively captures the variable emissions of inputsensitive functions.

Figure 2: The architecture of the proposed metrics collection system and carbon observability framework.

An efficient system to collect carbon-related metrics is essential to assess the carbon footprint of serverless functions accurately. Figure 2 demonstrates the proposed system architecture. The required components in the metrics collection and observability framework are primarily based on opensource projects and cloud-native tools, such as eBPF [16], OpenTelemetry [24], and Grafana, ensuring system feasibility. For accurate per-request carbon footprints, the architecture targets serverless platforms with non-interleaving concurrency models. This is similar to the non-interleaving concurrency models used in AWS Lambda [34] and the default configuration of GCF [12]. This setup allows for differentiating carbon emission sources for each request and simplifies event-driven metrics collection.

Besides metrics, prior work has shown that request traces are essential for providing carbon footprints for applications at a fine-grained request level [37]. We leverage the function middleware and distributed tracing techniques (e.g., OpenTelemetry) to keep a log of function execution, such as function invocation request ID, execution start time, and execution duration. With function execution logs, the usage-based and allocation-based metrics obtained by various collectors with different sampling rates can be linked to each individual function request, thereby enabling carbon modeling on a per-request basis. The metrics and logs are pushed to the observability platform (e.g., Grafana) and used to calculate the carbon emission of individual function requests with the carbon model discussed in §4.2.

Besides, we adopted an average server CPU utilization of 45% [43], an average last-level cache miss rate of 5 per 1,000 cycles [53], and an average cycle per instruction of 1.58 [55].