Green code:
Article date
08 10 2026
Article Author
Anipchenko Dmitry
Reading Time
10 minutes
Green code: How to reduce your cloud bills by 40% and what does carbon footprint have to do with it
Introduction
In 2022, the total energy consumption of data centers reached 460 TWh — roughly 2% of global electricity generation. According to the International Energy Agency (IEA), this figure could grow to 1,000 TWh by 2026, comparable to Japan's electricity consumption.
It is commonly accepted in the industry that energy losses are primarily related to cooling and infrastructure overhead (data center PUE is 1.4–1.8). However, no less significant factor is inefficient code that creates excessive computational load. In this article, we will analyze how code optimization affects operational costs, what metrics global leaders use, and how to start measuring the carbon footprint of your applications.
Introduction
In 2022, the total energy consumption of data centers reached 460 TWh — roughly 2% of global electricity generation. According to the International Energy Agency (IEA), this figure could grow to 1,000 TWh by 2026, comparable to Japan's electricity consumption.
It is commonly accepted in the industry that energy losses are primarily related to cooling and infrastructure overhead (data center PUE is 1.4–1.8). However, no less significant factor is inefficient code that creates excessive computational load. In this article, we will analyze how code optimization affects operational costs, what metrics global leaders use, and how to start measuring the carbon footprint of your applications.
Part 1. The scale of the problem: from CPU to LLM
The relevance of the topic is confirmed by data fr om independent research centers and cloud provider reports.
Idle resources
In 2024, Uptime Institute analysts found that average CPU utilization in commercial clouds does not exceed 12–18% during peak hours. The rest of the time, servers operate in standby mode, consuming up to 80% of peak power. This means that a significant portion of computing resources is paid for but not used productively.
Energy consumption per request
According to estimates by the Green Software Foundation, used in the SCI methodology, an average API request in a typical web application consumes 0.3 to 0.5 grams of CO₂-equivalent, depending on the complexity of the operation and the stack used. For an application with RPS = 1000, annual emissions can reach 9–15 tons of CO₂.
Programming languages and energy efficiency
The classic study by Pereira et al. (2017), presented at the ACM SPLASH conference, compared the energy efficiency of 27 programming languages. Key findings:
Compiled languages (C, Rust) perform the same tasks while consuming 50–80 times less energy than interpreted languages (Python, Ruby).
PHP and JavaScript consume on average 2–5 times more watt-hours per operation than Java.
Conclusion: stack selection directly affects energy consumption, which means operational costs and environmental footprint.
A separate issue: LLM servers
Infrastructure for large language models (LLMs) creates additional strain on energy systems.
Training energy consumption: According to Patterson et al. (2021), training GPT-3 (175 billion parameters) required about 1,287 MWh of electricity, accompanied by emissions of approximately 550 tons of CO₂. For comparison: this is equivalent to the emissions of five average cars over their entire lifetime.
It is important to note that machine learning itself is only part of the problem. The methodology for assessing the carbon footprint of ML training was laid out in earlier work that analyzed the energy costs of training large models in general.
Inference: One request to GPT-3 consumes approximately 0.001–0.003 kWh, which is 10–15 times higher than the energy consumption of a regular text search (0.0003 kWh). For GPT-4, exact figures have not been disclosed, but expert estimates indicate a comparable or higher level of energy consumption.
Water footprint: Research has shown that training GPT-3 required about 700,000 liters of fresh water (evaporation for cooling). For GPT-4, estimates range from 1.5 to 3 million liters. Inference of one short request (about 100 words) "evaporates" an average of 10–25 ml of water depending on the region and air temperature.
Geographic factor: The placement of LLM workloads is critical. In regions with hot climates (Arizona, Texas), water consumption for cooling is 2–3 times higher than in Scandinavia, wh ere free air cooling systems are used.
Idle resources
In 2024, Uptime Institute analysts found that average CPU utilization in commercial clouds does not exceed 12–18% during peak hours. The rest of the time, servers operate in standby mode, consuming up to 80% of peak power. This means that a significant portion of computing resources is paid for but not used productively.
Energy consumption per request
According to estimates by the Green Software Foundation, used in the SCI methodology, an average API request in a typical web application consumes 0.3 to 0.5 grams of CO₂-equivalent, depending on the complexity of the operation and the stack used. For an application with RPS = 1000, annual emissions can reach 9–15 tons of CO₂.
Programming languages and energy efficiency
The classic study by Pereira et al. (2017), presented at the ACM SPLASH conference, compared the energy efficiency of 27 programming languages. Key findings:
Compiled languages (C, Rust) perform the same tasks while consuming 50–80 times less energy than interpreted languages (Python, Ruby).
PHP and JavaScript consume on average 2–5 times more watt-hours per operation than Java.
Conclusion: stack selection directly affects energy consumption, which means operational costs and environmental footprint.
A separate issue: LLM servers
Infrastructure for large language models (LLMs) creates additional strain on energy systems.
Training energy consumption: According to Patterson et al. (2021), training GPT-3 (175 billion parameters) required about 1,287 MWh of electricity, accompanied by emissions of approximately 550 tons of CO₂. For comparison: this is equivalent to the emissions of five average cars over their entire lifetime.
It is important to note that machine learning itself is only part of the problem. The methodology for assessing the carbon footprint of ML training was laid out in earlier work that analyzed the energy costs of training large models in general.
Inference: One request to GPT-3 consumes approximately 0.001–0.003 kWh, which is 10–15 times higher than the energy consumption of a regular text search (0.0003 kWh). For GPT-4, exact figures have not been disclosed, but expert estimates indicate a comparable or higher level of energy consumption.
Water footprint: Research has shown that training GPT-3 required about 700,000 liters of fresh water (evaporation for cooling). For GPT-4, estimates range from 1.5 to 3 million liters. Inference of one short request (about 100 words) "evaporates" an average of 10–25 ml of water depending on the region and air temperature.
Geographic factor: The placement of LLM workloads is critical. In regions with hot climates (Arizona, Texas), water consumption for cooling is 2–3 times higher than in Scandinavia, wh ere free air cooling systems are used.
Part 2. How to measure the carbon footprint of code
To assess the environmental impact of software, the industry uses standardized metrics. The baseline standard is Software Carbon Intensity (SCI) fr om the Green Software Foundation.
SCI formula:
SCI = (E × I) + M / R
wh ere:
E — energy consumption of the code (kWh);
I — carbon intensity of the electricity grid (g CO₂/kWh): ~350 in Moscow, ~200 in California, ~600 in Beijing;
M — carbon footprint of hardware production and disposal (distributed over lifetime);
R — number of useful operations (User Operations).
For LLM applications, the formula becomes more complex: E adds cooling energy, and M adds rare earth metals for GPUs.
Benchmarks for the development team:
Leading global teams strive for a figure of no more than 1 kg CO₂ per 1 million useful requests for typical web applications. For AI products, this figure is currently 5–10 times higher, but the industry is actively seeking solutions through model optimization and hardware acceleration.
Example from industry reports:
Consider a typical API on Python + PostgreSQL:
Direct DB queries, CPU load ~70%.
Estimated footprint: ~2.1 kg CO₂ per 1 million requests.
Optimized architecture (Redis + rewriting the hot path in Go/Rust) allows reducing CPU load to 22–25% and carbon footprint to ~0.6 kg CO₂ per 1 million requests, providing cloud resource savings of up to 40–45%.
Regional factor: The choice of data center region also affects metrics. Deploying workloads in regions with a high share of renewable energy and cold climates can reduce the carbon footprint by 60–70% without changing code. For Russian companies, this means that the choice between domestic cloud providers (Yandex Cloud, SberCloud, VK Cloud) and own data centers should consider not only cost but also the carbon intensity of the power grid in the deployment region.
SCI formula:
SCI = (E × I) + M / R
wh ere:
E — energy consumption of the code (kWh);
I — carbon intensity of the electricity grid (g CO₂/kWh): ~350 in Moscow, ~200 in California, ~600 in Beijing;
M — carbon footprint of hardware production and disposal (distributed over lifetime);
R — number of useful operations (User Operations).
For LLM applications, the formula becomes more complex: E adds cooling energy, and M adds rare earth metals for GPUs.
Benchmarks for the development team:
Leading global teams strive for a figure of no more than 1 kg CO₂ per 1 million useful requests for typical web applications. For AI products, this figure is currently 5–10 times higher, but the industry is actively seeking solutions through model optimization and hardware acceleration.
Example from industry reports:
Consider a typical API on Python + PostgreSQL:
Direct DB queries, CPU load ~70%.
Estimated footprint: ~2.1 kg CO₂ per 1 million requests.
Optimized architecture (Redis + rewriting the hot path in Go/Rust) allows reducing CPU load to 22–25% and carbon footprint to ~0.6 kg CO₂ per 1 million requests, providing cloud resource savings of up to 40–45%.
Regional factor: The choice of data center region also affects metrics. Deploying workloads in regions with a high share of renewable energy and cold climates can reduce the carbon footprint by 60–70% without changing code. For Russian companies, this means that the choice between domestic cloud providers (Yandex Cloud, SberCloud, VK Cloud) and own data centers should consider not only cost but also the carbon intensity of the power grid in the deployment region.
Part 3. Anti-patterns that increase energy consumption
Industry audits have identified four typical architectural errors that create excessive load.
Anti-pattern 1. Retry Storm
Libraries are often configured by default with 5–10 retry attempts when a service is unavailable. This creates an avalanche-like growth of useless requests. According to observations of large distributed systems, up to 20–30% of computing power in some sectors is spent on retries.
Solution: Exponential backoff with a hard limit of 3 attempts and the use of the Circuit Breaker pattern.
Anti-pattern 2. Excessive network traffic
Data transmission over the network is one of the most energy-intensive operations due to the operation of network cards, switches, and routers. Transmitting 1 GB of data over the network can consume several times more energy than the same volume of in-memory operations.
Solution: Transmit only necessary fields (use GraphQL or protobuf) and implement aggressive caching at all levels.
Anti-pattern 3. Inefficient memory management and Garbage Collector
Automatic garbage collectors (GC) in Java/.NET can create peak loads under high memory consumption. This leads to additional CPU heating and performance losses.
Solution: Tuning GC for the specific load pattern (e.g., switching to ZGC instead of G1) allows reducing energy consumption by 10–15% without changing business logic.
Anti-pattern 4. Excessive logging
Writing DEBUG-level logs in production creates additional load on the disk subsystem (I/O), which is one of the most expensive operations in terms of energy consumption and hardware wear.
Solution: Structured logging of only errors and critical events in production, DEBUG only for staging.
Anti-pattern 1. Retry Storm
Libraries are often configured by default with 5–10 retry attempts when a service is unavailable. This creates an avalanche-like growth of useless requests. According to observations of large distributed systems, up to 20–30% of computing power in some sectors is spent on retries.
Solution: Exponential backoff with a hard limit of 3 attempts and the use of the Circuit Breaker pattern.
Anti-pattern 2. Excessive network traffic
Data transmission over the network is one of the most energy-intensive operations due to the operation of network cards, switches, and routers. Transmitting 1 GB of data over the network can consume several times more energy than the same volume of in-memory operations.
Solution: Transmit only necessary fields (use GraphQL or protobuf) and implement aggressive caching at all levels.
Anti-pattern 3. Inefficient memory management and Garbage Collector
Automatic garbage collectors (GC) in Java/.NET can create peak loads under high memory consumption. This leads to additional CPU heating and performance losses.
Solution: Tuning GC for the specific load pattern (e.g., switching to ZGC instead of G1) allows reducing energy consumption by 10–15% without changing business logic.
Anti-pattern 4. Excessive logging
Writing DEBUG-level logs in production creates additional load on the disk subsystem (I/O), which is one of the most expensive operations in terms of energy consumption and hardware wear.
Solution: Structured logging of only errors and critical events in production, DEBUG only for staging.
Part 4. Conclusion
Green code is an engineering discipline directly correlated with TCO (Total Cost of Ownership). Application optimization allows achieving a triple effect:
Reduction of cloud bills by 20–40% through reduced resource usage.
Performance acceleration — optimized code runs faster.
Compliance with ESG requirements of customers and regulators — both international and Russian (including the requirements of the Bank of Russia and the Ministry of Economic Development for non-financial disclosure).
Why this matters for business:
For client companies, environmental friendliness is not an abstract value, but concrete figures in cloud bills and compliance with growing ESG requirements. Optimizing code from the perspective of energy efficiency helps reduce operational costs and stay on trend with the global agenda.
Forecasts: According to industry experts, by 2027–2028, the availability of carbon efficiency metrics may become a condition for participation in tenders of large corporations and EU government agencies. The water footprint of AI products may also become a separate ESG reporting requirement. In Russia, a similar trend is forming within the framework of the taxonomy of "green" projects and sustainable development requirements approved by the Government of the Russian Federation.
Reduction of cloud bills by 20–40% through reduced resource usage.
Performance acceleration — optimized code runs faster.
Compliance with ESG requirements of customers and regulators — both international and Russian (including the requirements of the Bank of Russia and the Ministry of Economic Development for non-financial disclosure).
Why this matters for business:
For client companies, environmental friendliness is not an abstract value, but concrete figures in cloud bills and compliance with growing ESG requirements. Optimizing code from the perspective of energy efficiency helps reduce operational costs and stay on trend with the global agenda.
Forecasts: According to industry experts, by 2027–2028, the availability of carbon efficiency metrics may become a condition for participation in tenders of large corporations and EU government agencies. The water footprint of AI products may also become a separate ESG reporting requirement. In Russia, a similar trend is forming within the framework of the taxonomy of "green" projects and sustainable development requirements approved by the Government of the Russian Federation.