How AWS Well-Architected can improve your AWS cloud architecture

When talking about Amazon Web Services (AWS), most people associate it with Amazon’s online shopping platform. However, if you’re familiar with the “Web Services” aspect, this blog will interest you. Over the summer, I had the opportunity to participate in a training course regarding the Well Architected Partner Program. In this post, I will talk about AWS Well-Architected, a framework available to all AWS customers and which was the main subject of these trainings. It offers an approach to improve your architecture by using key concepts, design principles and architectural best practices in the cloud.

AWS Well-Architected consists of six pillars, which form the foundation of designing a robust, scalable, cost optimized and reliable architecture. By addressing questions for each of these pillars you can evaluate how well your architecture and strategy aligns with the best practices. Moreover, each pillar provides specific recommendations to consider while evaluating your cloud architecture.

When assessing your architecture in AWS using the Well Architected framework, there are a few things to keep in mind. The questions in each pillar can help you with identifying flaws in your architecture. However, their effectiveness relies on your candid responses. While these questions can guide improvements, engaging an external expert can offer a fresh perspective. They often have different insights than internal employees who work with your applications on a daily basis. These experts bring together the views and insights of every responsible person surrounding your architecture and identify potential enhancements.

This blog will briefly introduce each pillar and suggest initial steps to refine your architecture. Furthermore, I’ll share my insights regarding each pillar and the significance of each pillar in the cloud.

Operational Excellence Pillar

The primary objective of operational excellence lies in swiftly and consistently delivering new features and addressing software bugs, ensuring that customer needs are met. Companies that prioritize operational excellence not only ensure customer satisfaction but also effectively manage the introduction of new features, adjust to changes, and manage unforeseen failures. As part of this journey, operational excellence fosters the implementation of continuous integration and continuous delivery (CI/CD) practices, empowering developers to consistently produce high-quality outcomes.

The operational excellence pillar is very important when it comes to regular enhancements to your architecture. By making frequent and small but reversible modifications, you prevent long downtimes in case of failures due to mistakes. Furthermore, by adopting operations as code, you can automate the deployment and recovery of your services. Both are examples of recommendations in the Operational Excellence pillar and will reduce and mitigate the consequences of downtimes.

Security Pillar

The foremost thing to understand about the security pillar is that it is a shared responsibility between AWS and the customer. This shared model defines the border between the responsibilities of AWS and the responsibilities of the customer regarding security. For example, AWS is responsible for the security “of” the cloud, like physical machines. On the other hand, the customer is responsible for the security “in” the cloud, managing elements such as users operating systems and firewalls. The exact distribution of these responsibilities can vary based on the specific service in use. Some services will be more expensive to operate but come with less responsibilities for the customer.

From the customer’s perspective, AWS offers design principles that can help you with strengthening your cloud security. One of these is the principle of least privilege. By implementing this principle, identities are granted permissions only for specific actions on designated resources under defined conditions.  By using groups, you can provide access for a team of developers to manage resources within their project. Consequently, whenever a developer departs from the project, their access is automatically revoked.

Other fundamental design principles are protecting data in transit and at rest, maintaining traceability and implementing security across all layers.

Reliability Pillar

The Reliability Pillar is probably the most intuitive pillar of the six. It incorporates design principles that not only aid in recovery from failures, but also ensure workloads function as expected.

Much like security, the reliability of your AWS environment is a shared responsibility. AWS is responsible for the resilience “of” the cloud while the customer is responsible for the resilience “in” the cloud. This means that the products of AWS will have a reliability that meets the AWS Service Level Agreement. The customer, on the other hand, should select the appropriate configurations for AWS services and the applications installed on those services.

The primary focus of this pillar is to guarantee that your applications in the cloud have a certain percentage of uptime and to facilitate swift recovery post-failure.

Performance Efficience Pillar

The Performance Efficiency pillar emphasizes maximizing the efficacy of resources within the cloud. Collecting data and adjusting the architecture based on the collected data is one of the principles that is used in this pillar. Testing your infrastructure is also one way of collecting data before putting it into production. This can be done by load generation to simulate one or several user journeys on your applications.

Other principles that work together well are infrastructure as code and deployment pipelines. With AWS CloudFormation you can create templates for infrastructure that your pipelines can leverage to deploy new setups. Even applications and services can be initiated through the use of these templates and pipelines. This approach not only streamlines replication of your applications to alternative resources but also facilitates management by tweaking the templates.

Cost Optimization Pillar

The cost optimization pillar is quite straightforward. Its main focus is designing a cloud architecture that meets business objectives while minimizing the costs. One of the design principles under this pillar is embracing a consumption model. If you anticipate using a specific amount of EC2 instances over an extended period, your costs will be reduced if you commit to these instances for one or three years. During peak demands, you can switch on a few on-demand instances and scale back once demand subsides.

AWS also provides a suite of tools to check and restrict your spending by giving the option to set a limit on resources. By integrating Amazon CloudWatch and Amazon Billing, it’s feasible to generate visualizations that detail your infrastructure’s expenses. With Amazon Budgets, you can put limits on the costs for certain services and receive alerts when you are approaching the threshold.

When designing your architecture, you will encounter specific situations where you must invest more into your cloud to achieve desired outcomes. While managed resources might have a higher upfront cost, they simplify management, potentially reducing long-term expenses.

Sustainability Pillar

The sustainability pillar is the latest addition to the six pillars and represents a shared responsibility between AWS and its customers. This pillar does have some design principles, but I would describe them as considerations rather than mandatory modifications to your cloud environment. By just transitioning your Infrastructure to the cloud you enhance the sustainability of your applications. Most AWS services allocate resources based on customer requirements, avoiding the typical overhead seen in on-premises data centers.

Other principles of this pillar include maximizing the utilization of your hired services and minimizing the workload consumed for one transaction in your application. By applying both to your architecture you foster an efficient and sustainable cloud environment.

Closing

As you’ve probably identified, considering all the pillars allows the pieces of the architectural puzzle to align seamlessly. The pillars aren’t isolated segments of your architecture that you should look at, but interconnected aspects. One pillar might be less important for your architecture while others are essential for a well working application, but improving even one pillar will strengthen your overall architecture.

If you want to know more about AWS Well-Architected, the resources regarding this topic are freely available to everyone. Even if you are not using AWS to host your cloud application, most of the pillars will still be relevant for designing your cloud architecture and even to general application design.

Sources

Six Pillars of the AWS Well-Architected Framework: The Impact of its Usage When Building SaaS Application

https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/shared-responsibility-model-for-resiliency.html

https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/

Sander Van den Bogaert

I am Sander Van den Bogaert, and I have a background in applied information technologies. After spending a year abroad to finish my studies, I started at Aivix to work with AWS technologies and AI (Artificial Intelligence). I got the opportunity to study for two AWS certificates during my one year working experience at Aivix. This was a wonderful experience and I look forward to learning more about AWS technologies.