AWS Well-Architected Tool. User Guide

Transcription

1 AWS Well-Architected Tool User Guide

2 AWS Well-Architected Tool: User Guide Copyright 2019 Amazon Web Services, Inc. and/or its affiliates. All rights reserved. Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon.

3 Table of Contents What is the AWS Well-Architected Tool?... 1 The AWS Well-Architected Framework... 1 Definitions... 2 Getting Started... 3 Provisioning an IAM User... 3 Defining a Workload... 4 Starting a Workload Review... 5 Question Page... 5 Saving a Milestone... 6 Tutorial... 8 Step 1: Define a Workload... 8 Step 2: Review the Workload Step 3: Review the Improvement Plan Step 4: Make Improvements and Measure Success Workloads Workloads Page Workload Details Review Tab Improvement Plan Tab Milestones Tab Properties Tab Viewing a Workload Editing a Workload Deleting a Workload Generating a Workload Report Milestones Saving a Milestone Viewing Milestones Generating a Milestone Report Dashboard Resources Completed Workload Reviews Milestones Security Authentication and Access Control Introduction to Authorization and Access Control Permissions Required How AWS WA Tool Works with IAM Troubleshooting Authentication and Access Control What is Authentication? What is Access Control? What are Policies? Getting Started with IAM Document History AWS Glossary iii

4 The AWS Well-Architected Framework What is the AWS Well-Architected Tool? The AWS Well-Architected Tool (AWS WA Tool) is a service in the cloud that provides a consistent process for you to review and measure your architecture using AWS best practices. The AWS WA Tool provides recommendations for making your workloads more reliable, secure, efficient, and cost-effective. These best practices, known as the AWS Well-Architected Framework, were developed by AWS solutions architects based on their years of experience building solutions across a wide variety of businesses. The framework provides a consistent approach for reviewing architectures and provides guidance to help implement designs that scale with your needs over time. The process for reviewing an architecture is a constructive conversation about architectural decisions, and is not an audit mechanism. This tool is intended for those in technology roles, such as chief technology officers (CTOs), architects, developers, and operations team members. The AWS Well-Architected Framework The AWS Well-Architected Framework documents a set of foundational questions that enable you to understand how a specific architecture aligns with cloud best practices. The framework provides a consistent approach to evaluating systems against the qualities you expect from modern cloud-based systems, and the improvement that would be required to achieve those qualities. By using the framework, you learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud. It provides a way for you to consistently measure your architectures against best practices and identify areas for improvement. The framework is based on five pillars operational excellence, security, reliability, performance efficiency, and cost optimization. The Five Pillars of the Well-Architected Framework Pillar name Description Operational excellence The ability to run and monitor systems to deliver business value and to continually improve supporting processes and procedures. Security The ability to protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies. Reliability The ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues. Performance efficiency The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve. Cost optimization The ability to run systems to deliver business value at the lowest price point. 1

5 Definitions When designing workloads, you make trade-offs between these pillars based upon your business needs. These business decisions can drive your engineering priorities. In development environments, you might optimize to reduce cost at the expense of reliability. In mission-critical solutions, you might optimize reliability and be willing to accept increased costs. In ecommerce solutions, you might prioritize performance, since customer satisfaction can drive increased revenue. Security and operational excellence are generally not traded off against the other pillars. For much more information on the framework, see the AWS Well-Architected website. Definitions In the AWS Well-Architected Framework: A workload identifies a set of components that deliver business value. The workload is usually the level of detail that business and technology leaders communicate about. Examples of workloads are marketing websites, ecommerce websites, the backend for a mobile app, analytic platforms, etc. Workloads vary in their level of architectural complexity. They can be simple, such as a static website, or complex, such as microservices architectures with multiple data stores and many components. Milestones mark key changes in your architecture as it evolves throughout the product lifecycle design, testing, go live, and production. 2

