Same Function, Different CPU: Quantifying Hardware Heterogeneity in Commercial FaaS Platforms

Same Function, Different CPU: Quantifying Hardware Heterogeneity in Commercial FaaS Platforms Jonas Heisterberg

Natalie Carl

Technische Universität Berlin Berlin, Germany jh@3s.tu-berlin.de

Technische Universität Berlin Berlin, Germany nc@3s.tu-berlin.de

arXiv:2611.02990v1 [cs.DC] 2 Nov 2026

Trever Schirmer

David Bermbach

Technische Universität Berlin Berlin, Germany ts@3s.tu-berlin.de

Technische Universität Berlin Berlin, Germany db@3s.tu-berlin.de

Abstract Serverless computing, particularly Function-as-a-Service (FaaS), abstracts operational concerns such as scaling, scheduling, and resource management from users. This abstraction, however, conceals a heterogeneous hardware fleet on which function execution environments are scheduled behind a unified function interface. Consequently, otherwise identical invocations may run on different CPU types that differ in performance, a hardware lottery that users can neither see nor control. Since the resulting variability is entangled with other sources, such as noisy neighbors or diurnal effects, its contribution to overall performance variability and how this contribution differs across providers remain unclear. In this paper, we systematically study hardware heterogeneity and its impact on function performance across four widely used commercial FaaS platforms, covering regional, configurational, and temporal differences. Using variance decomposition, we find that CPU heterogeneity alone explains 54 % to 97 % of the performance variance on AWS Lambda and Google Cloud Run Functions. On Azure Functions, in contrast, we identify a platform-level mechanism that produces bimodal execution durations and overshadows CPU effects. We observe that the CPU composition on AWS Lambda shifts within a single week. Additionally, we reveal that on Google Cloud Run Functions and Alibaba Function Compute, the availability of instruction set extensions such as SHA-NI differs between CPU types, widening the performance gap further. Since all platforms bill by duration, performance gaps between CPU types translate directly into cost, with invocations on the slowest CPU type costing up to three times as much as those on the fastest.

CCS Concepts • Computer systems organization → Cloud computing.

Keywords FaaS, serverless, hardware heterogeneity, performance variability

1

Introduction

Function-as-a-Service (FaaS) has become an established cloud computing paradigm over the past decade. Developers decompose applications into small, event-driven units of code, known as serverless functions. The platform, in turn, manages the underlying execution environments, including resource provisioning, scaling, and load

User Perspective f()

f()

f()

f()

f()

FaaS Platform Abstraction Physical Infrastructure

CPU Type A

CPU Type B

CPU Type C

Figure 1: FaaS platforms abstract the underlying infrastructure behind a function interface. Requests to the same function may run on hosts with different CPU types, which users can neither see nor control.

balancing, abstracting operational concerns from users [27, 34]. Platforms dynamically multiplex these execution environments, which are also referred to as function instances, across shared infrastructure, improving resource utilization. Users benefit from a pay-per-use pricing model, only paying for the actual usage of their functions rather than for reserved or pre-allocated capacity [27]. A direct consequence of this model is that users have limited control over the hardware their code runs on, as platforms expose only a small set of predefined resource configurations, such as the memory size [27], rather than instance families as in Infrastructureas-a-Service (IaaS) [4]. This abstraction hides a heterogeneous CPU fleet underneath [47], meaning that otherwise identical invocations may execute on different CPU types as instances scale out (see Figure 1). Lower-performing hardware consequently increases both execution duration and cost, as users are billed for execution duration. The ephemeral nature of function instances [46, 47] exacerbates this effect. They turn over more often than long-lived virtual machines in IaaS, potentially redrawing the hardware assignment

Heisterberg et al.

with every new instance, which increases the performance variability between invocations. Prior studies document the hardware heterogeneity in FaaS [20, 47] and performance differences between CPU types [16]. However, how much of the overall performance variability is attributable to hardware heterogeneity, and how this contribution differs across providers, remains unquantified. Because commercial FaaS platforms reveal neither the hardware they assign nor the scheduling policies behind it, attributing performance differences to hardware requires measuring the platforms from the outside. In this paper, we therefore conduct a systematic measurement study across four commercial platforms (AWS Lambda [5], Azure Functions [38], Google Cloud Run Functions [23], and Alibaba Function Compute [2]), characterizing their hardware assignment patterns and quantifying how much of the observed performance variability hardware heterogeneity explains. We find that CPU type explains up to 97 % of performance variance and can triple invocation cost for hardware-accelerated tasks, although on Azure other platform characteristics overshadow its effect. We make the following contributions. • We design a platform-agnostic benchmark that samples the heterogeneous hardware underlying commercial FaaS platforms and captures function performance alongside CPU metadata (§3). • We apply this benchmark to four commercial FaaS platforms, use variance decomposition to attribute the observed performance variability to hardware heterogeneity, and quantify the resulting cost differences from billed durations (§4). • We discuss implications of our findings for users running production workloads and for researchers designing reproducible FaaS benchmarks (§5).

2

From Hardware to Serverless Performance

To save cost and increase resource utilization, serverless platforms use the heterogeneous hardware present in their datacenters to run function instances [27]. These instances draw on the same pool of heterogeneous hardware as other cloud service instances, but with less user control over the resulting assignment. This user-opaque assignment makes hardware heterogeneity an uncontrollable source of function performance variability.

2.1

FaaS Key Characteristics

In line with simplifying operational concerns for users, platforms expose only few options to configure the resources of a function instance [27]. Often, only the memory size is configurable, and the platform derives the other resources proportionally [29]. While users define these static parameters at deployment time, the runtime lifecycle of function instances is fully managed by the platform. Upon function invocation, the platform either reuses an existing idle function instance, also known as a warm start, or provisions a new one, known as a cold start [10, 46]. Whether to reuse, provision, or terminate an instance is entirely up to the platform. Another defining characteristic of FaaS is its pay-per-use billing model, where users are only charged for the resources they actually consume [27]. Specifically, billing is determined by the total execution duration of all function invocations scaled by the configured

resources, plus a potential per-invocation fee. Consequently, a function’s execution duration becomes the primary driver of cost [35].

2.2

Hardware Heterogeneity in Cloud Datacenters

Cloud providers operate datacenters across multiple geographic regions, housing thousands of servers procured over many years. As infrastructure continuously expands and new hardware generations are integrated, different generations of hardware concurrently operate within the same datacenter [8]. Although operators employ virtualization to abstract this heterogeneity from tenants, the underlying hardware differences remain visible as performance variation to users. The performance of the same workload on identical instances of the same cloud service can vary significantly depending on the underlying hardware [33, 41, 42]. This effect also extends to FaaS platforms, where function execution environments run on fleets of heterogeneous CPUs [15, 20, 47]. Unlike a long-running virtual machine in IaaS, which users provision once and which then typically runs on the same physical host for the lifetime of the deployment [41], FaaS instances are ephemeral and continually reprovisioned to serve fluctuating workloads [9].

2.3

Quantifying Performance Variability

