AWS Well-Architected Framework: Understanding the Six Pillars of Successful Architectures

In this article, you’ll learn:

• What is the AWS Well-Architected framework?
• AWS Well-Architected pillars and best practices
• AWS Well-Architected tool

When customers start with AWS Cloud they will soon discover that there is almost always more than one solution to a problem and sometimes it’s difficult to choose the right way. How can one know what is right in AWS and that they have made the right decision? This is why AWS launched the AWS Well-Architected framework to help cloud architects design, operate securely, and efficiently, and help teams make better-informed decisions when building applications.

The Well-Architected framework is built on six pillars which amplify your team's abilities by understanding how to make trade-offs between these pillars.

In this article, you will read about the AWS Well-Architected framework and we're going to dive deeper into each of the Well-Architected pillars.

What is AWS's Well-Architected framework?

AWS Well-Architected framework outlines the best architectural practices for developing and managing AWS Cloud systems that are dependable, secure, efficient, and cost-effective. The framework consists of a series of questions used to evaluate a current or planned architecture. Each pillar also includes a collection of AWS principles. In this blog post, we’ll look into every pillar and its principle.

A short history of a Well-Architected framework.

Optimize your AWS infrastructure with confidence! At Stormit, we offer AWS Well-Architected Reviews conducted by our certified experts. Ensure your cloud environment is efficient, reliable, and cost-effective.

Why AWS Well-Architected Framework?

AWS Well-Architected framework helps you:

• Deploy and build your application faster.
• Lower or even mitigate the risk.
• Make educated and informed decisions about your infrastructure.
• Build your infrastructure with the best practices of AWS.

By using the Well-Architected framework in your designs, you can create more dependable and functional systems that allow you to focus on critical needs. Using Well-Architected’s framework leads to more scalable and responsive applications thanks to developers using its best practices.

AWS have some general design principles that describe how you should design your workload in AWS:

• Don't estimate your capacity needs by guessing.
• Test systems at the scale you’ll need in production.
• It’s easier to accomplish testing processes with automation.
• Create a flexible architecture.
• Create live tests to improve infrastructure with simulations.
• Leverage AWS-managed services where possible.

AWS Well-Architected pillars and best practices

The pillars of the AWS Well-Architected framework help us organize the different decisions you're going to make when you're building our solution on AWS. All these pillars work together to give us the best possible solution to the problem at hand.

We have operational excellence, security, cost optimization, reliability, performance efficiency, and a kind of new pillar of sustainability.

Each of these has a specific set of principles and questions that you can ask to understand the impact of this area on the solution that you're building.

Operational excellence

This is a key area to ask yourself: Is my architecture valid? Will it continue to work? We assume that it will continue to operate as intended. However, anyone who has operated a cloud infrastructure for more than a second understands that unexpected problems pop up that need to be dealt with. This is where Operation Excellence comes into play.

This AWS Well-Architected pillar incorporates the idea that everything you create or change in AWS should be coded. This is because you must understand how to script any actions performed via the AWS Management Console. Automation provides consistent results.

Also, you want to always make small changes, because it's easier to undo small changes than try to save everything and do it every week.

Design principles:

• Perform operations as code.
• Make frequent, small, reversible changes.
• Refine operations procedures frequently.
• Anticipate failures.
• Learn from all operational failures.

Example in AWS

Performing patching by the AWS Systems Manager

This is a simple example of automation leveraging AWS Systems Manager that can be used for a variety of things. For example, you can select a resource group (EC2 instances) and view its recent activity, resource configuration changes, related notifications, software inventory, and patch compliance status.

Automate CI/CD pipeline by using AWS-managed services

Another example of automation is using AWS services for CI/CD pipelines, AWS Code Pipeline for management of the whole process, and AWS CodeCommit, AWS CodeBuild and AWS CodeDeploy for every step of this process.

Security

Security is an ongoing effort and even when a security incident occurs, it should be viewed as an opportunity to improve the security of your architecture.

Least privilege is something that you should implement from the start into your infrastructure. Every identity, account, user or role should only have the privilege to do what it needs to and be blocked from doing anything else.

The use of encryption to manage well-classified data provides comprehensive protection that every organization should implement.

Design principles:

• Implement a strong identity foundation.
• Implement traceability.
• Automate security best practices.
• Protect data in transit and at rest.
• Keep people away from data.
• Prepare for security events.

AWS example

AWS account management

Every account and user should only have the privileges that they need. AWS offers a free service called AWS Organizations which is for those who will use more than one account.

Traceability in AWS

AWS offers multiple services that help you trace what was done in your environment by every account and user. For example, AWS CloudTrail can trace every change done by API in AWS Console.

But more AWS services can help you secure your environment. We have blog posts that are focused on AWS Security Hub, Amazon GuardDuty, and Amazon Inspector.

Cost optimization

Next up is cost optimization. You only want to spend what you have to. You also want to be measuring constantly, for instance, right-sizing is a great way to cost optimize almost every compute service on AWS. But every decision should be backed by data.

