Introduction to Serverless
Cloud computing’s serverless architecture allows an organization to run cloud computing services without being responsible for the provisioning, operation, and management of the underlying server infrastructure. Instead, the cloud service provider (CSP) manages the provisioning, scaling, and maintenance of any of the computing required to run the workloads or applications.
This makes cloud computing even easier to use and scale for the organization but means that it has less insight into how its cloud computing services are run. CSPs do not tell the organization which instance architecture is being used to run their serverless cloud computing. This means that Tailpipe is unable to use the same methodology to calculate emissions for serverless cloud computing as non-serverless cloud computing.
Instead, Tailpipe uses the available data on each CSP’s serverless services to build a picture of their average serverless system. This average model can only be generated for the CPU and RAM behind serverless services, because CSPs do not release any further data on the additional components used. This means that Tailpipe’s emissions figures for serverless services will underestimate the actual emissions generated by an organization’s use of serverless cloud computing. This underestimation is mitigated to an extent by the high efficiency of serverless services – because CSPs are running these services themselves, they are likely to be more efficient than customer-managed cloud processes. Tailpipe continues to develop its methodology in light of new data and will update its approach in response.
Currently, Tailpipe can calculate emissions figures for AWS serverless services, because AWS releases some information on the CPU and memory hardware that hosts them. Azure does not release any information about their serverless hardware, so Tailpipe cannot currently calculate the emissions of Azure’s serverless offerings. Tailpipe is working to resolve this.
Serverless Services
Tailpipe calculates the emissions produced by two AWS serverless services: Lambda, and Fargate.
Lambda is a serverless compute service. With Lambda, you can run code without provisioning or managing servers. Instead, you write your code in small pieces called functions, and AWS Lambda executes these functions in response to specific events.
Fargate is AWS’s system for operating Kubernetes or containers as a serverless service.
Both these services run on the same hardware. Customers can choose whether they want their services to run on ARM or x86 CPUs. Memory is provided through DDR4 RAM.
Fargate
Fargate is AWS’s system for operating containers as a serverless service. Fargate customers choose the number of vCPU and GB of memory they need. They can also choose whether they want their services to run on an ARM or x86 processor.
If they select ARM, their services will be powered by a Graviton2 CPU (AWS, 2021). If they select x86, AWS will assign them one of nine Intel CPUs, without informing them which (ScaleFactory, 2021).
First, Tailpipe calculates the operational emissions of the customer’s use of Fargate:
((CPU + RAM) * PUE) * Carbon Intensity * Power Transmission Losses
Where CPU = (TDP * CPU Utilization Factor) * (vCPU Customer/CPU Threads) * Hours of Utilization
And RAM = ((Average power draw of DDR4 RAM at 100% CPU utilization) * GB of Memory) * Hours of Utilization
If the organization has selected the ARM-Graviton2 processor, Tailpipe knows the TDP (150) and CPU threads (64) of the Graviton2 CPU. If they select x86, Tailpipe uses an average model of the nine available Intel CPUs (a TDP of 173 and 16 CPU threads). For both ARM and x86 processors, Tailpipe assumes 50% utilization, because Fargate is a containerized service where workload is likely to fluctuate. Tailpipe then multiplies the TDP by the 50% CPU utilization factor of 0.815. Tailpipe then adds the apportioned responsibility: the number of vCPU the organization has bought, divided by the average vCPU count of the processor type.
CPU (if ARM) = (150 * 0.815) * Number of vCPUs/64 * Hours of Utilization
CPU (if x86) = (173 * 0.815) * Number of vCPUs/16 * Hours of Utilization
For memory, it is assumed that Fargate utilizes DDR4 RAM based on the CPU specifications available. The power draw of the serverless memory is calculated using the average power draw of DDR4 RAM at 50% CPU utilization (0.0598 W/GB). This is multiplied by the number of GB of memory and the number of hours of utilization.
RAM = (0.0598 * GB of Memory) * Hours of Utilization
Tailpipe adds together the power draw figures for CPU and RAM, to get the total power draw of the organization’s usage of Fargate. It then multiplies this figure by the Power Usage Effectiveness (PUE) of the data center that the server hosting the organization’s Fargate services is based in. PUE is a measure of how much of the total power consumed by a data center is used on other, non-computing loads.
The next step is to account for the carbon intensity and power transmission losses of the grid mix that powers the data center. See the Carbon Intensity article in Tailpipe’s Methodology for more details.
Next, Tailpipe calculates the embodied emissions of the customer’s use of Fargate:
(((CPU + RAM) * Disposal) * Time Share * Resource Share)
Where CPU = ((CPU Units * ((CPU Die Size) * CPU Die Impact + CPU Base Impact)) * (vCPU Customer/CPU Threads))
And RAM = ((RAM Units * ((RAM Capacity/RAM Density) * RAM Die Impact + RAM Base Impact)) * (Memory Customer/Memory Platform))
If the organization has selected the ARM-Graviton2 processor, Tailpipe knows the die size (457mm2) and CPU threads (64). If they have selected x86, Tailpipes uses an average model of the nine Intel CPUs (a die size of 531mm2 and a CPU thread count of 16).
CPU (if ARM) = ((1 * ((457) * 0.0197 + 9.14)) * (vCPU Customer/64))
CPU (if x86) = ((1 * ((531) * 0.0197 + 9.14)) * (vCPU Customer/16))
For RAM, Tailpipe assumes a RAM capacity of 128 GB, a RAM density of 21.1 GB/cm2, and a platform memory of 128 GB. This is based on the most common figures for DDR4 RAM in AWS instances.
RAM = ((1 * ((128/21.1) * 2.2 + 5.22)) * (Memory Customer/128))
The embodied figures for RAM and CPU are added together and multiplied by the disposal factor of 0.018. The disposal factor represents the 1.8% reduction in emissions that Cloud Service Providers’ hardware recycling schemes contribute. Finally, the Time Share is factored in – the percentage of the hardware’s 6-year lifespan that the customer has utilized.
Fargate Example
(((CPU + Memory) * PUE) * Carbon Intensity * Power Transmission Losses) + (((CPU + RAM) * Disposal) * Time Share * Resource Share)
Operational + Embodied = Total Emissions
As an example, consider an organization that has been using the Fargate service with 4 vCPUs on an x86 processor and 20 GB of memory for 1 year.
The CPU power draw would be:
(173 * 0.815) * 4/16 * 8760
= 308779.05 Wh
The RAM power draw would be:
(0.0598 * 20) * 8760
= 10476.96 Wh
The PUE, carbon intensity, and power transmission losses are then factored in. If this service was based in a data center in North Virginia with a PUE of 1.22, a carbon intensity of 0.000384, and a power transmission loss of 1.08, the operational emissions would be:
((308779.05 + 10476.96) * 1.22) * 0.000384 * 1.08 = 161.53 kgCO2e
The embodied emissions of the CPU’s entire lifespan would be:
((1 * ((531) * 0.0197 + 9.14)) * (4/16))
= 4.9 kgCO2e
The embodied emissions of the RAM‘s entire lifespan would be:
((1 * ((128/21.1) * 2.2 + 5.22)) * (20/128))
= 2.9 kgCO2e
The impact of disposal is removed:
(4.9 + 2.9) – ((4.9 + 2.9) * 0.018) = 7.66
The customer’s responsibility for 1 year of these embodied emissions is then factored in:
((7.66) * (1/6))
= 1.28 kgCO2e
This organization’s use of Fargate would therefore have produced 162.81 kgCO2e.
Lambda
AWS Lambda is a serverless compute service provided by AWS. With Lambda, a customer’s code is run without the customer having to provision or manage their own servers. Instead, the customer writes their code in small pieces called functions, and AWS Lambda executes these functions in response to specific events.
In AWS’s case, no utilization data for the CPU is provided for serverless services. Tailpipe therefore uses average data to complete its serverless calculation. AWS Cost and Usage Reports also report Lambda usage in seconds (rather than Hours or Months, which are the standard units for AWS billing).
First, Tailpipe calculates the operational emissions of Lambda usage:
((CPU + RAM) * PUE) * Carbon Intensity * Power Transmission Losses
Where CPU = ((TDP * CPU Utilization Factor) * ((GB of Memory * vCPU Factor)/CPU Threads))/Seconds in an Hour * Seconds of Utilization
And RAM = ((Average power draw of DDR4 RAM at 80% CPU utilization) * GB of Memory)/Seconds in an Hour * Seconds of Utilization
Customers can choose whether to run their serverless services on either Intel x86 or ARM processors (AWS, 2023), and the quantity of DDR4 RAM they need. If they select ARM, their services will be powered by a Graviton2 CPU (AWS, 2021). If they select x86, AWS will assign them one of several Intel CPUs, without informing them which.
If the organization has selected the ARM-Graviton2 processor, Tailpipe knows the TDP (150) and CPU thread count (64) of the Graviton2 CPU. If they select x86, Tailpipe uses an average model of the nine Intel CPUs used in another of AWS’s serverless services, Fargate (ScaleFactory, 2021). Tailpipe assumes that the same CPUs are used for all AWS’s serverless services, with an average TDP of 173 and 16 CPU threads. For both ARM and x86 processors, Tailpipe assumes 80% utilization, because Lambda is a burstable service that is best suited to intensive workloads. Tailpipe therefore multiplies the TDP by the 80% CPU utilization factor of 0.955.
The next step is to apportion the organization’s responsibility for the total power draw of the CPU. Tailpipe calculates this by dividing the number of vCPUs the organization is using, by the total CPU thread count of the processor being utilized. Lambda does not allow customers to choose how many vCPUs they want their services to run on but rather allocates vCPUs depending on memory size.
1 vCPU is allocated for every 1.769 GB of memory, or 0.565 vCPU for every 1 GB (AWS, 2024). Tailpipe calculates how many vCPUs an organization has been allocated by multiplying the number of GB of memory by 0.565.
CPU (if ARM) = (150 * 0.955) * ((GB of Memory * 0.565)/64) / 3600 * Seconds of Utilization
CPU (if x86) = (173 * 0.955) * ((GB of Memory * 0.565)/16) / 3600 * Seconds of Utilization
The power draw of the serverless memory is calculated using the average power draw of DDR4 RAM at 80% CPU utilization. This is multiplied by the number of GB of memory that the organization has chosen, and the number of seconds of utilization.
RAM = (0.0603 * GB of Memory) / 3600 * Seconds of Utilization
Tailpipe adds together the power draw figures for CPU and RAM, to get the total power draw of the organization’s usage of Lambda. It then multiplies this figure by the Power Usage Effectiveness (PUE) of the data center that the server hosting the organization’s Lambda services is based in. PUE is a measure of how much of the total power consumed by a data center is used on other, non-computing loads.
The next step is to account for the carbon intensity and power transmission losses of the grid mix that powers the data center. See the Carbon Intensity article in Tailpipe’s Methodology for more details.
Next, Tailpipe calculates the embodied emissions of Lambda usage:
((CPU + RAM) * Disposal) * Time Share * Resource Share
Where CPU = ((CPU Units * ((CPU Die Size) * CPU Die Impact + CPU Base Impact)) * (vCPU Customer/CPU Threads))
And RAM = ((RAM Units * ((RAM Capacity/RAM Density) * RAM Die Impact + RAM Base Impact)) * (Memory Customer/Memory Platform))
If the organization has selected the ARM-Graviton2 processor, Tailpipe knows the die size (457mm2) and CPU thread count (64). If they have selected x86, Tailpipes uses an average model of the nine Intel CPUs (a die size of 531mm2 and a CPU thread count of 16).
CPU (if ARM) = ((1 * ((457) * 0.0197 + 9.14)) * (vCPU Customer/64))
CPU (if x86) = ((1 * ((531) * 0.0197 + 9.14)) * (vCPU Customer/16))
For RAM, Tailpipe assumes a RAM capacity of 128 GB, a RAM density of 21.1 GB/cm2, and a platform memory of 128 GB. This is based on the most common figures for DDR4 RAM in AWS instances.
RAM = ((1 * ((128/21.1) * 2.2 + 5.22)) * (Memory Customer/128))
The embodied figures for CPU and RAM are added together and multiplied by the disposal factor of 0.018. The disposal factor represents the 1.8% reduction in emissions that Cloud Service Providers’ hardware recycling schemes contribute. Finally, the Time Share is factored in – the percentage of the hardware’s 6-year lifespan that the customer has utilized.
Lambda Example
(((CPU + Memory) * PUE) * Carbon Intensity * Power Transmission Losses) + (((CPU + RAM) * Disposal) * Time Share * Resource Share)
Operational + Embodied = Total Emissions
As an example, consider an organization that has been using the Lambda service on an ARM-Graviton2 processor with 10 GB of memory for 1 year.
The CPU power draw would be:
(150 * 0.955) * ((10 * 0.565)/64) / 3600 * 31,557,600
= 110857.4 Wh
The RAM power draw would be:
(0.0603 * 10) / 3600 * 31,557,600
= 5285.9 Wh
The PUE, carbon intensity, and power transmission losses are then factored in. If this service was based in a data center in North Virginia with a PUE of 1.22, a carbon intensity of 0.000384, and a power transmission loss of 1.08, the operational emissions would be:
((110857.4 + 5285.9) * 1.22) * 0.000384 * 1.08 = 58.76 kgCO2e
The embodied emissions of the CPU’s entire lifespan would be:
((1 * ((457) * 0.0197 + 9.14)) * ((10 * 0.565)/64))
= 1.6 kgCO2e
The embodied emissions of the RAM‘s entire lifespan would be:
((1 * ((128/21.1) * 2.2 + 5.22)) * (10/128))
= 1.45 kgCO2e
The impact of disposal is removed:
(1.6 + 1.45) – ((1.6 + 1.45) * 0.018) = 2.99
The customer’s responsibility for 1 year of these embodied emissions is then factored in:
2.99 * (1/6)
= 0.5 kgCO2e
This organization’s use of Lambda would therefore have produced 59.26 kgCO2e.
