Reduce tu huella de carbono de Google Cloud

Last reviewed 2021-10-11 UTC

En este documento, se explica el enfoque de Google Cloud para la sustentabilidad ambiental. Incluye información y otros recursos que puedes usar para comprender tu huella de carbono en Google Cloud y los métodos que puedes usar para reducir o minimizar esa huella. El público previsto para este documento incluye los siguientes:

  • Desarrolladores que desean compilar aplicaciones que tengan una huella de carbono mínima
  • Equipos de infraestructura y otros equipos técnicos que deseen conocer su huella de carbono actual e identificar oportunidades para reducir esa huella

En este documento, se supone que estás familiarizado con Google Cloud y que ejecutas cargas de trabajo de máquinas virtuales (VM).

Comprende las emisiones de carbono de la nube

Google no tiene emisiones de carbono desde 2007 y se comprometió a operar con energía neutra de carbono en un 100% las 24 horas, todos los días, para el año 2030. Los centros de datos de Google, incluidos los que ejecutan los servicios de Google Cloud, también usan mucho menos energía que los centros de datos típicos. Por este motivo, el uso de Google Cloud puede ayudarte a reducir la huella de carbono de tu TI en la actualidad.

Google opera múltiples regiones de la nube, que se entregan a través de una red global de centros de datos. Estos centros de datos consumen electricidad generada por la red local para ejecutar los servicios en la nube. El impacto ambiental de la electricidad que genera la red local se mide mediante la intensidad de carbono de la red. La intensidad de la emisiones de carbono de la red indica cuánto carbono emiten las centrales eléctricas que generan electricidad para la red.

El impacto ambiental no es igual en todas las ubicaciones de los centros de datos, debido a factores como la diferencia de energía y la eficiencia de producción. Desde 2017, Google también obtiene energía renovable igual a la electricidad que consume a nivel global en el mismo año, mediante acuerdos de compra de energía (PPA). Estos PPA dan como resultado una producción de energía sin emisiones de carbono que se puede atribuir a Google, que ingresa a las redes desde las que nuestros centros de datos consumen electricidad.

El impacto ambiental de la electricidad que consumen los centros de datos de Google se determina mediante la combinación de la intensidad de la energía de carbono de la red y la energía de fuentes de energía sin emisiones de carbono que se atribuyen a Google. Google introdujo la métrica del porcentaje de energía sin emisiones de carbono (CFE%), que se calcula a partir de estos dos elementos. El CFE% describe el consumo promedio de energía sin emisiones de carbono por hora en cada región, y representa el porcentaje promedio de tiempo que tu aplicación ejecuta energía sin emisiones de carbono. Debido a un suministro de energía más limpia, las regiones que tienen un CFE% más alto producen menos emisiones de carbono que las regiones que tienen un CFE% más bajo para la misma carga de trabajo.

Para reducir tus emisiones de carbono, debes reducir el consumo de electricidad de tus cargas de trabajo en la nube desde fuentes basadas en carbono. Para reducir las emisiones de carbono, te recomendamos las siguientes estrategias principales:

  1. Elige regiones de nube con un CFE% promedio más alto por hora y una intensidad de emisiones de carbono más baja de la red. En las regiones que tienen el mismo CFE%, usa la intensidad de las emisiones de carbono de la red para comparar aún más el rendimiento de las emisiones de esas regiones.
  2. Optimiza las cargas de trabajo en la nube para reducir las emisiones de carbono. Por ejemplo, aumenta la eficiencia mediante servicios elásticos de la nube y funciones de ajuste de escala automático para minimizar los recursos de procesamiento sin usar, y ejecuta cargas de trabajo por lotes durante los momentos en que la intensidad de las emisiones de carbono de la red es menor.
  3. Configura políticas de la organización para restringir la ubicación de los recursos en la nube a regiones más claras

Obtén información sobre tu huella de carbono