AWS customers are sometimes afraid of using managed AWS services, because they tend to cost more at the start. However, they have a lower overall cost, even if your actual out-of-pocket costs would be a little bit higher. Because you're letting someone else do the work, you can focus on other things, and for example, have time to optimize something which costs you thousands of dollars on your AWS bill, just because you did not have time to make the right decision.

Design principles:

• Practice cloud financial management (CFM).
• Adopt a consumption model.
• Measure overall efficiency.
• Stop spending money on undifferentiated
  heavy lifting and use managed services where possible.
• Analyze expenditure.

Examples in AWS

Investment vs cost

Analyze the efficiency of your investment in the AWS Cloud. If your cost goes higher, this isn’t always a bad thing. For example, if you use serverless architectures it can mean that there are more customers in your eCommerce app and they are buying more stuff from you. So you’ll spend more on the AWS architecture, but you’ll also get more orders. Essentially, you need to basically analyze the costs vs what you get from it.

Leverage AWS-managed services or serverless

AWS handles the heavy lifting of data center operations, such as stacking and powering servers. This can be leveraged by Amazon EC2.

But, you should also use managed services or serverless to remove the operational burden of managing operating systems and applications. For a little cost, this allows you to focus on customers and business projects, not IT infrastructure.

Reliability

This pillar is focused on asking questions such as will this system work consistently, and if something did happen, will it recover quickly?

To recover quickly, it's got to be automated. Scaling systems in AWS is also a great way to achieve availability, but it has to be horizontal scaling. So instead of getting bigger instances with more capacity, you want to get more instances involved because if something happens to one of those systems, you've got a bunch more to rely on.

You can read about the difference between vertical and horizontal scaling here: Scalability in Cloud Computing: Horizontal vs. Vertical Scaling

Design principles:

• Automatically recover from failure.
• Test recovery procedures.
• Scale horizontally to increase aggregate workload availability.
• Stop guessing capacity.
• Manage change in automation.

AWS examples

Scale horizontally where possible

Many applications don’t support horizontal scaling, but if it is possible it’s best practice to use horizontal scaling because it will bring you higher availability and reliability.

Leverage multi-AZ deployments

A majority of AWS services offer the possibility to use more than one availability zone for their deployments. Some of them do this automatically (DynamoDB, S3, Aurora) and some need your intervention (EC2, RDS).

Performance efficiency

Performance efficiency is focused on that you want to remove bottlenecks and waste.

You want to understand the dynamics of AWS Regions and the AWS Edge network to reduce latency to get better performance to your users or better-perceived performance in general.

Serverless is almost always going to be the right way to go. Even if some of the specific cases perform a little less well, the overall efficiency is so much better because of the event-driven architectures.

You also want to experiment with new services as they're released. A lot of the time you're going to see that as new services are released, they also address very specific issues, especially the managed services around performance, as well as the other pillars.

Design principles:

• Democratize advanced technologies.
• Go global in minutes.
• Use serverless architectures.
• Experiment more often.
• Consider mechanical sympathy.

Sustainability

When building cloud workloads, the sustainability practice is to understand the impact of the services used, quantify the impact throughout the workload lifecycle, and apply design principles and best practices to reduce this impact.

Set long-term sustainability goals for each cloud workload, such as reducing the computing and storage resources required for each transaction. Right-size workloads and implement efficient designs to ensure high utilization and maximize the energy efficiency of the underlying hardware. Two hosts running at 30% utilization are less efficient than one running at 60% utilization due to the base power consumption of each host, all while eliminating or minimizing idle resources, processing, and storage, to reduce the overall power required by your workloads.

Design principles:

• Understand your impact.
• Establish sustainability goals.
• Maximize utilization.
• Anticipate and adopt new, more efficient hardware and software offerings.
• Use managed services.
• Reduce the downstream impact of your cloud workloads.

Example in AWS

Adopt new, more efficient offerings and services

Every year, AWS presents new services and changes that can bring some savings, but, understandably, AWS customers don’t tend to always know about these new features. This is where AWS partners like StormIT can help and bring value through their knowledge about new AWS offerings and services.

Use managed services

Sharing services across a large customer base helps maximize resource utilization which reduces the number of resources needed.

For example, AWS Fargate provides a serverless approach to containerized services, which AWS operates on a large scale. This minimizes the impact on their consumption. You can also leverage lifecycle configurations in Amazon S3 to periodically move data to different storage classes that are again based on the usage and can lead to lower consumption in their data centers. Amazon EC2 Auto Scaling automatically expands computing capacity to your demand.

AWS Well-Architected tool

AWS Well-Architected Tool is a service that helps measure AWS architectures against best practices from years of collected solutions from architects and successful companies. This tool measures how you conform to these standards by using data from AWS architects and cloud service providers.

It includes guides for creating secure, cost-effective, reliable and more efficient workflows. It also enables users to document their design choices and work methods.

StormIT’s AWS architects will provide you with recommendations and guidance for designing and deploying high-availability architectures on AWS.

Conclusion

In this article, we’ve described some basics of the AWS Well-Architected framework and you should now understand on a higher level what pillars are in the Well-Architected framework and how they help you to implement best practices in your AWS infrastructure.