As part of our ongoing series exploring the AWS Well-Architected Framework, we arrive at the sixth and final pillar: Sustainability. Introduced at AWS re:Invent in 2021, the Sustainability Pillar is a relatively recent addition, but its relevance and impact have been immediate and significant.
What makes this pillar compelling is its simplicity: it consolidates many existing best practices into a coherent framework. AWS has taken an area that is traditionally difficult to quantify—carbon footprint—and made it more approachable by offering a structured, best-practice-driven approach for cloud workloads..
The Role of the Sustainability Pillar
Unlike the other pillars in the Well-Architected Framework, the Sustainability Pillar functions more like a catalogue of guidance rather than a Q&A checklist. It breaks down into six key categories:
- Region Selection
- User Behaviour Patterns
- Software and Architecture Patterns
- Data Patterns
- Hardware Patterns
- Development and Deployment Process
Let’s explore each in turn.
1. Region Selection
The concept here is straightforward: some AWS regions are greener than others due to the energy sources powering them. If your application doesn’t have stringent low-latency requirements, you can—and should—opt for a region with a higher sustainability rating. For example, Ireland and US East (N. Virginia) are considered sustainable within AWS.
As Werner Vogels put it, “Cloud providers are responsible for the sustainability of the cloud; customers are responsible for sustainability in the cloud.” AWS will ensure its data centres are optimised for energy efficiency. Our role, as architects and developers, is to build workloads that make sustainable use of those platforms.
2. User Behaviour Patterns
This category encourages us to align SLAs and UX with sustainability goals. As sustainability becomes a board-level concern, questions like “How green is your app?” will become standard.
SLAs should reflect not just performance and availability, but also environmental impact. For instance, do you need high availability 24/7 for a batch reporting system used once a week? Probably not. Minimising unnecessary uptime can directly reduce energy usage.
3. Software and Architecture Patterns
Efficient software design is sustainable software design. This includes refactoring for performance, reducing memory and CPU overhead, and adopting architectural patterns like serverless that naturally scale to actual demand.
Poorly optimised frontends also contribute to energy inefficiency. Heavy client-side apps shorten device battery life and increase user-side energy use. Lightweight web and mobile apps help prolong device lifespan—an often overlooked aspect of sustainability.
We must return to an older mindset: think in terms of limited resources. The cloud may feel limitless, but our planet isn’t.
4. Data Patterns
Data is both a goldmine and a minefield. As Adrian Cockcroft quipped:
“If you collect a piece of data and don’t immediately feed it into a model, delete it.”
That’s an extreme stance—but the underlying principle holds.
Storing and transmitting unneeded data has a sustainability cost. Classify your data. Process only what’s necessary. Minimise data movement across networks. And be ruthless about retention policies. Sustainable data practices are also secure and privacy-aware by nature.
5. Hardware Patterns
This section asks us to right-size our compute. All too often, teams overprovision with the biggest instance sizes they can find. But more isn’t always better.
Serverless platforms, such as AWS Lambda, abstract much of this concern. Tools like the Lambda Power Tuner can help you determine optimal resource settings. Meanwhile, newer architectures using Graviton processors offer better performance per watt—sustainability with speed.
6. Development and Deployment Process
Lastly, sustainable DevOps means streamlining your pipelines and environments. Avoid build environment sprawl. Don’t run full test suites if no one’s reading the results. And regularly audit your CI/CD tools to ensure they add value and aren’t just “always-on” by default.
A key question here is: “How do you enable rapid improvements in sustainability through process?”
If you adopt a serverless-first mindset, you’ll benefit instantly from platform-level improvements—such as Graviton-based infrastructure—without rewriting your stack.
Final Thoughts
The AWS Sustainability Pillar isn’t just another checkbox—it’s a strategic lens through which to view your entire cloud estate. Sustainability isn’t an add-on; it’s a design principle.
As energy prices rise and environmental regulations tighten, adopting sustainable architecture is no longer a “nice to have”. It’s a business imperative.
By aligning with the Sustainability Pillar today, you’re not just future-proofing your architecture—you’re building a greener, more resilient tomorrow.
Serverless Craic from The Serverless Edge
Check out our book, The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
I’m sorry, but putting a “sustainability” pillar into the Well Architected Framework is nothing but political and marketing nonsense!
I get environmental responsibility, and I support it. But this pillar does absolutely nothing to enhance or even inform architecting in the Cloud!
It’s just AWS marketing, that will not impact how Architects develop solutions for the AWS platform. For that reason, it does not belong in the framework. The framework is supposed to be a technical reference, not a tool for marketing.