Performance variability in computer systems refers to the dispersion of a performance metric observed across multiple executions of the same workload under similar conditions [26]. In FaaS, this manifests as differences in execution duration across invocations of the same function under the same configuration, a variance that is substantial yet often overlooked in serverless research [48]. To quantify this variability, we use the coefficient of variation (CV), defined as the ratio of the standard deviation to the mean, which is dimensionless and thus comparable across platforms and configurations [26]. Quantifying the overall variability alone, however, is insufficient to understand its causes. FaaS platforms experience variability from multiple sources, including cold starts, noisy neighbors, and configuration differences, all of which can confound the effect of hardware heterogeneity on performance. Separating the contribution of hardware differences from these other sources requires appropriate statistical methods. Effect size measures, specifically 𝜂 2 , serve this purpose by expressing the proportion of variance in a response variable that a given factor accounts for [30]. For a grouping factor 𝑔 that partitions the observations into groups, a one-way analysis of variance (ANOVA) decomposes the total sum of squares into a between-group and a within-group component, and 𝜂 2 is the ratio of the between-group sum of squares to the total, Í ¯2 SSbetween 𝑔 𝑛𝑔 (𝑦¯𝑔 − 𝑦) 𝜂2 = = Í (1) ¯2 SStotal 𝑖 (𝑦𝑖 − 𝑦) where 𝑦𝑖 are the individual observations, 𝑦¯𝑔 the mean of group 𝑔, 𝑦¯ the grand mean, and 𝑛𝑔 the number of observations in group 𝑔. We later use this measure with CPU type as the grouping factor to quantify how much of the observed performance variability hardware heterogeneity accounts for (§4.5). The between-group component then captures the differences between CPU types, whereas all

Same Function, Different CPU

other sources, such as noisy neighbors, end up in the within-group component, which is how the decomposition separates them from hardware heterogeneity.

3

Benchmark Design

To explore the impact of hardware heterogeneity on performance variability in FaaS platforms, we introduce a systematic benchmarking methodology that runs microbenchmarks inside serverless functions and captures their performance alongside CPU metadata. Our benchmark targets two primary dimensions in which hardware heterogeneity manifests, namely the composition of CPU types that function instances are scheduled on, and the extent to which performance differs between those CPU types. Reliable measurements require considering how workloads interact with platform scheduling. While placement is up to the platform, the invocation pattern of a benchmark influences how many instances it encounters and thus which hardware it samples. Sequential invocations can be routed to the same function instance, repeatedly sampling the same hardware and limiting exposure to hardware heterogeneity. Parallel requests, in contrast, force the platform to provision additional instances to serve the load, raising the likelihood of sampling different hardware. A purely parallel approach, however, would mostly measure cold starts rather than steady-state performance. We therefore generate a high volume of parallel invocations while allowing multiple sequential invocations per instance. Beyond the invocation pattern, our benchmark comprises a set of platform-agnostic components that together enable comparison across platforms, regions, and resource configurations. The source code is publicly available.1

3.1

Function Design

The first component comprises the functions, which a client-side module deploys while abstracting provider-specific deployment and call signatures. Each function is implemented for the Node.js 20 runtime, invoked via HTTPS, and consists of a wrapper and a microbenchmark. In each invocation, the wrapper extracts hardware and instance metadata and then runs a CPU-intensive microbenchmark. We measure function performance through the execution duration of the microbenchmark rather than the billed duration, since the billed duration also includes additional overhead such as initialization steps [35]. We employ five synthetic, compute-bound microbenchmarks designed to stress different CPU performance characteristics, chosen over application-level workloads to isolate CPU performance from confounding factors such as network latency and I/O [11]. We use matrix multiplication as a baseline CPU-bound workload commonly employed in serverless benchmarking studies [50]. JSON serialization repeatedly serializes and deserializes a deeply nested object structure, and gzip compression compresses a random buffer, both representing operations frequently found in serverless applications such as API request processing and payload transfer. Finally, SHA-256 repeatedly hashes a large buffer and AES-CTR repeatedly encrypts a large buffer, both benefiting from the optional instruction set extensions SHA-NI and AES-NI, respectively, allowing us to quantify the impact of their availability on performance variability. 1 https://github.com/Persists/benchmark-classifaas

3.2

Load Generation

The second component, the load generator, runs client-side, drives function invocations, and collects performance measurements. Motivated by the considerations above, it is designed to provoke the platform into provisioning new function instances. To this end, it employs a closed-loop workload model in which a fixed number of concurrent workers continuously issue requests to the same function [45]. We prefer a closed-loop model because, in an open-loop model with a fixed arrival rate, the number of concurrent instances would depend on the execution duration, and thus on the very CPU types we study.

3.3

Instance Lifecycle Management

Complementing the parallel invocation pattern of the load generator, we integrate a recycling mechanism to emulate workload patterns that exercise instance turnover. Beyond the platform’s scaling to serve concurrent requests, fresh instances are also provisioned in response to runtime crashes or other process failures [43]. To approximate this, we track the invocation count in a global variable within the runtime and terminate the process once it reaches a fixed threshold, prompting the platform to replace the terminated process before serving subsequent requests. This approach also addresses concurrency limits enforced by platforms per region, function, or account, which cap the number of coexisting function instances. How a platform responds to this turnover, however, is not under our control and may differ across platforms. Either it provisions a fresh instance on a potentially different physical host or restarts the runtime process within the existing instance and continues serving subsequent invocations on the same hardware. In our experiments, GCF and Alibaba Function Compute provision a fresh instance, whereas AWS Lambda and Azure Functions restart the runtime process within the existing instance, which we discuss in detail in §5.4. We set the recycling threshold to four invocations, yielding a maximum of four invocations per runtime process. Since the first invocation of each runtime process includes initialization overhead, we discard it to capture steady-state performance rather than warmup effects. As every new function instance starts a new runtime process, this also removes instance cold-start effects. Additionally, we trim the upper 1 % of execution durations within each CPU type and configuration for the computation of outlier-sensitive metrics such as the CV and 𝜂 2 , since skewed distributions otherwise distort these measures [26]. No lower trimming is required, since the microbenchmarks impose a natural floor on execution duration.

3.4

Processor Identification

As FaaS platforms do not expose information about the underlying hardware, our benchmark follows Cordingly et al. [18] and extracts CPU metadata at runtime from within each function instance by parsing the /proc/cpuinfo file. The wrapper captures this metadata alongside a runtime process identifier and the execution duration of each invocation so that measurements can be grouped by process and CPU type later on. The amount of information exposed through /proc/cpuinfo varies across platforms, consistent with prior work [47]. We therefore construct CPU type identifiers

Heisterberg et al.

using the most specific combination of available fields on each platform, resulting in different grouping granularities across platforms. Coarser groupings, however, yield conservative estimates of the impact of CPU heterogeneity, since pooling distinct CPU models under one identifier moves their performance differences into the within-group variance rather than the between-group variance. Moreover, the CPU type may co-vary with other host components that cannot be distinguished from within a function, such as the memory hierarchy, so we treat it as the observable identifier of the host configuration rather than of the processor alone.

4

Evaluation

We use our benchmark to evaluate hardware heterogeneity and its contribution to performance variability across four commercial FaaS platforms, with the results publicly available.2 We structure our investigation into three sets of experiments, covering regional differences (§4.2), configurational effects (§4.3), and temporal dynamics over seven days (§4.4). We then use the same seven-day dataset to analyze how different workloads react to these hardware differences (§4.5) and how the resulting performance differences translate into cost (§4.6).

4.1

Platforms and Configuration

