Choose a low-carbon cloud region by ranking candidates on provider carbon data, then filtering for latency, data residency, and cost before you move. Google publishes a carbon-free energy percentage, or CFE%, per region and calls a region low-carbon at 75% or above. Grid intensity varies more than tenfold between regions, so placing new and flexible workloads in the cleanest viable region is often the single biggest carbon cut available, with no change to the compute. Default new workloads there; relocate existing ones only when latency, egress, and cost all clear.
A cloud region is a low-carbon region when the electricity grid powering its data centers is supplied largely by carbon-free sources such as hydro, wind, solar, and nuclear. The grid is the variable that matters, because almost all of a cloud workload's emissions come from the electricity it consumes, and the carbon intensity of that electricity is set by where the data center physically sits. A kilowatt-hour in a hydro-heavy region can carry a tenth of the emissions of the same kilowatt-hour on a coal-heavy grid. That makes region selection the rare sustainability lever that lowers emissions without lowering capacity, which is why it belongs in every GreenOps program.
This article is part of our complete guide to cloud sustainability and GreenOps, the cluster pillar it links up to. It pairs with what is carbon-aware computing and how to schedule for it, which adds the timing dimension to the placement dimension covered here.
What is the carbon-free energy percentage (CFE%)?
CFE% is the share of energy consumed in a region, measured hourly, that comes from carbon-free sources. Google Cloud publishes a CFE% for every region and classifies a region as low-carbon when that figure is at least 75%, per its carbon-free energy for Google Cloud regions data. The hourly basis matters: a region can have abundant solar by day and fall back to gas at night, so a high CFE% means your workload runs on clean energy a high proportion of the time. AWS and Azure publish their own regional renewable and grid data; the metric names differ but the principle is identical.
Use CFE% or its equivalent as the ranking input, not the only input. A region with a 90% CFE% that sits 200 milliseconds from your users or outside a required data-residency boundary is not a candidate, no matter how clean the grid.
How do I actually choose a region?
Choose a low-carbon region by ranking on carbon data, then eliminating candidates that fail the hard constraints, and only then comparing cost. The steps:
- Pull the carbon data per region. Use provider carbon-free energy and grid-intensity figures, such as Google CFE% or AWS regional renewable data, to rank the candidate regions from cleanest to dirtiest.
- Filter by latency and data residency. Remove any region that breaches your latency budget for end users or violates data-residency and compliance rules. These constraints are non-negotiable and come first.
- Check the cost delta. Compare on-demand and committed pricing between the current region and the low-carbon candidate, and include cross-region egress, because region pricing and data-transfer charges differ.
- Place new and flexible workloads first. Default new latency-tolerant services, batch jobs, and disaster-recovery copies into the cleanest viable region, rather than trying to relocate the whole estate at once.
- Measure and set as policy. Confirm the emissions reduction in the provider carbon tool, then encode the region default in your infrastructure-as-code so new workloads inherit it automatically.
The fifth step is what makes the saving durable. Without a default in code, the next team will deploy to whatever region is nearest or most familiar, and the carbon advantage erodes. Encoding it is the Lock phase of our See, Cut, Lock, Run method.
Want region strategy built into your cloud governance?
Our FinOps implementation builds region and placement defaults into infrastructure-as-code, balancing carbon, latency, and cost across AWS, Azure, GCP and OCI. Fixed fee, performance fee, or fully managed.
Talk to us about FinOps implementation →When is relocating a workload not worth it?
Relocating is not worth it when latency, egress, or compliance costs outweigh the carbon benefit, which is common for chatty, stateful, or data-heavy systems. A workload that exchanges large volumes with services pinned to another region will rack up cross-region egress charges and added latency that can dwarf the value of a cleaner grid. Data-residency law may forbid the move outright. And a tightly coupled system may simply break if its components are split across regions. For these, the better levers are rightsizing and efficient hardware in place, not relocation. The judgment of when to move and when to optimize where you are is exactly what a FinOps implementation weighs case by case.
The FinOps Operating Model Blueprint includes the region-selection scorecard we use to balance carbon, latency, egress, and cost on every placement decision.
Common questions about low-carbon regions
What is the carbon-free energy percentage (CFE%)?
CFE% is Google Cloud's hourly measure of the share of energy consumed in a region that comes from carbon-free sources. Google classifies a region as low-carbon when its CFE% is at least 75%. It reflects how often a workload in that region runs on clean energy.
How much does region choice affect carbon?
A lot. Grid carbon intensity varies by more than tenfold between regions, so moving a workload from a coal-heavy region to a hydro or wind-heavy one can cut its electricity emissions dramatically without changing the compute. It is usually the single largest carbon lever that does not reduce capacity.
Does a greener region cost more?
Not necessarily. Region pricing varies for reasons unrelated to carbon, so some low-carbon regions are cheaper and some are dearer. Always compare the cost delta, including egress between regions, before relocating a workload.
Written by Morten Andersen and reviewed by Fredrik Filipsson, applying our See, Cut, Lock, Run method. Independent and vendor neutral.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.