This article is a machine translation of the contents of the following URL, which I wrote in Japanese:
https://qiita.com/Nana_777/items/66bc480b6de16a71d64c
Introduction
I gave a presentation on a similar topic at the JAWS event
[Presentation event]
Ops-JAWS Meetup 35 IaC CDK Branch Collaboration Project July 8, 2025 (Tuesday)
https://opsjaws.connpass.com/event/356387/
[Presentation materials]
https://speakerdeck.com/naonana777/wafrnoxin-chang-shi-iackodokararebiyuwoxiao-lu-hua
What is Well-Architected Framework Review (WAFR)?
6 Pillars
Well-Architected Framework Review (WAFR, also referred to as W-A Review in this article) is a consistent approach to achieving scalable design by conducting reviews based on perspectives described as six pillars.
The six pillars are "operational excellence," "security," "reliability," "performance efficiency," "cost optimization," and "sustainability."
[URL of AWS's AWS Well-Architected page]
Questions and check items for each pillar
The W-A review has six pillars, each of which has several questions and check items. There are 57 questions in total for the six pillars. Each question has about 5 check items, so there are about 300 check items in total for all pillars.
It is not necessary to perform all checks or meet all best practices
There are many check items, but it is not necessary to perform all of them. If the architecture places particular importance on security, you can review the check items in the security pillar, and prioritize the other pillars to decide the order of implementation and whether or not they are implemented.
In addition, it is not necessary to meet the best practices for all check items.
For example, if you use a redundant configuration because you place importance on reliability, it may be excessive from the perspective of cost optimization.
For details on the check items, see the AWS documentation
If you look at the checklist alone, the check items are written in very concise terms, but if you want to know more about the check items, you can check the AWS documentation.
When you check the AWS documentation, you will find detailed descriptions of each checklist, such as "expected results," "common anti-patterns," and "implementation guidance."
By reading these descriptions, you can learn why this check is necessary, what risks arise if the check is not applied, and what measures can be taken to avoid the risks.
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/appendix.html
W-A reviews are managed in units of workloads
You can manage the results of W-A reviews by using a service called AWS Well-Architected Tool.
You can display the W-A review checklist and check it, and if the questions do not apply to the architecture being reviewed, you can write down the reason and save it.
The review unit is managed in units of "workloads," and you can check what risks are occurring in each workload.
The workload unit can be determined in any unit, and you can set the workload according to the scope of the review you need, such as a workload for an architecture you are planning or a part of the system's functions.
Issues in implementing WAFR
Understanding the contents of W-A
If you understand the contents of the W-A review in advance, I don't think it will take that much time to do a W-A review.
The W-A review check items will be naturally included and discussed during meetings with customers to define requirements, and during design discussions and reviews within the team, and issues will be resolved.
Even when conducting repeated reviews, discussions will be smoother if you understand the contents of the W-A review.
Not understanding the contents of W-A
There are approximately 300 check items in the W-A review, and each one has its significance, anti-patterns, and implementation guidance, so it is not easy to understand them all.
If you conduct a W-A review without understanding the contents of the W-A review at all, you will need to read the architecture to be reviewed, the W-A review questions and check items, and the AWS documents that contain the details of the check items as many times as there are check items, which will take a huge amount of time.
Automation of Well-Architected Framework Review (WAFR) and the Well-Architected Partner Program
More options for "automation"
W-A reviews can take a lot of time in some cases, but they can also be automated.
There has been automation for a while, where AWS TrustedAdvisor and AWS Well-ArchitectedTool are linked to use the results of TrustedAdvisor as the basis for judging check items, but recently, with the technology of generative AI, it has become possible to have generative AI conduct reviews.
As a result, organizations that have had difficulty in conducting W-A reviews due to the time it takes can now conduct them more easily and efficiently through automation.
"Automation" is now part of the "maintenance requirements" of the Well-Architected Partner Program
The Well-Architected Partner Program is a program for partner companies that actively use Well-Architected best practices to build architectures.
By clearing several maintenance requirements each year, you can continue to participate in the partner program, but a new maintenance requirement has been added that you must be working on automating W-A reviews from 2025.
It does not mean that all reviews will be automated, but it will be a report on how you are working on automation.
For this reason, it can be said that it is essential for organizations involved in W-A reviews to have the know-how to automate reviews.
WAFR Acceleration with GenAI (Power)
※It seems that it is common to not add the last "Power".
The configuration is such that AmazonBedrock, which has learned the WAFR documents, reviews the design materials uploaded by the user.
AmazonTextract is used to extract the data to be reviewed from the design documents, and AWS StepFunctions is used to review each pillar.
The CDK code is available on GitHub, so you can install it in your AWS account.
[GitHub]
https://github.com/aws-samples/sample-well-architected-acceleration-with-generative-ai
AWS Well-Architected IaC Analyzer
Abbreviation: IaC Analyzer
The IaC Analyzer performs W-A reviews using AmazonBedrock, just like WAFR Acceleration with GenAI, but the main review targets are IaC code such as CloudFormation templates and CDK code.
The CloudFormation template is also available on GitHub, and can be deployed to your AWS account.
[GitHub]
https://github.com/aws-samples/well-architected-iac-analyzer
AWS Well-Architected IaC Analyzer results
Applied
If applied, the question reviewed, its check items, and the "reason" for determining that it was applied will be listed.
Not relevant
The W-A review also describes actions that people should take outside the system, and checks related to this do not appear in the IaC code, so the result is "not relevant."
Not applicable
If the IaC code is not suitable for the content of the check item, the check item will be judged as "not applicable."
For unapplied items, in addition to the reviewed questions, check items, and reasons, "recommendations" are listed.
Recommendations include hints on how to "apply" the corresponding check items.
Chat with the AI to deepen your understanding
Clicking the sparkly mark in the recommendations column or the Well Architected mark in the bottom right of the screen will open a chat dialog with the AI.
By using this chat with the AI, you can deepen your understanding of Well Architected by having them suggest specific IaC code for measures to be taken for unapplied items.
Chat conversations start in English, but if you request a response in Japanese, the rest of the conversation will be in Japanese.
AWS Well-Architected IaC Analyzer Operational Issues (Personal View)
It is difficult to determine the improvements that are essentially necessary.
We checked the reason for the check items that were judged to be "applied" and verified whether adding a change to the IaC code that would eliminate that reason would result in the check items being judged as "not applied."
The change made to the IaC code was to remove the setting for CloudFront HTTPS enforcement. This should result in the check items related to compliance being judged as "not applied."
The result was "not applied," but the "reason" for the judgment and the "recommendations" for applying the changes were more general recommendations, such as using Config, rather than pinpointing the CloudFront HTTPS enforcement that we changed this time.
"Applied" means "applied" with pinpoint content, but "not applied" means pinpoint fixes cannot be identified?
If it is a critical issue, fixing the pinpoint problem must be prioritized. At the same time, this does not mean that general best practice recommendations can be ignored.
It is important to make general recommendations, but they may result in more work than necessary and increased costs. Or they may overlook the unique issues that the architecture has. For this reason, it is dangerous to rely on general recommendations.
It seems necessary to find an answer to what kind of improvements are essentially correct for the architecture to be reviewed, not only by relying on the results of the IaC analyzer, but also by considering them in conjunction with human experience and knowledge.
The granularity of the required review may not match the granularity of the IaC code
The review granularity of the IaC analyzer is the uploaded IaC code range
As the name suggests, the IaC analyzer reviews based on the IaC code. Therefore, the scope of the review is the scope of the IaC code (the stack in CloudFormation).
The scope that people want to review depends on the time and situation
The scope of a person's review of an architecture varies depending on the time and situation. Sometimes you want to review the entire architecture, and sometimes you want to review a collection of functions within a certain range of the architecture. You may also want to review each renovation project, or you may want to review within the scope of the team's responsibility.
If the IaC code is not divided into the range that a person wants to review, the review results may be judged as "applied" or "not applied" based on the content of the IaC code that is not in the range that you want to review, and irrelevant recommendations may be proposed.
Should I adjust the IaC code to the range that I want to review, or should I operate it by making good use of the results of the IaC code?
If the IaC code could be divided into the range that I want to review, I could review it to the necessary range, but the range that I want to review changes from time to time, so I think it would be difficult to actually change the division of the IaC code to the range that I want to review.
Therefore, it is necessary to check whether the IaC code description that was the basis for the judgment is within the desired review range from the "reason" of the IaC analyzer result, and if it is outside the range, check whether the similar content in the reason is within the review range, and if it is not within the range, consider operating by performing a W-A review by a human.
Conclusion
I thought that automating reviews using generative AI such as the IaC analyzer is very effective in making reviews more efficient. Since it uses generative AI, I think the accuracy will vary depending on the model, but I think that further accuracy and efficiency can be expected as generative AI evolves in the future.
In addition, because the review is conducted using IaC code, there are concerns about the review results due to differences in the scope to be reviewed and the granularity of the IaC code. There is also a concern that the review will not include architectural or project constraints or characteristics that do not appear in the IaC code, resulting in a lack of information to make judgments.
Let's devise ways to perform better reviews by considering the scope to be left to the generation AI and the scope that humans understand.
Bonus
I received some questions about the IaC analyzer settings when I gave my presentation, so I'll post the information here
[GitHub for IaC Analyzer *Notes on generated AI models, etc. are also included]
https://github.com/aws-samples/well-architected-iac-analyzer
Generated AI model is optional (Claude Sonnet 3.5, 3.7) Recommended
The generated AI model can be entered as a parameter when running the CloudFormation template. Since it is a free input format, you can set it as long as it is the ID of a generated AI model that has been enabled in advance, but the description on GitHub recommends using Claude 3.5 Sonnet and Claude 3.7 Sonnet.
Pay attention to security measures
If you run the IaC analyzer with only the default settings when the CloudFormation template is executed, anyone can access the IaC analyzer system web page if they know the URL.
This is fine if you just want to try it out temporarily, but you need to consider the risk of being accessed from unexpected places or being charged a high usage fee due to unauthorized use.
As stated on GitHub, consider enabling authentication such as Cognito for actual operation (there is an optional parameter setting authentication setting when the CloudFormation template is executed)
*The slide captures in this article are quoted from my own presentation slides
[Presentation materials]
https://speakerdeck.com/naonana777/wafrnoxin-chang-shi-iackodokararebiyuwoxiao-lu-hua
Top comments (0)