Understanding the Six AWS Well-Architected Pillars of Successful Architectures

Why should you think about the AWS Well-Architected Pillars? When you start using AWS Cloud, you discover that there is almost always more than one solution to a problem, and sometimes it’s difficult to choose the right way. How do you know what is right in AWS and that you have made the right decision? 

AWS launched the Well-Architected Framework to help cloud architects design and operate securely and efficiently to help teams make better-informed decisions when building applications. Designing and developing systems is similar to constructing a physical building. If the foundation is not solid, it may cause structural problems that undermine the integrity and function of the building. 

Over the past six episodes, we have discussed each of the six pillars. Let’s recap what we have looked at.

Well-architected framework pillars

The first one is operational excellence. It’s the ability to run and monitor systems to deliver business value and continually improve support, processes, and procedures. 

Security: protecting information systems and assets while delivering business value through risk assessments and mitigation strategies.

Reliability: the ability for systems to recover infrastructure or service failures, acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transit network issues.

Performance efficiency: the ability to use compute resources effectively to meet system requirements and maintain efficiency.

Cost optimization: the ability to avoid or eliminate unneeded costs.

Sustainability: guidance and how AWS can help you reduce your footprint and best practices to improve the sustainability of your workloads.

So, there are six substantial pillars. The moment of truth has arrived! Mike, I will ask you first: what is your favourite pillar?

Operational Excellence

I always go back to the first well-architected pillar. It’s the first one in the well-architected reviews: operational excellence. I like this one because I’m a big fan of continuous improvement and getting yourself into a sustainable way of working. How do you learn from failure or react to certain things? How do you have visibility of everything around you? If you can assemble that apparatus and those behaviours, you can eat into the other pillars. For example, operational excellence refers to observing if something’s working or failing in production.

If something’s failing in production, how do you deal with it? Do you have ‘run books’? Do you have playbooks? What does your playbook say about this scenario? It’s fundamental and core. It’s where I start. If I’m going into a new team or area, I’ll always begin with operational excellence. This one is consistent across all squads and all parts of the organisation. That’s probably my favourite because I know and rely on it well.

Mark, what about you? 

Sustainability Pillar

They’re all strong pillars. But my favourite well-architected pillar is the sustainability pillar. If you have all other things in place, the sustainability pillar will drive you to that next level. If you’re trying to deliver a sustainable solution, you can only do that with a good handle on the other five pillars. So sustainability and the sustainability pillars and the questions within them are forcing functions for good practices, processes, and architectural choices that the other pillars are continuing. Our serverless first mindset and approach lends itself well to the sustainability pillar. Also, we want to ensure that we leave the world a better place than what we found. So if we don’t deliver sustainable workloads (especially with the exponential growth of compute devices in the digital era) it will not be good for the long-term health of the planet and the people on earth.

Security, Reliability, and Cost Optimization

I am going to cheat and pick three well-architected pillars! I’m thinking about security, reliability, and cost optimization. The reason why I like those three is because they’re things that a different team does. If a team thinks they’re excellent but completes one of those pillars, they realise there’s a bunch of stuff they’ve never thought about but is their responsibility. The most thought-provoking one is cost optimization. Most teams need to think about the cost. But they believe that there’s an IT manager somewhere who does it. It’s magic, and it happens in the background. But it spins their head when you ask how teams monitor or control their cost and optimise for cost.  I like the shock factor and that it’s about real money. If you make a tweak, you can save your organisation money. It’s green dollars and not pretend money. So, I always enjoy it when teams are connected back to reality. That’s interesting.

With carbon score tools coming online, that conversation can happen: what’s your carbon score? Do you know what your sustainability for print is? I’m also looking forward to that for the same reasons.  It will allow us to ask better questions of teams.

Your architecture is your cloud bill.

As you say, Mark, your architecture is your cloud bill. That is a great question. When a team tells you about a fantastic thing that they’ve built, and you ask what it cost, it levels everything. 

AWS will often do an audit, which is a good service. But they also talk about the self-service option. We’ve used it several times. It’s like a self-help tool for teams. Let the teams use the well-architected pillars as good practice to see where they want to improve. AWS designed it for you to use as a support function for the teams and not a judgement on the organisation. 

It’s a safe space. It’s very conversational and helps you to set goals and connect teams. Some teams do certain things well, and others aspire to do that. So it’s fantastic.

Whole team exercise

We’ve written a couple of articles about this on TheServerlessEdge.com. It needs to be a whole team exercise and a collaborative facilitated exercise. It’s not a ‘one and done’. It needs to be done regularly and over time. You must not use the Well-Architected Framework to judge teams or beat teams. You must use it to provide them with better information and questions to ask and then empower them to improve.

People ask about what’s compliant. What’s the mark that you need to pass well architected? One team’s good security might be another team’s bad! Because it depends on the workload and what the requirement is. So it’s different from what’s good enough. It’s the fact of how confident you feel you meet your requirements. Every workload has unique requirements. That’s the way you need to think of it. You can’t judge a team. You can ask: ‘Are you happy that you’ve done what you needed to do?’. And the framework helps you to do that.

Is your solution well-architected? 

There’s a great question that you use a lot, Dave: ‘Is your solution well architected?’ Listening to what a team has to say in response gives you a good idea of where they’re at on their journey.

Let’s end with the famous saying: ‘Are you well-architected? It’s like when the doctor asks if you eat your ‘five a day’. You can say no, and you’re being honest. You can say yes, but you eat fruit pastilles instead of fruit, so you’re lying to your doctor!  Or you can say yes, and you’re informed and educated. We know ‘five a day’ means five portions of fruit and veg. So if you lie to your doctor, it’s only you that you’re kidding. It’s the same as well architected. If you ask a team of architects, they can say no, we have work to do, or yes, we are. Or the fun starts when they try to pull the wool over your eyes. That’s when it gets interesting. 

There’s no point in being defensive. It’s a safe space. It’s your workload!