Google Cloud proporciona Huella de carbono, una herramienta que te ayuda a comprender la huella de carbono de tu uso de Google Cloud. Huella de carbono proporciona las emisiones totales basadas en la intensidad de carbono de la red eléctrica local. El informe atribuye adicionalmente emisiones a los proyectos de Google Cloud que posees y a los servicios en la nube que usas. Los datos de emisiones se informan según laMetodología de informes de la huella de carbono de Google y puede ayudarte con los requisitos de información de la Iniciativa del Protocolo de Gases Efecto Invernadero en su alcance 3 como cliente de Google Cloud. Puedes exportar los datos de Huella de carbono a BigQuery para analizarlos en detalle.

Puedes usar el panel de huella de carbono y BigQuery Export para comprender tus emisiones basadas en la ubicación causadas por el uso de los servicios de Google Cloud. Puedes usar estos datos para comparar la huella de carbono de diferentes servicios de Google Cloud. Por ejemplo, para comprender las emisiones relativas, puedes comparar las emisiones totales de dos o más servicios que se ejecutan en la misma región de la nube.

Los datos sobre las emisiones de gases de efecto invernadero específico del cliente de Google Cloud que proporciona el informe de huella de carbono no están verificados ni por terceros.

Elige las regiones más adecuadas en la nube

Elegir regiones más limpias en la nube para ejecutar cargas de trabajo es una de las formas más simples y efectivas de reducir las emisiones de carbono. Google publica datos de carbono para todas las regiones de la nube, incluido el CFE% y la intensidad de carbono de la red eléctrica local. Para reducir las emisiones generales, te recomendamos que elijas regiones con mayor CFE% cuando sea posible. Para ayudarte a elegir regiones más limpias, Google Cloud incluye un indicador de CO2 bajo en algunos de los selectores de ubicaciones de la consola de Google Cloud y las páginas "Ubicaciones" de la documentación de Google Cloud. Si deseas obtener información sobre los criterios que una región debe cumplir para recibir este indicador, consulta Energía sin emisiones de carbono para regiones de Google Cloud.

Cuando varias regiones tienen un CFE% similar, compara su intensidad de emisiones de carbono de la red. También es importante comparar la intensidad de emisiones de carbono de la red entre diferentes regiones si te enfocas en las reducciones de emisiones basadas en la ubicación. Por ejemplo, para una puntuación de CFE% similar, la red podría operar con centrales eléctricas a base de carbón o centrales eléctricas a base de gas. La intensidad de la emisiones de carbono de la red refleja esta mezcla y te ayuda a seleccionar la red con las emisiones de carbono más bajas.

La disminución de las emisiones puede ser uno de los numerosos requisitos que debes seguir cuando eliges una región. Por ejemplo, es posible que debas considerar la disponibilidad de los servicios específicos de Google Cloud, los precios, los requisitos de ubicación de datos y la latencia de la entrega a tus usuarios. Es posible que la región con el CFE% más alto general no sea adecuada para tu caso de uso. Para garantizar las emisiones más bajas, selecciona la región que tiene el CFE% más alto y que cumpla con todos tus requisitos.

A fin de simplificar la selección de regiones, usa el Selector de regiones de Google Cloud para determinar las mejores regiones en la nube que cumplen con tus requisitos en función de la huella de carbono, el precio y la latencia. Para obtener más información sobre el selector de región de Google Cloud, consulta Elige la región de Google Cloud adecuada para ti.

Si tu organización proporciona una opción a los usuarios para qué regiones de la nube usar, también puedes considerar configurar una política de la organización de restricción de ubicaciones en regiones con CO2 bajo.

Elige los servicios más adecuados en la nube

Google Cloud ofrece una gama de servicios en la nube que se adaptan a diferentes cargas de trabajo de TI. Para ayudar a reducir tu huella de carbono existente, considera migrar las cargas de trabajo de VM a Compute Engine desde una infraestructura de menor eficiencia energética, como un centro de datos local. Para obtener información sobre cómo migrar VMs a Google Cloud desde centros de datos locales y varios entornos de nube, consulta Recorrido de migración con Migrate to Virtual Machines.

