The AWS Well-Architected Framework lays out a set of principles to help builders make smart trade-offs with their designs. The framework is structured across five pillars;
And while we’d all love to have a solution that takes no effort to operate, is unbreakable, 100% secure, performs perfect, and costs almost nothing…most people know that’s unrealistic.
Best Practices?
On first glance, a lot of teams assume the framework is simply a collection of best practices. To be honest, there is a touch of that. Especially when you look at the AWS Well-Architected Tool and the AWS Well-Architected Labs, but that isn’t the point of the framework.
The goal of the framework is to help you understand the process of making better decisions. It’s designed to help you and your team evaluate the problem at hand, the potential solutions, and setup a process in order to re-evaluate the situation as new information, services, and features become available.
An Example
I recently published an in-depth example of how I apply the framework to Dev.to. In the post, I walk through trying to solve a problem for this very site. Without spoiling the post, my initial idea was wrong—but not for the reasons you would think—and I found the solution in a surprising place.
A place I probably wouldn’t have ended up without applying the principles of the Well-Architected Framework.
How have your experiences been with the framework? Let me know on Twitter where I’m @marknca.
