Transcript for AWS Well-Architected-

Module2-WAFR

1.1 AWS Well-Architected

Welcome to module two of AWS Well-Architected: How to Run a

Well-Architected Framework Review.

1.2 Learning objectives

In this module, you will learn how to complete a Well-Architected Framework Review,
understand the impacts of design decisions about your architecture, and evaluate risks
in your architecture and how to mitigate them.

1.3 What Is the Well-Architected Framework Review?

The Well-Architected Framework Review is a continuous improvement mechanism

that helps customers consistently evaluate their workloads against Amazon Web
Services, or AWS, best practices. They can identify recommended remediations to
address high-risk and medium-risk issues. The purpose of reviewing an architecture is
to help identify any critical issues that might need to be addressed or areas that could
be improved. The outcome of the review is a set of actions designed to improve the
workload’s architecture based on the six pillars of the framework.

1.4 A mechanism for continuous improvement

To achieve the desired goal from a framework review, it’s important to consider it as a
step in a continuous improvement plan that integrates with your workload lifecycle.
This mechanism has three steps: learn, measure, and improve.

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
First, start with learning the strategies and best practices for
architecting in the cloud.

Next, you can measure your architecture using the framework;

Well-Architected lenses, such as the data analytics lens; and your
organization’s best practices with the custom lenses in the AWS
Well-Architected Tool, or AWS WA Tool.

Finally, you can use the outcome to improve your cloud

architecture by addressing any high-risk issues. You can identify
issues using improvement plans, Well-Architected Labs, the AWS
Partner Network (APN), AWS solutions architecture teams, and more. You have to
apply this three-step mechanism on every workload in your organization. A workload
identifies a set of components that together deliver business value. You will learn
more about workload details in a later module.

1.5 Intent of a review

The purpose of reviewing an architecture is to identify any critical issues that might
need to be addressed or areas that could be improved. The outcome of the review is a
set of actions that should improve the experience of using the workload. To achieve
that goal, the review of architecture needs to be done consistently and with a blame-
free approach that encourages the team to dive deep. It should be a lightweight
process that is completed in hours, not days. This is a conversation, not an audit.

Team members who build an architecture using this framework should continually
review their architecture, rather than hold a formal review meeting. A continuous
approach helps your team members update answers as the architecture evolves,
improving the architecture as you deliver features.

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
1.6 Learnings

What have we learned from doing reviews? Review early in the

lifecycle when it is faster to fix things and can influence design.
The most common issue is not making bad decisions but when
decisions are neglected. Team members don’t decide to not back
up data; they just forget to talk about it. Most workloads have
high-risk items that need to be addressed. Finding them is not a
bad thing; they were always there. If you address them, it
becomes one less thing that can damage or slow your business.

1.7 Use cases

Now, you will learn about some of the most common use cases. The first use case is
learning best practices for the cloud. This applies to the majority of customers and
their teams who want to learn how to architect for the cloud. By learning AWS best
practices, companies can identify risks and improvement opportunity for their
architecture. Technology governance is another consideration. Before launching into
production, you want to know that you and your workload are ready. With lots of
teams, it can be hard to know if they are all doing the right things. With any launch
process or review, how can consistency be achieved? How are problems prioritized
over time?

The AWS WA Tool provides a consistent process for measuring your architecture using
AWS best practices. For portfolio management, most organizations are dependent on
their technology portfolio to operate. Organizations often don't have a central registry
of what is in that portfolio and what the risks are. This means that it can be difficult to
make informed decisions about where to invest. Those organizations that do have a
review process probably don’t have a consistent, comprehensive one, and the results
are not discoverable. By using the AWS WA Tool, you end up with a portfolio of
workloads in your organization. You have a place to record metadata about the
workloads, such as production, account, or Regions.

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Customers often use the tool to document the architecture
decisions they made. It creates a central view across all six pillars
and any risks that exist. Senior management can then check for
trends across the portfolio and any training that might be
needed.

1.8 Three review phases

There are three phases to running a Well-Architected Framework

Review: prepare, review, and improve. In the prepare phase, you define a workload for
review in your organization and identify individuals who can answer questions during
the review on each pillar. You also need to identify someone to own the improvement
plan and, eventually, the implementation of the improvement as a result of the
review. These individuals are called sponsors. During the review phase, you run the
actual review using the AWS WA Tool. Then, you publish the report that contains
details about the current state of the workload, including notes and recommended
improvement actions. During this phase, you identify high-risk issues and medium-risk
issues for remediation. In the improve phase, you start reviewing the risk issues
identified as part of the review, prioritize them, and create a detailed treatment plan
to address them. You will dive deeper into each phase and best practices in a future
module of this course.

1.9 Prepare

