a cloud platform’s carbon-efficiency depends, in part, on
the carbon-intensity of its energy supply, which varies
widely over time based on variations in both grid power’s
carbon-intensity and local renewable power’s availability.
Since modifying a cloud platform’s operations to adapt
to variations in carbon-intensity, e.g., by throttling work-
loads when carbon-intensity is high, is challenging, cloud
providers have largely focused on transparently reducing
their net carbon emissions using carbon offsets. Such off-
sets are an accounting mechanism that enables offsetting
the direct use of carbon-intensive energy by purchasing
zero-carbon renewable energy generated at another time
and location [
43
,
58
]. Carbon offsets are attractive be-
cause they do not require complex operational changes
to reduce net carbon emissions. Many prominent tech-
nology companies have eliminated their net carbon emis-
sions [
1
,
31
,
54
,
65
], which they often refer to as running
on “100% renewable energy.” Unfortunately, carbon off-
sets do not reduce direct carbon emissions, and become
increasingly less effective as carbon emissions decrease,
as there is less carbon left to offset. As a result, elimi-
nating absolute carbon emissions will ultimately require
cloud platforms to change their operations to reduce their
direct carbon emissions by better aligning their computing
load with when and where low-carbon energy is available.
Reducing direct carbon emissions is challenging largely
because it introduces a new constraint that requires
voluntarily making difficult tradeoffs between perfor-
mance/availability, cost, and carbon emissions. In gen-
eral, modifying design and operations to reduce direct
carbon emissions decreases performance/availability and
also increases cost, as energy prices do not (yet) incor-
porate the cost of carbon’s negative externalities to the
environment. Importantly, the optimal tradeoff between
performance/availability, cost, and carbon emissions dif-
fers across applications and users. As we show in §5,
the policies for reducing the carbon emissions of delay-
tolerant batch applications are significantly different from
those for interactive web services that must maintain a
strict latency Service Level Objective (SLO). More gen-
erally, though, cloud users, i.e., companies, have widely
different goals, strategies, and tolerances for reducing
carbon (at the expense of increased cost and lower perfor-
mance/availability), which cloud platforms do not know.
As a result, cloud platforms are not well-positioned to
manage carbon emissions at the system-level on behalf of
their users, which motivates our ecovisor’s approach of
exposing energy and carbon management to applications.
The motivation for our ecovisor’s application-level con-
trol of carbon is analogous to that for cloud auto-scaling:
all cloud platforms support elastic auto-scaling that en-
ables applications to horizontally or vertically scale their
resources in response to variations in their workload’s in-
tensity [
3
,
14
]. These auto-scaling policies are application-
specific for similar reasons as above, i.e., differing appli-
cation requirements and user tradeoffs between cost and
performance/availability. Our ecovisor’s API, discussed
in §3, enables similar “auto-scaling” but in response to
variations in grid power’s carbon-intensity and local re-
newable energy’s availability. A simple evolutionary path
to enabling such “carbon-scaling” using an ecovisor is
to augment existing cloud auto-scaling APIs. For exam-
ple, existing APIs, such as Amazon CloudWatch [
37
] and
Azure Monitor [
4
], already expose visibility into platform
resource usage, and could easily be extended to include
power and carbon information. In this case, cloud plat-
forms would “delegate” carbon-scaling to applications
just as they currently delegate auto-scaling resources.
While the ecovisor approach could apply to existing
cloud platforms, especially those hosted at datacenters
with substantial co-located renewables [
44
] and energy
storage [
59
], there is currently no financial incentive to
reduce carbon. This is a social problem, not a technical
one. In the end, to halt climate change, government poli-
cies will likely be necessary to create strong incentives for
monitoring and reducing carbon emissions, either directly,
e.g., via carbon caps, or indirectly, e.g., via carbon pricing.
Nevertheless, cloud platforms have already begun to ex-
pose visibility into their carbon emissions [
10
], driven by
their customers’ increasing desire to measure and report
carbon emissions data. This combination of customer
demand and government policy is likely to incentivize
future cloud platforms to adopt ecovisor-like mechanisms
for measuring and controlling carbon emissions.
Background.
Our work assumes a datacenter’s physi-
cal energy system connects to up to three distinct power
sources: the electric grid, local batteries (or other forms
of energy storage), and local renewable generation, such
as solar or wind. The power supplied to servers (and
other computing equipment) is a mix of these three power
sources. Not all facilities will have connections to all
three power sources, and the capacity of each source may
vary. For example, many large cloud data centers may not
have local renewables, while smaller edge sites might not
require a grid connection, i.e., if they have enough local
renewables and battery capacity to be self-powered [34].
An ecovisor requires software-defined monitoring and
control of both server power and the physical energy sys-
tem, i.e., power’s supply, demand, and carbon emissions.
Monitoring Power. An ecovisor must be capable of
monitoring each energy source’s power generation and
consumption. Energy system components commonly ex-
pose power monitoring via programmatic APIs. For ex-
ample, battery charge controllers, such as Tesla’s Pow-
erwall, support querying a battery’s energy level, and its
charge/discharge rate from the grid and solar [
15
], while
solar inverters support querying current and historical so-
lar power generation [
15
]. Our ecovisor builds on these
3