Non-functional Application Requirements: Sustainability

On 7 July 2026, Ireland's statistics office published a number worth sitting with. In 2025, data centers used 23% of the country's metered electricity. That's more than every urban home in Ireland combined, at 18% (CSO, 2026).

That same summer, Amazon's 2025 sustainability report said its absolute emissions rose 16% in a year. The same report says Amazon matched 100% of its electricity with renewable energy, for the third year running.

Both are true, because they measure different things. If you can't tell which is which, you can't tell whether your own architecture choices helped.

So this finale is built around a panel. I didn't interview anyone. I took the questions I'd ask and answered them from what six experts have already published.

TL;DR

Sustainability is energy, carbon and water per unit of useful work. Track a resource proxy (vCPU-minutes per transaction) weekly and carbon monthly.

Know which carbon number you're reading: location-based or market-based, and which scope.

AWS owns sustainability of the cloud. You own sustainability in it: fewer resources, busy for less time, on efficient chips, in a well-chosen Region.

AWS carbon data is monthly and stops at account, Region and service. Nothing gives you carbon per model call.

For AI, inference is the part you control. The smallest adequate model, caching and batch cut cost and carbon together. Sometimes the right model is a regex.

What: sustainability you can test

Sustainability is the requirement to keep the environmental cost of each unit of useful work low for the life of the workload. Three quantities get mixed up.

Energy is the kilowatt-hours your resources draw, busy or idle. Carbon is that energy times the grid's carbon intensity, plus the emissions from making the hardware. Water goes into cooling and power generation. A cleaner grid cuts carbon without saving a kilowatt-hour, so report them separately.

The GHG Protocol sorts emissions into scopes: Scope 1 is fuel burned on site, Scope 2 is bought electricity, Scope 3 is everything else, including making the servers. What AWS emits running your workload lands in your Scope 3. Then there's method. Location-based carbon uses the average grid where the power was used. Market-based carbon credits the renewable contracts a company buys. "100% matched" is a market-based claim.

To make it testable, the Green Software Foundation's Software Carbon Intensity (SCI) spec, now ISO/IEC 21031:2024, gives you a rate:

SCI = ((E × I) + M) per R

E is energy, I is grid carbon intensity, M is the hardware's share of embodied emissions and R is your functional unit, like one API call. Offsets and renewable certificates can't lower it. Only cutting emissions can.

flowchart LR E["E<br/>energy"] --> EI["E x I<br/>carbon from the energy used"] I["I<br/>grid carbon intensity"] --> EI EI --> T["Total emissions"] M["M<br/>hardware share of<br/>embodied emissions"] --> T T -->|"per R"| SCI["SCI<br/>carbon per functional unit<br/>like one API call"] X["Offsets and renewable<br/>certificates"] -.->|"can't lower it"| SCI

The score only falls when energy, grid intensity or embodied emissions per unit of work fall.

You won't know E for a managed service, so AWS Well-Architected suggests a proxy KPI: resources provisioned per unit of work, like vCPU-minutes per transaction. It moves within days of a change. The carbon report catches up weeks later.

Why: the grid can't keep up

Data center demand is outgrowing the grids that feed it. The IEA's April 2025 Energy and AI report put data centers at about 415 TWh in 2024, roughly 1.5% of global electricity. Its 2026 follow-up, Key Questions on Energy and AI, says demand grew 17% in 2025 to about 485 TWh, against 3% for electricity overall, with AI-focused data centers up 50%. It expects roughly 950 TWh by 2030.

Hardware matters too. Amazon's report puts supply-chain emissions, including data center construction and hardware, at 76% of its footprint, up 20% in a year. Every idle server you keep carries a slice of that.

The good news: almost every sustainability lever is also a cost lever, so savings fund the work.

The panel: six published answers

Each answer paraphrases published work, with a link and at most one short quote.

Where do I start? Adrian Cockcroft, former VP of Sustainability Architecture at Amazon. His QCon London 2023 talk boils developer advice down to "use fewer computers, and use them for less time" (InfoQ, 2023). He prefers location-based data for tuning, and AWS has published it since June 2025.