6 Provisioning an IAM User Getting Started with the AWS WellArchitected Tool This section describes how to get started with AWS WA Tool. Topics Provisioning an IAM User (p. 3) Defining a Workload (p. 4) Starting a Workload Review (p. 5) Saving a Milestone (p. 6) Provisioning an IAM User Create an IAM user or use an existing one associated with your AWS account. For more information, see Creating an IAM User in the IAM User Guide. Grant the IAM user access to the AWS Well-Architected Tool. Full access Full access allows the user to perform all actions in AWS WA Tool. This access is required to define workloads and run workload reviews. Apply the WellArchitectedConsoleFullAccess managed policy to the user. If you prefer to apply a custom inline policy, here is an example: { } "Version": " ", "Statement" : [ { "Effect" : "Allow", "Action" : [ "wellarchitected:*" ], "Resource": "*" } ] Read-only access Read-only access allows the user to see the results of workload reviews. Apply the WellArchitectedConsoleReadOnlyAccess managed policy to the user. If you prefer to apply a custom inline policy, here is an example: { "Version": " ", "Statement" : [ 3

7 Defining a Workload } ] { "Effect" : "Allow", "Action" : [ "wellarchitected:get*", "wellarchitected:list*" ], "Resource": "*" } The managed policies can be attached to an IAM user, group, or role. To learn how to attach a policy to an IAM user, see Working with Policies. For more information, see Security (p. 30). Defining a Workload The first step in a workload review is to define a workload. To define a workload 1. Sign in to the AWS Management Console and open the AWS Well-Architected Tool console at 2. If this is your first time using AWS WA Tool, you see a page that introduces you to the features of the tool. In the Define a workload section, choose Define workload. Alternately, in the left navigation pane, choose Workloads and choose Define workload. 3. In the Name box, enter a name for your workload. Note The name must be between 3 and 100 characters. At least 3 characters must not be spaces. Workload names must be unique. Spaces and capitalization are ignored when checking for uniqueness. 4. In the Description box, enter a description of the workload. The description must be between 3 and 250 characters. 5. In the Industry type box, choose the type of industry associated with your workload. 6. In the Industry box, choose the industry that best matches your workload. 7. In the Environment box, choose the environment for your workload: 8. Production Workload runs in a production environment. Pre-production Workload runs in a pre-production environment. In the Regions section, choose the regions for your workload: AWS Regions Choose the AWS Regions where your workload runs, one at a time. Non-AWS regions Enter the names of the regions outside of AWS where your workload runs. You can specify up to 5 unique regions, separated by commas. Use both options if appropriate for your workload. 9. (Optional) In the Account IDs box, enter the IDs of the AWS accounts associated with your workload. You can specify up to 100 unique account IDs, separated by commas. 10. Choose Define workload. If a required box is blank or if a specified value is not valid, you must correct the issue before your workload is defined. 4

8 Starting a Workload Review Starting a Workload Review After defining a workload, you can start a workload review. Pause the question and answer portion of a workload review at any time by choosing Save and exit. To start a workload review 1. After you define your workload, you see a page that shows the current details of your workload. Choose Start review to begin. Alternately, in the left navigation pane, choose Workloads and select the name of the workload you want to review to open the workload details page. Choose Start review. 2. You are now presented with the first question in the question and answer portion of the workload review. For each question: a. Read the question and determine if the question applies to your workload. For additional guidance, choose Info and view the information in the right panel. If the question does not apply to your workload, choose Question does not apply to this workload. Otherwise, select the practices that you are currently following from the list. If you are currently not following any of the practices, choose None of these. For additional guidance on any item, choose Info and view the information in the right panel. b. (Optional) Use the Notes box to record information related to the question. For example, you might explain why the question does not apply or you might provide clarification for the best practices selected. c. Choose Next to continue to the next question. Repeat these steps for each question. 3. Choose Save and exit at any time to save your changes and exit the question and answer portion of the workload review. To return to the workload review, go to the workload details page and choose Continue review. Question Page The question page has three panels. 5

9 Saving a Milestone 1. In the left panel, the questions for each pillar are shown. Questions that you have answered are marked Done and questions that do not apply to this workload are marked with N/A. The number of questions answered in each pillar is shown next to the pillar name. You can navigate to questions in other pillars by choosing the pillar name and then choosing the question you want to answer. 2. In the middle panel, the current question is displayed. Select the best practices that you are following. Choose Info to get additional information about the question or a best practice. Use the buttons at the bottom of this panel to go to the next question, return to the previous question, or save your changes and exit the workload review. 3. In the right panel, additional information and helpful resources are displayed. Saving a Milestone Any time after defining a workload, you can save a milestone. A milestone captures the current status of the workload review. To save a milestone 1. From the workload details page, choose Save milestone. 2. In the Milestone name box, enter a name for your milestone. 6

10 Saving a Milestone Note 3. The name must be between 3 and 100 characters. At least 3 characters must not be spaces. Milestone names associated with a workload must be unique. Spaces and capitalization are ignored when checking for uniqueness. Choose Save. After a milestone is saved, you cannot change the workload review data that was captured in that milestone. For more information, see Milestones (p. 26). 7