First, you will learn more about the prepare phase of the review.

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
1.10 Best practices for preparing reviews

What steps can you take to help prepare for the review? First,
define the workload that will be reviewed. A workload can be a
process, a technology, an infrastructure, a team, or a
combination of them all, that deliver business value to your
organization. For example, a website where you receive purchase
orders from your customers can be a workload.

Next, identify the core team for the workload reviewed. This
team is responsible for the success of that workload and contains
subject matter experts for each pillar. Experts on this team should be able to answer
the questions on each pillar and should own the future improvement plan that can
result from identifying risks in the architecture. Then you need to hold a scoping
session for the workload to be reviewed.

1.11 Best practices for preparing reviews (cont.)

Other preparations include deciding on the type of review. For example, is it a one-day
session to review the six pillars, or multiple sessions to review pillars separately?
Participants also need to prepare and gather necessary data to answer the review
questions. Finally, you are ready to schedule the review.

1.12 Review preparation steps

The following is an example timeline that can help you plan for the review.

Approximately three weeks before a planned review, select a workload and core
review team. Invite participants to the scoping meeting.

Around 16 days before the review, hold the scoping session. In this meeting, confirm
and capture workload definitions. Select the appropriate questions from the AWS WA

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Tool, including relevant lenses, where applicable. Identify subject
matter experts for all relevant questions, and define the review
type and approach. Request that participants gather relevant
data that is accessible, rather than building new data for the
review.

Then, five days before the review, the scope should be confirmed
by all participants. Send a reminder for them to bring all relevant
information that is readily available.

1.13 Review

The second phase is the review phase for conducting the actual review.

1.14 Best practices for running reviews

When conducting a review, some best practices are recommended.

• From the core review team, the moderator manages the meeting and sticks to
the scope defined during preparation.
• It is helpful if the review team appoints one person to take notes on the
discussion, and enters this into the tool. This role can be rotated in the team to
spread the load and effort. It is important that the moderator is not also the
note taker because this can lead to less productive reviews.
• Only one person updates the tool at a time.
• Fields do not dynamically change as modified across multiple clients. Updated
records are overwritten.
• Use the AWS WA Tool to track results.
• One tip is to set up an Amazon Simple Storage Service, or Amazon S3, bucket
to store analyses or other diagrams or documentation related to this workload.

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
 • You can use a simple naming convention such as the
account and workload name.

1.15 Improve

The third phase is the improve phase. This phase is about making
an improvement plan to mitigate some of the risks identified as
a result of conducting the review.

1.16 Risk prioritization methodology and considerations

The first step in the improve phase of the review is prioritizing risks. Before jumping
into risk prioritization, it’s a good idea to briefly define the term. Risk prioritizing is the
process of identifying the most critical risks so they can be addressed first. Priorities
should be set using the likelihood of a risk and the potential impact it poses to the
organization or business. The aim is to determine a most-to-least-critical rank order of
identified risks. Examples of risk impacts include lost sales, corporate liability, brand
reputation damage, loss of market share, longer time to market, legal, regulatory, and
so on.

Risks are identified based on business goals, needs, and priorities. Examples include
time to market, security, reliability, performance, and cost. In the Well-Architected
Framework, the risk levels are categorized as high or medium. As the name suggests,
high-risk issues are architectural and operational choices that AWS has found might
result in significant negative impact to a business. While medium risk issues also might
negatively impact business, they typically do so to a lesser extent.

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
1.17 Well-Architected improvement workflow

Now that you know the risk levels, it is helpful to go over the
improvement workflow to identify, prioritize, and later address
these risks. Start with identifying the risks and improvement
opportunities. This is achieved by running a Well-Architected
Framework Review against a workload to understand where the
workload is measured against cloud best practices in the
framework. As you capture data about the workload, we
generate insights to understand where those risks are and
improvement opportunities.

Next, you will take the improvement opportunities and determine prescriptive
solutions. These address the issues that take the greatest priority based on potential
impact and the level of effort required to implement them and eliminate as many risks
as possible at the same time. After solutions have been determined, it is important to
identify which solutions take the greatest priority from the business perspective. Work
can then begin on implementing the improvement solutions in order of priority.
Improvement progress should be tracked, monitoring results to ensure that the
desired benefits are achieved.

Best practices in the framework include guidance on people, processes, and

technology. Implementing a missing best practice requires a combination of a
collaboration between your AWS account team and actions on your part to apply
them. These phases are explained in more detail in future modules.

1.22 Summary

In this module, you learned how to complete a Well-Architected Framework Review

and the impacts of design decisions on your architecture. You also learned how to
identify and evaluate risks in your architecture and how to mitigate them

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
1.23 Thank you

Thank you for your participation!

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.