Reduza a pegada de carbono no Google Cloud

Last reviewed 2021-10-11 UTC

Neste documento, explicamos a abordagem do Google Cloud em relação à sustentabilidade ambiental. Ele inclui informações e outros recursos que podem ser usados para entender sua pegada de carbono no Google Cloud, além de métodos que podem ser usados para reduzir ou minimizar essa pegada. O público-alvo deste documento inclui o seguinte:

Desenvolvedores que querem criar aplicativos com um volume mínimo de carbono.
Infraestrutura e outras equipes técnicas que querem entender a pegada de carbono atual e identificar oportunidades para reduzir essas pegadas.

Neste documento, presumimos que você esteja familiarizado com o Google Cloud e com a execução de cargas de trabalho de máquinas virtuais (VM).

Entenda as emissões de carbono da nuvem

O Google é neutro em carbono desde 2007 e tem o compromisso de operar com 100% de carbono energia gratuita 24 horas por dia até 2030. Os data centers do Google, incluindo aqueles que executam serviços do Google Cloud, também usam muito menos energia do que os data centers comuns. Por esse motivo, o uso do Google Cloud pode ajudar a reduzir a emissão de carbono da sua TI hoje.

O Google opera várias regiões de nuvem, que são entregues por meio de uma rede global de data centers. Esses data centers consomem eletricidade gerada pela grade local para executar serviços de nuvem. O impacto ambiental da eletricidade gerada pela rede local é medido pela intensidade do carbono na grade. A intensidade da emissão de carbono indica a quantidade de carbono emitida pelas usinas que geram eletricidade para a rede.

O impacto ambiental não é igual em todos os locais de data centers devido a fatores como variação de energia e eficiência de produção. Desde 2017, o Google também adquire energia renovável igual à eletricidade que consome globalmente no mesmo ano usando contratos de compra de energia (PPAs). Esses PPAs resultam na produção de energia livre de carbono, atribuível ao Google, que entra nas redes de consumo de eletricidade dos nossos data centers.

O impacto ambiental da eletricidade consumida pelos data centers do Google é determinado pela combinação da intensidade do carbono da matriz e da energia de fontes de energia sem emissão de carbono atribuídas ao Google. O Google apresentou a métrica de porcentagem de energia livre de carbono (CFE, na sigla em inglês), calculada a partir desses dois elementos. O CFE descreve o consumo médio de energia livre de carbono por hora e representa a porcentagem média de tempo que seu aplicativo funciona com energia livre de carbono. Devido a um fornecimento de energia mais limpo, as regiões com um CFE% mais alto produzem menos emissões de carbono do que as regiões que têm um CFE% mais baixo para a mesma carga de trabalho.

Para diminuir as emissões de carbono, é preciso reduzir o consumo de eletricidade das cargas de trabalho na nuvem provenientes de fontes baseadas em carbono. Para reduzir a emissão de carbono, recomendamos as seguintes estratégias principais:

Escolha regiões de nuvem com uma CFE média mais alta por hora e menor intensidade de carbono em grade. Para regiões com o mesmo CFE%, use a intensidade do carbono da grade para comparar ainda mais o desempenho de emissões dessas regiões.
Otimize as cargas de trabalho na nuvem para reduzir a emissão de carbono. Por exemplo, aumente a eficiência usando serviços de nuvem elástica e recursos de escalonamento automático para minimizar recursos de computação não utilizados e execute cargas de trabalho em lote durante períodos em que a intensidade do carbono da grade é menor.
Defina políticas organizacionais para restringir a localização de recursos da nuvem para regiões mais limpas.

Entenda sua pegada de carbono

O Google Cloud oferece a pegada de carbono, uma ferramenta para ajudar você a entender a pegada de carbono do uso do Google Cloud. A Emissão de Carbono fornece a totalidade das emissões de acordo com a intensidade da emissão de carbono na grade da eletricidade elétrica. O relatório atribui ainda mais emissões aos projetos do Google Cloud de sua propriedade e aos serviços de nuvem usados. Os dados de emissões são relatados de acordo com a metodologia de relatórios da Pegada de carbono do Google e podem ajudar com o Padrão de Escopo 3 do Protocolo de Greenhouse Gas (GHG, na sigla em inglês) } relatórios como um cliente do Google Cloud. É possível exportar os dados do Carbon Footprint para o BigQuery para uma análise mais detalhada.

