Reduce your Google Cloud 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 Google Cloud customer-specific gross greenhouse gas emissions data provided by the Carbon Footprint report has not been third-party verified or assured.

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.

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.

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).

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 microservicesbased 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.