11 Step 1: Define a Workload Tutorial In this tutorial, we show how to use the AWS Well-Architected Tool to perform an architectural review of a workload. This example workload represents a retail website for a luxury goods merchant. This example illustrates, step by step, how to define a workload and perform a review of that workload. You will follow similar steps and choose from the same options for your workload. Topics Step 1: Define a Workload (p. 8) Step 2: Review the Workload (p. 11) Step 3: Review the Improvement Plan (p. 14) Step 4: Make Improvements and Measure Success (p. 17) Step 1: Define a Workload We begin by defining the workload. To define a workload 1. Sign in to the AWS Management Console and open the AWS Well-Architected Tool console at Note The IAM user who performs the workload review must have full access permissions (p. 3) to AWS WA Tool. 2. In the Define a workload section, choose Define workload. 3. In the Name box, we enter Retail Website - North America as the workload name. 4. In the Description box, we enter a description for the workload. 8

12 Step 1: Define a Workload 5. In the Industry type box, we choose Retail & Wholesale as the type of industry. 6. In the Industry box, we choose Specialty/Luxury as the industry category. 7. In the Environment box, we indicate that the workload is in a production environment. 8. Our workload runs on both AWS and at our local data center: a. We select AWS Regions, and choose the two regions in North America where the workload runs. b. We also select Non-AWS regions, and enter a name for our local data center. 9

13 Step 1: Define a Workload 9. The Account IDs box is optional, and we chose not to associate any AWS accounts with this workload. 10. We choose Define workload to save these values and define the workload. 11. After the workload is defined, you can choose Start review to begin your workload review. 10

14 Step 2: Review the Workload Step 2: Review the Workload To review the workload, you answer questions across the five pillars of the AWS Well-Architected Framework: operational excellence, security, reliability, performance efficiency, and cost optimization. For each question, choose the best practices you are following from the list provided. If you need details about a best practice, choose Info and view the additional information and resources in the right panel. Choose Next to get to the next question. You can use the left panel to navigate to a different question in the same pillar or to a question in one of the other pillars. 11

15 Step 2: Review the Workload If you choose Question does not apply to this workload or None of these, we recommend that you include the reason in the optional Notes box. These notes are included as part of the workload review report and can be helpful in the future as changes are made to the workload. You can pause the question and answer portion of a workload review by choosing Save and exit at any time. To resume the review later, reopen the AWS WA Tool console, choose Workloads in the left navigation pane, and select the name of the workload to open the workload details page. Choose Continue review and then navigate to where you paused your review. After you answer all of the questions, the review overview for the workload appears. You can review these details now or navigate to them later by choosing Workloads in the left navigation pane and selecting the name of the workload. 12

16 Step 2: Review the Workload After completing the first review of your workload, you should save a milestone and generate a workload review report. A milestone captures the current state of the workload review and enables you to measure future progress as you make changes based on your improvement plan. From the workload details page, we choose Save milestone, enter Version initial review as the Milestone name, and choose Save. 13

17 Step 3: Review the Improvement Plan You also might want to generate a workload review report at this time. Choose Generate report and a PDF file is created. The file contains the status of the workload review, the status of the workload review for each of the five pillars of the AWS Well-Architected Framework, and the answers to all of the review questions. Step 3: Review the Improvement Plan Based on your answers to the workload review, the AWS Well-Architected Tool identifies areas of high and medium risk as measured against the best practices in the AWS Well-Architected Framework. For this workload review, AWS WA Tool has identified three high risk items and one medium risk item. We update the Improvement status for the workload to indicate that we have not started workload improvements yet. 14

18 Step 3: Review the Improvement Plan For this improvement plan, we want to focus on the Reliability pillar last and trade the priorities of Performance Efficiency and Cost Optimization. To change the priority, choose Edit, drag the pillars into the order you want, and choose Save. 15

19 Step 3: Review the Improvement Plan The Improvement items section shows the recommended improvement items identified in our workload. The questions are ordered based on the pillar priority we set, with any high risk items listed first followed by any medium risk items. Expand Recommended improvement items to show the suggested best practices for a question. Each recommended improvement action links to detailed expert guidance to help you eliminate, or at least mitigate, the risks identified. 16

20 Step 4: Make Improvements and Measure Success Step 4: Make Improvements and Measure Success After deciding what improvement actions we want to take, we update the Improvement status to indicate that improvements are in progress. 17

21 Step 4: Make Improvements and Measure Success As part of our improvement plan, we addressed one of our high risk items by adding Amazon CloudWatch and AWS Auto Scaling support for our workload. We need to reflect these changes to our workload in AWS WA Tool. From the Improvement items section, we choose the pertinent question and update the answer to reflect the changes. We add Notes to record our improvements and choose Save and exit to update the workload review. 18

22 Step 4: Make Improvements and Measure Success After making other changes, we return to the Improvement plan and see that our actions have improved our risk profile down from three high risk items to only one. 19