Use o painel do Carbon Footprint e o BigQuery Export para ajudar a entender suas emissões com base na localização usando os serviços do Google Cloud. Use esses dados para comparar a pegada de carbono de diferentes serviços do Google Cloud. Por exemplo, para entender as emissões relativas deles, compare o total de emissão de dois ou mais serviços em execução na mesma região da nuvem.

Os dados brutos de emissões de gases do efeito estufa específicos do cliente do Google Cloud fornecidos pelo Relatório de emissão de carbono não foram verificados nem garantidos por terceiros.

Escolha as regiões de nuvem mais adequadas

Escolher regiões de nuvem mais limpas para executar cargas de trabalho é uma das maneiras mais simples e eficazes de reduzir a emissão de carbono. O Google publica dados de carbono de todas as regiões da nuvem, incluindo a CFE% e a intensidade da emissão de carbono da grade da eletricidade local. Para reduzir as emissões gerais, recomendamos que você escolha regiões com um CFE mais alto sempre que possível. Para ajudar você a escolher regiões mais limpas, o Google Cloud inclui um indicador Baixo CO2 em alguns dos seletores de local do Console do Google Cloud e nas páginas "Locais" do Google Cloud. Para informações sobre os critérios que uma região precisa atender para receber esse indicador, consulte Energia livre de carbono nas regiões do Google Cloud.

Quando várias regiões tiverem um CFE% semelhante, compare a intensidade do carbono da grade. Comparar a intensidade da emissão de carbono na grade de diferentes regiões também é importante se você estiver se concentrando nas reduções de emissões de acordo com a localização. Por exemplo, para uma pontuação de CFE% semelhante, a grade pode ser alimentada por usinas de carvão ou usinas a gás. A intensidade da emissão de carbono reflete essa combinação e ajuda a selecionar a menor grade de emissão de carbono.

A redução de emissões pode ser um de muitos requisitos que você precisa equilibrar ao escolher uma região. Por exemplo, talvez seja necessário considerar a disponibilidade de serviços, preços, requisitos de local de dados e latência específicos de Google Cloud para seus usuários. A região com o CFE% mais alto pode não ser adequada para seu caso de uso. Para garantir a menor emissão de carbono, selecione a região que tem o CFE mais alto e que atende a todos os seus requisitos.

Para simplificar a seleção de região, use o Seletor de região do Google Cloud para determinar as melhores regiões de nuvem que atendem aos seus requisitos com base na presença de carbono, no preço e na latência. Para mais informações sobre o seletor de região do Google Cloud, consulte Escolha a região certa para o Google Cloud.

Se sua organização oferece uma opção de usuário para quais regiões da nuvem usar, você também pode definir uma política da organização para restringir locais a regiões de CO2 baixo.

Escolha os serviços de nuvem mais adequados

O Google Cloud oferece uma variedade de serviços em nuvem adequados para diferentes cargas de trabalho de TI. Para ajudar a reduzir a pegada de carbono, considere migrar cargas de trabalho da VM para o Compute Engine de uma infraestrutura menos econômica, como um data center no local. Para informações sobre como migrar VMs para o Google Cloud de data centers no local e vários ambientes de nuvem, consulte Jornada de migração com o Migrate to Virtual Machines.

Muitas cargas de trabalho não exigem VMs, e é possível implantá-las em outros serviços totalmente gerenciados destinados a diferentes tipos de carga de trabalho. Esses serviços geralmente têm recursos automáticos de escalonamento e redimensionamento que ajudam a otimizar o desempenho e o uso de recursos para você. Por exemplo, o Cloud Run é um ambiente totalmente sem servidor que escalona aplicativos em contêineres mais rapidamente e com menos recursos inativos do que executando uma pilha de aplicativos comparável em VMs. Ter menos recursos inativos resulta em custos otimizados e redução na pegada de carbono.

Considere as seguintes ofertas para tipos de carga de trabalho comuns. A lista de serviços não é completa, mas explica como diferentes serviços gerenciados podem otimizar o uso de recursos da nuvem, geralmente automaticamente, o que reduz simultaneamente os custos em nuvem e a pegada de carbono.