We leverage our benchmark to study AWS Lambda [5], Google Cloud Run Functions (GCF) [23], Azure Functions [38], and Alibaba Function Compute [2], which together provide broad market coverage and enable meaningful cross-platform comparison. Since several platforms offer multiple hosting plans or product generations with distinct performance characteristics, we fix one variant per platform for all experiments, namely Gen 1 on GCF and the Flex Consumption plan on Azure Functions, a Linux-based option that exposes explicit memory configuration and supports horizontal scaling. Azure Functions and Alibaba Function Compute allow multiple concurrent invocations per function instance by default, which introduces performance interference between requests sharing the same instance [35]. We therefore set per-instance concurrency to one on both, matching the one-request-per-instance default of AWS Lambda and GCF. Alibaba is the only platform that decouples vCPU from memory size. To aid comparability between platforms, we configure it with 0.1 vCPU per 128 MB of memory. Finally, we calibrate the input parameters of each microbenchmark to yield an execution duration of approximately 2 s on AWS Lambda at 512 MB.

4.2

Regional Differences in CPU Fleets

To gain an initial understanding of the hardware heterogeneity landscape, we start by characterizing the CPU types present across different regions on each platform. We deploy the same matrix multiplication function in 12 randomly selected regions per provider with a fixed memory configuration of 512 MB, which is the lowest memory size offered by all four platforms. We schedule a separate load generator for each region that invokes the corresponding function 2500 times in total. Each generator issues 500 parallel invocations on AWS Lambda, GCF, and Alibaba Function Compute, and 300 on Azure Functions, the highest count the platform handled reliably in our setup. To mitigate temporal performance variations 2 https://github.com/Persists/results-classifaas

present on serverless platforms [44], we schedule all regional experiments on November 8, 2025, to start at the same local time in every region. The resulting CPU type distributions are shown in Figure 2. Azure reports the full model name for all CPUs, whereas AWS reports a generalized identifier consisting of vendor and clock frequency, and Alibaba falls in between, reporting the full model name for some CPUs and a generalized identifier for others. GCF masks the model name as “unknown”, matching prior findings from Wang et al. [47]. For GCF, we therefore group invocations by the combination of the reported vendor (AMD or Intel) and CPUID model number, a labeling scheme we retain throughout the remaining experiments. Every provider employs heterogeneous CPU types within and across regions, but the degree and distribution patterns vary substantially. AWS exhibits the most homogeneous fleet, consisting of only three CPU types, with most regions dominated by a single Intel Xeon 2.50 GHz type that accounts for over 90 % of invocations. In contrast, GCF shows the most heterogeneous fleet overall: only two regions are dominated by Model 85, while the others are distributed more evenly across multiple types. Azure and Alibaba fall in between, with some regions served exclusively by a single CPU type and others exhibiting a more mixed composition. Across the full sample, GCF and Alibaba expose the most distinct CPU types, though later experiments reveal that AWS deploys additional types not captured in this snapshot.

4.3

Configurational Effects

Having established that CPU heterogeneity exists across and within regions, we now examine how function configuration affects hardware assignment. We select a region with a diverse CPU composition in the regional survey for each platform, namely us-east-1 for AWS Lambda and Alibaba Function Compute, us-east1 for GCF, and germanywestcentral for Azure Functions. In each region, we deploy the matrix multiplication benchmark at three memory tiers (128, 512 and 2048 MB), except on Azure, where the Flex Consumption plan only offers 512 and 2048 MB from this range. We repeat the experiment 12 times at 2 h intervals on November 26–27, 2025, covering a full 24 h cycle, and invoke all functions simultaneously within each run to minimize temporal effects between configurations. Each configuration of the same function receives 1500 invocations per run, with 250 concurrent invocations so that the simultaneously running configurations stay within each platform’s concurrency limits, for a total of 18 000 invocations per configuration. 4.3.1 CPU Composition. The CPU composition remains stable across memory configurations on all four platforms, with the dominant CPU types unchanged and only minor fluctuations in their shares. AWS Lambda’s fleet in us-east-1 shows two CPU types absent from the regional survey, the AMD EPYC 2.25 GHz and the AMD EPYC 2.65 GHz, which together account for more than 16 % of invocations, a difference we examine in §4.4. 4.3.2 Relative Performance Differences Across Configurations. AWS Lambda and GCF show pronounced inter-CPU differences at low memory tiers that diminish with increasing memory, while Azure

AWS

Azure

GCF

eu-west-2 ap-southeast-1 ap-northeast-2 us-east-1 us-west-1 eu-west-3 us-east-2 sa-east-1 ap-south-1 eu-west-1 eu-north-1 ap-northeast-1

westus germanywc eastus uksouth centralindia japanwest ukwest koreacentral westus2 japaneast eastasia brazilsouth

asia-northeast2 us-central1 asia-south1 us-west1 asia-east2 us-east4 asia-east1 us-east1 europe-west2 asia-northeast1 sa-east1 europe-west1

Same Function, Different CPU

CPU share (%)

100

Alibaba

0

Intel Xeon 2.50GHz Intel Xeon 2.90GHz Intel Xeon 3.00GHz

AMD EPYC 9V74 Intel Xeon 8370C AMD EPYC 7763

Model 85 (Intel) Model 143 (Intel) Model 1 (AMD)

Model 17 (AMD) Model 106 (Intel) Model 173 (Intel)

ap-southeast-5 cn-shanghai us-west-1 ap-northeast-1 eu-central-1 us-east-1 cn-hangzhou ap-northeast-2 ap-southeast-7 cn-beijing eu-west-1 me-central-1

50

Intel Xeon 8269CY 2.50GHz Intel Xeon 2.50GHz Intel Xeon 8269CY 3.10GHz Intel Xeon 8163 2.50GHz Intel Xeon 2.90GHz

Figure 2: CPU type composition in 12 regions per platform, measured as the share of invocations. AWS

Deviation from dominant CPU (%)

50

Azure

Intel Xeon 2.50GHz (ref) AMD EPYC 2.25GHz Intel Xeon 3.00GHz Intel Xeon 2.90GHz AMD EPYC 2.65GHz

0 AMD EPYC 9V74 (ref) Intel Xeon 8370C AMD EPYC 7763

−50 128

512 GCF

2048

−50

512 2048 Alibaba

Intel Xeon 2.50GHz (ref) Intel Xeon 8269CY 3.10GHz Intel Xeon 2.90GHz

50 0

128

Model 143 (Intel) (ref) Model 17 (AMD) Model 1 (AMD) Model 85 (Intel) Model 106 (Intel)

128

512

2048

128

512

2048

Memory (MB)

Figure 3: Deviation of the median execution duration from each platform’s dominant CPU type (ref) across memory tiers. and Alibaba maintain stable differences across all tiers (Figure 3). On AWS Lambda, the median execution duration of the AMD EPYC 2.25 GHz is 45 % lower than the dominant Intel Xeon 2.50 GHz at 128 MB but 4 % higher at 2048 MB. GCF shows the same convergence, most pronounced for Model 85, which yields 55 % higher execution durations than the dominant Model 143 at 128 MB but only 6 % higher at 2048 MB. For users deploying on these platforms, this means that performance variability due to CPU heterogeneity

