beginnerintermediateadvanced

AWS · Section 50

Sustainability

Level: intermediate
Read: 20 min
Concepts: 3

Sustainability is one of the six Well-Architected pillars, and AWS defines it in terms an engineer can act on: continually improving sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload — maximizing the benefits from provisioned resources while minimizing the total resources required. Under shared responsibility the data centre's efficiency is AWS's concern and the workload's utilization is yours, which makes this an architecture property rather than a reporting exercise. The levers are the ones already familiar from cost work, read with a different question: utilization first, since a fleet at 15% provisions roughly six times what its work needs; then right-sizing and scheduling; then storage lifecycle policies and deleting data nothing references, because storage accumulates without anyone deciding to; then payload and transfer efficiency. Progress is best tracked as a ratio — requests served per provisioned vCPU-hour — since an absolute target makes growth and inefficiency indistinguishable. Finally, AWS is explicit that pillars are traded against each other on business context: development environments may favour sustainability and cost over reliability, mission-critical systems the reverse, and security and operational excellence are generally not traded away at all. The value of naming sustainability is that the trade becomes something written down rather than omitted.

This section

AWS re:Invent 2021 - Architecting for sustainabilityAWS Events

What is true here

AWS's definition has two levers: maximize benefit from provisioned resources, minimize resources required.
Utilization is the dominant lever; storage is the one that grows without a decision.
Track efficiency ratios rather than absolute totals, so growth does not look like failure.
Sustainability and cost usually agree; reliability and performance headroom are the real tensions.
Pillar trade-offs are per workload and business-driven — state them explicitly.

What you will be able to do

State AWS's definition of the sustainability pillar and what each half means in practice
Pick efficiency levers in the order that removes the most resource per unit of effort
Choose a sustainability metric that survives workload growth
Find provisioned-but-unused resources, especially in storage
Record a pillar trade-off explicitly, including its sustainability cost

From a pillar definition to a written trade-off

The sustainability pillar

Utilization, right-sizing, lifecycle

One pillar among six

Sustainability

The pillar as AWS defines it, the levers that actually reduce resource use, and how to state the trade-off against the other five pillars.

Sustainability as an Architectural Concern

coreintermediate

Sustainability is one of the six Well-Architected pillars, and AWS defines it in engineering terms: continually improving sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload — maximizing the benefit from provisioned resources and minimizing the total resources required. That is a statement about architecture, not about reporting.

Think of it as

Read the definition twice and it says: get more out of what you provision, and provision less. Both halves are things engineers change with design decisions, which is why sustainability sits alongside reliability and cost rather than in a separate document.

What we're doing: See why an absolute-usage target is the wrong sustainability metric for a growing service.

ratio-not-total.txttext

Target: "reduce total vCPU-hours by 20% this year."

Reality: traffic grew 60%. vCPU-hours grew 25% despite a large
efficiency programme. The target was missed and the work looks failed.

Better target: "improve requests served per provisioned vCPU-hour by
30%."

Same programme, and now the number reflects what the engineering
actually achieved — while still driving exactly the same decisions.

1: An absolute target makes growth and inefficiency indistinguishable, so a successful year can look like a failure.
6: A ratio isolates the thing engineering controls. It also happens to be the same number that drives cost per request down.

Why this works: Sustainability targets that ignore workload growth get abandoned, because they cannot be met by any amount of engineering in a growing business. Efficiency ratios survive growth and point at the same decisions.

Treating sustainability as a reporting obligation rather than a design input

Wrong

text

# Sustainability = a quarterly figure someone extracts for a report

Better

text

# Sustainability = a question asked in design review, alongside
# reliability and cost: what does this choice provision, and how much of
# it will actually be used?

What you see: The number is reported accurately and never changes, because nothing in the design process ever asks the question that would change it.

Why: AWS placed sustainability in the Well-Architected Framework precisely so it would be reviewed the way the other pillars are — as a property of the architecture, decided when the architecture is decided. A figure extracted after the fact influences nothing.

The two levers in the definition, made concrete

The two levers in the definition, made concrete
Lever	Means	Examples
Maximize benefit from what is provisioned	Raise utilization	Bin-pack containers, consolidate under-used instances, scale in aggressively
Minimize total resources required	Do less work	Cache, CDN, efficient queries, smaller payloads, delete unused data
Both, at once	Right-size and schedule	Match capacity to demand rather than to peak

Together

text

# The metric worth tracking is a ratio, not a total
requests served / provisioned vCPU-hours
GB stored actively read / GB stored
# Both improve when the workload gets more efficient, and neither
# punishes the business for growing.

Remember: AWS defines sustainability as reducing energy consumption and increasing efficiency across a workload — maximize the benefit from what you provision, and minimize what you provision. Track it as a ratio (work per resource), and ask the question in design review, not in a report.

Efficiency Levers That Reduce Impact

standardintermediate

