AWS Sustainability
AWS in October 2025 has released the new sustainability pillar into the well architecture framework, adding to the existing pillars within the well architecture framework.
Like other pillars there’s a continuation of the shared responsibility model which plays a common theme across their pillars. This is effectively highlighting the obvious, that Amazon takes the lion share of the commitment through how they manage feed and water (quite literally) their data centres, although there are things their customers can do to even further their sustainability drivers through “cleaner” code, better design for the application and platform (I’ll share thoughts on this later).
This effort can range from the initial selection of an efficient programming language, adoption of modern algorithms, use of efficient data storage techniques, deploying to correctly sized and efficient compute infrastructure, and minimizing requirements for high-powered end-user hardware. – Amazon (Sustainability in the cloud)
What’s not clear is where are these efficiencies are going to come from? Amazon already runs a rather optimised stack through the work taking part in Annapurna Labs. I find this tobe a massive commitment on their part considering the return on benefits from Moore’s Law are dwindling as chip architecture shrinks below the 3 nano metre mark it’s hard to see where the power efficiencies are going to come from if not purely through better circuit design?
All I can think of is that AWS will focus more on packing as much compute into a single space and thus through the power of scale would be able to localise the energy needed to sustain it.
Best Practices for Sustainability in the Cloud
Choice of region
not all regions are on even; some especially American one’s have a large investment in solar and wind renewables. Depending the region you’re in will heavily impact what services would be available for myself and the many others who in European regions might find we do not all stack up so positively.
User Behaviour
scale infrastructure with user load.
Rather self-explanatory, if you’ve been working in the cloud for any length of time you’ve most likely discovered the broad benefits of that strategy already as a means of dealing with predictable high peaks and managing scale of the application. On the flip side off that equation is the problem caused through scaling, in that generally developers have a tendency to over spec rather-then under, this as natural cause and effect from the behaviours in a professional IT Department, i.e. if the service falls-over due to load, then an engineer gets called out, the natural position to take then is to scale higher in anticipation to obfuscate this event from happening again.
The downside to that manner of thinking is compute gets wasted idling…. Now for those who may of noticed, yes I’ve intentionally left out the Cost Pillar in the above, and it is true that a matured product cost managed IT department would hold a squad over hot coals for wasteful spend, That said most service departments will tend to ignore the spend in exchange for the sense of comfort from a reliable system and rightly so… unless you’re tracking to the penny your ROI on each service it’s hard to make a counter argument to this line of thinking.
Align SLAs to sustainability
This one does what it says on the tin, and working with procurement to ensure that we worth with our vendors both internally and externally to ensure that mandate what our expectations are for working in a sustainable way.. For example asking vendors to commit to sustainable system design alongside the organization and commit to move towards net zero goals.
“The equilibrium between supply and demand is achieved only through a reaction against the upsetting of the equilibrium”― David Harvey
Stop the creation and maintenance of unused assets.
A reasonable ask, and for those who are already practicing good FinOps cleanliness, then you’ll be en-route to active this. This is one of angles that make economic sense to me with regards how to get business engagement on this initiative. If at the end of the day this impacts the bottom-line for companies then the investment makes sense…. In a sense, it a note to development teams to remember to put your toys way when you’re finished playing….
Optimise geographic placement of workloads for user locations.
Very practical, though this is money for old rope for those who are already have CDNs in place to enable better latency with our customers, what could be added here is not to have redundancy is zones where the amount of traffic doesn’t make sense, for example if you’re only getting a handful of users a month. That said, this could be seen equally as cost optimisation as it could being ecologically friendly…
Optimise team member resources for activities performed.
Software and architecture patterns
Optimise software and architecture for asynchronous and scheduled jobs.
It took me a while to work why this would make a difference, obvious when you really think about it. synchronous calls are infrastructural heavier, if you have to build in enough tin to take the beating of 500, 5,000 or 50,000 etc. requests per minute then you will obviously spec up the shared infrastructure be that the midddleware so chunky Oracle DB etc to take the beating when the requests are high. Regardless of the direction this scales there’s a good chance it will spend most of it’s time lurking around wasting energy (and money).
Remove or refactor workload components with low or no use.
Consolidate and remove. Now this forms a big part of my day-to-day already it is just good hygiene to remove things we nolonger use or do not give a return. As has been said a few times in this article, there’s allot of cross over between good cost management and sustainability.