is most pronounced at low memory tiers, while higher tiers offer more predictable performance regardless of the assigned CPU type. We hypothesize that this convergence reflects context-switch penalties that differ across CPU architectures [40]. Lower memory tiers receive a smaller share of a CPU core that is time-sliced among function instances. Consequently, the same work takes longer, the process is descheduled more often, and co-located instances pollute the cache in the meantime. Each context switch thus leaves the process with a partially cold cache, and since CPU architectures recover from this at different speeds, the penalty widens their performance gap at low tiers, whereas at high tiers, with few switches per invocation, the gap shrinks to the difference in raw compute speed. AWS Lambda is the only platform that exposes the context switch counter in /proc/stat, which we record inside the execution environment before and after each invocation. The number of context switches per invocation falls by a factor of 3.7 to 9.0 from 128 MB to 2048 MB, depending on the CPU type, consistent with this explanation. On Alibaba, the Intel Xeon 2.90 GHz consistently achieves 40 % to 50 % lower execution durations than the dominant Intel Xeon 2.50 GHz, and on Azure the other two CPU types take 22 % to 32 % longer than the dominant AMD EPYC 9V74. Beyond these interCPU differences, Azure’s overall variability at 512 MB stands out with a CV of 54 %, against only 18 % at 2048 MB. Since both the inter-CPU differences and the CPU composition remain nearly identical across the two configurations, CPU heterogeneity cannot explain this gap, pointing to a separate driver of variability, which we examine next. 4.3.3 Azure Bimodality. Closer inspection of the 512 MB execution durations in Figure 4 reveals a bimodal distribution, with up to 36 % of invocations completing roughly 4 × faster than the median. This bimodality is present across all three CPU types, suggesting that a platform-level mechanism rather than a CPU-specific effect drives the performance variability. We observe the same pattern across every region evaluated in §4.2, though its extent varies across

Heisterberg et al.

AWS CPU Type AMD EPYC 9V74 Intel Xeon 8370C AMD EPYC 7763

0.5

Memory 512 MB 2048 MB

CV (%)

ECDF

1.0

2000

3000

Figure 4: Empirical CDFs of execution durations on Azure Functions. At 512 MB, every CPU type is bimodal, with a subset of invocations as fast as at 2048 MB.

CPU share (%)

50

50

0

Gzip

JSON

AES-CTR

SHA-256

MatMul

Figure 6: Coefficient of variation and the share of variance explained by CPU type (𝜂 2 ) for each provider and microbenchmark at 512 MB.

100

50 Intel Xeon 2.50GHz Intel Xeon 2.90GHz

0

Mon

Tue

AMD EPYC 2.25GHz Intel Xeon 3.00GHz

Wed

Thu

Fri

AMD EPYC 2.65GHz

Sat

Sun

Figure 5: CPU type composition on AWS Lambda over a sevenday period, aggregated into four six-hour time slots (00:00, 06:00, 12:00, 18:00) per day in the region’s local time. regions, with some exhibiting a substantially larger share of faster invocations than others. Notably, on each CPU type, the faster 512 MB invocations align with the 2048 MB performance. This suggests that a subset of 512 MB instances may receive a higher effective compute allocation than expected from the nominal resource specification. According to the Azure Flex Consumption documentation, the 512 MB tier typically provides 0.25 vCPU, whereas the 2048 MB tier provides 1 vCPU. The documentation further states that initial instances may receive different core allocations to improve performance, which is consistent with the observed execution duration distributions [38]. In contrast, the 2048 MB tier exhibits a single tightly clustered distribution without visible bimodality.

4.4

Alibaba

4000

η 2 (%)

Execution duration (ms)

GCF

0 100

0.0 1000

Azure

Temporal Dynamics of CPU Assignment

While the previous experiments provide snapshots at specific points in time using a single workload, this final set of experiments investigates a broader temporal profile across a full seven-day period (December 1–7, 2025). We deploy each of the five microbenchmarks (§3.1) as a separate function with 512 MB of memory in the same regions as in §4.3. Across the entire period, we schedule the experiments in four daily time slots at 00:00, 06:00, 12:00, and 18:00 in the local time of each region’s datacenter, to capture both diurnal and day-to-day variability. To stay within platform-imposed

concurrency limits, we execute the microbenchmarks sequentially within each time slot, with a 10 min delay between runs. Furthermore, we randomize the execution order of the workloads within each time slot following the randomized multiple interleaved trials (RMIT) approach [1], reducing bias from ordering effects to keep the workloads comparable for the analyses in Sections 4.5 and 4.6. Each run uses the same settings as the regional survey (§4.2), 2500 invocations with 300 to 500 parallel invocations depending on the platform, totaling 70 000 invocations per workload and platform over the seven days. To investigate the temporal dynamics of CPU compositions, we pool the CPU shares of all five microbenchmarks per time slot. Since every slot contains the same five microbenchmarks, changes between slots reflect the CPU fleet rather than differences between workloads. The results show that Azure, GCF, and Alibaba maintain stable CPU compositions throughout the week, with the dominant CPU types and their shares remaining nearly identical over the entire period. AWS Lambda, in contrast, shows pronounced temporal shifts in its CPU composition, as highlighted in Figure 5. While the Intel Xeon 2.50 GHz remains the dominant type over the full period, its share fluctuates within and across days. On weekdays, the two middle time slots (06:00 and 12:00) show a higher share of the faster AMD and Intel variants, whereas the Intel Xeon 2.50 GHz takes a larger share in the outer slots (00:00 and 18:00). On weekends, the faster variants take a larger share across all time slots. These diurnal and weekly shifts, however, do not fully explain the composition discrepancy between the prior experiments in §4.2 and §4.3. The regional survey encountered no AMD CPU in us-east-1, although it ran on a Saturday morning, a time slot in which AMD CPUs are well represented in our seven-day experiment. Beyond the recurring patterns, the fleet composition thus also changed in the weeks between the experiments.

Same Function, Different CPU

Workload Sensitivity to CPU Heterogeneity

4.6

Cost Implications of CPU Assignment

The execution duration differences characterized so far are not only a performance concern. All four platforms charge for the duration of an invocation at a rate that does not depend on the assigned CPU type, so an invocation that lands on a slower CPU also incurs a higher cost. Therefore, we now derive cost for the seven-day dataset from the platform-reported billed durations at the pay-as-you-go list prices without free tiers [3, 6, 24, 39], applying each platform’s billing granularity, including the minimum of 1000 ms on Azure Functions [38]. However, while every invocation performs the same amount of work, the billed duration also covers the metadata collection of our wrapper, and each invocation incurs a fixed request fee. Both compress relative differences, so the cost differences we report are slightly smaller than they would be for a function without our metadata collection. Finally, we calculate the mean cost per CPU type over one million invocations.

AWS Gzip

Cost per million invocations ($)

4.5

The seven-day dataset across five microbenchmarks additionally allows us to quantify how much CPU type contributes to the overall variability of each workload. To this end, Figure 6 reports two complementary measures, the CV for total observed variability and 𝜂 2 (Equation (1)) for the share of that variability attributable to CPU type. We compute 𝜂 2 for each platform and workload from a one-way ANOVA with CPU type as the grouping factor on logtransformed execution durations. The log scale accounts for the multiplicative nature of inter-CPU performance differences and for the right-skewed execution duration distributions, following standard practice for performance measurements [26]. Two regimes emerge. On AWS Lambda and GCF, 𝜂 2 ranges from 54 % to 97 % and 56 % to 96 %, respectively. Hence, on these platforms most of the observed performance variability can be explained by differences in the underlying CPU type, consistent with narrow distributions within each CPU type, where the per-CPU CV stays below 11 % for every workload on AWS Lambda and below 21 % on GCF. Although AWS Lambda has the lowest CVs of any platform across all workloads, even its small residual variability is largely attributable to the assigned CPU type. Azure Functions shows the opposite pattern. Its CVs are consistently high, yet CPU type explains at most 12 % of the variance, because the bimodality identified in §4.3.3 appears for every workload. Alibaba Function Compute sits between these two regimes, with 𝜂 2 varying substantially across workloads, from 21 % on JSON to 80 % on SHA-256, as its distributions within each CPU type are considerably wider, with per-CPU CVs of up to 39 %. SHA-256 yields the highest 𝜂 2 on all platforms except Azure Functions, reaching 97 % on AWS Lambda, 96 % on GCF, and 80 % on Alibaba. On GCF and Alibaba, this traces back to instruction set extensions. The CPU flags in /proc/cpuinfo show that Model 85 is the only CPU type on GCF without SHA-NI, and it takes 3.1 × to 5.3 × as long as the other types, also explaining the high CV on GCF. On Alibaba, conversely, the Intel Xeon 2.90 GHz is the only CPU type with SHA-NI support and is 3.5 × to 4.2 × faster than the others. On AWS Lambda, no CPU type exposes SHA-NI, and on Azure Functions all of them do, so neither platform exhibits such inter-CPU differences for SHA-256.

