The Well-Architected Framework provides a way for customers to assess their workloads’ exposure to risk, helping to formulate a roadmap of actions and mitigation towards running at best practice.

In this article I will be writing about the advantages of aligning with the framework, including the key types of risk that can be managed using the framework’s opinion as a guide.

A little background

The framework has been around in recognisable form since 2017, but its history goes back to initial kick-off in 2012 which was followed over the next few years by development of features driven by customer feedback.

A review of a workload using the framework offers a way for you to get an idea of your exposure to risk by answering questions that are organised into pillars:

• Security
• Reliability
• Performance Efficiency
• Cost Optimization
• Operational Excellence (added 2016)
• Sustainability (added 2021)

In addition to a standard set of questions, it also provides features called “lenses” that include extra questions in some or all pillars that are specific to particular kinds of workloads, for example:

• SaaS
• Serverless Applications
• Data Analytics
• Financial Services Industry
• plus many more

The answers that are given to the questions in each pillar are analysed, and areas of risk are identified. These are presented as being in one of two categories of risk - High Risk and Medium Risk.

At this point a Milestone may be defined which allows you to say that the answers are current. Once a Milestone exists, the next time that you answer the questions the progress from the previous Milestone is compared and analysis performed on any improvements that have occurred.

This process can be repeated many times through the lifecycle of a workload - charting progress and refining its roadmap.

Key risks and the pillars

The pillars of the framework are designed to cover the main areas of risk that cloud-based systems commonly suffer from. It does this from an AWS reference point, of course, but it’s fair to say that almost every risk area will have some kind of analogy in whatever cloud provider is used.

No matter what stage you are at working with AWS, whether you are in the process of migration or are thinking about migrating to it, or if you’ve operated in it for a while, you may already have concerns around some aspects of your operations. Figuring out exactly what those concerns are and examining them in the context of the framework allows them to be reasoned about. Mitigation and remediation of risk can then be planned.

During this process it is important to determine where your highest priorities lie; where should your focus be? Is there just one thing that is holding you back?

Excellence is unlikely to be achieved without focus, as otherwise effort may be scattered across all the pillars just to get a few more green ticks. You should pick the pillar that matters to you the most.

For example:

• Worried about how big your monthly AWS bill is or might be in the future?

Focusing on the Cost Optimization pillar’s questions would be a good approach.

The Cost Optimization pillar is directly aligned with concerns you may have around your monthly AWS bill, and contains questions that will indicate what steps may be taken to reduce costs until they approach optimal.

• Nervous about what would happen if you were breached? Or maybe you want to add collateral to your messaging about how secure your platform is?

Focusing on the Security pillar’s questions would be a sensible option.

The Security pillar covers various best practices that if implemented correctly would most likely either mitigate the extent to which a network compromise could incur costs to your business and customers, or help to avoid it happening in the first place.

• Got a big launch coming up that you want to be ready for?

I’m sure you’ve got the idea by now - for this one it’s probably worth thinking about the questions in the Reliability pillar.

Project sizing and knowledge

Focusing on a pillar also holds a few different advantages for how a piece of work may be framed:

• Projects can be small enough to be actually delivered on-time.
• The scope of the project is narrow enough that it helps you articulate the kinds of risks you expect to be managed by its delivery.
• It allows you to become aware of the issues surrounding it which may not be obvious from another point of view.

We can help

At The Scale Factory, we can help you get your whole workload well-architected, or review your plan for getting there. Our consulting staff are experienced in running these reviews and in formulating projects using the framework that help our customers be successful.

As an example of how this can be applied, we worked with Thinksurance as they migrated to a microservices architecture ahead of a new product launch and aligned their security story to the standards of the Well-Architected Framework. This has given them tighter monitoring of events via security dashboards and has reduced developer on-boarding time, allowing Thinksurance to build on AWS with confidence. See our case study of this project to see what they say about it.

---

We’ve been an AWS SaaS Services Competency Partner since 2020. If you’re building SaaS on AWS, why not book a free health check to find out what the SaaS SI Partner of the Year can do for you?

---

This blog is written exclusively by The Scale Factory team. We do not accept external contributions.