23 Step 4: Make Improvements and Measure Success If we save a milestone at this point, we can go to Milestones and see how the workload has improved. 20

24 Workloads Page Workloads A workload is a collection of AWS resources and code that delivers business value, such as a customerfacing application or a backend process. A workload might consist of a subset of resources in a single AWS account or be a collection of multiple resources spanning multiple AWS accounts. A small business might have only a few workloads while a large enterprise might have thousands. AWS WA Tool performs a cloud architecture review on a workload. Workloads Page The Workloads page, available from the left navigation, provides information about all of your defined workloads. The following information is displayed for each workload: Name The name of the workload. Overall status An indication of whether all questions have been answered. High risks The number of high risk items identified. Medium risks The number of medium risk items identified. Improvement status The improvement status that you have set for the workload: None Not Started 21

25 Workload Details In Progress Complete Risk Acknowledged Last updated Date and time that the workload was last updated. After you choose a workload from the list, you can: Choose Generate report to create a workload report. This report contains the responses to the workload review questions, your notes, and the current number of high and medium risks identified in the workload. Choose View details to review the details of the workload. Choose Edit to change the properties of the workload. Choose Delete to delete the workload and all of its milestones. Warning Deleting a workload cannot be undone. All data associated with the workload is deleted. Choose Define workload to define a new workload. Workload Details The workload details page provides information about your workload, its milestones, and your improvement plan. Use the tabs at the top of the page to navigate to the different detail sections. Topics Review Tab (p. 22) Improvement Plan Tab (p. 23) Milestones Tab (p. 23) Properties Tab (p. 23) Review Tab When you initially view a workload, the Review tab is the first information displayed. This tab provides the overall status of your workload followed by status per pillar. If your review is not complete, a banner appears at the top to remind you to start or continue your workload review. The Review overview section shows the current overall status of the review and any Review notes that you have entered. Choose Edit to update the status or notes. Choose Save milestone to capture the current state of the workload review. Milestones are immutable and cannot be changed after they are saved. Choose Generate report to create a workload report. This report contains the responses to the workload review questions, your notes, and the current number of high and medium risks identified in the workload. The Pillars section shows the status and notes for each of the five pillars of the AWS Well-Architected Framework. Choose the pillar name to display details about that pillar. 22

26 Improvement Plan Tab Pillar Details Page The Pillar overview section shows the status of the questions associated with the pillar, your notes, and the overall status. Choose Edit to edit your pillar notes. The Questions section shows your responses to the pillar questions. You can filter which questions are displayed by either: Selecting Answered, Unanswered, or Not Applicable in the filter box. Choose the count associated with the Question status in the Pillar overview section. Improvement Plan Tab To display the improvement plan for your workload, choose the Improvement plan tab. The Improvement plan overview section lists the number of high and medium risks identified in your workload, the Improvement status you set, and the priority order that you applied to the five pillars of the AWS Well-Architected Framework. Choose Edit to update the priority order of the pillars. You can drag and drop the pillars into the desired order or use the up and down arrows to arrange them. Choose Save to save your changes. The Improvement items section shows the recommended improvement items identified in your workload. The questions are ordered based on the pillar priority you set, with high risk items listed first followed by medium risk items. Only those questions with risks identified are displayed. You can filter the improvement items by level of risk, by pillar, or both. Choose a question to review your answer and any notes recorded during the workload review. Expand Recommended improvement items for expert guidance to help you fix the identified risks. Each recommended improvement item links to a page with actionable details to help you eliminate, or at least mitigate, the risks identified. Milestones Tab Choose the Milestones tab to display the milestones for your workload. After you select a milestone, choose Generate report to create the workload report associated with the milestone. The report contains the responses to the workload review questions, your notes, and the number of high and medium risks that were present in the workload at the time the milestone was saved. You can view details about the state of your workload at the time of a specific milestone by either: Choosing the name of the milestone. Selecting the milestone and choosing View milestone. Properties Tab Choose the Properties tab to display the properties of your workload. These properties are the values you specified when you initially defined the workload. Choose Edit to make any necessary changes. For descriptions of the properties, see Defining a Workload (p. 4). 23