60

Azure JSON Most expensive

GCF

AES-CTR Cheapest

Alibaba

SHA-256

MatMul

Actual cost

40 20 0

Figure 7: Mean cost per million invocations, derived from billed durations at list prices including the per-request fee.

Figure 7 shows the resulting cost of invocations running on the cheapest and the most expensive CPU type, considering only types with a share of at least 1 %, together with the actual cost, i.e., the average over all invocations given the CPU types the platform assigned. Overall, the differences are smallest on AWS Lambda and Azure Functions, where invocations on the most expensive CPU type still cost up to 1.6 × and 1.4 × as much as those on the cheapest one, respectively. They are largest on GCF and Alibaba Function Compute, with up to 2.9 × and 3.0 × for SHA-256, where only some CPU types support SHA-NI, consistent with the findings in §4.5. Where the actual cost falls within this range depends on how often each CPU type is assigned. On Alibaba Function Compute, it is close to the most expensive CPU type for all workloads. AWS Lambda shows a similar pattern for JSON, AES-CTR, and MatMul, while the remaining workloads fall towards the middle of the range. GCF also falls around the middle, except for SHA-256, where the actual cost is close to the cheapest type because the CPU type without SHA-NI support is rarely assigned. In contrast, Azure Functions stays close to the cheapest type for every workload.

5

Discussion

Our results show that the underlying hardware, which FaaS platforms promise to abstract away, remains a primary driver of userfacing performance variability. We find that CPU type explains 54 % to 97 % of the performance variance on AWS Lambda and GCF. While the serverless abstraction holds at the interface, it breaks down in the resulting performance, exposing users to this hidden hardware lottery. The Azure results, however, show that hardware is not a universal explanation for FaaS variability, since a platform mechanism overshadows CPU effects.

5.1

Users Facing the Hardware Lottery

For users, hardware-dependent variability is systematic rather than transient. Once a function instance is assigned to a physical host, all of its invocations inherit that host’s performance and, due to payper-use billing, its cost, until the platform recycles the instance. This distinguishes hardware-dependent variability from noisy neighbors or network jitter, which can fluctuate within an instance’s

Heisterberg et al.

lifetime. The CPU type can, however, be read at runtime at negligible cost, and logging it alongside latency and billing data lets users attribute anomalies to hardware rather than to their code. Whether a slowdown stems from the processor itself or from covarying components such as the memory hierarchy is irrelevant for this purpose, since the CPU type is the observable property that predicts both performance and cost. On AWS Lambda and GCF, the differences between CPU types shrink with increasing memory, so functions with strict latency requirements can gain predictability from a higher tier, even if they do not use the additional memory. Workloads that rely on instruction set extensions such as SHA-NI face the largest gaps and should check the CPU flags at runtime rather than assume availability. Beyond observation, users can attempt placement gaming to reduce cost or improve performance [22, 43], provoking fresh instances until a favorable CPU type is assigned. Even if every invocation landed on the cheapest CPU type, the saving is bounded by the distance between the observed mix and the cheapest type in Figure 7, which depends on both platform and workload and therefore has to be monitored per function. At the same time, each attempt incurs a cold start, which adds latency and billed initialization time [35], and since the fleet on AWS Lambda shifts within days, current compositions should not be assumed to persist. CPU identification is therefore more reliable for monitoring performance than for controlling placement.

5.2

Scheduling Flexibility at the Cost of User Predictability

Our results indicate that, on AWS Lambda and GCF, allowing users to select a CPU type could substantially reduce performance variability for their functions. Such control is not unprecedented, as IaaS offerings let users select instance families [4] or a minimum CPU platform [25], and AWS Lambda already prices ARM and x86 functions differently [6]. Following this precedent, pricing could depend on the selected CPU type in addition to the memory tier. For FaaS providers, however, CPU-dependent placement would reduce scheduling flexibility. The current model of billing the entire fleet at a uniform rate allows providers to place instances on whichever compatible host is available, supporting high utilization through statistical multiplexing [27]. Restricting placement to specific CPU types would fragment this pool and could increase the risk of underutilization. We therefore propose three possible measures, in increasing order of cost to providers. First, making the assigned CPU type available as instance metadata would make the hardware lottery visible to users. Second, normalizing billing by CPU performance could prevent users from paying more for the same workload on slower hardware. Billing by consumed CPU time instead of wallclock time, as proposed by Cao et al. [12], would not prevent this issue, since the same workload still consumes more CPU time on a slower CPU. Lastly, an optional tier tied to a specific CPU generation, which may incur an additional cost, could allow users to exchange scheduling flexibility for predictability, while maintaining the current model for other workloads.

5.3

Hardware Awareness as a Serverless Benchmarking Requirement

In contrast to users, who value the ease of use of FaaS and might accept the hardware lottery as a trade-off, researchers require reproducibility and comparability in their experiments [11]. CPU assignment is an uncontrolled experimental variable, as two experiments with identical function code and resource configurations may encounter different CPU compositions and therefore differ for reasons unrelated to the factor under investigation. Beyond known time-of-day effects [44], fleet composition itself shifts over time and differs across regions. Region and measurement period are therefore part of the experimental context, an issue Schad et al. [42] already raised for IaaS. We therefore recommend concrete measures to mitigate this confounding factor in future FaaS benchmarking studies. Researchers should record the CPU type of every function instance, which is available at runtime with negligible overhead. They should then stratify the results by CPU type, or at least verify that the conditions being compared encountered a similar CPU composition, before attributing a difference to the factor under investigation. Researchers should also ensure that they sample many instances rather than a few instances repeated many times, since hardware is assigned per instance and repeated invocations of one instance only resample the same hardware. Finally, reporting the CPU composition renders this confounding factor explicit, enabling subsequent studies to evaluate whether their measurements were obtained on comparable hardware.

5.4

Threats to Validity