How do I measure honestly? Asim Hussain, executive director of the Green Software Foundation until March 2026. The SCI is built so a score falls only when emissions do. In a 2023 interview he called carbon-aware scheduling a cheap way to save a few percent, not the big win. He also says green software is "more efficient, which translates almost always to being faster" (MIT Technology Review, 2023).

Which practices matter? Anne Currie, Sarah Hsu and Sara Bergman, authors of Building Green Software (O'Reilly, 2024). Their chapters give you three buckets for any change (O'Reilly): code efficiency (less compute per task), hardware efficiency (fewer devices, kept longer) and carbon awareness (run work when and where the grid is clean).

Training or inference? David Patterson and Jeff Dean, Google. Their 2022 paper reports inference at about three-fifths of Google's machine-learning energy (arXiv, 2022). A Meta team led by Carole-Jean Wu saw a similar 10:20:70 split across experimentation, training and inference. Patterson and Dean also co-authored Google's 2025 Gemini study: 0.24 Wh per median text prompt, after a 33x drop in a year.

Does model choice matter? Sasha Luccioni, then at Hugging Face, now co-founder of Sustainable AI Group. With Yacine Jernite and Emma Strubell, she measured 1,000 inferences across many tasks. General-purpose generative models were "orders of magnitude more expensive than task-specific systems", even at similar sizes (ACM FAccT, 2024). Her AI Energy Score now rates models one to five stars per task.

Is it getting better? Fatih Birol, Executive Director of the IEA. He puts it plainly: "there is no AI without energy" (IEA, 2026). The IEA also says energy per AI task has fallen by at least an order of magnitude a year. Total demand still climbs, because there are far more calls.

When: one check per stage

Each stage gets one sustainability check:

Design. Shortlist Regions on residency, cost and latency, then pick the lowest-carbon one left, as Well-Architected's SUS01-BP01 advises. Define your proxy KPI, and ask whether the feature needs an LLM.
Build. Default to arm64. Batch instead of trickling. Give every table, bucket and log group an expiry on day one.
Test. Run Lambda Power Tuning, and record the proxy KPI next to p95.
Operate. Read the proxy weekly and the carbon report monthly. Delete what's idle.

Where: your levers on AWS

Well-Architected splits it. AWS handles sustainability of the cloud: infrastructure, water, renewable power. You handle sustainability in the cloud: your workloads, utilization and how much you deploy. Everything below is yours.

flowchart LR AWS["AWS<br/>sustainability of the cloud"] --> A1["Infrastructure, water<br/>and renewable power"] YOU["You<br/>sustainability in the cloud"] --> Y1["Workloads, utilization<br/>and how much you deploy"] Y1 --> L1["Lambda on arm64"] Y1 --> L2["Graviton on EC2, ECS and EKS"] Y1 --> L3["DynamoDB on-demand with TTL"] Y1 --> L4["S3 lifecycle and Intelligent-Tiering"] Y1 --> L5["AWS Sustainability console and API"]

AWS owns the infrastructure, water and power, and every lever in this section sits on your side of the line.

Lambda on arm64. For most Node.js and Python functions it's one line. AWS's 2021 launch claim was up to 19% better performance at 20% lower cost. Native binaries without arm64 builds will block you, and Compute Optimizer only sizes memory for x86_64 functions.

Graviton on EC2, ECS and EKS. AWS says Graviton instances use up to 60% less energy than comparable EC2 instances for the same performance. That's a vendor ceiling with no stated baseline, so benchmark your own workload.

DynamoDB on-demand with TTL. On-demand removes idle capacity. TTL deletes expired items without using write throughput, typically within a few days, so filter them in reads. On global tables, replicated deletes do cost write units.

S3 lifecycle and Intelligent-Tiering. Objects under 128 KB never tier down. AWS doesn't publish energy per storage class, so tiering is a proven cost lever but only an assumed carbon one. Expiration is the lever you can count on. Deleted bytes need no disks.