27 Viewing a Workload Viewing a Workload You can view the details of a workload after it has been defined. To view a workload 1. In the left navigation pane, choose Workloads. 2. Select the workload to view in one of the following ways: Choose the name of the workload. Select the workload and choose View details. The workload details page is displayed. Editing a Workload You can edit the details of a workload after it has been defined. To edit a workload 1. In the left navigation pane, choose Workloads. 2. Select the workload you want to edit and choose Edit. 3. Make your changes to the workload. For descriptions of the fields, see Defining a Workload (p. 4). 4. Choose Save to save your changes to the workload. If a required field is blank or if a specified value is not valid, you must correct the issue before your updates to the workload are saved. Deleting a Workload You can delete a workload when it is no longer needed. Deleting a workload removes all data associated with the workload including any milestones. Warning Deleting a workload cannot be undone. All data associated with the workload is permanently removed. To delete a workload 1. In the left navigation pane, choose Workloads. 2. Select the workload you want to delete and choose Delete. 3. In the Delete window, choose Delete to confirm the deletion of the workload and its milestones. Generating a Workload Report You can generate a workload report. The report contains the responses to the workload review questions, your notes, and the current number of high and medium risks identified in the workload. 24

28 Generating a Workload Report A report enables you to share details about your workload review with others who do not have access to the AWS Well-Architected Tool. To generate a workload report 1. In the left navigation pane, choose Workloads. 2. Select the workload you want to generate a report for and choose Generate report. The report is generated and you can download or view it. 25

29 Saving a Milestone Milestones A milestone records the current status of a workload review. You should save a milestone after you initially complete the questions and answers portion of a workload review. As you change your workload based on items in your improvement plan, you can save additional milestones to measure progress. A best practice is to save a milestone after major changes are made to your workload and you perform a workload review. Saving a Milestone Any time after defining a workload, you can save a milestone. A milestone records the current status of the workload review. To save a milestone 1. From the workload details page, choose Save milestone. 2. In the Milestone name box, enter a name for your milestone. Note The name must be between 3 and 100 characters. At least 3 characters must not be spaces. Milestone names associated with a workload must be unique. Spaces and capitalization are ignored when checking for uniqueness. 3. Choose Save to save the milestone. After a milestone is saved, you cannot change the workload review data that was recorded. When you delete a workload, its associated milestones are also deleted. Viewing Milestones You can view milestones for a workload in the following ways: On the workload details page, choose Milestones and choose the milestone you want to view. For complete workload reviews, from the Dashboard page, choose the workload and in the Milestones section, choose the milestone you want to view. Generating a Milestone Report You can generate a milestone report. The report contains the responses to the workload review questions, your notes, and the number of high and medium risks that were present in the workload at the time the milestone was saved. A report enables you to share details about the milestone with others who do not have access to the AWS Well-Architected Tool. 26

30 Generating a Milestone Report To generate a milestone report 1. Select the milestone in one of the following ways. From the workload details page, choose Milestones and choose the milestone. For complete workload reviews, from the Dashboard page, choose the workload with the milestone that you want to report on. In the Milestones section, choose the milestone. 2. Choose Generate report to generate a report. The PDF file is generated and you can download or view it. 27

31 Dashboard The Dashboard, available from the left navigation, gives you access to your completed workload reviews and their associated milestones. The Dashboard consists of three sections. 1. Resources Shows the number of completed workload reviews and how many reviews have high and medium risks. 2. Completed workload reviews Shows a list of the completed workload reviews, which you can filter by level of risk. 3. Milestones Shows any milestones associated with the workload selected in Completed workload reviews. 28

32 Resources Resources The Resources section shows the number of completed workload reviews and the number of reviews with high or medium risks. Choose a review count to filter the workload reviews shown in the Completed workload reviews section. Completed Workload Reviews The Completed workload reviews section displays information for each completed workload review. You can filter the list based on risk. The following information is displayed for each workload: Name The name of the workload. High risks The number of high risk items identified. Medium risks The number of medium risk items identified. Select a workload to display its milestones. Choose the workload name to view the workload details page. Milestones The Milestones section displays the milestones associated with the workload selected in the Completed workload reviews section. The following information is displayed for each milestone: Name The name of the milestone. Milestone status An indication whether all questions have been answered. High risks The number of high risk items identified. Medium risks The number of medium risk items identified. Date saved Data and time that the milestone was saved. Choose a milestone to view the milestones detail page. 29

