GreenOps y cloud sostenible: medir y reducir la huella de carbono digital

El datacenter que no ves contamina igual

Cada consulta a una API, cada pipeline de CI/CD, cada modelo de machine learning entrenado consume electricidad. Esa electricidad genera emisiones. El sector tecnologico produce aproximadamente el 2-4% de las emisiones globales de CO2, una cifra comparable a la aviacion comercial. Y crece cada ano.

La diferencia con otros sectores es que estas emisiones son invisibles. Nadie ve el humo salir de una instancia EC2. Pero los 33 TWh que consumieron los datacenters de Amazon en 2023, o los 24 TWh de Google, son energia real con impacto real.

La pregunta ya no es si esto importa. La Directiva de Reporting de Sostenibilidad Corporativa (CSRD) de la UE obliga a las grandes empresas a reportar emisiones Scope 3 desde enero de 2025, y las medianas desde 2026. Tu proveedor cloud es Scope 3. Tu infraestructura digital ya forma parte de tu huella de carbono corporativa, lo sepas o no.

Que es GreenOps

GreenOps aplica la misma logica que FinOps (optimizacion financiera del cloud) pero con la dimension medioambiental anadida. Si FinOps pregunta “cuanto cuesta este workload?”, GreenOps pregunta “cuanto contamina este workload y que podemos hacer al respecto?”.

No son disciplinas separadas. En la practica, la mayoria de las optimizaciones de GreenOps reducen costes simultaneamente, porque el recurso mas barato es el que no consumes. Pero hay decisiones donde coste y carbono divergen, y ahi es donde GreenOps aporta un framework de decision distinto.

Los tres pilares de GreenOps son:

Medir. No puedes reducir lo que no mides. Esto requiere visibilidad sobre el consumo energetico y las emisiones asociadas a tu infraestructura.

Reducir. Optimizar la eficiencia de los workloads, eliminar recursos ociosos, y disenar arquitecturas que consuman menos.

Desplazar. Mover cargas de trabajo a momentos y regiones donde la electricidad es mas limpia.

Midiendo la huella de carbono digital

Las herramientas de los cloud providers

Los tres hyperscalers principales ofrecen herramientas nativas de medicion de carbono:

• AWS: Customer Carbon Footprint Tool. Muestra emisiones mensuales por servicio y region. Datos disponibles con 3 meses de retraso. No desglosa por recurso individual.
• Google Cloud: Carbon Footprint Dashboard. Datos por proyecto y region, actualizados mensualmente. Incluye energia total y mix de renovables por region. El mas granular de los tres.
• Azure: Emissions Impact Dashboard. Emision total por suscripcion. Integrable con Power BI para reporting.

Las tres herramientas son utiles como punto de partida pero tienen limitaciones importantes. Los datos llegan con retraso (semanas o meses), la granularidad es insuficiente para optimizacion a nivel de servicio, y las metodologias de calculo no son comparables entre providers. AWS reporta emisiones Scope 1 y 2 del datacenter; Google incluye emisiones Scope 3 parciales; Azure esta en algun punto intermedio.

Cloud Carbon Footprint (CCF)

Para mediciones independientes y comparables, Cloud Carbon Footprint (cloudcarbonfootprint.org) es la referencia open source. CCF conecta con las APIs de facturacion de AWS, GCP y Azure, y estima emisiones basandose en el tipo de recurso, la utilizacion y la intensidad de carbono de la red electrica en cada region.

La metodologia es transparente: convierte horas de uso de cada tipo de instancia en kWh utilizando factores de PUE (Power Usage Effectiveness) publicados por cada provider, y luego aplica la intensidad de carbono de la grid local (gCO2e/kWh) publicada por fuentes como electricityMap o la IEA.

Hemos desplegado CCF en clientes con infraestructura multi-cloud y los resultados son reveladores. Una empresa de logistica con 120 instancias EC2 descubrio que el 35% de sus emisiones cloud venian de 8 instancias de GPU para un modelo de ML que solo se ejecutaba durante 4 horas al dia pero estaba provisionado 24/7.

Software Carbon Intensity (SCI)