Muchas cargas de trabajo no requieren VM y, en su lugar, puedes implementarlas en otros servicios completamente administrados destinados a diferentes tipos de cargas de trabajo. Estos servicios suelen tener funciones integradas de ajuste de escala automático y redimensionamiento que ayudan a optimizar el rendimiento y el uso de recursos por ti. Por ejemplo, Cloud Run es un entorno completamente sin servidores que escala las aplicaciones alojadas en contenedores más rápido y con menos recursos inactivos en comparación con la ejecución de una pila de aplicaciones comparable en VM. Tener menos recursos inactivos genera costos optimizados y reduce la huella de carbono.

Considera las siguientes ofertas para los tipos de cargas de trabajo comunes. La lista de servicios no es exhaustiva, pero explica cómo los diferentes servicios administrados pueden optimizar el uso de recursos en la nube (a menudo, automáticamente), lo que reduce los costos de la nube y la huella de carbono de forma simultánea.

  • Cloud Run: Es una oferta sin servidores para ejecutar aplicaciones alojadas en contenedores, escrita en el lenguaje que elijas. Ofrece un ajuste de escala automático rápido de tu aplicación de cero a N instancias de contenedor según el tráfico. Si no hay tráfico, la aplicación no usa recursos de procesamiento para la entrega. El servicio está diseñado para controlar patrones de tráfico inestables y optimizar el uso de los recursos de procesamiento en consecuencia.
  • Cloud Functions: Es una oferta de funciones como servicio (FaaS) sin servidores. Se ejecuta en la misma infraestructura que Cloud Run y App Engine, que extiende la misma funcionalidad de ajuste de escala automático rápido y escala desde cero a Cloud Functions.
  • Google Kubernetes Engine (GKE): Es un servicio de nube que proporciona entornos de Kubernetes administrados. En comparación con el uso directo de VM, la ejecución de cargas de trabajo alojadas en contenedores mediante entornos de Kubernetes en GKE puede minimizar los recursos en la nube sin usar, lo que genera costos de nube reducidos y una huella de carbono más pequeña para tus cargas de trabajo.
  • BigQuery: Es un almacén de datos en la nube sin servidores que admite consultas de conjuntos de datos grandes a escala de petabytes. BigQuery admite de manera eficiente muchos usuarios en una infraestructura grande de múltiples usuarios mediante los recursos de procesamiento a través de economías de escala masivas. La arquitectura de BigQuery separa el almacenamiento y el procesamiento, que asigna de manera eficiente los recursos de procesamiento para escalar el almacenamiento de datos por separado desde la ejecución de consultas. BigQuery asigna de forma dinámica recursos de procesamiento (llamados ranuras) según sea necesario para ejecutar consultas. La programación equilibrada reasigna la capacidad de las ranuras de forma automática entre los proyectos y ejecuta consultas según sea necesario.

Es posible que tengas otras cargas de trabajo que aún requieran VM. Cuando las VM sean necesarias, evita el aprovisionamiento en exceso más allá de lo que necesitas y evita dejar en ejecución los recursos que no se usan, lo que puede generar mayores costos y emisiones.

Minimiza los recursos inactivos en la nube

Es posible que observes que las prácticas de optimización de costos que reducen los recursos inactivos (o ineficientes) de la nube también se traducen bien a una reducción de la huella de carbono. Los recursos inactivos crean desperdicio debido a emisiones y costos innecesarios. Considera las siguientes formas de recursos sin usar:

  1. Recursos de nube activos y sin usar, por ejemplo, instancias de VM que no se finalizan cuando se completa una carga de trabajo.
  2. Recursos aprovisionados en exceso, por ejemplo, que usan más VM o tipos de máquinas de VM más grandes de lo necesario para una carga de trabajo.
  3. Arquitectura o flujo de trabajo no óptimos, como aplicaciones lift-and-shift que se migraron a la nube (pero no están optimizadas para esta), o infraestructura de almacenamiento y procesamiento que no está separada para las cargas de trabajo de estadísticas y el procesamiento de datos.