33 Authentication and Access Control AWS Well-Architected Tool Security Cloud security at AWS is the highest priority. As an AWS customer, you will benefit from a data center and network architecture built to meet the requirements of the most security-sensitive organizations. Use the following topics to learn how to secure your AWS WA Tool resources. Topics Authentication and Access Control for the AWS Well-Architected Tool (p. 30) Authentication and Access Control for the AWS Well-Architected Tool AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS Well-Architected Tool resources. Administrators use IAM to control who is authenticated (signed in) and authorized (has permissions) to use AWS WA Tool resources. IAM is a feature of your AWS account offered at no additional charge. Important To get started quickly, review the introductory information on this page and then see Getting Started with IAM (p. 40). You can optionally learn more about authentication and access control by viewing What is Authentication? (p. 34), What is Access Control? (p. 35), and What are Policies? (p. 38). Topics Introduction to Authorization and Access Control (p. 30) Permissions Required (p. 31) Understanding How AWS WA Tool Works with IAM (p. 32) Troubleshooting Authentication and Access Control (p. 34) Introduction to Authorization and Access Control Authentication To sign in to AWS, you must use root user credentials (not recommended), IAM user credentials, or temporary credentials using IAM roles. To learn more about these entities, see What is Authentication? (p. 34). Access Control AWS administrators use policies to control access to AWS resources, such as the AWS WA Tool workload. To learn more, see What is Access Control? (p. 35) and What are Policies? (p. 38). Important All resources in an account are owned by the account, regardless of who created those resources. You must be granted access to create a resource. However, just because you created a resource does not mean that you automatically have full access to that resource. An administrator must explicitly grant permissions for each action that you want to perform. That administrator can also revoke your permissions at any time. To help you understand the basics of how IAM works, review the following terms: Resources AWS services, such as AWS WA Tool and IAM, are made up of objects called resources. You can create, manage, and delete these resources from the service. IAM resources include users, groups, roles, and policies. 30

34 Permissions Required Users An IAM user represents the person or application who uses its credentials to interact with AWS. A user consists of a name, a password to sign into the AWS Management Console, and up to two access keys that can be used with the AWS CLI or AWS API. Groups An IAM group is a collection of IAM users. You can use groups to specify permissions for its member users. This makes it easier for you to manage permissions for multiple users. Roles An IAM role does not have any long-term credentials (password or access keys) associated with it. A role can be assumed by anyone who needs it and has permissions. An IAM user can assume a role to temporarily take on different permissions for a specific task. Federated users can assume a role by using an external identity provider that is mapped to the role. Some AWS services can assume a service role to access AWS resources on your behalf. Policies Policies are JSON policy documents that define the permissions for the object to which they are attached. AWS supports identity-based policies that you attach to identities (users, groups, or roles). Some AWS services allow you to attach resource-based policies to resources to control what a principal (person or application) can do to that resource. AWS WA Tool does not support resourcebased policies. Identities Identities are IAM resources for which you can define permissions. These include users, groups, and roles. Entities Entities are IAM resources that you use for authentication. These include users and roles. Principals In AWS, a principal is a person or application that uses an entity to sign in and make requests to AWS. As a principal, you can use the AWS Management Console, the AWS CLI, or the AWS API to perform an operation (such as deleting a workload). This creates a request for that operation. Your request specifies the action, resource, principal, principal account, and any additional information about your request. All of this information provides AWS with context for your request. AWS checks all the policies that apply to the context of your request. AWS authorizes the request only if each part of your request is allowed by the policies. To view a diagram of the authentication and access control process, see Understanding How IAM Works in the IAM User Guide. For details about how AWS determines whether a request is allowed, see Policy Evaluation Logic in the IAM User Guide. Permissions Required To use AWS WA Tool or to manage authorization and access control for yourself or others, you must have the correct permissions. Permissions Required to Use the AWS WA Tool Console To access the AWS Well-Architected Tool console, you must have a minimum set of permissions that allows you to list and view details about the AWS WA Tool resources in your AWS account. If you create an identity-based permissions policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities with that policy. To ensure that those entities can still use the AWS WA Tool console, also attach the following AWS managed policy to the user, as described in Creating Policies on the JSON Tab: WellArchitectedConsoleReadOnlyAccess Permissions Required for Authentication Management To manage your own credentials, such as your password, access keys, and multi-factor authentication (MFA) devices, your administrator must grant you the required permissions. To view the policy that includes these permissions, see Allow Users to Self-Manage Their Credentials (p. 43). 31

35 How AWS WA Tool Works with IAM As an AWS administrator, you need full access to IAM so that you can create and manage users, groups, roles, and policies in IAM. You should use the AdministratorAccess AWS managed policy that includes full access to all of AWS. This policy does not provide access to the AWS Billing and Cost Management console or allow tasks that require root user credentials. For more information, see AWS Tasks That Require AWS Account Root User Credentials in the AWS General Reference. Warning Only an administrator user should have full access to AWS. Anyone with this policy has permission to fully manage authentication and access control, in addition to modifying every resource in AWS. To learn how to create this user, see Create your IAM Admin User (p. 40). Permissions Required for Access Control If your administrator provided you with IAM user credentials, they attached policies to your IAM user to control what resources you can access. To view the policies attached to your user in the AWS Management Console, you must have the following permissions: { } "Version": " ", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:getuserpolicy", "iam:listgroupsforuser", "iam:listattacheduserpolicies", "iam:listuserpolicies", "iam:getuser" ], "Resource": [ "arn:aws:iam::*:user/${aws:username}" ] }, { "Sid": "ListUsersViewGroupsAndPolicies", "Effect": "Allow", "Action": [ "iam:getgrouppolicy", "iam:getpolicyversion", "iam:getpolicy", "iam:listattachedgrouppolicies", "iam:listgrouppolicies", "iam:listpolicyversions", "iam:listpolicies", "iam:listusers" ], "Resource": "*" } ] If you need additional permissions, ask your administrator to update your policies to allow you to access the actions that you require. Understanding How AWS WA Tool Works with IAM Services can work with IAM in several ways: 32