Cloud Run: uma oferta sem servidor para executar aplicativos em contêineres, escrito na linguagem de sua escolha. Ele conta com escalonamento automático rápido do aplicativo de zero a N instâncias de contêiner, dependendo do tráfego. Se não houver tráfego, o aplicativo não usará recursos de computação para exibição. O serviço foi projetado para lidar com padrões de tráfego em bursts e otimizar o uso de recursos de computação conforme necessário.
Cloud Functions: uma oferta de funções como serviço (FaaS) sem servidor. Ele é executado na mesma infraestrutura que o Cloud Run e o App Engine, que estende a mesma funcionalidade de escalonamento automático do zero e rápido para o Cloud Functions.
Google Kubernetes Engine (GKE): um serviço de nuvem que fornece ambientes gerenciados do Kubernetes. Em comparação com o uso direto da VM, a execução de cargas de trabalho em contêiner usando ambientes do Kubernetes no GKE pode minimizar recursos de nuvem não utilizados, o que resulta na diminuição dos custos de nuvem e em uma menor pegada de carbono nas cargas de trabalho.
BigQuery: um armazenamento de dados na nuvem sem servidor compatível com consulta de grandes conjuntos de dados em escala de petabytes. Ao oferecer suporte a muitos usuários em uma infraestrutura grande e multilocatária, o BigQuery usa com eficiência recursos de computação por meio de economias maciças de escala. A arquitetura do BigQuery separa o armazenamento e a computação, que aloca recursos de computação de modo eficiente para escalonar o armazenamento de dados separadamente da execução da consulta. O BigQuery atribui dinamicamente os recursos de computação (chamados de slots) conforme necessário para executar consultas. A programação justa aloca automaticamente a capacidade do slot entre projetos e executa consultas conforme necessário.

Talvez você tenha outras cargas de trabalho que ainda precisem de VMs. Quando as VMs forem necessárias, evite o provisionamento excessivo além do que você precisa e evite manter recursos não utilizados, o que pode levar a um aumento de custos e emissões.

Minimize os recursos inativos da nuvem

Você pode observar que as práticas de otimização de custos que reduzem o uso inativo ou ineficiente de recursos da nuvem também têm bons resultados na redução da pegada de carbono. Os recursos inativos criam desperdício por incorrer em custos e emissões desnecessários. Considere as seguintes formas de recursos não utilizados:

Recursos de nuvem ativos e não usados, como instâncias de VM que não são encerradas quando uma carga de trabalho é concluída.
Recursos com provisionamento excessivo, por exemplo, usando mais VMs ou tipos de máquina de VM maiores do que o necessário para uma carga de trabalho.
Arquitetura ou fluxo de trabalho não ideal, por exemplo, aplicativos lift-and-shift que foram migrados para a nuvem, mas não otimizados para ela, ou infraestrutura de armazenamento e computação que não é separado para cargas de trabalho de processamento de dados e análise.

Os recursos de VM não utilizados e sobreprovisionados geralmente têm o impacto mais significativo no custo desnecessário e no aumento da pegada de carbono. Para minimizar a presença de carbono, pense em como minimizar a capacidade da VM inativa e outros recursos de nuvem não utilizados por meio dos processos de automação, monitoramento e otimização de carga de trabalho. Esses tópicos estão fora do escopo deste documento. No entanto, existem práticas simples que podem ter um grande impacto nos seus custos e na emissão de carbono. Algumas dessas práticas são ativadas pelo Active Assist, uma solução que fornece os seguintes tipos de recomendações automatizadas para otimizar seu uso na nuvem:

Identificar e excluir recursos de VM inativa: verifique regularmente recomendações sobre recursos inativos, como discos não utilizados, no Console do Google Cloud. Também é possível ver recomendações de recursos inativos usando a CLI gcloud ou por meio da API. Depois de garantir que os recursos de inatividade não sejam mais necessários, é possível excluí-los para economizar custos e emissões.
Dimensionar as instâncias de VM: dimensione as VMs de maneira ideal de acordo com o uso de recursos verificando regularmente as recomendações de redimensionamento no console do Google Cloud. Isso pode ajudar a resolver o desperdício devido ao superprovisionamento. As recomendações de redimensionamento também podem ser visualizadas usando a CLI gcloud ou a API.
Identificar e excluir VMs inativas: use o recomendador de VM inativa para ajudar a identificar instâncias de VM que não foram usadas. É possível excluir VMs inativas após garantir que elas não sejam mais necessárias.
Recuperar ou remover projetos autônomos: use o recomendador de projetos autônomos para ajudar a descobrir projetos autônomos com uso baixo ou nenhum uso e, quando possível, encerre esses projetos.
Programe VMs para serem executadas quando elas forem necessárias: se as VMs forem necessárias apenas em determinados momentos, considere programar instâncias de VM para iniciar e interromper automaticamente.
Corrigir instâncias do Cloud SQL inativas e sobreprovisionadas: use o Active Assist para identificar Cloud SQL provisionado e inativo do Cloud SQL para Instâncias do MySQL, PostgresSQL e SQL Server. Depois de identificadas, é possível redimensionar ou excluir essas instâncias.