Los recursos de VM sin usar y aprovisionados en exceso suelen tener el impacto más significativo en el costo innecesario y el aumento de la huella de carbono. Para minimizar la huella de carbono, considera cómo puedes minimizar la capacidad de la VM inactiva y otros recursos de nube sin usar a través de los procesos de automatización, supervisión y optimización de las cargas de trabajo. Estos temas están fuera del alcance de este documento; sin embargo, existen prácticas simples que pueden tener un gran impacto en los costos y la huella de carbono. Active Assist, que habilita algunas de estas prácticas, es una solución que proporciona los siguientes tipos de recomendaciones automatizadas para optimizar el uso de la nube:

  1. Identificar y borrar los recursos de VM inactivos: verifica con regularidad si hay recomendaciones de recursos inactivos, como los discos sin usar, en la consola de Google Cloud. También puedes ver recomendaciones de recursos inactivos mediante gcloud CLI o la API. Después de asegurarte de que los recursos inactivos ya no son necesarios, puedes borrarlos para ahorrar costos y emisiones.
  2. Instancias de VM de tamaño adecuado: ajusta el tamaño de VM de forma óptima según su uso de recursos mediante la verificación periódica de recomendaciones de redimensionamiento en la consola de Google Cloud. El redimensionamiento puede ayudar a abordar el desperdicio debido al aprovisionamiento en exceso. Las recomendaciones de redimensionamiento también se pueden ver mediante gcloud CLI o la API.
  3. Identificar y borrar las VM inactivas: Usa el recomendador de VM inactivas para ayudar a identificar las instancias de VM sin usar. Puedes borrar las VM inactivas después de asegurarte de que ya no son necesarias.
  4. Reclama o quita proyectos sin supervisión: Usa el recomendador de proyectos sin supervisión para ayudar a descubrir proyectos sin supervisión con un uso bajo o nulo, y cuando sea posible, cierra estos proyectos.
  5. Programar las VM para que se ejecuten cuando sean necesarias: Si se necesitan VM solo en ciertos momentos, considera programar las instancias de VM para que se inicien y se detengan de forma automática.
  6. Solucionar problemas de instancias de Cloud SQL inactivas y con aprovisionamiento excesivo: Usa Active Assist para identificar instancias de Cloud SQL para MySQL, PostgresSQL y SQL Server con aprovisionado en exceso e inactivas. Una vez identificadas, puedes cambiar el tamaño de esas instancias o borrarlas.

Una arquitectura no óptima conduce a un uso menos eficiente de los recursos en la nube. Aunque pueden ocurrir problemas arquitectónicos con las aplicaciones compiladas para la nube, estos problemas suelen ocurrir con cargas de trabajo locales. Por ejemplo, las aplicaciones monolíticas que se migraron a Google Cloud sin optimización o con una optimización mínima (comúnmente conocida como lift-and-shift). Las siguientes prácticas pueden ayudarte a optimizar tu arquitectura:

  1. Crea recursos cuando sean necesarios: Aunque los recursos en la nube son elásticos, obtienes beneficios de eficiencia limitados si las cargas de trabajo se implementan en recursos fijos que se ejecutan de forma continua, sin importar el uso real. Identifica oportunidades para crear (y borrar) recursos según sea necesario, como usar la programación de VM o las funciones elásticas dentro de los servicios en la nube. La utilización de características elásticas incluye el uso de Compute Engine a fin de aplicar el ajuste de escala automático a las VM que ejecutan servidores web sin estado o el uso de Dataflow para aplicar el ajuste de escala automático a los trabajadores en una canalización de datos de transmisión.
  2. Alojar cargas de trabajo en contenedores: Considera empaquetar tus cargas de trabajo en contenedores y usar un organizador de contenedores como Google Kubernetes Engine (GKE) a fin de ejecutar los contenedores de manera eficiente. Cuando usas GKE, puedes programar contenedores de manera eficiente en un clúster de VM según sus requisitos de recursos. Varios contenedores también pueden compartir los recursos de una sola VM, si sus requisitos de recursos lo permiten.