We restricted our analysis to JavaScript functions and a fixed set of CPU-bound microbenchmarks. This simplification strengthens our attribution of variance to CPU type, but it also means that the magnitude of variability for other languages, runtimes, and application-level workloads may differ from our reported values. Moreover, our evaluation focuses on the variance associated with the observable CPU type rather than an isolated causal effect of the processor, as the CPU type may co-vary with other components of the host, such as the memory hierarchy or rack-level hardware configuration. Additionally, the regions we selected for the configuration and temporal experiments were chosen for their heterogeneity in the initial regional survey, which means our results characterize regions where heterogeneity is present rather than the platform as a whole. The recycling mechanism (§3.3) was only effective on GCF and Alibaba Function Compute. We verify the instance identity through an identifier that the first invocation writes to the local /tmp filesystem, which persists even after process termination. On GCF and Alibaba, a new identifier appears after almost every recycling, confirming a fresh instance, whereas on AWS Lambda and Azure Functions it persists, meaning that the runtime process was restarted within the existing instance. On these two platforms, instances therefore serve more than four invocations, and our sampling reflects organic scaling under sustained parallel load rather than forced churn. As a result, we sampled fewer distinct instances than intended.

Same Function, Different CPU

Finally, CV and 𝜂 2 remain sensitive to skewness and heavy upper tails, which we mitigate by trimming the upper 1 % of execution durations and by analyzing on the log scale for the decomposition.

6

Related Work

The opacity of commercial serverless platforms has led to extensive efforts to infer platform characteristics solely through external measurements and observations. Various studies have proposed benchmarking methodologies that stress different aspects of serverless platforms to gather insights about performance and other system properties [14, 28, 49, 51], enabling cross-platform comparisons. By combining benchmarks with controlled configurations, prior work has isolated specific performance factors within serverless platforms, such as the impact of CPU architecture in AWS Lambda when comparing x86 and ARM [13, 31], the effect of resource configuration [20, 36] and programming language [17, 37], or temporal effects derived from repeated measurements [19, 44]. While the explicit selection of available configurations or time windows allows for controlled setups, another line of work infers characteristics by leveraging the little information commercial FaaS platforms do not hide from users. Several studies, e.g., [15, 20, 47], extracted CPU metadata from /proc/cpuinfo to characterize the employed hardware. Lloyd et al. [36] investigated AWS Lambda by creating a temporary file on the local filesystem; if the file was already present during a subsequent invocation, they inferred that the same execution environment was reused, enabling analysis of cold-start behavior. Utilizing the CPU information further, Awwad et al. [7] derived infrastructure sustainability properties such as power draw and operational and embodied carbon. Lin et al. [35] used user-space timing measurements to infer OS scheduler parameters and billing quantization effects on AWS Lambda, GCF, and IBM Cloud Functions. Among inferred cloud platform characteristics, hardware heterogeneity has emerged as a significant driver of performance variability. Over a decade ago, Schad et al. [42] reported up to 24 % CPU-performance variation on AWS EC2, primarily attributing it to hardware differences. Lenk et al. [33] similarly traced a bimodal performance distribution on AWS EC2 to the assigned CPU type after ruling out datacenter location and time of day, and reported the probability of landing on each CPU type for a given instance class. Later, these findings were revisited, revealing that the impact of hardware heterogeneity on performance had decreased [32]. In the serverless domain, the issue resurfaced with Cordingly et al. [16] observing that CPU heterogeneity increased the CV significantly on AWS Lambda (7.4×), while the effect was considerably smaller on IBM Cloud Functions (1.2×), when comparing overall variance to the variance of a single CPU model. During the evaluation of a serverless MapReduce framework, Giménez-Alventosa et al. [21] measured execution duration differences of up to 51 % between CPU types on AWS Lambda. Building upon inferred platform knowledge, different systems have been proposed to improve performance by exploiting favorable placements. Even before serverless platforms emerged, Ou et al. [41] exploited CPU heterogeneity within a single IaaS instance type on EC2 through a trial-and-better strategy that keeps

fast instances and discards slow ones, achieving up to 30 % cost savings, and analyzed how this benefit erodes once many users adopt it. Ginzburg and Freedman [22] proposed placement-gaming strategies based on execution duration and CPU-steal measurements. Similarly, Minos [43] uses preliminary benchmarks to identify and selectively terminate slow instances, thereby achieving the same goal of favoring faster hardware. Cordingly et al. [15] present a sky computing approach that exploits CPU fleet differences across availability zones to redeploy functions to better-performing hardware. To determine the CPU composition, they exhausted entire availability zones through repeated function invocations until the zone was saturated, exceeding a failure threshold. In contrast to prior work, which demonstrates that FaaS hardware is heterogeneous or exploits favorable placements, our work quantifies how strongly CPU type contributes to overall performance variability across four commercial FaaS platforms. Rather than treating hardware heterogeneity as an isolated phenomenon, we decompose total variability to identify when hardware-induced effects dominate execution duration variability and when other factors become the primary source of variance.

7

Conclusion

In this paper, we showed that hardware heterogeneity is a firstorder driver of performance variability in commercial FaaS platforms that users and researchers should account for when designing applications and evaluating platforms. Combining compute-bound microbenchmarks with runtime hardware introspection, we quantified the contribution of CPU type to the observed variance on four platforms. We found that each platform employs heterogeneous CPU fleets, and that on AWS Lambda these fleets shift within a single week rather than remaining static. CPU type explained 54 % to 97 % of the variance in execution duration on AWS Lambda and GCF, but at most 12 % on Azure Functions, where a platformlevel mechanism produced bimodal execution durations. Alibaba Function Compute sat between these regimes. The common thread is that the serverless abstraction hides a source of variability it does not remove. On AWS Lambda and GCF the hidden factor is the assigned CPU, while on Azure Functions it is an opaque platform mechanism, and in both cases users are exposed to performance and cost differences they can observe but not control. This places workloads with tight performance or cost requirements in tension with the operational convenience that motivates the FaaS model.

References

[1] Ali Abedi and Tim Brecht. 2017. Conducting Repeatable Experiments in Highly Variable Cloud Computing Environments. In Proceedings of the 8th ACM/SPEC on International Conference on Performance Engineering (ICPE ’17). ACM, New York, NY, USA, 287–292. doi:10.1145/3030207.3030229 [2] Alibaba Cloud. 2026. Function Compute. https://www.alibabacloud.com/product/ function-compute. (Accessed: October 15, 2026). [3] Alibaba Cloud. 2026. Function Compute pricing. https://www.alibabacloud.com/ en/product/function-compute/pricing. (Accessed: October 15, 2026). [4] Amazon Web Services. 2026. Amazon EC2 Instance Types. https://docs.aws. amazon.com/ec2/latest/instancetypes. (Accessed: October 15, 2026). [5] Amazon Web Services. 2026. AWS Lambda. https://aws.amazon.com/lambda/. (Accessed: October 15, 2026). [6] Amazon Web Services. 2026. AWS Lambda Pricing. https://aws.amazon.com/ lambda/pricing/. (Accessed: October 15, 2026). [7] Hanan Awwad, Changyuan Lin, Rabab Ward, and Mohammad Shahrad. 2025. Estimating the Carbon Footprint of Serverless Functions on a Public Cloud

Heisterberg et al.