The AWS Sustainability console and API. The Customer Carbon Footprint Tool added Scope 3 (hardware and buildings, fuel and energy, upstream transport) and Scope 1 data in October 2025. AWS deprecated it on 30 June 2026 for the AWS Sustainability console, which keeps the methodology but has its own permissions, so analysts don't need Billing access (CCFT release notes). The limits matter: monthly at best, published between the 15th and 21st of the next month, by account, Region and service only.

Open source fills the gaps. The Green Software Foundation's Carbon Aware SDK reads grid data from WattTime or Electricity Maps so you can shift work in time or place. Lambda Power Tuning finds the cheapest or fastest memory size. It measures money and time, not watts, so GB-seconds are your proxy.

Decide: which lever, and what it costs elsewhere

I'd start with the certain, cheap levers and work down:

Lever	Carbon effect	Cost effect	Main risk
Expire data, delete idle resources	Large and certain	Saves	Deleting something you needed. Use TTL and lifecycle rules, not scripts.
Right-size memory and instances	Large	Saves	Too small hurts p95
Move to arm64 or Graviton	Medium to large, per AWS	Usually saves	Dependencies without arm64 builds
Batch and queue	Medium	Saves	Added latency
Run batch work in a low-carbon Region	Large for that workload	Neutral to higher	Residency, more Regions to run
Time-shift to clean hours	Small, a few percent per Hussain	Neutral	Complexity

Region choice is where sustainability collides with two requirements at once. Picture a team serving users in Lagos. The closest AWS compute is the Lagos Local Zone, whose parent Region is Africa (Cape Town). Ember reports that South Africa generated 18% of its electricity from low-carbon sources in 2025, against a 43% global average. Sweden, home to Europe (Stockholm), managed 99%. And section 41 of Nigeria's Data Protection Act 2023 lets personal data leave the country only when the recipient offers adequate protection, unless another basis in the Act applies.

Cleanest, closest and legal are three different answers.

flowchart LR C["Cleanest grid<br/>Stockholm eu-north-1<br/>99% low-carbon in 2025"] ---|"long way from Lagos users"| L["Closest to users<br/>Lagos Local Zone<br/>parent Region Cape Town"] L ---|"you inherit an 18% low-carbon grid"| D["Where the law allows<br/>NDPA 2023 section 41<br/>adequacy test"] D ---|"may rule Stockholm out for personal data"| C B["Batch jobs, evals,<br/>fine-tuning"] -.->|"free to move"| C I["Interactive APIs<br/>and chat"] -.->|"stay close"| L P["Personal or<br/>regulated data"] -.->|"stays put"| D

Each workload picks its own corner: move what nobody waits for, and keep regulated and interactive paths where they must be.

So decide per workload. Here's how sustainability trades against the other eight requirements:

NFR	Where sustainability helps	Where it hurts
Security	Fewer resources, less attack surface	Scanning, encryption and logging use compute
Compliance	Data minimization serves both	Residency can rule out the cleanest Regions
Accessibility	Lean pages work on low-end devices	Rarely in conflict
Performance	Efficient code is usually faster	Always-warm capacity burns energy idle
Availability	Rarely helps	Redundancy multiplies resources
Scalability	Scale-to-zero removes idle	Headroom you never use
Maintainability	Fewer moving parts	Carbon-driven multi-Region adds parts
Cost	Mostly aligned	A cheap token isn't always a low-energy token

Hands-on: a lean ingest stack for Harbor Works

Let's put the certain levers into code. Harbor Works is the fictional plant from Luso, this series' companion app, and its production lines send batches of inspection events. The stack uses an arm64 Lambda, on-demand DynamoDB with TTL, an S3 rule that tiers then expires raw batches, and two-week log retention.

Checked against the AWS CDK v2 API reference for lambda.Function, dynamodb.TableV2 and s3.LifecycleRule on Oct 29, 2026, type-checked in strict mode and synthesized with aws-cdk-lib 2.275.0. Not deployed, so test it in a sandbox account first.

