Love the sustainability of AWS Well Architected Reviews

Written by Manuel Vogel

This blog post is part of a series about the AWS Well-Architected Framework, what it is, why it makes sense to do it, and how we at kreuzwerker do it. In this blog post, we will focus on the Sustainability pillar, which could also be called the Green Pillar - optimize beyond costs.

What it is

The Well-Architected Review is NOT AN AUDIT, but a way of working together on how to improve your architecture by using best practices. It describes key concepts, design principles, and architectural best practices for designing and running workloads in the AWS cloud. The process leads you through several foundational questions and checks. It has been derived from years of experience gained from working with the AWS cloud regarding security, cost efficiency, and performance. Hence, it gives good advice on improvements. It helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for various applications and workloads.

It is built around six pillars

operational excellence 👨🏽‍💻
security 🔒
reliability 💪🏾
performance efficiency 🚀
cost optimization 💵
sustainability 🌳

and the AWS Well-Architected provides a consistent approach for customers and partners to evaluate architectures and implement scalable designs.

The hard facts about AWS Well-Architected reviews in 2022 are:

it consists of 58 questions in total across all pillars
it takes around 4-6 hours for one workload (without tool support)
the goal is to remediate 45% of the high-risk findings with a minimum of 20 questions answered.

We also described the process from our perspective in more detail here.

How we do it at kreuzwerker

Why should you do it with us?

As a Well-Architected partner, we do at least 20 well-architected reviews per year and have built overall deep architectural expertise for every pillar and hands-on experience.

How do we perform such a review?

For us, it's an interactive process: we inspect and adapt every time we do it by requesting feedback from our clients and doing a short internal retrospective. As of now, we perform it as follows:

We do it in 2 blocks from 09:00 - 12:00 and 13:00 - 15:00 with a lunch break. However, we can continually adapt if we are faster, e.g., we shift the gap, and we are also flexible whether doing it remotely or at your office.
We do it in an interactive, story-telling mode. This means: you talk, we listen, and then dig deeper into specific areas while being able to cover multiple questions.
Our process is supported by tools (more in the other part of the blog post series 🥳)

We do not just handle the questioning but give guidance to answering them. We can tell you how and why there could be improvements to be made. Alright, enough for the introduction. Let's jump right into it.

Sustainability Pillar

Sustainability is now on the mind of many enterprises. The announcement of this pillar at re'invent 2021 showed that AWS wants to prioritize a sustainable ecosystem. Lately, more and more companies have signed up for the Climate Pledge, promising to achieve net-zero carbon by 2040. However, many companies need support in how they will accomplish this; AWS’s Sustainability Pillar and we, as partners, will help companies achieve this goal.

The pillar was the 6th one announced, meaning it is now also seen as one of the top 6 fundamental principles and should be considered when designing and working with AWS environments. It offers practical advice on how to better architect your code, infrastructure, and practices to deliver sustainable workloads on AWS. As shown in the following graphic, the responsibilities are shared:

AWS is responsible for the sustainability of the cloud, such as data centers, cooling, water, building materials, etc.
You are responsible for the sustainability in the cloud, such as data design & usage & storage, utilization & scaling, code efficiency, etc.

Diagram showing the AWS shared responsibility model.

However, what does this mean in detail?

In a nutshell

If you're too overwhelmed to read the full whitepaper from AWS, Roman Sevko and Mark Faiers have created excellent summaries and AWS practical advice with their blog post series on sustainability.

Before you start, it's crucial to define metrics, targets, and KPIs. You need to understand where you are starting from in order to measure your progress and success. These are crucial in the other AWS WAR pillars as well. It is a whole topic by itself, and AWS gives a very good starting point in their blog post series.

Let's jump in. We structured and adapted contents about this pillar. So, in a nutshell, this is what it includes:

User behavior patterns 👨🏽‍💻

Cache: with services like e.g. ElasticCache to reduce the load on underlying resources such as databases, and RDS proxy for pooling of connections
Choose AWS Regions for your load near wind turbines and solar plants, which you can find on their interactive map.
Use Cloudfront, e.g., static assets, which also takes advantage of their edge locations

