Part 3 – Introduction to the Six Pillars

Part 3 of our series introduces the six pillars of the AWS Well-Architected Framework.

We’ll continue our layered approach of exploring each part of the framework. We’ll break down each part one by one in this multi-part series to understand them in depth.

Check out parts 1 and 2 of our series here if you haven’t seen them yet. Take some time and read through those now, as this one builds on the topics covered in those earlier articles. 

Make sure you don’t miss out on the latest cloud technology insights by signing up for our newsletter.

At this point, we understand what the AWS Well-Architected Framework is all about now. Essentially the wisdom of millions of cloud practitioner brains collected over a ten-year span. Then bottled up into a framework of guiding principles and best practices.

We also took a look at the general design principles, which are the foundation of the framework itself.

When learning about AWS Well-Architected, I like using the simple building construction analogy to help visualize the AWS Well-Architected pillars. Bear with me, there are a lot of parallels going on here.

The general design principles of the well-architected framework and it’s pillars, serve as our foundation, or solid ground, that we start our cloud workload construction on.

So, what comes next?

Well, the AWS Well-Architected Framework pillars have evolved over the years, and we can safely assume it will continue to do so into the future. In fact, the framework itself seems to live and breathe the same concepts from the general design principles that make up the framework itself.

We’ve looked at how the AWS Well-Architected Framework was built from the feedback of thousands of customers, professional services teams, solutions architects, support teams and so forth. Then taking all this data, analyzing and using it to drive the principles and best practices.

Along those same lines, we could say the framework has also been tested at production scale. Utilizing the huge pool of data coming from the feedback of customers and their internal teams. Teams working with customers in real-world scenarios, learning what works and what doesn’t.

The information the framework was built from is data-driven. There’s no guessing of needs or no guessing of what the principles and best practices should be. This is all battle-tested, data-driven guidance that AWS customers can benefit from.

Just as the general design principles tell us we should allow for evolutionary cloud architectures, the AWS Well-Architected framework itself continues to evolve.

The Well-Architected Framework was started back in 2012. Since then, it was used and refined internally at AWS until it was eventually launched to the public in 2015.

Since becoming a published framework, the framwork has helped thousands of AWS customers build well-architected workloads in the AWS cloud. And with that, has come many refinements to the framework along the way.

Just like our cloud architecture designs need to evolve to changes in technology and new data, the Well-Architected framework and its pillars does the same.

Over the years, AWS has added new major categories of best practices as new “pillars” and new areas of focus for specific workloads through the introduction of “lenses”. AWS also made the framework available as a self-service tool that AWS customers can use within their AWS account to facilitate an easier review of their cloud workloads against the best practices defined within the framework.

So with this brief review and history lesson out of the way, we know we have a solid foundation we can build on. 

What construction concepts are used to help guide customers through the best practices and guiding principles of the framework?

Well, AWS builds on the foundation of the general design principles with the concept of pillars. 

Each pillar has a set of design principles and best practices focused on the specific aspects of its domain scope.

So to recap, we have the foundational general best practices to start with, then as we take a deeper look at our cloud workloads, we can zoom in on these different pillar domain areas that allow us to dive deeper into specific design principles and best practices.

The AWS Well-Architected Framework consists of six pillars.

The 6 Pillars of the AWS Well-Architected Framework

• Operational Excellence
• Security
• Reliability
• Performance Efficiency
• Cost Optimization
• Sustainability

Well-Architected pillars initially started out with the four pillars of Security, Reliability, Performance Efficiency, and Cost Optimization.

Operational Excellence was added back shortly after the public publication of the framework and remained at five pillars until just recently, when AWS introduced a sixth pillar, Sustainability.

In the next few parts of this series, we’ll be looking at each pillar in isolation. This will help us really understand all the design principles and best practices that make up each of these domains.

Remember to sign up for our newsletter so you don’t miss out on the next piece of the Well-Architected puzzle.

Want to learn more about the Well-Architected Pillars?

By incorporating these six pillar areas of the AWS Well-Architected framework into your cloud architectures and design decisions, you can be sure you have the solid foundation and supporting structure to build and operate your AWS cloud workloads.

Using our construction analogy, if we think of these pillars as big concrete structural columns holding up a building, chances are that if we remove one or neglect the maintenance of it over time, we start to introduce a variety of risks or cost impacts to the overall structure.

Depending on the design, weight, and dynamics of the load those pillars carry, removing a pillar or two completely may still keep the overall structure standing. But it’s certainly not as stable as if you had all six pillars equally supporting your cloud workload running in AWS.

Now, these six pillars of the AWS Well-Architected framework are in no particular order.

One isn’t necessarily more important than the others.

It all depends on the nature of the cloud workload you’re building and the context of your business objectives.

When looking at where to start with the different pillars, you may want to just focus on certain pillar areas and ignore others. Or maybe you want to incorporate all six pillars, but you need to prioritize specific pillar domains first that would have the most positive impact on your business in the short-term. Then later, plan on building stronger pillars in the other areas later on to make your overall cloud architecture more stable.

So now you know about the six pillars of the AWS Well-Architected Framework.

The next parts of this series will be taking a look at each of the pillar areas. Starting with Cost Optimization.

Learn more about the AWS Well-Architected Framework here.

How can Autimo help?

We work with customers to go much deeper than the AWS Well-Architected Framework, tightly integrating with your teams to learn about your business, your challenges, and goals.

We understand your business and team dynamics and can help tailor specific action plans that matter the most to you.

Our team can work with your internal groups to take the results of the AWS Well-Architected review, prioritize them and simply engage as a trusted advisor with your team as they work through the design improvement tasks. If more help is needed, Autimo can directly augment your existing team, by providing AWS experts and project management capabilities to help shorten project deliverables.