Migrate for GKE y GKE Enterprise proporciona una ruta simplificada para la migración de cargas de trabajo de VMs a contenedores. La migración de VM a contenedores puede ser un primer paso para la modernización de aplicaciones. Los pasos posteriores pueden incluir prácticas de optimización de costos que también reducen las emisiones y refactorizan las aplicaciones en microservicios.

Si necesitas flexibilidad total de configuración y control sobre la organización de los contenedores, considera usar GKE. Si necesitas ejecutar una aplicación web o un contenedor alojados en contenedores, y si no necesitas un entorno completo de Kubernetes, considera usar Cloud Run. Cloud Run simplifica la complejidad de la ejecución de contenedores y, en su lugar, se enfoca en proporcionar una experiencia mejorada a los desarrolladores. Para obtener una comparación más detallada, consulta Comparación entre Google Kubernetes Engine y Cloud Run.

  1. Refactoriza aplicaciones monolíticas en microservicios: Las aplicaciones monolíticas combinan todos sus módulos en un solo programa, lo que dificulta la asignación de recursos para ejecutar módulos específicos. Por lo tanto, las aplicaciones monolíticas pueden ser difíciles de ejecutar y escalar de manera eficiente, y pueden tener una huella de carbono más grande en comparación con una implementación basada en microservicios.

    Considera un sitio web monolítico de comercio electrónico que tenga un servicio de carrito de compras y un servicio de pagos. Los usuarios pueden interactuar con el servicio de carrito de compras varias veces en una sesión y, además, interactuar con el servicio de pagos solo al final de una sesión. Los dos servicios tienen diferentes requisitos de recursos debido a diferentes características de tráfico y carga, pero no se pueden ejecutar por separado porque ambos forman parte de la misma aplicación monolítica. Si la aplicación monolítica se ejecuta en VM, cada VM adicional agrega recursos de procesamiento para ejecutar ambos servicios, incluso si solo un servicio necesita aumentar la capacidad de entrega.

    A diferencia de las aplicaciones monolíticas, los microservicios separan los módulos de la aplicación en sus propios programas ligeros que se integran mediante llamadas a la red. Los microservicios se pueden escalar de forma independiente entre sí y usan diferentes formas de recursos (por ejemplo, tipos de máquina de VM, asignaciones de memoria y CPU virtual de Cloud Run, o tipos de instancias de App Engine) adecuados para ejecutar ese servicio. El escalamiento de microservicios da como resultado un uso más eficiente de los recursos de la nube a través del escalamiento detallado y una disminución del aprovisionamiento excesivo, lo que genera costos y emisiones más bajos. Para obtener más información, consulta Refactoriza una aplicación monolítica en microservicios.

  2. Usa los servicios en la nube que separan los recursos de procesamiento y de almacenamiento: Algunas cargas de trabajo de procesamiento y estadísticas de datos locales (y basadas en la nube), como Apache Hadoop y Apache Spark a menudo comparten la misma infraestructura para el almacenamiento y el procesamiento de los datos. Si mantienes una huella de infraestructura grande para almacenar datos, mientras tienes que dimensionar esa misma huella para los requisitos de procesamiento máximo, el uso de recursos de procesamiento suele ser bajo. El uso bajo genera más recursos inactivos, lo que aumenta los costos y genera más emisiones de forma innecesaria.

    Cuando migres estas cargas de trabajo a Google Cloud, te recomendamos que uses servicios administrados que separen el infraestructura de procesamiento y almacenamiento, como los siguientes:

    • BigQuery: BigQuery es un almacén de datos como servicio sin servidores a escala de petabytes. Puedes usar BigQuery para las cargas de trabajo de estadísticas basadas en SQL. El almacenamiento de conjunto de datos en BigQuery está separado de los recursos de procesamiento. Esta separación significa que el almacenamiento de BigQuery se escala para proporcionar un almacenamiento prácticamente ilimitado de tal manera que use los recursos de manera eficiente. También significa que los conjuntos de datos se pueden compartir en el lugar sin duplicar los datos ni iniciar un clúster nuevo.
    • Dataproc: Dataproc es un servicio administrado para cargas de trabajo de Hadoop y Spark. Muchas implementaciones locales de Hadoop y Spark usan clústeres de procesamiento que están siempre activos, sin importar las características de uso. Aunque puedes crear clústeres de larga duración con Dataproc, te recomendamos que crees clústeres efímeros cuando necesites ejecutar trabajos. Los datos que leen o escriben los trabajos de Dataproc se mantienen por separado en servicios de almacenamiento dedicados, como Cloud Storage y Bigtable. Cuando se elimina la necesidad de mantener un entorno para el almacenamiento de Hadoop, incluso cuando no se ejecutan trabajos, se reducen la complejidad operativa, los costos y las emisiones.
    • Spanner: Spanner es un servicio de base de datos SQL distribuido y escalable a nivel global que separa el procesamiento del almacenamiento, lo que permite escalar estos recursos por separado. También puedes escalar de forma automática la cantidad de nodos de recursos de procesamiento para instancias de Spanner mediante la herramienta del escalador automático. El ajuste de escala automático de las implementaciones de Spanner permite que la infraestructura se adapte y escale de forma automática para satisfacer los requisitos de carga, y ayuda a reducir los costos y las emisiones de carbono cuando hay cargas bajas.
  3. Migra cargas de trabajo a servicios administrados: Las ofertas administradas pueden minimizar los recursos sin usar mediante el ajuste de escala automático de las cargas de trabajo y ofrecen otras funciones que pueden reducir los requisitos de infraestructura. Para obtener más información, consulta Elige el servicio en la nube más adecuado en este documento.