36 How AWS WA Tool Works with IAM Actions AWS WA Tool supports using actions in a policy. This allows an administrator to control whether an entity can complete an operation in AWS WA Tool. For example, to allow an entity to define a workload, an administrator must attach a policy that allows wellarchitected:* actions. Resource-level permissions AWS WA Tool does not support resource-level permissions. Resourcelevel permissions allow you to use ARNs to specify individual resources in the policy. Because AWS WA Tool does not support this feature, then you must choose All resources in the policy visual editor. In a JSON policy document, you must use * in the Resource element. Resource-based policies AWS WA Tool does not support resource-based policies. Authorization based on tags AWS WA Tool does not support authorization based tags. Temporary credentials AWS WA Tool does not support temporary credentials. Service-linked roles AWS WA Tool does not support service roles. Service roles AWS WA Tool does not support service roles. To provide access to the AWS Well-Architected Tool, assign one of the following managed policies. Full access Full access allows the user to perform all actions in AWS WA Tool. This access is required to define workloads and run workload reviews. Apply the WellArchitectedConsoleFullAccess managed policy to the user, group, or role. If you prefer to apply a custom inline policy, here is an example: { } "Version": " ", "Statement" : [ { "Effect" : "Allow", "Action" : [ "wellarchitected:*" ], "Resource": "*" } ] Read-only access Read-only access allows the user to see the results of workload reviews. Apply the WellArchitectedConsoleReadOnlyAccess managed policy to the user, group, or role. If you prefer to apply a custom inline policy, here is an example: { } "Version": " ", "Statement" : [ { "Effect" : "Allow", "Action" : [ "wellarchitected:get*", "wellarchitected:list*" ], "Resource": "*" } ] 33

37 Troubleshooting Authentication and Access Control Troubleshooting Authentication and Access Control Use the following information to help you diagnose and fix common issues that you might encounter when working with IAM. Topics I am not authorized to perform an action in AWS WA Tool (p. 34) I'm an administrator and want to allow others to access AWS WA Tool (p. 34) I want to understand IAM without becoming an expert (p. 34) I am not authorized to perform an action in AWS WA Tool If you receive an error in the AWS Management Console that tells you that you're not authorized to perform an action, then you must contact the administrator that provided you with your user name and password. The following example error occurs when an IAM user named my-user-name tries to use the console to perform the CreateWorkload action, but does not have permissions. User: arn:aws:iam:: :user/my-user-name is not authorized to perform: wellarchitected:createworkload on resource: my-workload For this example, ask your administrator to update your policies to allow you to access the my-workload resource using the wellarchitected:createworkload action. I'm an administrator and want to allow others to access AWS WA Tool To allow others to access AWS WA Tool you must create an IAM entity (user or role) for the person or application that needs access. They will use the credentials for that entity to access AWS. You must then attach a policy to the entity that grants them the correct permissions in AWS WA Tool. To get started right away, see Getting Started with IAM (p. 40). I want to understand IAM without becoming an expert To learn more about IAM terms, concepts, and procedures, see the following pages: What is Authentication? (p. 34) What is Access Control? (p. 35) What are Policies? (p. 38) What is Authentication? Authentication is how you sign in to AWS using your credentials. Note To get started quickly, you can ignore this page. First, review the introductory information on Authentication and Access Control for the AWS Well-Architected Tool (p. 30) and then see Getting Started with IAM (p. 40). As a principal, you must be authenticated (signed in to AWS) using an entity (root user, IAM user, or IAM role) to send a request to AWS. An IAM user can have long-term credentials such as a user name 34

