Sustainability

Introduction

For a long time, sustainability sounded like a topic for the facilities team, the annual ESG report or the marketing slide with a leaf on it. Architects had "real" problems to solve: latency, availability, security, the bill. Well, the cloud changed that. When your data center is an API call away, every architectural decision you make is also an energy decision, and energy (along with the hardware that consumes it) has a carbon footprint.

That's why AWS added Sustainability as the sixth pillar of its Well-Architected Framework, Microsoft published guidance for sustainable workloads in the Azure Well-Architected Framework, and Google Cloud has a sustainability pillar in its Architecture Framework. On the community side, the Green Software Foundation (GSF) has been turning the subject into engineering practice, with principles, patterns and even a specification for measuring the carbon intensity of software.

The goal of this principle is simple to state and hard to practice: deliver the same business value using fewer resources, less energy and cleaner energy. It isn't about making the product worse to save the planet. It's about removing waste that nobody would miss.

When a team ignores this principle, the symptoms are surprisingly familiar:

• Virtual machines running at single-digit CPU utilization, 24 hours a day, 7 days a week;
• Development and test environments that nobody turns off at night or on weekends;
• Data kept forever in the hottest (and most energy-hungry) storage tier "just in case";
• Batch jobs scheduled at whatever time the developer happened to type into the cron expression;
• Huge AI models answering questions a much smaller one would handle just fine;
• No idea at all of how much carbon the workload emits, and therefore no way to improve it;

Yep, it's rare, but it happens all the time... Who hasn't found a forgotten cluster humming along in some subscription, burning energy for a project that ended months ago?

Easy there, Junior! That's exactly the misunderstanding this principle tries to fix. The provider is responsible for a lot, but not for everything. Let's see how that responsibility is split.

Shared Responsibility for Sustainability

You probably know the shared responsibility model from security: the provider secures the physical infrastructure and you secure what you build on top of it. AWS applies the same idea to sustainability, and it works nicely as a mental model for any cloud:

• Sustainability OF the cloud belongs to the provider: data center efficiency, cooling, how the energy is sourced, the hardware supply chain, server utilization across its fleet, and what happens to equipment at the end of its life.
• Sustainability IN the cloud belongs to you: which region you deploy to, how well you use what you provision, how efficient your code is, how much data you store and for how long, and which architectural patterns you choose.

The provider can run the most efficient data center on the planet, but if you leave a hundred idle machines running inside it, those machines still consume energy and still occupy hardware that had to be manufactured. Efficiency of the building doesn't cancel waste in the tenant.

The Building Blocks of Green Software

The Green Software Foundation organizes the topic around a few core ideas. They're worth knowing by name, because every practice later in this article is an application of one of them.

Carbon efficiency

Emit the least amount of carbon possible per unit of useful work. This is the umbrella goal. Everything else is a way to get there. Notice the "per unit of work": a system that serves ten times more users with twice the emissions became more carbon efficient, even though its total footprint grew.

Energy efficiency

Use the least amount of energy possible to do the job. Energy is the main proxy for operational carbon: less energy consumed means less carbon emitted, whatever the grid mix is. There's a subtle point here called energy proportionality: servers don't consume energy in proportion to their load. An idle or lightly loaded server still draws a significant share of its peak power just by being on. That's why a few well-utilized machines beat many idle ones.

Hardware efficiency (embodied carbon)

Every server, disk, network switch and phone had carbon emitted to build it, ship it and eventually dispose of it. That's embodied carbon, and it's "spent" before your first request arrives. The practical conclusion: use the least hardware possible and get the most out of the hardware that already exists. Higher utilization amortizes embodied carbon over more useful work, and extending the useful life of devices avoids manufacturing new ones.

Carbon awareness

The same kilowatt-hour doesn't have the same carbon everywhere, or at every hour. The carbon intensity of electricity depends on the mix of sources feeding the grid (solar, wind, hydro, gas, coal...), and that mix changes by location and time of day. Carbon awareness means doing more when and where the energy is cleaner, and less when and where it's dirtier. This is achieved in two ways:

• Demand shifting: moving flexible work in time (run it later) or in space (run it in another region) to where the grid is cleaner;
• Demand shaping: changing how much work you do based on the energy available, for example reducing video quality or pausing non-essential features when intensity is high, the same way a phone's low-power mode trades features for battery life.

Measurement

What you don't measure, you can't improve. This one is so important it deserves its own section.

Measure Before You Optimize

Who hasn't seen a team debate for weeks about rewriting a service in a "faster language" to save energy, when the real waste was a forgotten environment costing more than the whole service? Measuring first keeps the effort where the emissions actually are.

SCI: Software Carbon Intensity

The Green Software Foundation created the Software Carbon Intensity (SCI) specification, later published as the ISO/IEC 21031:2024 standard. Instead of producing a single total, it gives you a rate: carbon emitted per unit of something meaningful for your business.

• E is the energy consumed by the software;
• I is the carbon intensity of the electricity where and when it ran (location-based, grams of CO2 equivalent per kWh);
• M is the share of the hardware's embodied emissions attributable to the software;
• R is the functional unit: per user, per API call, per transaction, per training run, per report generated.

The beauty of it is that the formula itself tells you the three levers you have: use less energy (E), use cleaner energy (I), or use less hardware (M). And because it's a rate, it rewards efficiency instead of punishing growth.

Not so fast, Junior! Renewable energy purchase agreements and certificates are a real and valuable effort by the providers, but they're an accounting instrument over a whole year and a whole fleet. At any given hour, the machine running your code is still plugged into a physical grid with a physical mix of sources. That's why the SCI uses location-based intensity and explicitly doesn't let you lower your score with offsets or market-based instruments: the only way to improve it is to actually emit less. Offsets may have a place in a company's climate strategy, but they're not an architecture decision. Reducing waste is.

Provider carbon dashboards

You don't need to start from zero. The three major providers offer carbon reporting for your account:

Tool	What it gives you
Azure: Emissions Impact Dashboard (and carbon optimization views in the portal)	Estimated emissions of your Azure usage, broken down by service and region, suitable for reporting and trend tracking.
AWS: Customer Carbon Footprint Tool	Estimated emissions of your AWS usage by service and region, available in the billing console, with historical data to track progress.
Google Cloud: Carbon Footprint	Estimated emissions per project, service and region, with export to BigQuery for your own analysis.

A few honest caveats: these reports usually lag behind by weeks or months, use each provider's own methodology (so comparing across clouds is tricky), and are better for trends and reporting than for real-time decisions. For day-to-day engineering, pair them with the proxies you already have: CPU and memory utilization, idle hours, storage volume, data transferred and, of course, the bill. For carbon-aware scheduling, you'll want grid intensity data by region and hour, which the GSF's open source Carbon Aware SDK can fetch from third-party data providers.

Design Principles for Sustainability

With the building blocks and the measurement in place, let's get practical. The following principles bring together the AWS Sustainability pillar, the Azure guidance on sustainable workloads and the Green Software Foundation's patterns.

1. Choose regions deliberately

Goal: Run workloads where the energy is cleaner, as long as business requirements allow it.

Regions differ in the carbon intensity of the local grid and in how much renewable or carbon-free energy the provider has there. Google, for example, publishes carbon-free energy information per region, and its console highlights lower-carbon regions. Latency, data residency laws (like LGPD or GDPR), service availability and cost still come first, but when two regions satisfy the requirements, carbon is a legitimate tiebreaker.

Approach	Benefit
Include carbon intensity in region selection criteria, alongside latency, compliance and cost.	Moves the whole workload to a cleaner baseline with a one-time decision.
Place flexible work (batch, training, analytics) in cleaner regions, even if interactive traffic stays close to users.	Captures most of the benefit without hurting user experience.
Keep data close to compute.	Avoids moving large volumes across regions, which costs energy and money.

2. Maximize utilization and right size

Goal: Get more useful work out of every machine you provision.