Platform. In Proceedings of the 3rd Workshop on SErverless Systems, Applications and MEthodologies (SESAME ’25). ACM, New York, NY, USA, 12–20. doi:10.1145/ 3721465.3721863 [8] Luiz André Barroso, Urs Hölzle, and Parthasarathy Ranganathan. 2026. The Data Center as a Computer: Designing Warehouse-Scale Machines (4 ed.). Springer Nature Switzerland, Cham. doi:10.1007/978-3-031-99489-0 [9] David Bermbach, Abhishek Chandra, Chandra Krintz, Aniruddha Gokhale, Aleksander Slominski, Lauritz Thamsen, Everton Cavalcante, Tian Guo, Ivona Brandic, and Rich Wolski. 2021. On the Future of Cloud Engineering. In Proceedings of the 9th IEEE International Conference on Cloud Engineering (IC2E 2021). IEEE, New York, NY, USA, 264–275. doi:10.1109/IC2E52221.2021.00044 [10] David Bermbach, Ahmet-Serdar Karakaya, and Simon Buchholz. 2020. Using Application Knowledge to Reduce Cold Starts in FaaS Services. In Proceedings of the 35th ACM Symposium on Applied Computing (SAC ’20). ACM, New York, NY, USA, 134–143. doi:10.1145/3341105.3373909 [11] David Bermbach, Erik Wittern, and Stefan Tai. 2017. Cloud Service Benchmarking: Measuring Quality of Cloud Services from a Client Perspective. Springer, Cham, Switzerland. doi:10.1007/978-3-319-55483-9 [12] Tingjia Cao, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, and Tyler Caraza-Harter. 2025. Making Serverless Pay-For-Use a Reality with Leopard. In Proceedings of the 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI ’25). USENIX Association, Berkeley, CA, USA, 189–204. https://www.usenix.org/conference/nsdi25/presentation/cao [13] Xinghan Chen, Ling-Hong Hung, Robert Cordingly, and Wes Lloyd. 2023. X86 vs. ARM64: An Investigation of Factors Influencing Serverless Performance. In Proceedings of the 9th International Workshop on Serverless Computing (WoSC ’23). ACM, New York, NY, USA, 7–12. doi:10.1145/3631295.3631394 [14] Marcin Copik, Grzegorz Kwasniewski, Maciej Besta, Michal Podstawski, and Torsten Hoefler. 2021. SeBS: A Serverless Benchmark Suite for Function-as-aService Computing. In Proceedings of the 22nd International Middleware Conference (Middleware ’21). ACM, New York, NY, USA, 64–78. doi:10.1145/3464298. 3476133 [15] Robert Cordingly, Xinghan Chen, Ling-Hong Hung, and Wes Lloyd. 2025. Sky Computing for Serverless: Infrastructure Assessment to Support Performance Enhancement. In Proceedings of the 18th IEEE/ACM International Conference on Utility and Cloud Computing (UCC ’25). ACM, New York, NY, USA, Article 11, 10 pages. doi:10.1145/3773274.3774266 [16] Robert Cordingly, Wen Shu, and Wes J. Lloyd. 2020. Predicting Performance and Cost of Serverless Computing Functions with SAAF. In Proceedings of the 2020 IEEE Intl Conf on Dependable, Autonomic and Secure Computing (DASC/PiCom/CBDCom/CyberSciTech). IEEE, New York, NY, USA, 640–649. doi:10.1109/DASC-PICom-CBDCom-CyberSciTech49142.2020.00111 [17] Robert Cordingly, Hanfei Yu, Varik Hoang, David Perez, David Foster, Zohreh Sadeghi, Rashad Hatchett, and Wes J. Lloyd. 2020. Implications of Programming Language Selection for Serverless Data Processing Pipelines. In Proceedings of the 2020 IEEE Intl Conf on Dependable, Autonomic and Secure Computing (DASC/PiCom/CBDCom/CyberSciTech). IEEE, New York, NY, USA, 704–711. doi:10. 1109/DASC-PICom-CBDCom-CyberSciTech49142.2020.00120 [18] Robert Cordingly, Hanfei Yu, Varik Hoang, Zohreh Sadeghi, David Foster, David Perez, Rashad Hatchett, and Wes Lloyd. 2020. The Serverless Application Analytics Framework: Enabling Design Trade-off Evaluation for Serverless Software. In Proceedings of the 2020 Sixth International Workshop on Serverless Computing (WoSC ’20). ACM, New York, NY, USA, 67–72. doi:10.1145/3429880.3430103 [19] Simon Eismann, Joel Scheuner, Erwin van Eyk, Maximilian Schwinger, Johannes Grohmann, Nikolas Herbst, Cristina L. Abad, and Alexandru Iosup. 2021. A Review of Serverless Use Cases and their Characteristics. arXiv:2008.11110 [cs.SE] [20] Kamil Figiela, Adam Gajek, Adam Zima, Beata Obrok, and Maciej Malawski. 2018. Performance evaluation of heterogeneous cloud functions. Concurrency and Computation: Practice and Experience 30, 23 (2018), e4792. doi:10.1002/cpe.4792 [21] V. Giménez-Alventosa, Germán Moltó, and Miguel Caballer. 2019. A framework and a performance assessment for serverless MapReduce on AWS Lambda. Future Generation Computer Systems 97 (2019), 259–274. doi:10.1016/j.future.2019.02.057 [22] Samuel Ginzburg and Michael J. Freedman. 2020. Serverless Isn’t Server-Less: Measuring and Exploiting Resource Variability on Cloud FaaS Platforms. In Proceedings of the 2020 Sixth International Workshop on Serverless Computing (WoSC ’20). ACM, New York, NY, USA, 43–48. doi:10.1145/3429880.3430099 [23] Google Cloud. 2026. Cloud Run functions. https://cloud.google.com/functions/. (Accessed: October 15, 2026). [24] Google Cloud. 2026. Cloud Run functions pricing. https://cloud.google.com/ functions/pricing. (Accessed: October 15, 2026). [25] Google Cloud. 2026. CPU Platforms. https://docs.cloud.google.com/compute/ docs/cpu-platforms. (Accessed: October 15, 2026). [26] Raj Jain. 1991. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling. John Wiley & Sons, New York, NY, USA. [27] Eric Jonas, Johann Schleier-Smith, Vikram Sreekanti, Chia-Che Tsai, Anurag Khandelwal, Qifan Pu, Vaishaal Shankar, Joao Carreira, Karl Krauth, Neeraja Yadwadkar, Joseph E. Gonzalez, Raluca Ada Popa, Ion Stoica, and David A.