38 What is Access Control? and password or a set of access keys. When you assume an IAM role, you are given temporary security credentials. To authenticate from the AWS Management Console as a user, you must sign in with your user name and password. To authenticate from the AWS CLI or AWS API, you must provide your access key and secret key or temporary credentials. AWS provides SDK and CLI tools to cryptographically sign your request using your credentials. If you don t use AWS tools, you must sign the request yourself. Regardless of the authentication method that you use, you might also be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. As a principal, you can sign in to AWS using the following entities (users or roles): AWS account root user When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the address and password that you used to create the account. We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. IAM user An IAM user is an entity within your AWS account that has specific permissions. IAM role An IAM role is an IAM identity that you can create in your account that has specific permissions. It is similar to an IAM user, but it is not associated with a specific person. An IAM role enables you to obtain temporary access keys that can be used to access AWS services and resources. IAM roles with temporary credentials are useful in the following situations: Federated user access Instead of creating an IAM user, you can use existing user identities from AWS Directory Service, your enterprise user directory, or a web identity provider. These are known as federated users. AWS assigns a role to a federated user when access is requested through an identity provider. For more information about federated users, see Federated Users and Roles in the IAM User Guide. Temporary user permissions An IAM user can assume a role to temporarily take on different permissions for a specific task. Cross-account access You can use an IAM role to allow a trusted principal in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). AWS WA Tool does not support these resource-based policies. For more information about choosing whether to use a role or a resource-based policy to allow cross-account access, see Controlling Access to Principals in a Different Account (p. 37). AWS service access You can use an IAM role in your account to grant an AWS service permissions to access your account s resources. For example, you can create a role that allows Amazon Redshift to access an Amazon S3 bucket on your behalf and then load data from that bucket into an Amazon Redshift cluster. For more information, see Creating a Role to Delegate Permissions to an AWS Service in the IAM User Guide. Applications running on Amazon EC2 You can use an IAM role to manage temporary credentials for applications that are running on an EC2 instance and making AWS API requests. This is preferable to storing access keys within the EC2 instance. To assign an AWS role to an EC2 instance and make it available to all of its applications, you create an instance profile that is attached to the instance. An instance profile contains the role and enables programs that are running on the EC2 instance to get temporary credentials. For more information, see Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances in the IAM User Guide. What is Access Control? After you sign in (are authenticated) to AWS, your access to AWS resources and operations is controlled using policies. Access control is also known as authorization. 35

39 What is Access Control? Note To get started quickly, you can ignore this page. First, review the introductory information on Authentication and Access Control for the AWS Well-Architected Tool (p. 30) and then see Getting Started with IAM (p. 40). During authorization, AWS uses values from the request context to check for policies that apply. It then uses the policies to determine whether to allow or deny the request. Most policies are stored in AWS as JSON documents and specify the permissions that are allowed or denied for principals. For more information about the structure and contents of JSON policy documents, see What are Policies? (p. 38). Policies let an administrator specify who has access to AWS resources, and what actions they can perform on those resources. Every IAM entity (user or role) starts with no permissions. In other words, by default, users can do nothing, not even view their own access keys. To give a user permission to do something, an administrator must attach a permissions policy to a user. Or they can add the user to a group that has the intended permissions. When an administrator then give permissions to a group, all users in that group get those permissions. You might have valid credentials to authenticate your requests, but unless an administrator grants you permissions you cannot create or access AWS Well-Architected Tool resources. For example, you must have explicit permissions to create an AWS Well-Architected Tool workload. As an administrator, you can write a policy to control access to the following: AWS for Principals (p. 36) Control what the person making the request (the principal) is allowed to do. IAM Identities (p. 36) Control which IAM identities (groups, users, and roles) can be accessed and how. IAM Policies (p. 37) Control who can create, edit, and delete customer managed policies, and who can attach and detach all managed policies. AWS Resources (p. 37) Control who has access to resources using an identity-based policy or a resource-based policy. AWS Accounts (p. 37) Control whether a request is allowed only for members of a specific account. Controlling Access for Principals Permissions policies control what you, as a principal, are allowed to do. An administrator must attach an identity-based permissions policy to the identity (user, group, or role) that provides your permissions. Permissions policies allow or deny access to AWS. Administrators can also set a permissions boundary for an IAM entity (user or role) to define the maximum permissions that the entity can have. Permissions boundaries are an advanced IAM feature. For more information about permissions boundaries, see Permissions Boundaries for IAM Identities in the IAM User Guide. For more information and an example of how to control AWS access for principals, see Controlling Access for Principals in the IAM User Guide. Controlling Access to Identities Administrators can control what you can do to an IAM identity (user, group, or role) by creating a policy that limits what can be done to an identity, or who can access it. Then attach that policy to the identity that provides your permissions. For example, an administrator might allow you to reset the password for three specific users. To do this, they attach a policy to your IAM user that allows you to reset the password for only yourself and users with the ARN of the three specified users. This allows you to reset the password of your team members but not other IAM users. 36