This is where sustainability and cost shake hands. Because of energy proportionality and embodied carbon, an oversized fleet running at low utilization is wasteful twice: it burns energy while doing little, and it ties up hardware that had a carbon cost to manufacture.

Approach	Benefit
Right size continuously based on real utilization metrics, not on the "just to be safe" estimate from launch day.	Fewer, fuller machines doing the same work.
Scale to demand with autoscaling, including scale-in and scale to zero where the platform supports it.	Capacity follows the load curve instead of sitting at peak all day.
Turn off non-production environments outside working hours, and create them on demand.	Removes a huge share of idle hours with a simple schedule.
Prefer higher-density platforms: containers, serverless and managed services where it makes sense.	The provider packs many tenants on shared hardware, raising utilization far beyond what a single team usually reaches.
Use the latest efficient instance families, including ARM-based processors where your stack supports them.	Newer generations generally deliver more performance per watt. Validate with your own benchmarks.

3. Shift and shape demand

Goal: Do flexible work when and where the grid is cleaner, and scale down optional work when it isn't.

Not everything needs to run right now. Nightly reports, data pipelines, model training, video transcoding, backups and index rebuilds usually have a deadline, not a specific minute. That flexibility is an opportunity.

Approach	Benefit
Separate urgent work from flexible work in your design, with queues and deadlines instead of fixed schedules.	Creates the freedom to choose when things run.
Schedule flexible jobs using grid intensity forecasts (time shifting) or run them in a cleaner region (location shifting).	Same work, same energy, lower emissions.
Shape demand: degrade gracefully when intensity is high, for example lower default video resolution, fewer background refreshes, or deferred non-essential features.	Keeps the core experience while trimming optional consumption.
Flatten peaks with queues and load leveling.	Smoother load means less capacity provisioned only for the peak.

4. Manage the data lifecycle

Goal: Store only what you need, in the right tier, for as long as you need it.

Data feels free because it's invisible. It isn't. Every copy lives on disks that consume energy and were manufactured with embodied carbon, and hot storage with high redundancy consumes more than cold archival tiers. Who hasn't found terabytes of debug logs from a service that was decommissioned two years ago?

Approach	Benefit
Classify data and define retention policies from day one.	Data stops accumulating by default.
Use lifecycle rules to move data between tiers (hot, cool, archive) and to delete it when retention ends.	Less energy-intensive storage for data that's rarely read, automatically.
Avoid unnecessary copies and over-replication: match redundancy to the data's real criticality.	Fewer disks spinning for the same information.
Compress and use efficient formats (for example columnar formats for analytics).	Less storage, less data transferred, less compute to scan it.
Reduce data transfer: caching, CDNs and sending only the fields the client needs.	Network equipment consumes energy too, and so do the devices on the other end.

5. Write efficient software

Goal: Do the same work with fewer CPU cycles, less memory and fewer network round trips.

This is where developers have direct influence. Efficient code isn't about micro-optimizations everywhere; it's about not doing work that isn't needed.

• Avoid unnecessary work: N+1 queries, polling where events would do, recomputing results that could be cached, serializing huge payloads nobody reads;
• Choose appropriate algorithms and data structures for hot paths, guided by profiling rather than guesses;
• Optimize the front end: smaller bundles, optimized images, lazy loading. A heavy page costs energy on every visit, on every device, forever;
• Use asynchronous and event-driven designs so resources aren't held while waiting;
• Remove dead features: code paths, scheduled jobs and integrations nobody uses still consume resources.

6. Be deliberate with AI and LLM workloads

Goal: Use the smallest model, the least hardware and the fewest tokens that meet the quality bar.

AI workloads deserve a principle of their own, because they concentrate everything we've discussed: power-hungry accelerators with significant embodied carbon, long-running training jobs, and inference traffic that grows with every user.

