AWS Well-Architected Framework: From Myth to Reality (part 2)
In my previous article, I briefly explained the AWS Well-Architected Framework (WAF), a quick guide to approaching it, and its outcomes. Today, I want to delve into an analogy and review examples of how to apply the WAF to a workload.
The words “Construction and Architecture” apply to different fields of knowledge. However, we will discuss them in the context of building construction and architecture. These fields certainly vary from the IT industry in practices and decision-making regarding technology solutions, and they have significantly different impacts. Unlike in construction, software generally does not involve a structural failure that could be as critical, luckily not.
It is particularly common to see how Proof of Concepts (PoCs) or pilot projects often evolve into productive solutions with varying scopes and changes. The individuals who designed the pilot design are typically not the same ones responsible for the production architecture, with almost no documentation, as shown in the next image:
This is why sometimes we encounter particular and innovative architectures, which are risky and likely beyond the standards:
Every construction must have a SOLID GROUND, with topographical and ground tests, among many other studies. Without these grounds, the construction could be riskier, and it is essential to consider all the base conditions for the success of both functional and non-functional requirements.
The AWS WAF is a framework that, in a certain way, does not address this groundwork. In practice, the AWS WAF on each question addresses points from the basics to the advanced aspects of each practice, so it is possible for reviews not to reach completion or lose their direction due to the lack of a well-established foundation or due to the inherent depth of the framework.
Taking from the “Mastering the AWS Well-Architected Framework” course by Mark Nunnikhoven on Cloud Guru. Mark defines these aspects that may seem simple but are often not considered during a WAF review:
Taking up the construction example, we have the following SOLID GROUND:
One last thing I would like to highlight due to its great importance in the definition of software architectures: TIME management. It is often the cause of poor decisions driven by the need to meet delivery deadlines.
Back to Our IT Reality
For didactic purposes in this article, solutions and architectures typically have scalability requirements, multiple application and data layers with high-security demands. For such scenarios, we will address the following SOLID GROUND:
If we read the statements in bold, we can infer that this client prioritizes platform security and reliability. Therefore, we will start the evaluation of these two pillars: Security and Reliability.
I have selected three questions from these pillars as examples and key points to consider for the review:
Security:
Security Pillar
- SEC08-BP01: As data protection is a priority, start to decide on the encryption storage of the key material, access policies, and auditing.
- SEC08-BP02: Validate encryption features based on the architecture components. How can I ensure that storage services have data encryption by default.
- SEC08-BP03: Implement the principle of least privilege for each role based on its responsibility.
Now Let’s Continue with Reliability
Reliability plays a crucial role in today’s context. The capacity to recover from failure is a high-priority feature in many architectural designs, enabling them to adapt dynamically to demands and thereby reducing the risk of a solution encountering any disruptions. Similar to the Security pillar, in the next image, we will address three questions related to this aspect to illustrate the concept:
Reliability:
Reliability Pillar
- REL01-BP01: The design of your architecture can be radically affected by service quotas and their soft and hard limits.
- REL05-BP03: Protecting concurrency is not only done with firewalls, networks, or other methods but it can also be protected at the code level.
- REL013-BP01: Defining service availability and acceptable loss of data with an associated RTO and RPO is vital for business continuity:
- RTO (Recovery Time Objective): Maximum acceptable downtime for a system or service after a disruption occurs.
- RPO (Recovery Point Objective): Maximum amount of data loss that an organization is willing to tolerate in the event of a disaster.
- DR (Disaster Recovery): Ensures business continuity by outlining the steps and processes needed to restore critical systems, applications, and data in the event of a catastrophe.
Keep in mind these tips:
Summary
In conclusion, this framework is a great ally to address and understand best practices when designing IT architectures, even by considering just three questions from two pillars, and there are around 60 questions in total. With these, you can enrich your architectures and learn and mature your solutions.
The framework serves as a guide for making architectural decisions. It is essential to understand that there is no one-size-fits-all solution. By following the framework, we can mitigate the risk of errors and make informed choices. Embracing a process of making incremental decisions backed by data-driven insights can lead to more successful outcomes in our architectural endeavors.