Reduce las emisiones de las cargas de trabajo por lotes

A diferencia de muchas cargas de trabajo de entrega en línea, las cargas de trabajo por lotes suelen ser flexibles en términos de dónde y cuándo se ejecutan. Los ejemplos de cargas de trabajo por lotes incluyen trabajos de computación de alto rendimiento (HPC) para cálculos científicos, la ejecución de conciliaciones diarias de cuentas o la generación de recomendaciones de productos para correos electrónicos de marketing.

Al igual que con otras cargas de trabajo, recomendamos que ejecutes cargas de trabajo por lotes en regiones con un CFE% más alto para reducir tu huella de carbono general. Si existe flexibilidad sobre cuándo deben ejecutarse los trabajos por lotes, es posible que puedas reducir aún más tu huella de carbono mediante la ejecución de trabajos en momentos que coincidan con una intensidad menor de emisiones de carbono de la red. Para ver los datos de mezcla de red y de la intensidad de carbono por hora en diferentes ubicaciones globales donde se encuentran las regiones de Google Cloud, usa el sitio web de electricityMap, que mantiene Tomorrow.

Las cargas de trabajo por lotes deben ser sensibles a la latencia por definición, aunque pueden depender de sistemas relacionados (como fuentes de datos y receptores) que creen una sobrecarga de red no deseada. Esta dependencia puede existir para los trabajos que forman parte de una aplicación o un flujo de trabajo más grande, por ejemplo, un trabajo de extracción, transformación y carga (ETL) que lee datos desde uno o más sistemas de origen y, luego, escribe datos transformados en un almacén de datos. Si el trabajo de ETL procesa y transfiere grandes cantidades de datos entre regiones en la nube, podría ser costoso o no práctico ejecutar trabajos por separado debido al impacto en el rendimiento de la red y mayores costos de salida entre regiones.