Let me tell you a story I've seen in more than one version. A team gets a GPU cluster approved for a proof of concept. The experiment runs for a couple of weeks, the results go into a presentation, everyone is happy, and the project moves on to the next phase... with a different architecture. The cluster? It stays there, fully provisioned, utilization close to zero, for months. Nobody owns it anymore, nobody remembers why it exists, and nobody wants to be the one who deletes it "in case someone needs it". Accelerators are among the most expensive and energy-hungry resources in the cloud, so this one forgotten cluster can easily outweigh every other optimization the team ever made. The finance team eventually noticed, of course, because cost and carbon waste usually show up in the same place.

Easy there, Junior! The biggest model is the most capable, not necessarily the most appropriate. Classifying a ticket into five categories doesn't need the same model that writes a legal analysis. A larger model generally needs more compute per token, more memory and often more accelerators to serve. If a smaller model meets your quality bar in your evaluations, the larger one is just burning energy to give you the same answer.

Approach	Benefit
Pick the smallest model that passes your evaluations, and route by task: small models for simple tasks, large ones only where they're needed.	Less compute per request for most of the traffic.
Use distilled, fine-tuned or quantized models where quality allows.	Smaller memory footprint, fewer accelerators, faster inference.
Batch inference requests and use batch APIs for work that isn't interactive.	Higher accelerator utilization; providers often price batch processing lower, too.
Cache responses and prompts (including provider prompt caching) and avoid regenerating identical answers.	Work done once, reused many times.
Keep prompts and outputs lean: trim context, limit output length, retrieve only relevant documents.	Tokens are compute; fewer tokens, less energy.
Prefer fine-tuning or retrieval over training from scratch, and schedule training in cleaner regions and windows.	Avoids the most energy-intensive step when it isn't needed, and makes the unavoidable part cleaner.
Give every accelerator an owner and an expiry, with alerts on low utilization and automatic scale to zero.	The idle GPU cluster story never happens again.

7. Extend hardware life and think about the end user

Goal: Reduce the embodied carbon your system demands, on both sides of the wire.

Embodied carbon isn't only in the data center. If your web app is so heavy that it only runs well on last year's phones, you're nudging users toward new hardware. If your internal tools require top-tier laptops, the same applies.

• Support older devices and browsers where reasonable, and keep the client lightweight;
• Prefer managed and shared services over dedicated hardware you'll underuse;
• For on-premises or hybrid estates, extend refresh cycles when the equipment still meets requirements, and consolidate before buying more.

Sustainability and Cost: Usually Friends, Not Twins

If you read the Cost Optimization principle, many of the practices above probably felt familiar: right sizing, turning off idle resources, lifecycle policies, autoscaling. That's no coincidence. In the cloud, you pay for resources, and resources consume energy and hardware. Most of the time, cutting waste cuts both the bill and the emissions.

Most of the time. Not always.

A few situations where the two diverge:

• The cheapest region isn't always the cleanest. Moving a workload to save a few percent on compute can land it on a grid that emits considerably more per kWh.
• "It's already paid for." Reservations and savings plans are great for cost, but they create a perverse incentive: if the capacity is prepaid, nobody bothers to turn it off. Financially it's sunk cost; for the planet, an idle machine is still drawing power. Right sizing the commitment in the next cycle matters.
• Carbon-aware engineering has a price. Measuring, building schedulers that follow grid intensity and running jobs in a more expensive but cleaner region all cost money and engineering time.
• Offsets cost money and reduce nothing in the architecture. They may be part of a corporate strategy, but they don't change the system's SCI.

Tradeoffs

Sustainability pushes the workload toward doing more with less: fewer resources, higher utilization, less data, cleaner energy. That's a healthy pressure, but like every pillar, it pulls against the others at some point. Shall we look at a few practical examples?

Tradeoffs with Reliability

Redundancy is the reliability pillar's best friend, and redundancy means resources that exist "just in case". A multi-region active-passive setup keeps a whole standby environment consuming energy and hardware while waiting for a disaster that may never happen.

Higher utilization leaves less headroom. A fleet running at high utilization is efficient, but a traffic spike or a failed node has less spare capacity to absorb it.

Aggressive scale-in and scale to zero introduce cold starts and scaling delays, which can hurt availability during sudden peaks.