El Green Software Foundation ha definido una metrica estandar: SCI (Software Carbon Intensity), medida en gCO2e por unidad funcional. La unidad funcional la defines tu: por request, por transaccion, por usuario activo, por pedido procesado.

SCI = (E * I) + M, donde:

• E = energia consumida por el software
• I = intensidad de carbono de la electricidad
• M = carbono embebido del hardware (amortizado)

La ventaja de SCI es que normaliza las emisiones. Un servicio que procesa 10 millones de requests con un SCI de 0.3 gCO2e/request es mas eficiente que uno que procesa 1 millon con un SCI de 2.5, aunque el primero emita mas en terminos absolutos. Esto permite comparar entre servicios, trackear progreso temporal, y establecer objetivos significativos.

Reducir: optimizacion de eficiencia

Right-sizing con dimension de carbono

El right-sizing clasico de FinOps (ajustar el tamano de tus instancias al uso real) es la primera palanca de GreenOps. Pero anade un matiz: no todos los tipos de instancia tienen la misma eficiencia energetica.

Los procesadores ARM (AWS Graviton, Google Axion, Azure Cobalt) consumen entre un 30% y un 60% menos de energia que los equivalentes x86 para la mayoria de workloads. Esto no es un dato teorico. AWS publica que Graviton3 ofrece hasta un 60% menos de consumo energetico para la misma carga de trabajo que instancias C5 comparables. En nuestras mediciones con workloads reales de procesamiento de datos, la reduccion ha sido del 35-45%.

El cambio a ARM no es trivial (requiere recompilar dependencias nativas, verificar compatibilidad de imagenes Docker), pero el impacto combinado en coste y en carbono justifica el esfuerzo para la mayoria de aplicaciones cloud-native.

Serverless y eficiencia de carbono

Las arquitecturas serverless son inherentemente mas eficientes en carbono que los servidores provisionados, porque la unidad de consumo es la invocacion, no la hora de servidor. Un servidor provisionado al 15% de utilizacion media desperdicia el 85% de los recursos (y la energia) que consume. Un Lambda que se ejecuta solo cuando hay trabajo no desperdicia nada.

No todo puede ser serverless. Workloads con latencia estricta, conexiones persistentes, o procesamiento de larga duracion encajan mejor en contenedores. Pero para event-driven processing, APIs con trafico variable, y batch jobs, serverless reduce tanto el coste como las emisiones en ordenes de magnitud.

Un cliente nuestro migro un pipeline de procesamiento de facturas de EC2 (2 instancias m5.xlarge, 24/7) a Step Functions + Lambda. El procesamiento paso de 730 horas de servidor al mes a aproximadamente 45 horas equivalentes de Lambda. La reduccion de emisiones fue del 92%. (La de costes, del 78%.)

Eliminar el desperdicio obvio

Antes de optimizar la arquitectura, elimina el desperdicio evidente:

• Recursos huerfanos: discos EBS sin adjuntar, snapshots antiguos, IPs elasticas sin usar, load balancers sin targets. AWS estima que el 30% del gasto cloud es waste.
• Entornos de desarrollo/staging siempre encendidos: si tu equipo trabaja de 9 a 19, esos entornos pueden estar apagados 14 horas al dia y todo el fin de semana. Eso es un 65% menos de consumo.
• Logs y metricas excesivos: cada byte almacenado y procesado consume energia. Retenciones de logs de 90 dias para datos que nadie consulta despues de 7 dias es desperdicio puro.
• Overprovisioning de bases de datos: el clasico RDS en multi-AZ con un 8% de CPU media.

No hay glamour en apagar lo que no se usa. Pero es donde esta el 30-40% de reduccion inmediata, en cloud y en carbono.

Desplazar: carbon-aware computing

Aqui es donde GreenOps se diferencia fundamentalmente de FinOps. No toda la electricidad es igual. Un kWh en Irlanda a las 3 de la tarde un dia ventoso puede tener una intensidad de 50 gCO2e. El mismo kWh en Virginia a las 7 de la tarde un dia caluroso puede tener 400 gCO2e.

Regiones verdes

Cada cloud provider publica (con mayor o menor transparencia) el mix energetico de sus regiones. Las diferencias son enormes:

• GCP europe-north1 (Finlandia): 97% carbon-free energy (CFE). Intensidad media: ~30 gCO2e/kWh.
• AWS eu-west-1 (Irlanda): buena conectividad eolica. Variable, pero media anual baja.
• AWS us-east-1 (Virginia): el mas popular y uno de los mas sucios. Intensidad media: ~350 gCO2e/kWh.
• GCP us-central1 (Iowa): 98% CFE gracias a acuerdos de renovables.

Mover un workload de us-east-1 a eu-north-1 puede reducir sus emisiones un 85% sin cambiar una linea de codigo. Por supuesto, hay que considerar latencia y compliance de datos (GDPR, residencia). Pero para workloads batch, training de ML, backups, y procesamiento asincrono, la ubicacion geografica es flexible.

Workload scheduling temporal

La intensidad de carbono de la grid electrica varia a lo largo del dia. Durante las horas de sol, la contribucion solar reduce la intensidad. Durante los picos de demanda nocturnos, las plantas de gas natural y carbon cubren la diferencia.

El carbon-aware scheduling ejecuta workloads no urgentes cuando la grid es mas limpia. La API de electricityMap proporciona datos en tiempo real e historicos de intensidad de carbono para la mayoria de regiones del mundo.

Implementar esto requiere dos componentes:

1. Un scheduler que consulte la intensidad de carbono antes de lanzar jobs batch. Si la intensidad actual supera un umbral, el job se encola hasta que la grid se limpie. Con un deadline de 24 horas, practicamente siempre hay una ventana de baja intensidad.

2. Workload classification: separar las cargas que necesitan ejecucion inmediata de las que toleran retraso. Requests de usuario: inmediatos. Generacion de informes diarios: pueden esperar 6 horas. Reentrenamiento de modelos: puede esperar 24 horas.

El Green Software Foundation publica la Carbon Aware SDK, una libreria open source que encapsula la logica de consultar datos de intensidad y tomar decisiones de scheduling. Se integra con Kubernetes, Azure Batch, y AWS Step Functions.

Hemos implementado scheduling carbon-aware para un cliente que ejecuta pipelines de ETL nocturnos. Desplazando la ventana de ejecucion una media de 3 horas (de las 2am a las 5am, cuando la contribucion eolica es mayor en Europa occidental), las emisiones del pipeline se redujeron un 22% sin impacto funcional.

Reporting ESG: del datacenter al informe de sostenibilidad

CSRD y las emisiones digitales

La CSRD obliga a reportar bajo los European Sustainability Reporting Standards (ESRS). Las emisiones de infraestructura cloud caen en ESRS E1 (cambio climatico), especificamente en Scope 3, categoria 1 (bienes y servicios adquiridos).

El reto es que los cloud providers no proporcionan datos en el formato que ESRS requiere. Hay que transformar los datos de las herramientas de medicion (CCF, dashboards nativos) al framework de reporting corporativo. Esto implica:

• Definir boundaries: que infraestructura incluyes. Solo produccion? Tambien desarrollo? Edge? Dispositivos de usuario?
• Metodologia consistente: market-based vs location-based. Los cloud providers compran RECs (Renewable Energy Certificates) y PPAs (Power Purchase Agreements), lo que reduce sus emisiones market-based pero no necesariamente las location-based.
• Auditabilidad: los datos deben ser trazables desde el informe final hasta la fuente de medicion original.

El framework de reporting que usamos

Para clientes sujetos a CSRD, implementamos un pipeline de datos que alimenta el reporting ESG:

1. Ingesta: datos de facturacion cloud + datos de CCF + datos de emisiones del provider.
2. Calculo: conversion a tCO2e usando factores de emision actualizados (IEA, AIB residual mix).
3. Normalizacion: emision por unidad funcional de negocio (tCO2e por millon de euros de facturacion, por empleado, por envio procesado).
4. Almacenamiento: serie temporal con metadata de origen para auditoria.
5. Reporting: exportacion a formato ESRS E1, integracion con herramientas de reporting corporativo (Workiva, Sphera, o incluso un spreadsheet bien estructurado).

