Recommended
AWS Sustainability
Azure Sustainability
GCP Sustainability
Sustainability focuses on minimising the environmental impact of the solution by optimising the use of compute, storage, and network resources. This quality attribute was introduced by the AWS Well-Architected Framework and addresses energy consumption, carbon emissions, and resource efficiency. Evaluate this quality attribute across all architectural views documented in Section 3.
Sustainability is decided at the point of architecture choice, not retrofitted at scoring time. Concrete sustainability prompts are embedded in the views and lifecycle so they are confronted when the decision is being made, not parked in a separate section that gets filled in last:
| Where | What’s captured |
|---|
| 3.1.7 Logical View — Sustainability Considerations | Caching, async patterns, batch consolidation, framework weight |
| 3.3.6 Physical View — Sustainability Considerations | Region carbon intensity, auto-shutdown, ARM/efficient compute, auto-scaling, DR posture |
| 3.4.6 Data View — Sustainability Considerations | Retention minimisation, tiering, replication justification, compression |
| 5.5 Operations & Support — Sustainability in Operation | Auto-shutdown schedules, right-sizing cadence, orphan-resource reclamation, retirement |
| Cheat Card 6 — Sustainability Quick Hits | One-page summary of where carbon footprint is actually decided |
The remainder of this section captures the underlying measurement and reporting (carbon baseline, SCI metric, code/network/data efficiency) that supports those view-level decisions.
Before signing off the SAD, the architect should be able to answer these without consulting the team:
- Region choice — why this region for this workload, and what’s its carbon intensity relative to alternatives?
- DR proportionality — is the DR posture (cold / pilot light / warm / hot) matched to the actual RTO, or is it always-on by default?
- Non-production discipline — what’s the auto-shutdown schedule for dev/test, and how is it enforced?
- Data retention — what’s the retention period for each data store, and is it the minimum the regulator and business need?
- The biggest contributor — what’s the largest single source of this solution’s carbon footprint, and what would it take to halve it?
If any of these has no answer, the design is not yet sustainability-complete at Recommended depth.
Recommended
| Question | Response |
|---|
| Has the hosting location been chosen to reduce environmental impact? | Yes / No - [describe criteria: CO2 intensity, renewable energy, water usage] |
| What is the expected workload demand pattern? | Variable / Constant - [describe peaks and patterns] |
| Question | Response |
|---|
| Must the application be available continuously? | Yes / No |
| Can the solution be shut down or scaled down during off-peak hours? | Yes / No - [describe schedule] |
| Are non-production environments configured to downscale or shut down when not in use? | Yes / No - [details] |
| Question | Response |
|---|
| Are resources rightsized to avoid overprovisioning? | [describe approach] |
| Is vCPU utilisation monitored? | [target utilisation %] |
| Are the highest performance-per-watt hardware options used? | [details] |
Recommended
| Question | Response |
|---|
| Has a carbon footprint baseline been established for the solution? | Yes / No |
| Which cloud provider carbon reporting tool is used? | AWS Customer Carbon Footprint Tool / Azure Emissions Impact Dashboard / Google Carbon Footprint / Other / None / N/A |
| Is there a target for carbon reduction? | Yes / No — [target and timeframe] |
| Is the Software Carbon Intensity (SCI) metric tracked? | Yes / No |
Guidance
The Green Software Foundation defines three principles for sustainable software:
- Carbon efficiency — emit the least carbon possible
- Energy efficiency — use the least energy possible
- Carbon awareness — do more when the electricity is cleaner, less when it is dirtier
The Software Carbon Intensity (SCI) specification provides a standard metric for measuring the carbon impact of software: SCI = ((E * I) + M) per R where E = energy, I = carbon intensity of electricity, M = embodied emissions, R = functional unit. See sci.greensoftware.foundation.
| Question | Response |
|---|
| Is a CDN used to reduce origin server traffic? | Yes / No |
| Is edge computing used to process data closer to users? | Yes / No |
| Are efficient protocols used (e.g., HTTP/3, gRPC, protocol buffers)? | Yes / No — [details] |
| Is cross-region data transfer minimised? | Yes / No — [details] |
| Are data compression strategies applied to reduce transfer volumes? | Yes / No |
Comprehensive
| Question | Response |
|---|
| How do the language and framework choices contribute to efficiency? | [describe] |
| Has the code been optimised for the target platform and workload? | [describe] |
| Are efficient algorithms and data structures used? | [describe] |
| Is the number of vCPU hours per job/request minimised? | [describe] |
Comprehensive
| Question | Response |
|---|
| Is data held close to compute to reduce network transfer? | [details] |
| Are data replicas minimised? | [details] |
| Is old or unused data removed to reduce storage? | [details] |
| Are efficient data formats and compression used? | [details] |
| Are jobs prioritised and distributed to optimise resource usage? | [details] |
| Are efficient networking patterns used (reduced distance, data transfer volume)? | [details] |
Guidance
Consider the environmental impact of:
- DR environments - Optimal patterns for standby compute (e.g., pilot light vs. warm standby)
- Non-production environments - Auto-shutdown schedules, right-sized environments
- Data lifecycle - Tiered storage, data expiry, archive strategies
- Network design - Minimising cross-region traffic, edge computing
Scoring Guidance
| Score | What This Looks Like |
|---|
| 1 | Sustainability acknowledged but no specific actions taken |
| 3 | Hosting location considered for carbon impact, non-production auto-shutdown enabled, resources right-sized, carbon baseline established |
| 5 | All of the above plus SCI metric tracked, workload patterns optimised, network efficiency addressed, continuous availability justified where required |