Software architecture patterns 🏡

Use containers and serverless, e.g., services like EMR, MSK, Redshift, which offer this feature as well
Use event-driven architectures because they correlate with the level of usage and scale accordingly

Data patterns 📑

Classify data with AWS Macie and use Lifecycles in S3
Before sending, compress data with compression algorithms like brotli, for example, at the CloudFront distribution
Use data formats like Parquet, for example, when working with AWS Athena, to keep query sizes low

Hardware patterns 🖥

Scale based on the utilization or prediction which is now natively part of Auto-scaling groups (ASG)
Use Graviton V2, Spot & Burstable instances and check the data in AWS Cost Explorer to find the right size for your instances
Use managed services wherever possible as AWS constantly improves the efficiency under the hood. Additionally you can use the AWS Compute Optimizer for EC2, EBS volumes and Lambda functions

Development and deployment process 🏗

Rewrite everything in Rust or any other low footprint language like Golang or spot already expensive lines of code at development time with AWS CodeGuru
Create software with backward compatibility of versions so that customers do not need to buy new devices (and so there is enough space on the old ones), especially API backward compatibility
Update libraries and other software, or let it automatically get upgraded from Services like the AWS Systems Manager Patch Manager
Build sustainability into your Software Development Cycle (SDLC): shift-left like, e.g., security
Update your OS regularly, and use golden images

Use SSM and CloudShell instead of bastion hosts

After summarizing this pillar from our point of view, let's talk briefly about the design principles which navigate us through all other pillars as well.

Design principles

All pillars have their own design principles, which will also guide us through this one. They summarize the pillar as follows:

Understand your impact: Measure the impact of your cloud workload to establish key performance indicators (KPIs)
Establish sustainability goals: For each cloud workload, establish long-term sustainability goals.
Maximize utilization: Right-size workloads and implement an efficient design to ensure high utilization and eliminate or minimize idle resources.
Anticipate and adopt new, more efficient hardware and software offerings: Continually monitor and evaluate new, more efficient hardware and software offerings and design for flexibility to rapidly adopt new efficient technologies.
Use managed services: Sharing services across a broad customer base helps maximize resource utilization with managed services, such as AWS Fargate for serverless containers or even multi-tenant EKS clusters. Moving infrequently accessed data to cold storage with Amazon S3 Lifecycle configurations or Amazon EC2 Auto Scaling to adjust capacity to meet demand.
Reduce the downstream impact of your cloud workloads: Test using device farms to understand the expected effects and test with customers to understand the implications of using your services.

Keeping the design principles in the back of your head, the question is now how to improve your workloads? We will talk about this in the next section. And you can find all the material in the official AWS whitepaper focusing on the design principles.

Improvement process

The architectural improvement process includes understanding what you already have and what you can do to improve, selecting targets for improvement, testing and adapting them, and quantifying your success. Afterwards you share what you have learned so that it can be replicated elsewhere, and then you repeat the cycle ♻️

1 Improvements

Identify workloads
Evaluate their potential
Prioritize and plan: identify the low hanging fruits
Test and validate

2 Deploy changes to production
3 Measure results and replicate successes

Conclusion

After talking about our approach at kreuzwerker, the pillar in a nutshell, its principles and the improvement process, we want to emphasize that knowing how efficient your resources are is crucial when optimizing your AWS infrastructure for environmental sustainability. Using the fewest number of resources possible and using them to their fullest will have the lowest impact on the environment. Split in 3 categories it's

Compute efficiency: track metrics like "Total vCPUs hours", and yes they will increase
Storage efficiency includes right-sizing storage volumes, choosing storage tiers depending on data access patterns, and compressing and converting data.
Networking efficiency: reduce the network traveled per request via CDN, edge services, data sizes.

We're happy to perform an AWS Well-Architected Review with you. Contact us directly via our Contact Form or send us an E-Mail.

You want to know more about the AWS Well-Architected Framework, here are the other parts of our series:

Blog