Uma arquitetura não ideal torna o uso de recursos da nuvem menos eficiente. Os problemas de arquitetura podem ocorrer com aplicativos criados para a nuvem, mas eles geralmente ocorrem com cargas de trabalho locais. Por exemplo, aplicativos monolíticos que foram migrados para o Google Cloud, sem otimização mínima ou mínima (normalmente chamada de migração lift-and-shift). As práticas a seguir podem ajudar a otimizar sua arquitetura:

Crie recursos quando forem necessários: ainda que os recursos de nuvem sejam elásticos, você terá benefícios de eficiência limitados se as cargas de trabalho forem implantadas e recursos fixos executados continuamente, independentemente do uso real. Identifique oportunidades para criar (e excluir) recursos conforme necessário, como usar a programação de VM ou recursos elásticos nos serviços de nuvem. Os recursos elásticos incluem o uso do Compute Engine para fazer o escalonamento automático de VMs que executam servidores da Web sem estado ou o uso do Dataflow para fazer o escalonamento automático dos workers em um pipeline de dados de streaming.
Colocar cargas de trabalho em contêineres: empacote as cargas de trabalho em contêineres e use um orquestrador de contêineres, como o Google Kubernetes Engine (GKE), para executar os contêineres com eficiência. de dados. Ao usar o GKE, é possível programar contêineres de maneira eficiente em um cluster de VMs com base nos requisitos de recurso. Vários contêineres também podem compartilhar os recursos de uma única VM, se os requisitos de recursos permitirem.

O Migrate for GKE and GKE Enterprise oferece um caminho simplificado para migração de cargas de trabalho de VMs para contêineres. A migração de VMs para contêineres pode ser o primeiro passo para a modernização de aplicativos. As próximas etapas podem envolver práticas de otimização de custos que também reduzem a emissão de carbono e refatoram aplicativos em microsserviços.

Se você precisar de flexibilidade e controle completos da configuração do contêiner, use o GKE. Se você precisar executar um aplicativo da Web ou um microsserviço em contêiner e não precisar de um ambiente completo do Kubernetes, use o Cloud Run. O Cloud Run abstrai a complexidade da execução de contêineres e, em vez disso, se concentra em fornecer uma experiência aprimorada aos desenvolvedores. Para uma comparação mais detalhada, consulte Google Kubernetes Engine x Cloud Run.

Refatorar aplicativos monolíticos em microsserviços: aplicativos monolíticos combinam todos os módulos em um único programa, o que dificulta a alocação de recursos para executar módulos específicos. Portanto, os aplicativos monolíticos podem ser difíceis de executar e escalonar com eficiência e, portanto, podem ter uma pegada de carbono maior em comparação com uma implementação baseada em microsserviços.

Imagine um site de comércio eletrônico monolítico que tem um serviço de carrinho de compras e um serviço de pagamento. Os usuários podem interagir com o serviço de carrinho de compras várias vezes em uma sessão e interagir com o serviço de pagamento apenas no final de uma sessão. Os dois serviços têm diferentes requisitos de recursos devido a diferentes características de tráfego e carga, mas não podem ser executados separadamente porque fazem parte do mesmo aplicativo monolítico. Se o aplicativo monolítico for executado em VMs, cada VM adicional adicionará recursos de computação para executar os dois serviços, mesmo que apenas um serviço precise aumentar a capacidade de serviço.