import { App, Stack, StackProps, Duration, RemovalPolicy, CfnOutput } from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as lambda from 'aws-cdk-lib/aws-lambda'; import * as logs from 'aws-cdk-lib/aws-logs'; import * as dynamodb from 'aws-cdk-lib/aws-dynamodb'; import * as s3 from 'aws-cdk-lib/aws-s3'; export class LeanIngestStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Hot data. Inspection events expire through TTL, which uses no write throughput. const events = new dynamodb.TableV2(this, 'LineEvents', { partitionKey: { name: 'lineId', type: dynamodb.AttributeType.STRING }, sortKey: { name: 'ts', type: dynamodb.AttributeType.STRING }, billing: dynamodb.Billing.onDemand(), // no idle provisioned capacity timeToLiveAttribute: 'expiresAt', // epoch seconds, set by the writer removalPolicy: RemovalPolicy.DESTROY, // sandbox only, use RETAIN in prod }); // Cold data. Raw batches tier down on their own, then get deleted. const archive = new s3.Bucket(this, 'RawArchive', { encryption: s3.BucketEncryption.S3_MANAGED, blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, enforceSSL: true, lifecycleRules: [{ id: 'tier-then-expire', prefix: 'raw/', transitions: [ // Unknown access pattern: let Intelligent-Tiering decide. { storageClass: s3.StorageClass.INTELLIGENT_TIERING, transitionAfter: Duration.days(0) }, // After a year it's only kept for audit. { storageClass: s3.StorageClass.DEEP_ARCHIVE, transitionAfter: Duration.days(365) }, ], expiration: Duration.days(365 * 3), // the rule that actually removes bytes abortIncompleteMultipartUploadAfter: Duration.days(7), }], removalPolicy: RemovalPolicy.DESTROY, autoDeleteObjects: true, // sandbox only }); // Logs are data too. Two weeks, not the default of forever. const logGroup = new logs.LogGroup(this, 'IngestLogs', { retention: logs.RetentionDays.TWO_WEEKS, removalPolicy: RemovalPolicy.DESTROY, }); const ingest = new lambda.Function(this, 'Ingest', { runtime: lambda.Runtime.NODEJS_24_X, architecture: lambda.Architecture.ARM_64, // Graviton memorySize: 512, // starting point, then Power Tuning decides timeout: Duration.seconds(10), handler: 'index.handler', code: lambda.Code.fromInline(` exports.handler = async (event) => { // Batch, don't trickle: one invocation handles many events. return { received: (event.Records || []).length }; };`), logGroup, environment: { TABLE: events.tableName, BUCKET: archive.bucketName }, }); events.grantWriteData(ingest); archive.grantPut(ingest); // Printed by cdk deploy. Power Tuning needs it below. new CfnOutput(this, 'IngestArn', { value: ingest.functionArn }); } } const app = new App(); // Pick the Region on residency and latency first. eu-north-1 is only an example. new LeanIngestStack(app, 'LeanIngestStack', { env: { region: 'eu-north-1' } });

The synthesized template shows Architectures: [arm64], BillingMode: PAY_PER_REQUEST, TTL, RetentionInDays: 14 and both transitions.

So why 512 MB? It's a starting guess. Lambda gives CPU in proportion to memory, a full vCPU at 1,769 MB, so the setting with the fewest GB-seconds is sometimes larger than you'd expect. Deploy Power Tuning from its repo and let it decide.

Checked against the Lambda Power Tuning execution docs on Oct 29, 2026. Not run, so test it in a sandbox account first.

# INGEST_ARN comes from the stack output. POWER_TUNING_ARN is the tool's state machine. cat > tuning-input.json <<EOF { "lambdaARN": "${INGEST_ARN}", "powerValues": [128, 256, 512, 1024, 1769], "num": 50, "payload": { "Records": [] }, "parallelInvocation": true, "strategy": "cost" } EOF aws stepfunctions start-execution \ --state-machine-arn "$POWER_TUNING_ARN" \ --input file://tuning-input.json

Then take a monthly carbon baseline. The end date is exclusive, so this returns January to September 2026.

Checked against the AWS CLI reference for get-estimated-carbon-emissions on Oct 29, 2026. Not run, so test it in a sandbox account first.

aws sustainability get-estimated-carbon-emissions \ --time-period Start=2026-01-01T00:00:00Z,End=2026-10-01T00:00:00Z \ --group-by REGION SERVICE \ --granularity MONTHLY \ --emissions-types TOTAL_LBM_CARBON_EMISSIONS TOTAL_MBM_CARBON_EMISSIONS

Chart the location-based column, the one Cockcroft says to tune on, next to your proxy KPI.

Sustainability in the age of AI

AI as a workload

Patterson's and Wu's numbers agree: over a model's life, inference dominates, and inference is the part you pay for and control. The Green Software Foundation's SCI for AI, ratified in December 2025, formalizes this. A provider boundary covers design, training and deployment. A consumer boundary covers operation, with units like carbon per token or per agent workflow.

Better still, the Amazon Bedrock features that cut your token bill also cut compute per answer:

Model Distillation. AWS claims distilled models run up to 500% faster and cost 75% less, with under 2% accuracy loss for use cases like RAG.
Prompt caching. Up to 90% lower cost and 85% lower latency, per AWS, because the cached prefix isn't reprocessed.
Intelligent Prompt Routing. Picks between two models in a family per prompt, so easy requests can go to the smaller one.
Batch inference and the Flex tier. Batch costs 50% of on-demand for selected models. Flex is discounted for work that can wait.

Here's the caveat. AWS publishes prices and speedups for these, not watts. The energy saving is my inference, not published data.

flowchart LR F["Model Distillation<br/>prompt caching<br/>Intelligent Prompt Routing<br/>batch inference and Flex"] -->|"published by AWS"| C["Lower token bill<br/>and faster answers"] F -.->|"inferred, no watts published"| W["Less compute<br/>per answer"]

The cost saving is published by AWS, but the energy saving is an inference, not measured data.

Silicon. AWS claims Inf2 instances give up to 50% better performance per watt than comparable EC2 instances. Trainium3's figures use different baselines, so they don't compare. The December 2025 launch post claims "4x greater energy efficiency" for UltraServers against Trainium2 UltraServers and "40% better" for the chip against earlier generations. Amazon's 2025 sustainability report says over five times more output tokens per megawatt. They matter if you self-host on SageMaker or EKS. On Bedrock, you don't pick the chip.

The measurement gap. The Sustainability API groups by USAGE_ACCOUNT_ID, REGION and SERVICE, nothing finer. You'll see a monthly service share, not which model or agent produced it. So estimate per call from token counts and a public benchmark such as the AI Energy Score, label it an estimate, and track tokens per successful task as your proxy. Cross-Region inference also moves prompts onto other grids, which makes it a Compliance decision too.

The biggest lever comes first: whether to call a model at all. Luccioni's "orders of magnitude" is why this tree exists.

flowchart TB A["New feature idea"] --> B{"Is the output fixed<br/>for a given input?"} B -->|"yes"| R1["Rules, regex, SQL<br/>or a lookup table"] B -->|"no"| C{"Narrow task with<br/>labeled examples?"} C -->|"yes"| R2["Small task-specific model<br/>classifier or extractor"] C -->|"no"| D{"Asked and answered<br/>before?"} D -->|"often"| R3["Cache or retrieve<br/>the stored answer"] D -->|"rarely"| E{"Does a user wait<br/>for the result?"} E -->|"no"| R4["Smallest adequate LLM<br/>through batch or Flex"] E -->|"yes"| R5["Smallest adequate LLM<br/>with caching and routing"]

A general-purpose LLM is the last stop on every branch, after rules, small models and caches.

At Harbor Works, flagging a reading above a line's temperature limit is a rule. Summarizing last night's shift log goes through batch, because nobody waits on it at 2 a.m.

AI as an engineering aid

Coding assistants are good at the mechanical work: porting builds to arm64, adding lifecycle rules and log retention across a repo. They're bad at numbers. Ask one for a Region's carbon intensity and you'll get a confident figure with no source. So:

Accept no carbon or energy figure from an assistant without a primary link.
Judge each suggested optimization on the proxy KPI before and after, not on how good the explanation sounds.
Count the assistant itself. Agent loops are inference too, so cap their iterations in CI.

Who: owners and the shared responsibility split

Activity	Product owner	Architect	Developers	Platform / FinOps
Define unit of work and proxy KPI	A	R	C	C
Region and silicon choice	C	A	C	R
Right-sizing, arm64, retention	I	C	R/A	C
Monthly carbon reporting	I	C	I	R/A
"Should this use an LLM?"	A	R	C	I

R = responsible, A = accountable, C = consulted, I = informed.

Your share depends on the compute type:

EC2. AWS runs facilities, power and hardware. You own instance family, utilization, schedules and Region.
Fargate. AWS also packs hosts. You own task size, arm64 images and scaling to zero.
Lambda. AWS also packs environments. You own memory, architecture, invocations and logs.
Bedrock. AWS runs serving and the model provider owns training. You own whether to call, which model, tokens, caching and batch.

Monday checklist

[ ] Pick one unit of work and chart vCPU-minutes or GB-seconds per unit weekly.
[ ] Record a location-based carbon baseline by Region and service.
[ ] Switch your three busiest Lambda functions to arm64 and run Power Tuning on each.
[ ] Give the five largest log groups a retention period and the five largest buckets a lifecycle rule.
[ ] Add TTL to every DynamoDB table holding time-bound data.
[ ] Check whether residency lets your batch and eval jobs run in a lower-carbon Region.
[ ] Put every new AI feature through the decision tree, and log tokens per successful task.

Conclusion

I couldn't put these six in a room, but their published answers line up. Cockcroft gives the instruction: fewer computers, for less time. Hussain and the SCI make it measurable without offsets. Currie, Hsu and Bergman sort the work. Patterson and Luccioni show that for AI, inference and model choice are where your control sits. Birol warns that cheaper calls won't help if the calls keep multiplying.

So keep three habits: a proxy you move weekly, a carbon report you read monthly, and the reflex of asking whether a model call is needed. Ireland's 23% is what millions of small provisioning decisions add up to.

Make every watt answer a question someone actually asked.

Series wrap-up: nine requirements, one system

Part 1 started from Werner Vogels' re:Invent 2023 keynote and the first law of his Frugal Architect: make cost a non-functional requirement. Nine requirements later, none stands alone, and AI has pulled them tighter. One LLM feature now touches residency, prompt injection, screen readers on streamed text, time-to-first-token, throttling, token quotas, prompt versioning, the token bill and the energy behind it.

flowchart LR SEC["Security"] -->|"controls add latency"| PERF["Performance"] SEC -.->|"both non-negotiable"| COMP["Compliance"] COMP -->|"residency limits failover Regions"| AVAIL["Availability"] COMP -->|"residency limits clean Regions"| SUS["Sustainability"] A11Y["Accessibility"] -.->|"lean pages help low-end devices"| PERF PERF -->|"warm capacity sits idle"| SUS AVAIL -->|"redundancy multiplies resources"| COST["Cost"] SCAL["Scalability"] -->|"headroom costs money"| COST SCAL -.->|"autoscaling absorbs spikes"| AVAIL MAINT["Maintainability"] -.->|"simple systems are easier to tune"| PERF COST -.->|"mostly aligned"| SUS

Solid arrows are tensions you have to decide, and dotted arrows are alliances you can use.

Security, Compliance and Accessibility are the floor. The other six are trade-offs you make on purpose, write down and revisit as things change.

Now over to you. Which of the nine do you find hardest to get right, and why? Tell me in the comments.

Series: Non-functional Application Requirements