The levers are the ones you already know from cost work, read with a different question. High utilization means fewer machines doing the same work. Right-sizing means not provisioning capacity that is never used. Lifecycle policies mean cold data stops occupying expensive, always-spinning storage. And architecture decides how much work has to happen at all.

Think of it as

Cost and sustainability point the same direction almost everywhere, because both are functions of resources provisioned and resources used. The rare places they diverge — extra redundancy for reliability, a hot standby Region — are trade-offs to state, not to hide.

text

# S3 lifecycle: tier and expire without anyone remembering to
Days 0-30    Standard          (actively read)
Days 31-90   Standard-IA       (occasionally read)
Days 91-365  Glacier Flexible  (rarely read)
Day 366      Expire            (unless retention says otherwise)

Where the resources actually go

Provisioned

what you pay for and power

Utilized

the fraction actually doing work

Useful work

requests served, bytes delivered

Stored

and how much of it is ever read

Right-sizing compute while ignoring storage that nothing reads

Wrong

text

# Efficiency programme covers EC2 and Fargate sizing only

Better

text

# Include storage: unattached volumes, old snapshots, un-tiered S3, and
# log groups with no retention policy

What you see: Compute efficiency improves measurably while the storage footprint keeps growing, because nothing in the system ever removes data and nobody owns the growth.

Why: Storage accumulates by default and is never noticed at any single moment, since each individual addition is small. Compute is visible because someone provisions it deliberately; storage is the residue of work already finished, which is why lifecycle automation rather than review is the only thing that controls it.

Levers, and the measurement that shows whether they worked

Levers, and the measurement that shows whether they worked
Lever	Action	Measure
Compute utilization	Bin-pack, consolidate, scale in faster	Average utilization across the fleet
Right-sizing	Match size to observed demand	Provisioned vs used, per resource
Scheduling	Stop non-production out of hours	Instance-hours per week
Storage lifecycle	Tier and expire automatically	GB by storage class, and age of the oldest data
Data deletion	Remove orphaned volumes, snapshots, logs	GB stored that nothing references
Payload efficiency	Compression, smaller responses, CDN	GB transferred per request

Together

text

# Find the storage nobody references
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query "Volumes[].{id:VolumeId,size:Size,created:CreateTime}"
# "available" means attached to nothing — provisioned, powered, unused

Remember: Utilization first (a fleet at 15% provisions six times what it needs), then right-sizing and scheduling, then storage lifecycle and deleting what nothing reads, then payload and transfer efficiency. Nearly all of it reduces cost by the same mechanism.

Sustainability as a Trade-off Among the Pillars

standardintermediate

The Well-Architected Framework has six pillars, and AWS says explicitly that you make trade-offs between them based on business context. A development environment might be optimized for sustainability and cost at the expense of reliability; a mission-critical system optimized for reliability at the expense of both. Sustainability is one voice in that decision, not an override.

Think of it as

Six pillars, and the honest position is that they pull against each other. The value of naming sustainability as one of them is that the trade becomes explicit — "we chose a hot standby Region and accepted the resource cost" is a decision, whereas not mentioning it is an omission.

text

# The six pillars
operational excellence · security · reliability
performance efficiency · cost optimization · sustainability
# Security and operational excellence are generally not traded away.

Using sustainability to argue against redundancy in a critical workload

Wrong

text

# "A standby environment is wasteful, so run a single AZ."

Better

text

# State the trade: this workload optimizes reliability at a known
# sustainability and cost impact — which is exactly the example AWS
# gives for mission-critical solutions.

What you see: An availability decision is made on sustainability grounds and produces an outage whose business cost dwarfs the resources saved.

Why: AWS frames pillar trade-offs as business decisions, and gives the mission-critical case explicitly as one where reliability is optimized at increased cost and sustainability impact. Applying a single pillar as a rule across every workload is the failure mode the framework is structured to prevent.

Where sustainability genuinely trades against another pillar

Where sustainability genuinely trades against another pillar
Decision	Gains	Costs in sustainability
Multi-Region hot standby	Near-zero RTO	A full duplicate environment, mostly idle
Provisioned concurrency	No cold starts	Environments held ready whether used or not
Over-provisioned headroom	Absorbs spikes without scaling delay	Capacity idle most of the time
Multi-AZ everything	Survives an AZ failure	Standby capacity that serves no traffic
Longer retention	More recovery points, more audit history	Storage for data almost never read

Together

text

# A trade written down is a decision; unwritten it is an oversight
Decision: warm standby in eu-central-1 for the payments service.
  Reliability: RTO 10 min instead of 4 h.
  Cost: +$6.4k/month.
  Sustainability: a scaled-down duplicate environment always running.
  Accepted because: an hour of payments downtime exceeds the annual cost.

Remember: Six pillars, traded against each other per workload and per business context. Sustainability and cost usually agree; the real tensions are with reliability and performance headroom. Write the trade down — an unstated trade-off is an oversight, and security and operational excellence are generally not traded away.