How to calculate the carbon emission of your cloud services
You can use Climatiq to calculate the carbon emissions of your use of cloud computing. How much power cloud computing uses depends on many factors such as:
- The amount of CPU, Memory and Storage your services use
- How well utilized the machines in the data centers are used.
- How efficiently the data centers are cooled and use their electricity, generally specified as Power Usage Effectiveness or PUE.
- Where the data centers are located to determine the electricity grid mix.
- The embodied emissions, meaning the emissions related to the manufacturing and disposal of the physical components.
Let's dive into the different types of services and how Climatiq can help you calculate your emissions.
Many services either allow you to rent a Virtual Machine(VM) in the cloud, such as GCP's Compute Engine, Azure Virtual Machines or AWS's EC2 instances. Many other services are often backed by a virtual machine you specify, such as Azure's App Service or Kubernetes clusters.
For all the situations where you know your workload is running on a specific virtual machine, Climatiq has a Virtual Machine Endpoint where you need to put in the region you're running, the instance type and optionally the CPU load of the instance.
Using this endpoint will automatically calculate the electricity used for the memory and CPU usage, and the embodied emissions for this specific instance type.
Here is an example of renting a t2.nano from AWS for 24 hours in the "us west 2" region. For more information about this endpoint, we refer to the API reference documentation.
curl --request POST \ --url https://beta3.api.climatiq.io/compute/aws/instance \ --header 'Authorization: Bearer API_KEY' \ --data '{ "instance": "t2.nano", "region": "us_west_2", "duration": 24, "duration_unit": "h"}'{ "total_co2e": 0.038731613137886506, "total_co2e_unit": "kg", "memory_estimate": { "co2e": 0.001570062789086502, "co2e_unit": "kg", "co2e_calculation_method": "ar4", "co2e_calculation_origin": "source", "emission_factor": { "name": "Electricity supplied from grid", "activity_id": "electricity-energy_source_grid_mix", "uuid": "b26fede6-2351-41ef-8106-43aad644f5ba", "id": "electricity-energy_source_grid_mix", "access_type": "public", "source": "EPA", "source_dataset": "eGRID", "year": "2022", "region": "US-NWPP", "category": "Electricity", "lca_activity": "electricity_generation", "data_quality_flags": [] }, "constituent_gases": { "co2e_total": 0.001570062789086502, "co2e_other": null, "co2": 0.0015601279323868027, "ch4": 1.43318763700224e-7, "n2o": 2.293100219203584e-8 } }, "cpu_estimate": { "co2e": 0.0158160103488, "co2e_unit": "kg", "co2e_calculation_method": "ar4", "co2e_calculation_origin": "source", "emission_factor": { "name": "Electricity supplied from grid", "activity_id": "electricity-energy_source_grid_mix", "uuid": "b26fede6-2351-41ef-8106-43aad644f5ba", "id": "electricity-energy_source_grid_mix", "access_type": "public", "source": "EPA", "source_dataset": "eGRID", "year": "2022", "region": "US-NWPP", "category": "Electricity", "lca_activity": "electricity_generation", "data_quality_flags": [] }, "constituent_gases": { "co2e_total": 0.0158160103488, "co2e_other": null, "co2": 0.015715931678400002, "ch4": 0.0000014437200000000002, "n2o": 2.309952e-7 } }, "embodied_cpu_estimate": { "co2e": 0.02134554, "co2e_unit": "kg", "co2e_calculation_method": "ar4", "co2e_calculation_origin": "source", "emission_factor": { "name": "AWS - Embodied emissions - t2.nano - Xeon E5-2676 v3", "activity_id": "cpu-provider_aws-type_t2.nano_xeon_e5_2676_v3", "uuid": "7a8ff5fd-3361-427b-aedf-e47a5e49ea82", "id": "cpu-provider_aws-type_t2.nano_xeon_e5_2676_v3", "access_type": "public", "source": "CCF", "source_dataset": "Derived from CCF models", "year": "2021", "region": "GLOBAL", "category": "Cloud Computing - CPU", "lca_activity": "upstream-end_of_life", "data_quality_flags": [ "notable_methodological_variance" ] }, "constituent_gases": { "co2e_total": 0.02134554, "co2e_other": null, "co2": null, "ch4": null, "n2o": null } }, "calculation_details": { "instance": "t2.nano", "instance_memory": 0.536870912, "memory_unit": "GB", "vcpu_cores": 1, "average_vcpu_utilization": 0.5, "power_usage_effectiveness": 1.135, "energy_used_cpu": 0.0577488, "energy_used_memory": 0.00573275054800896, "energy_unit": "kWh" }}When viewing or overriding electricity emission factors, a number of aspects need to be taken
into account including; what particular mix of energy is being provided by the source, whether
the factor includes upstream emissions and whether it includes transmission and distribution
losses. This information is encoded in the activity_id and the lca_activity fields provided
in API response. More information can be retrieved from the issuing source. Read more about
selecting electricity EFs in our
how-to-guide.
For many services you're not renting out a whole virtual machine, but simply renting out some storage, some memory or some CPU power.
Climatiq can still help you in this case. We have endpoints for estimating emissions based on storage reserved, memory available or virtual CPU power used
The difficulty of getting some of these metrics vary widely from service to service. It's outside the scope of this guide to explain how to retrieve these metrics, but a good place to start is your cloud providers monitoring systems or your billing/usage data. If you're still not sure how to get these metrics, we refer you to this document, or the documentation of your cloud provider.
Let's take a couple of examples of how we can use the Climatiq endpoints to measure based on this more granular input.
If you are running serverless functions, you are often able to retrieve the CPU usage from monitoring or billing. Assuming you retrieve this information, and you have an AWS Lambda function running for 200ms using 1 vCPU core. You could then calculate the CPU emissions using the CPU endpoint like this.
curl --request POST \ --url https://beta3.api.climatiq.io/compute/aws/cpu \ --header 'Authorization: Bearer API_KEY' \ --data '{ "cpu_count": 1, "region": "us_west_2", "duration": 200, "duration_unit": "ms"}'{ "co2e": 3.661113506666668e-8, "co2e_unit": "kg", "co2e_calculation_method": "ar4", "co2e_calculation_origin": "source", "emission_factor": { "name": "Electricity supplied from grid", "activity_id": "electricity-energy_source_grid_mix", "uuid": "b26fede6-2351-41ef-8106-43aad644f5ba", "id": "electricity-energy_source_grid_mix", "access_type": "public", "source": "EPA", "source_dataset": "eGRID", "year": "2022", "region": "US-NWPP", "category": "Electricity", "lca_activity": "electricity_generation", "data_quality_flags": [] }, "constituent_gases": { "co2e_total": 3.661113506666668e-8, "co2e_other": null, "co2": 3.6379471477777794e-8, "ch4": 3.3419444444444453e-12, "n2o": 5.347111111111112e-13 }}Now that we've looked at CPU emissions, let's take a look at how to calculate the emissions caused by using memory (RAM) using a serverless function again.
As memory uses power even when it's not used, a good rule of thumb is to use the total amount of RAM you have allocated, not just the amount you use.
For AWS Lambda you can specify the memory allocated, but the same might not be true for all serverless functions. Let's assume we've specified our above function running for 200ms has 1792MB of memory allocated to it.
You could then calculate the memory emissions using the memory endpoint like this.
curl --request POST \ --url https://beta3.api.climatiq.io/compute/aws/memory \ --header 'Authorization: Bearer API_KEY' \ --data '{ "region": "us_west_2", "data": 1792, "data_unit": "MB", "duration": 200, "duration_unit": "ms"}'{ "co2e": 1.2131134143146666e-8, "co2e_unit": "kg", "co2e_calculation_method": "ar4", "co2e_calculation_origin": "source", "emission_factor": { "name": "Electricity supplied from grid", "activity_id": "electricity-energy_source_grid_mix", "uuid": "b26fede6-2351-41ef-8106-43aad644f5ba", "id": "electricity-energy_source_grid_mix", "access_type": "public", "source": "EPA", "source_dataset": "eGRID", "year": "2022", "region": "US-NWPP", "category": "Electricity", "lca_activity": "electricity_generation", "data_quality_flags": [] }, "constituent_gases": { "co2e_total": 1.2131134143146666e-8, "co2e_other": null, "co2": 1.205437219441778e-8, "ch4": 1.1073564444444446e-12, "n2o": 1.7717703111111112e-13 }}Combining the CPU and memory usage for this serverless function will then give you a good idea of the use phase emissions.
Storing things on a hard drive takes power, whether it's on a hard drive you rent or on a dedicated storage system like AWS S3 or Azure Blob Storage.
Let's look at calculating the storage - there are three factors you need to take into account:
- It matters which hardware is backing your storage - the storage endpoint needs to know whether a hard disk drive (HDD) or a solid state drive (SSD). HDD's generally emit less greenhouse gas but are also slower.
- You should calculate your storage emissions based on how much storage you've bought. Even if you're not using the storage, having it available will use electricity.
- In many services, storage is replicated across multiple machines or even data centers. If your storage is replicated you should take your storage amount and multiply it by how many times it's replicated. You'll have to look at your cloud provider and the specific services you use to figure out how many times data is replicated. Here's a list of list of replication factors, which covers many services for all the major cloud providers.
Here are two examples of how storage can be calculated.
In this example, we mount a 20GB SSD instance storage on our EC2 instance, and we want to calculate the emissions over a week.
Looking at the AWS replication factors, the EC2 Instance Storage is not replicated. This means we only have estimate with the data we've purchased.
curl --request POST \ --url https://beta3.api.climatiq.io/compute/aws/storage \ --header 'Authorization: Bearer API_KEY' \ --data '{ "region": "us_west_2", "data": 20, "data_unit": "GB", "storage_type": "ssd", "duration": 7, "duration_unit": "day"}'{ "co2e": 0.00125334421632, "co2e_unit": "kg", "co2e_calculation_method": "ar4", "co2e_calculation_origin": "source", "emission_factor": { "name": "Electricity supplied from grid", "activity_id": "electricity-energy_source_grid_mix", "uuid": "b26fede6-2351-41ef-8106-43aad644f5ba", "id": "electricity-energy_source_grid_mix", "access_type": "public", "source": "EPA", "source_dataset": "eGRID", "year": "2022", "region": "US-NWPP", "category": "Electricity", "lca_activity": "electricity_generation", "data_quality_flags": [] }, "constituent_gases": { "co2e_total": 0.00125334421632, "co2e_other": null, "co2": 0.0012454134537600002, "ch4": 1.14408e-7, "n2o": 1.830528e-8 }}Let's take a slightly harder example, where we try to calculate emissions based on the use of S3 to store files.
This is harder for several reasons:
- Amazon has never published which sort of physical storage they use in S3. As HDD's are generally cheaper than SSD's, it's a safe guess that they're probably primarily powered by HDD's - so we'll use the HDD emission factor.
- In S3 you don't "pre-allocate" storage. You don't buy a 20GB hard disk you can use as you want - you only pay for what you actually store. It's likely that you share hard-drives with other consumers - so we'll only consider the amount of storage we're actually using in this case.
- S3 is replicated. Your data is replicated in 3 different locations, which means that we'll need to take the amount we've stored and multiply it by 3.
So if we're storing 5GB in S3 - we'll make the call with the HDD emission factor, and an amount of "15GB" - because since the data is allocated three places, we're actually using 15GB of storage.
Let's see how much CO2e it uses to store this data for a week.
curl --request POST \ --url https://beta3.api.climatiq.io/compute/aws/storage \ --header 'Authorization: Bearer API_KEY' \ --data '{ "region": "us_west_2", "data": 15, "data_unit": "GB", "storage_type": "hdd", "duration": 7, "duration_unit": "day"}'{ "co2e": 0.0005091710878800001, "co2e_unit": "kg", "co2e_calculation_method": "ar4", "co2e_calculation_origin": "source", "emission_factor": { "name": "Electricity supplied from grid", "activity_id": "electricity-energy_source_grid_mix", "uuid": "b26fede6-2351-41ef-8106-43aad644f5ba", "id": "electricity-energy_source_grid_mix", "access_type": "public", "source": "EPA", "source_dataset": "eGRID", "year": "2022", "region": "US-NWPP", "category": "Electricity", "lca_activity": "electricity_generation", "data_quality_flags": [] }, "constituent_gases": { "co2e_total": 0.0005091710878800001, "co2e_other": null, "co2": 0.0005059492155900002, "ch4": 4.647825000000001e-8, "n2o": 7.436520000000001e-9 }}Climatiq relies on the Cloud Carbon Footprint methodology for most of our assumptions such as the power-usage of memory and vCPU's. While the CCF methodology allows for specific power calculations based on the underlying hardware, Climatiq currently only uses an average watts per vCPU per provider, and not architecture specific power consumption data.
We've shown you how you can calculate the carbon emissions of some of your cloud compute uses.
While Climatiq's emission factors are reasonably comprehensive for many parts of the cloud computing, it still doesn't cover things like network traffic to the end-user, or network traffic between your servers.
If you're looking at supporting more accurate and complex use-case, please get in touch.