Patterson. 2019. Cloud Programming Simplified: A Berkeley View on Serverless Computing. arXiv:1902.03383 [cs.OS] [28] Jeongchul Kim and Kyungyong Lee. 2019. FunctionBench: A Suite of Workloads for Serverless Cloud Function Service. In Proceedings of the 2019 IEEE 12th International Conference on Cloud Computing (CLOUD). IEEE, New York, NY, USA, 502–504. doi:10.1109/CLOUD.2019.00091 [29] Jörn Kuhlenkamp, Sebastian Werner, Chin Hong Tran, and Stefan Tai. 2022. Synthesizing Configuration Tactics for Exercising Hidden Options in Serverless Systems. In Intelligent Information Systems. Springer International Publishing, Cham, 36–44. doi:10.1007/978-3-031-07481-3_5 [30] Daniël Lakens. 2013. Calculating and Reporting Effect Sizes to Facilitate Cumulative Science: A Practical Primer for t-Tests and ANOVAs. Frontiers in Psychology 4, Article 863 (2013), 12 pages. doi:10.3389/fpsyg.2013.00863 [31] Danielle Lambion, Robert Schmitz, Robert Cordingly, Navid Heydari, and Wes Lloyd. 2022. Characterizing X86 and ARM Serverless Performance Variation: A Natural Language Processing Case Study. In Companion of the 2022 ACM/SPEC International Conference on Performance Engineering (ICPE ’22). ACM, New York, NY, USA, 69–75. doi:10.1145/3491204.3543506 [32] Philipp Leitner and Jürgen Cito. 2016. Patterns in the Chaos—A Study of Performance Variation and Predictability in Public IaaS Clouds. ACM Transactions on Internet Technology 16, 3, Article 15 (2016), 23 pages. doi:10.1145/2885497 [33] Alexander Lenk, Michael Menzel, Johannes Lipsky, Stefan Tai, and Philipp Offermann. 2011. What Are You Paying For? Performance Benchmarking for Infrastructure-as-a-Service Offerings. In Proceedings of the 2011 IEEE 4th International Conference on Cloud Computing (CLOUD). IEEE, New York, NY, USA, 484–491. doi:10.1109/CLOUD.2011.80 [34] Zijun Li, Linsong Guo, Jiagan Cheng, Quan Chen, Bingsheng He, and Minyi Guo. 2022. The Serverless Computing Survey: A Technical Primer for Design Architecture. Comput. Surveys 54, 10s, Article 220 (2022), 34 pages. doi:10.1145/ 3508360 [35] Changyuan Lin, Yuanzhi Ma, and Mohammad Shahrad. 2026. Demystifying Serverless Costs on Public Platforms: Bridging Billing, Architecture, and OS Scheduling. In Proceedings of the 21st European Conference on Computer Systems (EUROSYS ’26). ACM, New York, NY, USA, 1964–1981. doi:10.1145/3767295. 3769374 [36] Wes Lloyd, Shruti Ramesh, Swetha Chinthalapati, Lan Ly, and Shrideep Pallickara. 2018. Serverless Computing: An Investigation of Factors Influencing Microservice Performance. In Proceedings of the 2018 IEEE International Conference on Cloud Engineering (IC2E). IEEE, New York, NY, USA, 159–169. doi:10.1109/IC2E.2018. 00039 [37] Johannes Manner, Martin Endreß, Tobias Heckel, and Guido Wirtz. 2018. Cold Start Influencing Factors in Function as a Service. In Proceedings of the 2018 IEEE/ACM International Conference on Utility and Cloud Computing Companion (UCC Companion). IEEE, New York, NY, USA, 181–188. doi:10.1109/UCCCompanion.2018.00054 [38] Microsoft. 2026. Azure Functions Flex Consumption Plan hosting. https://learn. microsoft.com/en-us/azure/azure-functions/flex-consumption-plan. (Accessed: October 15, 2026). [39] Microsoft. 2026. Azure Functions pricing. https://azure.microsoft.com/en-us/ pricing/details/functions/. (Accessed: October 15, 2026). [40] Jeffrey C. Mogul and Anita Borg. 1991. The Effect of Context Switches on Cache Performance. In Proceedings of the Fourth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS IV). ACM, New York, NY, USA, 75–84. doi:10.1145/106972.106982 [41] Zhonghong Ou, Hao Zhuang, Andrey Lukyanenko, Jukka K. Nurminen, Pan Hui, Vladimir Mazalov, and Antti Ylä-Jääski. 2013. Is the Same Instance Type Created Equal? Exploiting Heterogeneity of Public Clouds. IEEE Transactions on Cloud Computing 1, 2 (2013), 201–214. doi:10.1109/TCC.2013.12 [42] Jörg Schad, Jens Dittrich, and Jorge-Arnulfo Quiané-Ruiz. 2010. Runtime Measurements in the Cloud: Observing, Analyzing, and Reducing Variance. Proceedings of the VLDB Endowment 3, 1–2 (2010), 460–471. doi:10.14778/1920841.1920902 [43] Trever Schirmer, Natalie Carl, Nils Höller, Tobias Pfandzelter, and David Bermbach. 2025. Minos: Exploiting Cloud Performance Variation with Functionas-a-Service Instance Selection. In Proceedings of the 13th IEEE International Conference on Cloud Engineering (IC2E ’25). IEEE, New York, NY, USA, 194–199. doi:10.1109/IC2E65552.2025.00036 [44] Trever Schirmer, Nils Japke, Sofia Greten, Tobias Pfandzelter, and David Bermbach. 2023. The Night Shift: Understanding Performance Variability of Cloud Serverless Platforms. In Proceedings of the 1st Workshop on SErverless Systems, Applications and MEthodologies (SESAME ’23). ACM, New York, NY, USA, 6 pages. doi:10.1145/3592533.3592808 [45] Bianca Schroeder, Adam Wierman, and Mor Harchol-Balter. 2006. Open Versus Closed: A Cautionary Tale. In Proceedings of the 3rd USENIX Symposium on Networked Systems Design and Implementation (NSDI ’06). USENIX Association, Berkeley, CA, USA, 239–252. https://www.usenix.org/conference/nsdi-06/openversus-closed-cautionary-tale [46] Mohammad Shahrad, Rodrigo Fonseca, Inigo Goiri, Gohar Chaudhry, Paul Batum, Jason Cooke, Eduardo Laureano, Colby Tresness, Mark Russinovich, and Ricardo

Same Function, Different CPU

Bianchini. 2020. Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider. In Proceedings of the 2020 USENIX Annual Technical Conference (ATC ’20). USENIX Association, Berkeley, CA, USA, 205–218. https://www.usenix.org/conference/atc20/presentation/shahrad [47] Liang Wang, Mengyuan Li, Yinqian Zhang, Thomas Ristenpart, and Michael Swift. 2018. Peeking Behind the Curtains of Serverless Platforms. In Proceedings of the 2018 USENIX Annual Technical Conference (ATC ’18). USENIX Association, Berkeley, CA, USA, 133–146. https://www.usenix.org/conference/atc18/ presentation/wang-liang [48] Jinfeng Wen, Zhenpeng Chen, Federica Sarro, and Shangguang Wang. 2025. Unveiling Overlooked Performance Variance in Serverless Computing. Empirical Software Engineering 30, 2 (2025), 26 pages. doi:10.1007/s10664-025-10615-3

[49] Jinfeng Wen, Yi Liu, Zhenpeng Chen, Junkai Chen, and Yun Ma. 2023. Characterizing Commodity Serverless Computing Platforms. Journal of Software: Evolution and Process 35, 10, Article e2394 (2023), 23 pages. doi:10.1002/smr.2394 [50] Sebastian Werner, Jörn Kuhlenkamp, Markus Klems, Johannes Müller, and Stefan Tai. 2018. Serverless Big Data Processing using Matrix Multiplication as Example. In Proceedings of the 2018 IEEE International Conference on Big Data (Big Data). IEEE, New York, NY, USA, 358–365. doi:10.1109/BigData.2018.8622362 [51] Tianyi Yu, Qingyuan Liu, Dong Du, Yubin Xia, Binyu Zang, Ziqian Lu, Pingchao Yang, Chenggang Qin, and Haibo Chen. 2020. Characterizing Serverless Platforms with ServerlessBench. In Proceedings of the 11th ACM Symposium on Cloud Computing (SoCC ’20). ACM, New York, NY, USA, 30–44. doi:10.1145/3419111. 3421280

Related documents

• Ermes: a Stateful Serverless Platform for the Edge-to-Cloud Continuum#1013081
• Ermes: a Stateful Serverless Platform for the Edge-to-Cloud Continuum#965377
• Leveraging Serverless Computing for Flexibility and Scalability in Applications#106919
• Optimizing OpenFaaS on Kubernetes: Comparative Analysis of Language Runtimes and Cluster Distributions#1488337
• Scheduling Analysis of UAV Flight Control Workloads on PREEMPT_RT Linux Using a Raspberry Pi 5#1534022