Recomendamos que ejecutes los siguientes tipos de cargas de trabajo por lotes en regiones con bajo CO2:

  1. Cargas de trabajo independientes por lotes: Considera una carga de trabajo de HPC independiente en la que elijas la región con las mejores características de precios y emisiones para tus necesidades, usa servicios de almacenamiento y procesamiento en esa región y descarga los resultados del análisis directamente. En esta situación, no hay tráfico entre regiones que pueda causar penalizaciones de rendimiento de red o costos de salida de red, más allá de recuperar los resultados del análisis.
  2. Cargas de trabajo por lotes que requieren una transferencia de datos mínima con otras regiones en la nube: Considera una API que entregue recomendaciones de productos desde un modelo de aprendizaje automático (AA). Es posible que la API esté alojada en varias regiones de la nube para la entrega de baja latencia a los usuarios. Los modelos de AA se pueden entrenar de forma periódica desde los datos de flujo de clics de los navegadores como un proceso por lotes centralizado, y se copian en cada región de la nube en la que se aloja la API. En esta situación, los artefactos del modelo de salida de los trabajos de entrenamiento son pequeños, quizás de decenas de megabytes.

    En esta situación, los datos de flujo de clics para entrenar modelos de AA se envían directamente desde los navegadores a la región de la nube que aloja el backend de AA. Cuando el backend de AA entrena un conjunto nuevo de modelos, la transferencia de datos para copiar los modelos en otras regiones en la nube es relativamente pequeña (tal vez cientos de megabytes si se deben copiar diez modelos).

Recomendaciones

En la siguiente tabla, se resumen las recomendaciones para reducir tu huella de carbono de Google Cloud:

Tema Recomendaciones
Comprende las emisiones de carbono de la nube

Comprende cómo el porcentaje de energía sin emisiones de carbono (CFE%) describe el consumo de energía sin emisiones de carbono de las regiones de la nube.

Comprende las estrategias principales para reducir tu huella de carbono.

Obtén información sobre tu huella de carbono Usa la herramienta Huella de carbono para comprender la huella de carbono de tu uso de Google Cloud.
Elige las regiones más adecuadas en la nube

Usa el selector de región de Google Cloud para determinar las mejores regiones de la nube según la huella de carbono, el precio y la latencia como consideraciones relativas.

Considera crear políticas de la organización para restringir el uso a regiones con bajo nivel de CO2.

Elige los servicios más adecuados en la nube

Migra las VM de centros de datos locales menos eficientes a Compute Engine.

Usa servicios administrados en la nube que estén optimizados para cargas de trabajo específicas en lugar de VM autoadministradas.

Minimiza los recursos de nube sin usar

Usa las funciones de Active Assist para borrar las VM que no se usan, optimizar las formas de VM y cerrar los proyectos sin supervisión.

Identifica las oportunidades para crear (y borrar) los recursos de la nube según sea necesario, en lugar de mantenerlos perpetuamente.

Programa las VM para que se inicien y se detengan según sea necesario.

Migra cargas de trabajo a contenedores y ejecútalas de forma eficiente con servicios administrados, como Cloud Run y GKE.

Refactoriza aplicaciones monolíticas a microservicios para obtener beneficios de eficiencia.

Usa servicios que separan el procesamiento y el almacenamiento para el procesamiento y estadísticas de datos.

Migra las cargas de trabajo de VM existentes a servicios administrados.

Reduce las emisiones de las cargas de trabajo por lotes

Ejecuta cargas de trabajo por lotes que tengan una salida mínima o nula entre regiones con CO2 bajo.

Ejecuta cargas de trabajo por lotes durante momentos del día que coincidan con una menor intensidad de emisiones de carbono de la red siempre que sea posible.

¿Qué sigue?