This document explains the Google Cloud approach to environmental sustainability. It includes information and other resources that you can use to understand your carbon footprint on Google Cloud, and methods that you can use to reduce or minimize that footprint. The intended audience for this document includes the following:
- Developers who want to build applications that have a minimal carbon footprint.
- Infrastructure and other technical teams who want to understand their current carbon footprint and identify opportunities to reduce that footprint.
This document assumes that you're familiar with Google Cloud and running virtual machine (VM) workloads.
Understand cloud carbon emissions
Google has been carbon neutral since 2007, and has committed to operating on 100% carbon-free energy 24/7 by 2030. Google's data centers, including those that run Google Cloud services, also use much less energy than typical data centers. For this reason, using Google Cloud can help you reduce the carbon footprint of your IT today.
Google operates multiple cloud regions, which are delivered through a global network of data centers. These data centers consume electricity that is generated by the local grid to run cloud services. The environmental impact of the electricity that is generated by the local grid is measured by its grid carbon intensity. The grid carbon intensity indicates how much carbon is emitted by the power plants that generate electricity for the grid.
The environmental impact isn't equal across all data center locations, due to factors such as differing energy mix and production efficiency. Since 2017, Google also procures renewable energy equal to the electricity that it consumes globally in the same year, by using power purchase agreements (PPAs). These PPAs result in the production of carbon-free energy that's attributable to Google, which enters the grids that our data centers consume electricity from.
The environmental impact of electricity consumed by Google data centers is determined by the combination of grid carbon intensity and energy from carbon-free energy sources that are attributed to Google. Google introduced the carbon free energy percentage (CFE%) metric, which is calculated from these two elements. CFE% describes the average hourly carbon-free energy consumption for each region, and it represents the average percentage of time that your application runs on carbon-free energy. Due to a cleaner energy supply, regions that have a higher CFE% produce fewer carbon emissions than regions that have a lower CFE% for the same workload.
To lower your carbon emissions, you need to reduce the electricity consumption of your cloud workloads from carbon-based sources. To lower your carbon emissions, we recommend the following primary strategies:
- Choose cloud regions with higher average hourly CFE%, and lower grid carbon intensity. For regions that have the same CFE%, use grid carbon intensity to further compare the emissions performance of those regions.
- Optimize cloud workloads to reduce carbon emissions. For example, increase efficiency by using elastic cloud services and autoscaling features to minimize unused compute resources, and run batch workloads during times when grid carbon intensity is lower.
- Set organizational policies to restrict the location of cloud resources to cleaner regions.
Understand your carbon footprint
Google Cloud provides Carbon Footprint, a tool to help you understand the carbon footprint from your Google Cloud usage. Carbon Footprint provides the total emissions based on the grid carbon intensity of the local electricity grid. The report further attributes emissions to the Google Cloud projects that you own and the cloud services that you use. The emissions data is reported according to Google's Carbon Footprint reporting methodology, and it can assist with your Greenhouse Gas (GHG) Protocol Scope 3 Standard reporting requirements as a Google Cloud customer. You can export the Carbon Footprint data to BigQuery for further analysis.
You can use the Carbon Footprint dashboard and BigQuery export to help you understand your location-based emissions from using Google Cloud services. You can use this data to compare the carbon footprint of different Google Cloud services. For example, to understand their relative emissions, you can compare the total emissions of two or more services that are running in the same cloud region.
The Google Cloud customer-specific gross greenhouse gas emissions data provided by the Carbon Footprint report has not been third-party verified or assured.
Choose the most suitable cloud regions
Choosing cleaner cloud regions to run workloads is one of the simplest and most effective ways to reduce carbon emissions. Google publishes carbon data for all cloud regions, including the CFE% and grid carbon intensity of the local electricity grid. To reduce your overall emissions, we recommend that you choose regions with higher CFE% where possible. To help you pick cleaner regions, Google Cloud includes a Low CO2 indicator on some of the location selectors of the Google Cloud console and the "Locations" pages of the Google Cloud documentation. For information about the criteria that a region must meet in order to receive this indicator, see Carbon free energy for Google Cloud regions.
Where multiple regions have a similar CFE%, compare their grid carbon intensity. Comparing the grid carbon intensity of different regions is also important if you're focusing on location-based emissions reductions. For example, for a similar CFE% score, the grid could either be powered by coal-fired power plants or gas-fired power plants. The grid carbon intensity reflects this mix and it helps you to select the lowest carbon-emitting grid.
Lowering emissions might be one of many requirements that you need to balance when you choose a region. For example, you might need to consider the availability of specific Google Cloud services, pricing, data location requirements, and serving latency to your users. The region with the overall highest CFE% might not be suitable for your use case. To ensure the lowest emissions, select the region that has the highest CFE% and that meets all of your requirements.
To simplify region selection, use the Google Cloud Region Picker to determine the best cloud regions that meet your requirements based on carbon footprint, price, and latency. For more information about the Google Cloud Region Picker, see Pick the Google Cloud region that's right for you.
If your organization provides a choice to users for which cloud regions to use, you can also consider setting an organization policy to restrict locations to Low CO2 regions.
Choose the most suitable cloud services
Google Cloud offers a range of cloud services that are suited to different IT workloads. To help reduce your existing carbon footprint, consider migrating VM workloads to Compute Engine from less energy-efficient infrastructure, such as an on-premises data center. For information about how to migrate VMs to Google Cloud from on-premises data centers and various cloud environments, see Migrating VMs with Migrate to Virtual Machines.
Many workloads don't require VMs, and you can instead deploy them to other fully managed services that are intended for different workload types. These services often have built-in automatic scaling and rightsizing features that help to optimize performance and resource usage for you. For example, Cloud Run is a fully serverless environment that scales containerized applications faster and with fewer idle resources compared to running a comparable application stack on VMs. Having fewer idle resources results in optimized costs and reduced carbon footprint.
Consider the following offerings for common workload types. The list of services isn't exhaustive, but it explains how different managed services can optimize cloud resource usage (often automatically), which simultaneously reduces cloud costs and carbon footprint.
- Cloud Run: a serverless offering for running containerized applications, written in your language of choice. It features fast autoscaling of your application from zero to N container instances depending on traffic. If there is no traffic, your application uses zero computing resources for serving. The service is designed to handle bursty traffic patterns and optimize your use of computing resources accordingly.
- Cloud Functions: a serverless functions-as-a-service (FaaS) offering. It runs on the same infrastructure as Cloud Run and App Engine, which extends the same scale-from-zero and fast autoscaling functionality to Cloud Functions.
- Google Kubernetes Engine (GKE): a cloud service that provides managed Kubernetes environments. Compared to direct VM usage, running containerized workloads using Kubernetes environments on GKE can minimize unused cloud resources, which results in decreased cloud costs and a smaller carbon footprint for your workloads.
- BigQuery: a serverless cloud data warehouse which supports querying of large, petabyte-scale datasets. By supporting many users on a large, multi-tenanted infrastructure, BigQuery efficiently utilizes computing resources through massive economies of scale. The BigQuery architecture separates storage and compute, which efficiently allocates computing resources to scale data storage separately from query execution. BigQuery dynamically assigns computing resources (called slots) as needed to run queries. Fair scheduling automatically reallocates slot capacity across projects and running queries as needed.
You might have other workloads that still require VMs. When VMs are necessary, avoid over-provisioning beyond what you need, and avoid leaving unused resources running, which can lead to increased costs and emissions.
Minimize idle cloud resources
You might observe that cost optimization practices that reduce idle (or inefficient use of) cloud resources also translate well to carbon footprint reduction. Idle resources create wastage by incurring unnecessary costs and emissions. Consider the following forms of unused resources:
- Unused, active cloud resources, for example VM instances that aren't terminated when a workload has completed.
- Over-provisioned resources, for example using more VMs or larger VM machine types than necessary for a workload.
- Non-optimal architecture or workflow, for example lift-and-shift applications that were migrated to (but not optimized for) the cloud, or storage and compute infrastructure that isn't separated for data processing and analytics workloads.
Unused and over-provisioned VM resources usually have the most significant impact on unnecessary cost and increased carbon footprint. To minimize carbon footprint, consider how you can minimize idle VM capacity and other unused cloud resources through your workload automation, monitoring, and optimization processes. These topics are out of scope for this document; however, there are simple practices that can make a large impact on your costs and carbon footprint. Some of these practices are enabled by Active Assist, a solution that provides the following kinds of automated recommendations to optimize your cloud usage:
- Identify and delete idle VM resources: Regularly check for idle resource recommendations, such as unused disks, in the Google Cloud console. You can also view idle resource recommendations by using the gcloud CLI or through the API. After you ensure that the idle resources are no longer needed, you can delete them to save on costs and emissions.
- Rightsize VM instances: Optimally size VMs according to their resource usage by regularly checking for rightsizing recommendations in the Google Cloud console. Rightsizing can help address wastage due to overprovisioning. Rightsizing recommendations can also be viewed using the gcloud CLI or the API.
- Identify and delete idle VMs: Use the idle VM recommender to help identify VM instances that have not been used. You can delete idle VMs after ensuring that they're no longer needed.
- Reclaim or remove unattended projects: Use the unattended project recommender to help discover unattended projects with low or no usage, and where possible shut down these projects.
- Schedule VMs to run when they're needed: If VMs are needed only at certain times, consider scheduling VM instances to automatically start and stop.
- Remediate idle and over-provisioned Cloud SQL instances: Use Active Assist to identify over-provisioned and idle Cloud SQL for MySQL, PostgresSQL, and SQL Server instances. Once identified, you can resize or delete those instances.
Non-optimal architecture leads to less efficient use of cloud resources. Although architectural issues can occur with applications that are built for the cloud, these issues most commonly occur with on-premises workloads. For example monolithic applications that were migrated to Google Cloud, with no or minimal optimization (commonly referred to as lift-and-shift). The following practices can help you to optimize your architecture:
- Create resources when they're needed: Although cloud resources are elastic, you gain limited efficiency benefits if workloads are deployed to fixed resources that run continuously, regardless of actual usage. Identify opportunities to create (and delete) resources as they're needed, such as using VM scheduling or elastic features within cloud services. Use of elastic features include using Compute Engine to autoscale VMs that run stateless web servers, or using Dataflow to autoscale workers for a streaming data pipeline.
- Containerize workloads: Consider packaging your workloads into containers, and using a container orchestrator like Google Kubernetes Engine (GKE) to run the containers efficiently. When you use GKE, you can efficiently schedule containers across a cluster of VMs based on their resourcing requirements. Multiple containers can also share the resources of a single VM, if their resourcing requirements allow.
Migrate for GKE and GKE Enterprise provides a simplified pathway for workload migration from VMs to containers. Migrating VMs to containers can be a first step toward application modernization. Later steps can involve cost optimization practices that also reduce emissions, and refactoring applications into microservices.
If you need complete configuration flexibility and control over container orchestration, consider using GKE. If you need to run a containerized web application or microservice, and if you don't require a full Kubernetes environment, consider using Cloud Run. Cloud Run abstracts the complexity of running containers, and instead focuses on providing an enhanced experience to developers. For a more detailed comparison, see Google Kubernetes Engine vs Cloud Run.
Refactor monolithic applications into microservices: Monolithic applications combine all of their modules into a single program, which makes it difficult to allocate resources to run specific modules. Monolithic applications can therefore be challenging to run and scale efficiently, and might therefore have a larger carbon footprint as compared to a microservices-based implementation.
Consider a monolithic ecommerce website that has a shopping cart service and a payment service. Users might interact with the shopping cart service multiple times in a session, and interact with the payment service only at the end of a session. The two services have different resourcing requirements due to different traffic and load characteristics, but they cannot be run separately because they're both part of the same monolithic application. If the monolith runs on VMs, each additional VM adds compute resources to run both services, even if only one service needs to increase serving capacity.
In contrast to monoliths, microservices separate application modules into their own lightweight programs that are integrated using network calls. Microservices can be scaled independently of each other, and they use different resource shapes (for example, VM machine types, Cloud Run vCPU and memory allocations, or App Engine instance types) that are suitable for running that service. Microservice scaling results in more efficient use of cloud resources through granular scaling and decreased over-provisioning, which results in lower costs and emissions. For more information, see Refactoring a monolith into microservices.
Use cloud services that decouple storage and compute resources: Some on-premises (and cloud-based) data processing and analytics workloads, such as Apache Hadoop and Apache Spark, often share the same infrastructure for data storage and compute. If you maintain a large infrastructure footprint to store data, while you have to size that same footprint for peak compute requirements, then compute resource utilization is often low. Low utilization results in more idle resources, which increases costs and unnecessarily generates more emissions.
When you migrate these workloads to Google Cloud, we recommend that you use managed services that separate storage and compute infrastructure, such as the following:
- BigQuery: BigQuery is a serverless, petabyte-scale data warehouse as a service. You can use BigQuery for SQL-based analytics workloads. Dataset storage within BigQuery is decoupled from the compute resources. This separation means that BigQuery storage is scaled to provide virtually limitless storage in a way that uses resources efficiently. It also means that datasets can be shared in place without duplicating data or spinning up a new cluster.
- Dataproc: Dataproc is a managed service for Hadoop and Spark workloads. Many on-premises Hadoop and Spark deployments use compute clusters that are always-on, independent of usage characteristics. Although you can create long-lived clusters using Dataproc, we recommend that you create ephemeral clusters when you need to run jobs. Data that is read or written by Dataproc jobs is maintained separately in dedicated storage services, such as Cloud Storage and Bigtable. By eliminating the need to maintain an environment for Hadoop storage, even when no jobs are running, you reduce operational complexity, costs, and emissions.
- Spanner: Spanner is a distributed, globally scalable SQL database service that decouples compute from storage, which makes it possible to scale these resources separately. You can also automatically scale the number of compute resource nodes for Spanner instances using the Autoscaler tool. Autoscaling Spanner deployments enables your infrastructure to automatically adapt and scale to meet load requirements, and helps with reducing costs and carbon emissions when there are low loads.
Migrate workloads to managed services: Managed offerings can minimize unused resources by automatically scaling workloads, and they offer other features that can reduce your infrastructure requirements. For more information, see Choose the most suitable cloud service earlier in this document.
Reduce emissions for batch workloads
Unlike many online serving workloads, batch workloads are often flexible in terms of where and when they run. Examples of batch workloads include high-performance computing (HPC) jobs for scientific calculations, running daily account reconciliations, or generating product recommendations for marketing emails.
Similar to other workloads, we recommend that you run batch workloads in regions with higher CFE% to lower your overall carbon footprint. If there is flexibility on when batch jobs should run, you might be able to further reduce your carbon footprint by running jobs at times that coincide with lower grid carbon intensity. To view hourly, grid-mix, carbon-intensity data at different global locations where Google Cloud regions are located, use the electricityMap website, which is maintained by Tomorrow.
Batch workloads should be latency insensitive by definition, although there can be dependencies on related systems (such as data sources and sinks) that create undesirable networking overhead. This dependency might exist for jobs that are part of a larger application or workflow, for example an Extract, Transform, and Load (ETL) job that reads data from one or more source systems, and then writes transformed data to a data warehouse. If the ETL job processes and transfers large quantities of data between cloud regions, it might be impractical or costly to run jobs separately due to network performance impact and increased cross-region egress costs.
We recommend that you run the following types of batch workloads in Low CO2 regions:
- Standalone batch workloads: Consider a standalone HPC workload where you choose the region with the best price and emissions characteristics for your needs, use storage and compute services in that region, and download the analysis results directly. In this scenario, there is no cross-region traffic that might cause network performance penalties or network egress costs beyond retrieving the analysis results.
Batch workloads that require minimal data transfer with other cloud regions: Consider an API that serves product recommendations from a machine learning (ML) model. The API might be hosted in multiple cloud regions for low-latency serving to users. The ML models might be trained periodically from clickstream data from browsers as a centralized batch process, and copied to each cloud region where the API is hosted. In this scenario, the output model artifacts from training jobs are small, perhaps tens of megabytes in size.
In this scenario, clickstream data for training ML models is sent directly from browsers to the cloud region that hosts the ML backend. When the ML backend trains a new set of models, the data transfer for copying the models to other cloud regions is relatively small (perhaps in the low hundreds of megabytes if ten models need to be copied).
The following table summarizes the recommendations for reducing your Google Cloud carbon footprint:
|Understand cloud carbon emissions||
Understand how carbon free energy percentage (CFE%) describes the carbon-free energy consumption of cloud regions.
Understand the primary strategies for reducing your carbon footprint.
|Understand your carbon footprint||Use the Carbon Footprint tool to help you understand the carbon footprint from your Google Cloud usage.|
|Choose the most suitable cloud regions||
Use the Google Cloud Region Picker to determine the best cloud regions according to carbon footprint, price, and latency as relative considerations.
Consider creating organizational policies to restrict usage to Low CO2 regions.
|Choose the most suitable cloud services||
Migrate VMs from less efficient on-premises data centers to Compute Engine.
Use cloud managed services that are optimized for specific workloads instead of self-managed VMs.
|Minimize unused cloud resources||
Use Active Assist features to delete unused VMs, optimize VM shapes, and shut down unattended projects.
Identify opportunities to create (and delete) cloud resources as they're needed, instead of keeping them perpetually.
Schedule VMs to start and stop according to when they're needed.
Migrate workloads to containers, and run them efficiently using managed services such as Cloud Run and GKE.
Refactor monolithic applications to microservices to gain efficiency benefits.
Use services that decouple compute and storage for data processing and analytics.
Migrate existing VM workloads to managed services.
|Reduce emissions for batch workloads||
Run batch workloads that have minimal or no cross-region egress in low CO2 regions.
Run batch workloads during times of day coinciding with lower grid carbon intensity where possible.
- Read the Google Cloud Carbon Footprint dashboard documentation.
- Read more about Google's progress toward 24/7 Carbon-Free Energy.
- For more reference architectures, diagrams, and best practices, explore the Cloud Architecture Center.