Shorter retention and fewer data copies reduce storage, but also reduce the options for recovery and forensic analysis.

How to balance: match redundancy to the real criticality of each component (not every service needs multi-region), prefer active-active designs where the standby capacity does useful work, and use Reliability targets (SLOs, RTO, RPO) to justify every spare resource instead of adding them by reflex.

Tradeoffs with Performance Efficiency

Carbon-aware scheduling delays work on purpose. If a report needs to be ready in minutes, waiting for a cleaner window isn't an option.

Running in a cleaner but farther region adds latency for interactive users.

Smaller AI models are more efficient but may deliver lower quality on complex tasks, and demand shaping (lower video quality, fewer refreshes) is literally a reduction in experience.

On the other hand, Performance Efficiency and sustainability agree more often than they fight: efficient code, caching and less data transferred make systems both faster and greener.

Tradeoffs with Cost Optimization

As we saw above, they usually walk together, but cleaner regions can be more expensive, measurement and carbon-aware tooling cost engineering time, and early hardware refreshes for efficiency add embodied carbon and capital expense at the same time.

Tradeoffs with Security

Security controls consume resources: encryption, detailed audit logs, extended retention for compliance, scanning and duplicate environments for isolation all add energy and storage. You don't cut these to save carbon; you size them correctly, retain what regulations require (and not "forever by default"), and tier security logs like any other data.

Sharing infrastructure increases utilization but can weaken isolation. Multi-tenant density is great for sustainability, but some data classifications demand dedicated resources.

Tradeoffs with Operational Excellence

Measuring carbon, maintaining lifecycle policies, owning schedules and running carbon-aware pipelines is additional operational work. More automation, more components, more things to monitor. Without the discipline from Operational Excellence (ownership, IaC, automation), sustainability initiatives become one-off cleanups that decay within months.

Technically correct, Junior, and also a great way to get fired! A system that doesn't deliver value isn't sustainable, it's just off. The point was never to minimize resources at any cost, it's to minimize waste: resources that don't contribute to the value the business needs. Like every tradeoff, the answer is a conscious decision, documented and made together with the team and the business, not a reflex in either direction.

Conclusion

Sustainability is the newest pillar in the Well-Architected frameworks, but its ideas aren't new at all: use what you need, turn off what you don't, do work efficiently and pay attention to where your energy comes from. What changed is that we can now measure it, attribute it and design for it, just like we do with cost and performance.

The provider takes care of sustainability of the cloud; sustainability in the cloud is ours. That includes region choice, utilization, demand shifting, data lifecycle, efficient code and, increasingly, the deliberate use of AI. Most of these practices also lower the bill, which makes them an easy sell. The ones that don't should be discussed openly, as the tradeoffs they are.

In the end, sustainable architecture is simply architecture without waste. And a system without waste is cheaper, simpler, faster and easier to operate. Not a bad deal for something that's also good for the planet.

Next Steps

1. Get visibility Enable your provider's carbon reporting (Emissions Impact Dashboard, Customer Carbon Footprint Tool or Carbon Footprint) and review it alongside your cost reports. Pick one proxy you already track, such as idle hours or average utilization, as a starting metric.

2. Harvest the "Both win" quadrant Turn off idle resources, schedule non-production environments, right size oversized machines and apply lifecycle policies to storage and logs. Give every expensive resource, especially accelerators, an owner and an expiry date.

3. Define an SCI for a key workload Choose a meaningful functional unit (per user, per transaction, per job), estimate E, I and M, and track the rate over time. Use it to compare design options, not just to report.

4. Make flexible work carbon aware Identify batch, training and analytics jobs with flexible deadlines, move them to queues with deadlines, and experiment with time or location shifting using grid intensity data.

5. Review AI workloads with an efficiency lens Evaluate smaller or distilled models, add caching and batching, trim prompts and route tasks to the right model size.

6. Add sustainability to architecture reviews Include carbon as a criterion in design decisions and ADRs, next to cost, reliability and performance, and document the tradeoffs when you consciously choose against it.