La normalizacion es clave. A un consejo de administracion no le dice nada que tu cloud emitio 42 tCO2e el ultimo trimestre. Le dice mucho que tus emisiones digitales por millon de euros de facturacion bajaron un 18% respecto al ano anterior, o que procesas un 30% mas de envios con las mismas emisiones.

Implementacion practica: roadmap de GreenOps

Fase 1: Visibilidad (meses 1-2)

• Activar las herramientas nativas de carbon footprint de tu provider.
• Desplegar CCF si usas multi-cloud.
• Definir tu SCI: elegir la unidad funcional relevante para tu negocio.
• Establecer la baseline: emisiones actuales por servicio, region y tipo de recurso.
• Identificar los hot spots: los 5 recursos que mas emiten.

Coste de implementacion: minimo. Son herramientas gratuitas o open source. El esfuerzo principal es de configuracion y analisis.

Fase 2: Quick wins (meses 3-4)

• Eliminar recursos huerfanos y overprovisioned. Ahorro tipico: 20-30% de emisiones.
• Programar apagado de entornos no-productivos fuera de horario.
• Migrar workloads no criticos a regiones con mayor porcentaje de renovables.
• Evaluar migracion a ARM para los top-10 servicios por consumo.

Coste de implementacion: bajo. La mayoria son cambios de configuracion. La migracion a ARM requiere testing.

Fase 3: Arquitectura (meses 5-8)

• Implementar carbon-aware scheduling para workloads batch.
• Migrar candidatos a serverless.
• Establecer budgets de carbono por equipo/servicio (analogo a los budgets de coste de FinOps).
• Integrar metricas de SCI en dashboards de operaciones.

Coste de implementacion: medio. Requiere cambios de arquitectura y desarrollo.

Fase 4: Reporting y gobernanza (meses 9-12)

• Implementar pipeline de datos para reporting ESG.
• Definir KPIs de sostenibilidad digital y revisarlos trimestralmente.
• Incluir carbono en el proceso de decision de compra cloud (junto a coste y rendimiento).
• Formar al equipo: GreenOps no es un proyecto, es una practica continua.

El argumento economico

La pregunta que siempre surge es: esto genera ROI o es un coste de compliance?

Nuestra experiencia con 8 proyectos de GreenOps indica que el ahorro de costes supera el coste de implementacion en un factor de 3x a 5x en el primer ano. No porque GreenOps sea magico, sino porque las optimizaciones que reduce carbono (right-sizing, eliminar waste, scheduling eficiente) son las mismas que reducen la factura del cloud.

Un cliente del sector fintech con 800K EUR/ano de gasto cloud implemento el roadmap completo en 10 meses. Resultado: 31% de reduccion de emisiones, 27% de reduccion de costes (216K EUR), y compliance con CSRD desde el primer informe. El coste del proyecto fue de 45K EUR en consultoria y 20K EUR en herramientas.

No todo es economico. La presion regulatoria crece. Los inversores preguntan. Los RFPs de grandes cuentas incluyen criterios ESG. Tener datos reales y un plan de reduccion es un diferenciador competitivo, especialmente en sectores como logistica, finanzas y retail donde la presion ESG es mas intensa. Para empresas que quieran optimizar su infraestructura multi-cloud, GreenOps y FinOps comparten las mismas palancas de accion.

La realidad de la sostenibilidad digital

Seamos honestos: GreenOps no va a salvar el planeta. La contribucion individual de una empresa mediana al cambio climatico via su infraestructura cloud es insignificante en terminos globales.

Pero eso no significa que sea irrelevante. La CSRD no es voluntaria. Los criterios ESG en procurement son una realidad. Y el desperdicio, ya sea en euros o en carbono, sigue siendo desperdicio.

Lo pragmatico de GreenOps es que no pide sacrificar rendimiento ni competitividad. Pide medir, eliminar lo innecesario, y tomar decisiones informadas. Es, en esencia, buena ingenieria aplicada a una dimension nueva. Y la buena ingenieria siempre termina siendo rentable. Nuestro equipo de cloud y DevOps ayuda a empresas a implementar GreenOps desde la fase de visibilidad hasta el reporting ESG completo.