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 tecnológico produce aproximadamente el 2-4% de las emisiones globales de CO2, una cifra comparable a la aviación comercial. Y crece cada año.
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 energía 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.
Qué es GreenOps
GreenOps aplica la misma lógica que FinOps (optimización financiera del cloud) pero con la dimensión medioambiental añadida. Si FinOps pregunta “cuánto cuesta este workload?”, GreenOps pregunta “cuánto contamina este workload y qué podemos hacer al respecto?”.
No son disciplinas separadas. En la práctica, la mayoría de las optimizaciones de GreenOps reducen costes simultáneamente, porque el recurso más barato es el que no consumes. Pero hay decisiones donde coste y carbono divergen, y ahí es donde GreenOps aporta un framework de decisión distinto.
Los tres pilares de GreenOps son:
Medir. No puedes reducir lo que no mides. Esto requiere visibilidad sobre el consumo energético y las emisiones asociadas a tu infraestructura.
Reducir. Optimizar la eficiencia de los workloads, eliminar recursos ociosos, y diseñar arquitecturas que consuman menos.
Desplazar. Mover cargas de trabajo a momentos y regiones donde la electricidad es más limpia.
Midiendo la huella de carbono digital
Las herramientas de los cloud providers
Los tres hyperscalers principales ofrecen herramientas nativas de medición de carbono:
- AWS: Customer Carbon Footprint Tool. Muestra emisiones mensuales por servicio y región. Datos disponibles con 3 meses de retraso. No desglosa por recurso individual.
- Google Cloud: Carbon Footprint Dashboard. Datos por proyecto y región, actualizados mensualmente. Incluye energía total y mix de renovables por región. El más granular de los tres.
- Azure: Emissions Impact Dashboard. Emisión total por suscripción. Integrable con Power BI para reporting.
Las tres herramientas son útiles como punto de partida pero tienen limitaciones importantes. Los datos llegan con retraso (semanas o meses), la granularidad es insuficiente para optimización a nivel de servicio, y las metodologías de cálculo no son comparables entre providers. AWS reporta emisiones Scope 1 y 2 del datacenter; Google incluye emisiones Scope 3 parciales; Azure está en algún 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 facturación de AWS, GCP y Azure, y estima emisiones basándose en el tipo de recurso, la utilización y la intensidad de carbono de la red eléctrica en cada región.
La metodología 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 logística con 120 instancias EC2 descubrio que el 35% de sus emisiones cloud venían de 8 instancias de GPU para un modelo de ML que solo se ejecutaba durante 4 horas al día pero estaba provisionado 24/7.
Software Carbon Intensity (SCI)
El Green Software Foundation ha definido una métrica estándar: SCI (Software Carbon Intensity), medida en gCO2e por unidad funcional. La unidad funcional la defines tú: por request, por transacción, por usuario activo, por pedido procesado.
SCI = (E * I) + M, donde:
- E = energía 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 más eficiente que uno que procesa 1 millón con un SCI de 2.5, aunque el primero emita más en términos absolutos. Esto permite comparar entre servicios, trackear progreso temporal, y establecer objetivos significativos.
Reducir: optimización de eficiencia
Right-sizing con dimensión de carbono
El right-sizing clásico de FinOps (ajustar el tamaño de tus instancias al uso real) es la primera palanca de GreenOps. Pero añade un matiz: no todos los tipos de instancia tienen la misma eficiencia energética.
Los procesadores ARM (AWS Graviton, Google Axion, Azure Cobalt) consumen entre un 30% y un 60% menos de energía que los equivalentes x86 para la mayoría de workloads. Esto no es un dato teórico. AWS publica que Graviton3 ofrece hasta un 60% menos de consumo energético para la misma carga de trabajo que instancias C5 comparables. En nuestras mediciones con workloads reales de procesamiento de datos, la reducción ha sido del 35-45%.
El cambio a ARM no es trivial (requiere recompilar dependencias nativas, verificar compatibilidad de imágenes Docker), pero el impacto combinado en coste y en carbono justifica el esfuerzo para la mayoría de aplicaciones cloud-native.
Serverless y eficiencia de carbono
Las arquitecturas serverless son inherentemente más eficientes en carbono que los servidores provisionados, porque la unidad de consumo es la invocación, no la hora de servidor. Un servidor provisionado al 15% de utilización media desperdicia el 85% de los recursos (y la energía) 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 duración encajan mejor en contenedores. Pero para event-driven processing, APIs con tráfico variable, y batch jobs, serverless reduce tanto el coste como las emisiones en órdenes de magnitud.
Un cliente nuestro migró un pipeline de procesamiento de facturas de EC2 (2 instancias m5.xlarge, 24/7) a Step Functions + Lambda. El procesamiento pasó de 730 horas de servidor al mes a aproximadamente 45 horas equivalentes de Lambda. La reducción de emisiones fue del 92%. (La de costes, del 78%.)
Eliminar el desperdicio obvio
Antes de optimizar la arquitectura, elimina el desperdicio evidente:
- Recursos huérfanos: discos EBS sin adjuntar, snapshots antiguos, IPs elásticas 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 día y todo el fin de semana. Eso es un 65% menos de consumo.
- Logs y métricas excesivos: cada byte almacenado y procesado consume energía. Retenciones de logs de 90 días para datos que nadie consulta después de 7 días es desperdicio puro.
- Overprovisioning de bases de datos: el clásico RDS en multi-AZ con un 8% de CPU media.
No hay glamour en apagar lo que no se usa. Pero es donde está el 30-40% de reducción inmediata, en cloud y en carbono.
Desplazar: carbon-aware computing
Aquí 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 día ventoso puede tener una intensidad de 50 gCO2e. El mismo kWh en Virginia a las 7 de la tarde un día caluroso puede tener 400 gCO2e.
Regiones verdes
Cada cloud provider publica (con mayor o menor transparencia) el mix energético 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 eólica. Variable, pero media anual baja.
- AWS us-east-1 (Virginia): el más popular y uno de los más 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 línea de código. Por supuesto, hay que considerar latencia y compliance de datos (GDPR, residencia). Pero para workloads batch, training de ML, backups, y procesamiento asíncrono, la ubicación geográfica es flexible.
Workload scheduling temporal
La intensidad de carbono de la grid eléctrica varía a lo largo del día. Durante las horas de sol, la contribución solar reduce la intensidad. Durante los picos de demanda nocturnos, las plantas de gas natural y carbón cubren la diferencia.
El carbon-aware scheduling ejecuta workloads no urgentes cuando la grid es más limpia. La API de electricityMap proporciona datos en tiempo real e históricos de intensidad de carbono para la mayoría de regiones del mundo.
Implementar esto requiere dos componentes:
-
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, prácticamente siempre hay una ventana de baja intensidad.
-
Workload classification: separar las cargas que necesitan ejecución inmediata de las que toleran retraso. Requests de usuario: inmediatos. Generación de informes diarios: pueden esperar 6 horas. Reentrenamiento de modelos: puede esperar 24 horas.
El Green Software Foundation publica la Carbon Aware SDK, una librería open source que encapsula la lógica 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 ejecución una media de 3 horas (de las 2am a las 5am, cuando la contribución eólica 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 climático), específicamente en Scope 3, categoría 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 medición (CCF, dashboards nativos) al framework de reporting corporativo. Esto implica:
- Definir boundaries: qué infraestructura incluyes. Solo producción? También desarrollo? Edge? Dispositivos de usuario?
- Metodología 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 medición original.
El framework de reporting que usamos
Para clientes sujetos a CSRD, implementamos un pipeline de datos que alimenta el reporting ESG:
- Ingesta: datos de facturación cloud + datos de CCF + datos de emisiones del provider.
- Cálculo: conversión a tCO2e usando factores de emisión actualizados (IEA, AIB residual mix).
- Normalización: emisión por unidad funcional de negocio (tCO2e por millón de euros de facturación, por empleado, por envío procesado).
- Almacenamiento: serie temporal con metadata de origen para auditoría.
- Reporting: exportación a formato ESRS E1, integración con herramientas de reporting corporativo (Workiva, Sphera, o incluso un spreadsheet bien estructurado).
La normalización es clave. A un consejo de administración no le dice nada que tu cloud emitió 42 tCO2e el último trimestre. Le dice mucho que tus emisiones digitales por millón de euros de facturación bajaron un 18% respecto al año anterior, o que procesas un 30% más de envíos con las mismas emisiones.
Implementación práctica: 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, región y tipo de recurso.
- Identificar los hot spots: los 5 recursos que más emiten.
Coste de implementación: mínimo. Son herramientas gratuitas o open source. El esfuerzo principal es de configuración y análisis.
Fase 2: Quick wins (meses 3-4)
- Eliminar recursos huérfanos y overprovisioned. Ahorro típico: 20-30% de emisiones.
- Programar apagado de entornos no-productivos fuera de horario.
- Migrar workloads no críticos a regiones con mayor porcentaje de renovables.
- Evaluar migración a ARM para los top-10 servicios por consumo.
Coste de implementación: bajo. La mayoría son cambios de configuración. La migración 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 (análogo a los budgets de coste de FinOps).
- Integrar métricas de SCI en dashboards de operaciones.
Coste de implementación: 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 decisión de compra cloud (junto a coste y rendimiento).
- Formar al equipo: GreenOps no es un proyecto, es una práctica continua.
El argumento económico
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 implementación en un factor de 3x a 5x en el primer año. No porque GreenOps sea mágico, 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/año de gasto cloud implementó el roadmap completo en 10 meses. Resultado: 31% de reducción de emisiones, 27% de reducción de costes (216K EUR), y compliance con CSRD desde el primer informe. El coste del proyecto fue de 45K EUR en consultoría y 20K EUR en herramientas.
No todo es económico. La presión regulatoria crece. Los inversores preguntan. Los RFPs de grandes cuentas incluyen criterios ESG. Tener datos reales y un plan de reducción es un diferenciador competitivo, especialmente en sectores como logística, finanzas y retail donde la presión ESG es más intensa. Para empresas que quieran optimizar su infraestructura multi-cloud, GreenOps y FinOps comparten las mismas palancas de acción.
La realidad de la sostenibilidad digital
Seamos honestos: GreenOps no va a salvar el planeta. La contribución individual de una empresa mediana al cambio climático vía su infraestructura cloud es insignificante en términos 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 pragmático de GreenOps es que no pide sacrificar rendimiento ni competitividad. Pide medir, eliminar lo innecesario, y tomar decisiones informadas. Es, en esencia, buena ingeniería aplicada a una dimensión nueva. Y la buena ingeniería 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.