Ao contrário dos monolíticos, os microsserviços separam os módulos dos aplicativos nos próprios programas leves integrados por chamadas de rede. Os microsserviços podem ser escalonados independentemente entre si e usam diferentes formatos de recursos (por exemplo, tipos de máquina de VM, alocações de vCPU e memória do Cloud Run ou tipos de instância do App Engine) adequados para execução. esse serviço. O escalonamento de microsserviços resulta no uso mais eficiente dos recursos de nuvem por meio de escalonamento granular e menos provisionamento em excesso, o que resulta em custos e emissões mais baixos. Para mais informações, consulte Como refatorar um monolítico em microsserviços.
Use serviços de nuvem que separam o armazenamento e os recursos de computação: Algumas cargas de trabalho de processamento e análise de dados locais (e baseadas na nuvem), como Apache Hadoop e Apache Spark;, geralmente compartilham a mesma infraestrutura para armazenamento e computação de dados. Se você mantiver um volume de infraestrutura grande para armazenar dados e, ao mesmo tempo, tiver que dimensionar o mesmo volume para requisitos de pico de computação, o uso de recursos de computação geralmente é baixo. A baixa utilização resulta em mais recursos ociosos, o que aumenta os custos e gera desnecessariamente mais emissões.

Ao migrar essas cargas de trabalho para o Google Cloud, recomendamos que você use serviços gerenciados que separam a infraestrutura de armazenamento e computação, como:
- BigQuery: o BigQuery é um serviço de armazenamento de dados em escala de petabytes sem servidor como um serviço. É possível usar o BigQuery para cargas de trabalho de análise baseadas em SQL. O armazenamento de conjuntos de dados no BigQuery é separado dos recursos de computação. Essa separação significa que o armazenamento do BigQuery é escalonado para fornecer armazenamento praticamente ilimitado de uma forma que utilize os recursos de maneira eficiente. Isso também significa que os conjuntos de dados podem ser compartilhados no local sem duplicar dados ou ativar um novo cluster.
- Dataproc: o Dataproc é um serviço gerenciado para cargas de trabalho do Hadoop e do Spark. Muitas implantações locais do Hadoop e do Spark usam clusters de computação que estão sempre ativados, independentemente das características de uso. Embora seja possível criar clusters de longa duração usando o Dataproc, recomendamos que você crie clusters efêmeros quando precisar executar jobs. Os dados lidos ou gravados por jobs do Dataproc são mantidos separadamente em serviços de armazenamento dedicados, como Cloud Storage e Bigtable. Ao eliminar a necessidade de manter um ambiente para o armazenamento do Hadoop, mesmo quando nenhum job estiver em execução, você reduz a complexidade operacional, os custos e as emissões.
- Spanner: o Spanner é um serviço de banco de dados SQL distribuído e globalmente escalonável que separa a computação do armazenamento, o que possibilita escalonar esses recursos separadamente. Também é possível escalonar automaticamente o número de nós de recursos de computação para instâncias do Spanner usando a ferramenta de escalonador automático. O escalonamento automático de implantações do Spanner permite que sua infraestrutura se adapte e escalone automaticamente para atender aos requisitos de carga e ajuda a reduzir custos e emissões de carbono quando há baixa carga.
Migrar cargas de trabalho para serviços gerenciados: as ofertas gerenciadas podem minimizar recursos não utilizados ao escalonar automaticamente cargas de trabalho e oferecem outros recursos que podem reduzir seus requisitos de infraestrutura. Para mais informações, consulte Escolher o serviço de nuvem mais adequado anteriormente neste documento.

Reduza emissões para cargas de trabalho em lote

Ao contrário de muitas cargas de trabalho de exibição on-line, as cargas de trabalho em lote geralmente são flexíveis em termos de onde e quando são executadas. Exemplos de cargas de trabalho em lote incluem jobs de computação de alto desempenho (HPC) para cálculos científicos, execução de reconciliações diárias de conta ou geração de recomendações de produtos para e-mails de marketing.

Assim como outras cargas de trabalho, recomendamos executar cargas de trabalho em lote em regiões com maior CFE% para diminuir sua pegada de carbono geral. Se houver flexibilidade sobre quando os jobs em lote devem ser executados, será possível reduzir ainda mais a pegada de carbono executando jobs em momentos que coincidem com uma intensidade de carbono mais baixa. Para visualizar dados por hora, mistura de grade, intensidade de carbono em diferentes locais globais onde as regiões do Google Cloud estão localizadas, use o site tricityMap, que é mantido por Amanhã.

As cargas de trabalho em lote precisam ser insensíveis a latência por definição, embora existam dependências em sistemas relacionados (como fontes de dados e coletores) que criem sobrecarga de rede indesejável. Essa dependência pode existir para jobs que fazem parte de um aplicativo ou fluxo de trabalho maior, por exemplo, um job Extrair, Transformar e Carregar (ETL) para ler dados de um ou mais sistemas de origem e, em seguida, grava dados transformados em um armazenamento de dados. Se o job de ETL processa e transfere grandes quantidades de dados entre regiões da nuvem, pode ser impraticável ou caro executar jobs separadamente devido ao impacto no desempenho da rede e ao aumento dos custos de saída entre regiões.

Recomendamos que você execute os seguintes tipos de cargas de trabalho em lote nas regiões de CO2 baixo:

Cargas de trabalho em lote independentes: considere uma carga de trabalho de HPC independente em que você escolhe a região com as melhores características de preço e emissão para suas necessidades, use serviços de armazenamento e computação nessa região e faça o download dos resultados da análise diretamente. Nesse cenário, não há tráfego entre regiões que possa causar penalidades de desempenho de rede ou custos de saída de rede além da recuperação dos resultados da análise.
Cargas de trabalho em lote que requerem transferência de dados mínima com outras regiões da nuvem: considere uma API que atenda a recomendações de produtos de um modelo de machine learning (ML). A API pode ser hospedada em várias regiões de nuvem para exibir aos usuários uma latência baixa. Os modelos de ML podem ser treinados periodicamente com base nos dados da sequência de cliques dos navegadores como um processo em lote centralizado e copiados para cada região da nuvem em que a API está hospedada. Nesse cenário, os artefatos do modelo de saída dos jobs de treinamento são pequenos, talvez de dezenas de megabytes.

Nesse cenário, os dados da sequência de cliques para treinar modelos de ML são enviados diretamente dos navegadores para a região da nuvem que hospeda o back-end de ML. Quando o back-end de ML treina um novo conjunto de modelos, a transferência de dados para copiar os modelos a outras regiões da nuvem é relativamente pequena. Talvez isso ocorra nas poucas centenas de megabytes, se dez modelos precisarem ser copiados. de dados.

Recomendações

Veja na tabela a seguir um resumo das recomendações para reduzir a pegada de carbono do Google Cloud:

Tópico	Recomendações
Entenda as emissões de carbono da nuvem	Entenda como a porcentagem de energia livre de carbono (CFE, na sigla em inglês) descreve o consumo de energia livre de carbono nas regiões de nuvem. Entenda as principais estratégias para reduzir sua pegada de carbono.
Entenda sua pegada de carbono	Use a ferramenta pegada de carbono para ajudar a entender a pegada de carbono do uso do Google Cloud.
Escolha as regiões de nuvem mais adequadas	Use o Seletor de região do Google Cloud para determinar as melhores regiões de nuvem de acordo com a pegada de carbono, o preço e a latência como considerações relativas. Considere criar políticas organizacionais para restringir o uso a regiões de CO2 baixo.
Escolha os serviços de nuvem mais adequados	Migre VMs de data centers locais menos eficientes para o Compute Engine. Use serviços gerenciados em nuvem otimizados para cargas de trabalho específicas, em vez de VMs autogerenciadas.
Minimize os recursos não utilizados na nuvem	Use os recursos do Active Assist para excluir VMs não utilizadas, otimizar formatos de VM e encerrar projetos autônomos. Identifique oportunidades para criar (e excluir) recursos na nuvem conforme necessário, em vez de mantê-los permanentemente. Programe VMs para iniciar e parar de acordo com quando elas forem necessárias. Migre cargas de trabalho para contêineres e as execute com eficiência usando serviços gerenciados, como o Cloud Run e o GKE. Refatore aplicativos monolíticos para microsserviços para ter benefícios de eficiência. Use serviços que desacoplam computação e armazenamento para processamento de dados e análise. Migre as cargas de trabalho da VM para os serviços gerenciados.
Reduza emissões para cargas de trabalho em lote	Execute cargas de trabalho em lote que tenham saída mínima ou sem região entre as regiões de baixa CO2. Execute cargas de trabalho em lote durante os horários do dia com uma intensidade de carbono mais baixa sempre que possível.

A seguir

Leia a documentação do painel do Google Cloud Footprint.
Leia mais sobre o progresso do Google em direção à energia livre de carbono 24 horas.
Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.