{"id":272,"date":"2026-04-13T11:01:18","date_gmt":"2026-04-13T11:01:18","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-well-architected-tool-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance\/"},"modified":"2026-04-13T11:01:18","modified_gmt":"2026-04-13T11:01:18","slug":"aws-well-architected-tool-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-well-architected-tool-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance\/","title":{"rendered":"AWS Well-Architected Tool Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Management and governance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Management and governance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>AWS Well-Architected Tool is an AWS Management and governance service that helps you review, measure, and improve your cloud architectures against AWS best practices.<\/p>\n\n\n\n<p>In simple terms: you describe a workload (an application or system), answer guided questions, and the tool identifies risks and recommended improvements using the AWS Well-Architected Framework pillars.<\/p>\n\n\n\n<p>Technically, AWS Well-Architected Tool is a managed review workflow that organizes your architecture assessment into <strong>workloads<\/strong>, evaluates them using <strong>lenses<\/strong> (including the AWS Well-Architected Framework lens), tracks <strong>high-risk issues (HRIs)<\/strong>, and lets you create <strong>milestones<\/strong> to snapshot progress over time. It also supports automation through an API\/SDK so teams can standardize reviews and reporting across many workloads and accounts.<\/p>\n\n\n\n<p>The problem it solves is common in real environments: teams scale faster than architecture documentation and governance. Without a consistent method, architecture reviews become subjective, inconsistent, and hard to operationalize. AWS Well-Architected Tool provides a repeatable mechanism to identify risks early, align on best practices, track improvements, and demonstrate governance over time.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS Well-Architected Tool?<\/h2>\n\n\n\n<p><strong>Official purpose:<\/strong> AWS Well-Architected Tool helps you <strong>review the state of your workloads and compares them to the latest AWS architectural best practices<\/strong>. It is designed to operationalize the AWS Well-Architected Framework in a consistent, auditable way.<br\/>\nOfficial docs: https:\/\/docs.aws.amazon.com\/wellarchitected\/latest\/userguide\/what-is-aws-well-architected-tool.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create and manage <strong>workloads<\/strong> (applications\/systems you want to review).<\/li>\n<li>Assess workloads using <strong>lenses<\/strong> (sets of questions and best practices), including AWS-provided lenses and <strong>custom lenses<\/strong>.<\/li>\n<li>Identify <strong>high-risk issues (HRIs)<\/strong> and improvement opportunities.<\/li>\n<li>Capture point-in-time snapshots via <strong>milestones<\/strong> to track progress.<\/li>\n<li>Share workloads with other AWS principals\/accounts (for collaboration and reviews).<\/li>\n<li>Programmatic access via the <strong>AWS Well-Architected Tool API<\/strong> (for automation and reporting).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual model)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Workload:<\/strong> A reviewed system\/application, including metadata such as environment, regions, and answers to review questions.<\/li>\n<li><strong>Lens:<\/strong> A structured set of best-practice questions. AWS provides the core Well-Architected Framework lens and may provide additional domain lenses (availability varies; use what appears in your console).<\/li>\n<li><strong>Question \/ Best practice:<\/strong> Each lens contains questions mapped to best practices.<\/li>\n<li><strong>Risk levels &amp; HRIs:<\/strong> The tool flags risks based on your answers (HRIs are the most urgent).<\/li>\n<li><strong>Milestone:<\/strong> A snapshot of your workload\u2019s review state at a point in time.<\/li>\n<li><strong>Sharing \/ collaboration:<\/strong> Controlled access to workloads and reviews.<\/li>\n<li><strong>API\/SDK:<\/strong> Enables repeatable governance and integration with internal tooling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type and scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service type:<\/strong> Managed governance\/review tool (console + API). It does not deploy infrastructure; it helps you assess and govern it.<\/li>\n<li><strong>Scope:<\/strong> Workloads are created <strong>per AWS account<\/strong> and accessed via IAM permissions. Workload sharing enables cross-account collaboration.<\/li>\n<li><strong>Regional vs global:<\/strong> AWS Well-Architected Tool is a <strong>regional service<\/strong> (you select a region in the console). Your workload can describe architectures spanning multiple regions, but the review data is stored\/managed in the region where you create the workload. Verify region availability and data residency requirements in official docs and the AWS Regional Services List: https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>AWS Well-Architected Tool complements (not replaces) operational services:\n&#8211; <strong>AWS Organizations \/ multi-account strategy:<\/strong> Perform consistent reviews across accounts; use sharing and standard processes.\n&#8211; <strong>AWS IAM \/ IAM Identity Center:<\/strong> Control who can create, view, and update reviews.\n&#8211; <strong>AWS CloudTrail:<\/strong> Audit API actions performed in the tool.\n&#8211; <strong>AWS Config, Trusted Advisor, Security Hub, CloudWatch, Systems Manager:<\/strong> These provide operational signals and controls; Well-Architected Tool provides a structured architecture-review process to guide improvements using those signals.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS Well-Architected Tool?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce risk and downtime:<\/strong> Identify design gaps before they become incidents.<\/li>\n<li><strong>Make architecture decisions consistent:<\/strong> Standardize how teams evaluate architectures.<\/li>\n<li><strong>Improve time-to-market responsibly:<\/strong> Ship faster without skipping governance.<\/li>\n<li><strong>Support stakeholder reporting:<\/strong> Milestones and reports help communicate progress and risk posture to leadership.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Framework-driven reviews:<\/strong> Align to AWS best practices across pillars.<\/li>\n<li><strong>Repeatability:<\/strong> Run the same review pattern across dozens\/hundreds of workloads.<\/li>\n<li><strong>Versioned progress tracking:<\/strong> Milestones provide traceability over time.<\/li>\n<li><strong>Automation:<\/strong> API-based workflows enable inventory, reporting, and governance at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Create a review cadence:<\/strong> Quarterly reviews, pre-launch reviews, or post-incident reviews.<\/li>\n<li><strong>Operationalize improvements:<\/strong> HRIs can drive backlog items and remediation plans.<\/li>\n<li><strong>Better handoffs:<\/strong> Shared workload reviews improve collaboration among platform, security, and app teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Evidence of governance:<\/strong> Auditors often want proof of architecture oversight. Milestones and review artifacts can help demonstrate process (but do not replace formal compliance controls).<\/li>\n<li><strong>Shared language:<\/strong> Security, engineering, and ops teams can align on risk categories and best-practice expectations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Design for growth:<\/strong> The Performance Efficiency pillar helps teams identify bottlenecks and plan capacity\/scaling strategies.<\/li>\n<li><strong>Avoid re-architecture costs:<\/strong> Catch foundational issues early (networking, data design, scaling patterns).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose AWS Well-Architected Tool<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You run workloads on AWS and need a <strong>structured<\/strong> architecture review process.<\/li>\n<li>You want to standardize best practices across multiple teams\/accounts.<\/li>\n<li>You need to track improvements over time with milestones.<\/li>\n<li>You want to build an internal governance program (architecture reviews as code\/process).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>real-time operational monitoring<\/strong> or automated drift remediation (use CloudWatch, Config, Systems Manager, etc.).<\/li>\n<li>Your workloads are entirely outside AWS and you need a cloud-agnostic tool with deep integrations across multiple clouds (you might use internal checklists or third-party governance platforms).<\/li>\n<li>You are looking for a service that automatically fixes issues; AWS Well-Architected Tool identifies risk and recommendations, but remediation is up to your team.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS Well-Architected Tool used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SaaS and technology:<\/strong> Standardizing reviews across many microservices.<\/li>\n<li><strong>Financial services \/ regulated industries:<\/strong> Governance, audit trails, and repeatable review processes.<\/li>\n<li><strong>Healthcare:<\/strong> Aligning security and reliability practices with compliance needs.<\/li>\n<li><strong>E-commerce \/ media:<\/strong> Performance and resilience under demand spikes.<\/li>\n<li><strong>Public sector \/ education:<\/strong> Governance and cost controls across many teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering and cloud enablement teams (standardize review processes).<\/li>\n<li>Solution architects (pre-launch and design reviews).<\/li>\n<li>SRE\/operations (post-incident learning, reliability reviews).<\/li>\n<li>Security engineering and GRC (security posture improvement and evidence of process).<\/li>\n<li>Product engineering teams (self-service reviews as part of delivery).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices and container platforms (EKS\/ECS).<\/li>\n<li>Serverless applications (Lambda\/API Gateway\/event-driven).<\/li>\n<li>Data platforms (lake\/warehouse\/streaming).<\/li>\n<li>Traditional 3-tier web apps and enterprise apps.<\/li>\n<li>Hybrid connectivity (VPN\/Direct Connect) architectures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Pre-production gates:<\/strong> Reviews before launch or major releases.<\/li>\n<li><strong>Post-migration:<\/strong> Validate architecture after moving to AWS.<\/li>\n<li><strong>Continuous improvement:<\/strong> Quarterly or semiannual reviews.<\/li>\n<li><strong>M&amp;A \/ portfolio rationalization:<\/strong> Assess and standardize inherited workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> Most valuable when assessing critical production workloads and tracking milestones over time.<\/li>\n<li><strong>Dev\/test:<\/strong> Useful for teaching best practices early and preventing \u201cbad patterns\u201d from reaching production.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where AWS Well-Architected Tool fits well.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Pre-launch architecture review for a new production workload<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams are about to launch without a consistent review process.<\/li>\n<li><strong>Why this service fits:<\/strong> Provides a structured checklist aligned to AWS best practices.<\/li>\n<li><strong>Example:<\/strong> A payments API prepares for GA; architects run a Well-Architected review and address HRIs before launch.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Standardized quarterly reviews across a microservices portfolio<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Hundreds of services drift over time; architecture standards vary by team.<\/li>\n<li><strong>Why it fits:<\/strong> Repeatable reviews; milestones show progress and prevent regression.<\/li>\n<li><strong>Example:<\/strong> Platform team requires a quarterly milestone for each tier-1 service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Post-incident resilience review (\u201clearning review\u201d)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A major outage occurred; root causes point to architectural gaps.<\/li>\n<li><strong>Why it fits:<\/strong> Reliability pillar and operational excellence questions guide remediation planning.<\/li>\n<li><strong>Example:<\/strong> After a regional dependency issue, the team reviews failover design and creates an improvement plan.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Migration readiness and modernization planning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Lift-and-shift apps run, but aren\u2019t optimized for AWS.<\/li>\n<li><strong>Why it fits:<\/strong> Identifies cost, performance, and reliability improvements after migration.<\/li>\n<li><strong>Example:<\/strong> An ERP workload is moved to EC2; review highlights backup strategy gaps and scaling opportunities.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Security baseline assessment for regulated workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Security requirements are known, but implementation is inconsistent.<\/li>\n<li><strong>Why it fits:<\/strong> Security pillar questions drive consistent controls and operational practices.<\/li>\n<li><strong>Example:<\/strong> A healthcare app review identifies gaps in audit logging and identity governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Cost optimization program across business units<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Cloud spend increases; teams lack a consistent approach to cost efficiency.<\/li>\n<li><strong>Why it fits:<\/strong> Cost Optimization pillar provides targeted questions and actions.<\/li>\n<li><strong>Example:<\/strong> FinOps team reviews top-10 spend workloads and uses HRIs to prioritize savings work.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Multi-account governance for a cloud center of excellence (CCoE)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Many accounts and teams; no consistent architecture oversight.<\/li>\n<li><strong>Why it fits:<\/strong> Workload reviews plus sharing enable centralized visibility while keeping app ownership.<\/li>\n<li><strong>Example:<\/strong> CCoE defines a review standard and requires milestone evidence for production workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Introducing new engineers to AWS architectural best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> New hires build services but lack AWS best-practice context.<\/li>\n<li><strong>Why it fits:<\/strong> The guided questions teach the \u201cwhy\u201d behind design choices.<\/li>\n<li><strong>Example:<\/strong> A bootcamp uses a sample workload review as a training exercise.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Vendor\/partner collaboration on architecture (with controlled sharing)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> External partner needs to participate in a review without broad account access.<\/li>\n<li><strong>Why it fits:<\/strong> Share workload review access with least privilege.<\/li>\n<li><strong>Example:<\/strong> A consulting partner reviews reliability and security choices for a new platform.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Creating an internal \u201carchitecture review as code\u201d workflow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Reviews are manual and hard to track.<\/li>\n<li><strong>Why it fits:<\/strong> API enables automation: list workloads, track HRIs, export artifacts, build dashboards.<\/li>\n<li><strong>Example:<\/strong> A CI job checks that a workload has a recent milestone before allowing a major production release.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Consolidating architecture documentation and decision records<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Architecture docs are scattered across wikis and tickets.<\/li>\n<li><strong>Why it fits:<\/strong> The workload object provides a consistent, searchable home for review outcomes.<\/li>\n<li><strong>Example:<\/strong> Architects record key decisions and notes per question and track improvements over time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Assessing shared platform services (network, identity, CI\/CD)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Platform teams also own \u201cworkloads\u201d that impact many apps.<\/li>\n<li><strong>Why it fits:<\/strong> Apply the framework lens to platform components and track improvements.<\/li>\n<li><strong>Example:<\/strong> Identity platform review identifies gaps in break-glass access procedures and logging.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on current, commonly used AWS Well-Architected Tool capabilities. If a feature\u2019s availability differs by region or account type, <strong>verify in official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Creates a named entity representing an application\/system and its architecture review data.<\/li>\n<li><strong>Why it matters:<\/strong> Establishes a consistent unit of governance and reporting.<\/li>\n<li><strong>Practical benefit:<\/strong> Lets you track risk and improvements by application, team, or business unit.<\/li>\n<li><strong>Caveats:<\/strong> Workloads are created in a specific AWS region; plan for data residency and standardize which region your organization uses.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">AWS-provided lenses (including the AWS Well-Architected Framework lens)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides structured questions aligned to the Well-Architected pillars.<\/li>\n<li><strong>Why it matters:<\/strong> Standardizes how architects evaluate and improve designs.<\/li>\n<li><strong>Practical benefit:<\/strong> Teams get consistent recommendations and can compare maturity across workloads.<\/li>\n<li><strong>Caveats:<\/strong> Lens content can evolve. Re-run reviews periodically to align with updated best practices.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Custom lenses<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows organizations to create their own lens tailored to internal standards (for example, security baselines or platform requirements).<\/li>\n<li><strong>Why it matters:<\/strong> Many companies have requirements beyond generic guidance.<\/li>\n<li><strong>Practical benefit:<\/strong> Embed organizational policies and reusable patterns into the review process.<\/li>\n<li><strong>Caveats:<\/strong> Custom lenses require maintenance and governance (versioning, ownership, review). Validate custom lens questions for clarity and actionability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Question-level notes, choices, and review workflow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Captures answers to lens questions, notes, and rationale.<\/li>\n<li><strong>Why it matters:<\/strong> Architecture decisions need context, not just checkboxes.<\/li>\n<li><strong>Practical benefit:<\/strong> Helps with knowledge transfer and auditability of decisions.<\/li>\n<li><strong>Caveats:<\/strong> Avoid putting secrets (passwords, keys) into notes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Risk identification (including High-Risk Issues \/ HRIs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Flags risk levels based on answers, surfacing HRIs to prioritize remediation.<\/li>\n<li><strong>Why it matters:<\/strong> Not all issues are equal; HRIs help triage.<\/li>\n<li><strong>Practical benefit:<\/strong> Teams can focus limited time on the most impactful improvements first.<\/li>\n<li><strong>Caveats:<\/strong> The tool identifies risk based on framework logic; your context may change priority. Use engineering judgment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Improvement plans and reports<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides ways to summarize results and recommended improvements for a workload review.<\/li>\n<li><strong>Why it matters:<\/strong> Teams need actionable outputs, not just assessment data.<\/li>\n<li><strong>Practical benefit:<\/strong> Supports converting review outcomes into a remediation backlog.<\/li>\n<li><strong>Caveats:<\/strong> Export\/report formats and options may vary. Use the console options available in your region and verify in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Milestones (point-in-time snapshots)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Captures a snapshot of the workload review at a moment in time.<\/li>\n<li><strong>Why it matters:<\/strong> Architecture is a moving target; milestones show progress and regression.<\/li>\n<li><strong>Practical benefit:<\/strong> Enables governance like \u201cmust have a milestone within last 90 days\u201d for tier-1 workloads.<\/li>\n<li><strong>Caveats:<\/strong> Milestones are snapshots, not automatic enforcement. You still need process and ownership.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Sharing and collaboration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you share workloads for review collaboration, potentially across accounts.<\/li>\n<li><strong>Why it matters:<\/strong> Reviews often involve multiple teams (security, platform, app).<\/li>\n<li><strong>Practical benefit:<\/strong> Enables distributed ownership while keeping centralized governance.<\/li>\n<li><strong>Caveats:<\/strong> Treat sharing as access control. Use least privilege and periodically review who has access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">API\/SDK access (automation)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows programmatic management of workloads, lens reviews, milestones, and sharing.<\/li>\n<li><strong>Why it matters:<\/strong> At scale, manual reviews and reporting become a bottleneck.<\/li>\n<li><strong>Practical benefit:<\/strong> Build dashboards, automate compliance checks, export review status to internal systems.<\/li>\n<li><strong>Caveats:<\/strong> API permissions must be carefully scoped. Also account for regional endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tagging (resource organization)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports tags for workloads (and possibly other entities depending on AWS support; verify in docs).<\/li>\n<li><strong>Why it matters:<\/strong> Tags enable cost allocation, ownership mapping, and portfolio views.<\/li>\n<li><strong>Practical benefit:<\/strong> Filter workloads by team, environment, system tier, or compliance domain.<\/li>\n<li><strong>Caveats:<\/strong> Standardize tag keys\/values to avoid fragmentation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>AWS Well-Architected Tool is a managed AWS service. You interact through:\n&#8211; <strong>AWS Management Console<\/strong> (interactive reviews, HRIs, milestones)\n&#8211; <strong>AWS Well-Architected Tool API<\/strong> (automation)\n&#8211; <strong>IAM<\/strong> for authentication\/authorization<\/p>\n\n\n\n<p>The service stores your workload review metadata and answers. You can share workloads with other principals\/accounts for collaboration.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (conceptual)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>User authenticates to AWS via IAM (or IAM Identity Center in many orgs).<\/li>\n<li>User opens AWS Well-Architected Tool in a chosen region.<\/li>\n<li>User creates a workload and selects one or more lenses.<\/li>\n<li>User answers lens questions; the service evaluates risk and flags HRIs.<\/li>\n<li>User generates reports\/improvement plan and captures milestones.<\/li>\n<li>Optional: automation via API lists workloads, exports results, enforces review cadence.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations and related services<\/h3>\n\n\n\n<p>Common integrations in real environments:\n&#8211; <strong>AWS IAM \/ IAM Identity Center:<\/strong> access control.\n&#8211; <strong>AWS Organizations:<\/strong> multi-account governance patterns.\n&#8211; <strong>AWS CloudTrail:<\/strong> audit API calls (who changed what).\n&#8211; <strong>AWS Service Quotas:<\/strong> track any service limits (verify quotas for this service).\n&#8211; <strong>Ticketing\/Backlog tools:<\/strong> not a native AWS integration, but teams commonly export improvement items and track them in Jira\/ADO\/GitHub Issues (manual or automated).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>AWS Well-Architected Tool itself is managed; you don\u2019t provision compute. The main \u201cdependencies\u201d are your identity and governance foundations:\n&#8211; IAM roles\/policies\n&#8211; Org structure (if used)\n&#8211; CloudTrail for auditing<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Uses <strong>AWS IAM<\/strong> for authentication and authorization.<\/li>\n<li>Access is controlled by IAM permissions to the Well-Architected Tool API actions and resource ARNs.<\/li>\n<li>Sharing workloads extends access to other principals\/accounts (within boundaries you control).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primarily accessed via the public AWS Console endpoints.<\/li>\n<li>API calls go to regional service endpoints over HTTPS.<\/li>\n<li>If you have strict egress requirements, validate endpoint behavior and corporate network allowlists. For private connectivity requirements, <strong>verify in official docs<\/strong> whether the service supports AWS PrivateLink\/VPC endpoints in your region (do not assume).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>AWS CloudTrail<\/strong> to log API actions for change tracking and audits.<\/li>\n<li>Use IAM Access Analyzer and periodic access reviews for principals who can share or modify workloads.<\/li>\n<li>Establish governance standards:<\/li>\n<li>Naming conventions for workloads<\/li>\n<li>Required tags (Owner, CostCenter, Environment, DataClassification)<\/li>\n<li>Review cadence and milestone frequency<\/li>\n<li>HRI remediation SLAs for tier-1 workloads<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Simple diagram (conceptual)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[Engineer \/ Architect] --&gt;|Console or API| WA[AWS Well-Architected Tool (Regional)]\n  WA --&gt; L[Lenses (AWS-provided + Custom)]\n  WA --&gt; R[Review Results\\nRisks \/ HRIs]\n  R --&gt; M[Milestones]\n  R --&gt; P[Improvement Plan \/ Reports]\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Production-style diagram (governed multi-account usage)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[AWS Organization]\n    A1[App Account(s)]\n    A2[Shared Services \/ Platform Account]\n    A3[Security \/ Audit Account]\n  end\n\n  IdP[IAM Identity Center \/ IAM Federation] --&gt; IAM[IAM Permissions &amp; Roles]\n\n  IAM --&gt; WA1[AWS Well-Architected Tool\\n(Region chosen by org)]\n  A1 --&gt;|Workload owners create\/update reviews| WA1\n  A2 --&gt;|Platform team contributes| WA1\n  A3 --&gt;|Security reviewers read\/verify| WA1\n\n  WA1 --&gt; CT[CloudTrail Logs]\n  CT --&gt; SIEM[Central log archive \/ SIEM\\n(optional)]\n\n  WA1 --&gt; EXP[Exports \/ Reports]\n  EXP --&gt; Repo[Internal repo or docs site\\n(optional)]\n  EXP --&gt; Backlog[Ticketing \/ backlog system\\n(manual or automated)]\n\n  classDef optional stroke-dasharray: 5 5;\n  class SIEM,Repo,Backlog optional;\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>AWS account<\/strong> with access to the AWS Management Console.<\/li>\n<li>If you work in a multi-account org, you may want:<\/li>\n<li>AWS Organizations configured<\/li>\n<li>A standard \u201cgovernance\u201d account strategy<\/li>\n<li>A chosen home region for reviews (for consistency and data residency)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need IAM permissions to use AWS Well-Architected Tool. AWS provides documentation and API action names. The safest approach is:\n&#8211; Start with broader access for lab usage (in a sandbox).\n&#8211; Tighten to least privilege for production.<\/p>\n\n\n\n<p><strong>Practical minimum for labs:<\/strong> ability to create and manage workloads in AWS Well-Architected Tool in a single region.<\/p>\n\n\n\n<p>If you do not have an AWS-managed policy available in your account, you can create a customer-managed policy. Example (broad for lab; tighten in production):<\/p>\n\n\n\n<pre><code class=\"language-json\">{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"WellArchitectedToolFullAccessForLab\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"wellarchitected:*\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n<\/code><\/pre>\n\n\n\n<p>For production, scope permissions to specific actions and resources; use CloudTrail to see required calls. <strong>Verify the latest IAM actions and resource ARN formats in the official API reference<\/strong>:<br\/>\nhttps:\/\/docs.aws.amazon.com\/wellarchitected\/latest\/APIReference\/Welcome.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Well-Architected Tool is generally advertised as <strong>no additional charge<\/strong> for using the tool itself (see Pricing section).<\/li>\n<li>You still need billing enabled for your AWS account.<\/li>\n<li>Indirect costs may exist for logging\/auditing exports and any remediation changes you implement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Optional but recommended for automation:<\/li>\n<li><strong>AWS CLI v2<\/strong> (configured with credentials and region)<\/li>\n<li>Python\/boto3 or other AWS SDKs (optional)<\/li>\n<li>Configure credentials:<\/li>\n<li><code>aws configure<\/code> (for local dev) or<\/li>\n<li>SSO\/IAM Identity Center auth flows (enterprise)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You must choose a region where AWS Well-Architected Tool is available.<\/li>\n<li>Standardize a region for your organization\u2019s reviews unless data residency requires otherwise.<\/li>\n<li>Verify: https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service quotas apply (for example, number of workloads, lenses, milestones, shares).<br\/>\nCheck <strong>Service Quotas<\/strong> in the AWS console and\/or the service documentation. Do not assume numeric limits without verification.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required to \u201crun\u201d the tool; it is managed.<\/li>\n<li>Recommended for governance:<\/li>\n<li>AWS CloudTrail enabled (ideally organization-wide)<\/li>\n<li>IAM Identity Center or strong IAM role governance for access control<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (accurate, non-fabricated)<\/h3>\n\n\n\n<p>AWS Well-Architected Tool is commonly documented by AWS as being provided <strong>at no charge<\/strong> for using the tool. However, always confirm using official sources because pricing and conditions can change.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary product page (commonly references pricing at a high level): https:\/\/aws.amazon.com\/well-architected\/<\/li>\n<li>User guide entry point: https:\/\/docs.aws.amazon.com\/wellarchitected\/latest\/userguide\/what-is-aws-well-architected-tool.html<\/li>\n<li>For broader estimation of related AWS costs, use AWS Pricing Calculator: https:\/\/calculator.aws\/<\/li>\n<\/ul>\n\n\n\n<p>If you need a contractual view for enterprise procurement, verify with AWS Sales or your AWS account team.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Direct cost for AWS Well-Architected Tool usage:<\/strong> Typically $0 (verify in official sources above).<\/li>\n<li><strong>Indirect costs:<\/strong> You may incur costs for:<\/li>\n<li><strong>CloudTrail<\/strong> management events logging and storage (S3, CloudWatch Logs) if you store\/retain logs.<\/li>\n<li>Any <strong>automation<\/strong> infrastructure you build (Lambda, Step Functions, EventBridge, ECS, etc.).<\/li>\n<li>Any <strong>remediation changes<\/strong> you implement in your workloads (for example, adding Multi-AZ databases, additional NAT gateways, extra logging, backups).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what actually changes your bill)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Increased resiliency often increases spend (multi-region, multi-AZ, backups).<\/li>\n<li>More logging and longer retention increases storage costs.<\/li>\n<li>Security controls (WAF, GuardDuty, Security Hub, KMS usage) may add cost.<\/li>\n<li>Performance improvements (caching, higher instance sizes, provisioned throughput) may add cost\u2014though can also reduce waste.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>People\/time cost:<\/strong> Reviews take engineering time; standardize to reduce overhead.<\/li>\n<li><strong>Governance overhead:<\/strong> Custom lenses and org-wide processes need ownership.<\/li>\n<li><strong>Tooling integration:<\/strong> Exporting and tracking HRIs may require custom scripts or pipelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The tool itself is metadata-driven; network costs are typically negligible.<\/li>\n<li>If exports are stored centrally or copied across regions\/accounts, data transfer and storage costs may apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (while using the tool)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat the tool as free governance, but optimize the remediation plan:<\/li>\n<li>Prioritize <strong>HRIs<\/strong> and high-impact improvements.<\/li>\n<li>Quantify cost impact of each remediation item (FinOps + architects).<\/li>\n<li>Use milestones to avoid \u201creview churn\u201d and focus on measurable improvements.<\/li>\n<li>Minimize operational overhead:<\/li>\n<li>Standardize tags and workload metadata.<\/li>\n<li>Use profiles\/custom lenses carefully to reduce duplicate work (verify availability in your environment).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate<\/h3>\n\n\n\n<p>A starter setup can be effectively <strong>$0 additional<\/strong> for the tool itself:\n&#8211; Use AWS Well-Architected Tool in one region.\n&#8211; Create a few workloads and milestones.\n&#8211; Keep exports local\/manual.\n&#8211; Ensure CloudTrail is already enabled (many accounts have it by default; org-wide trails may add S3 storage but are usually a standard security baseline anyway).<\/p>\n\n\n\n<p>Because exact costs depend on your existing CloudTrail\/logging setup and retention, do not assume a numeric estimate\u2014use the AWS Pricing Calculator for S3\/CloudWatch Logs retention scenarios.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In a mature environment:\n&#8211; CloudTrail organization trail + long retention in S3 Glacier can be a predictable baseline.\n&#8211; A centralized reporting pipeline (Lambda\/Step Functions + storage) adds modest monthly costs.\n&#8211; The bigger costs come from <strong>implementing<\/strong> recommendations:\n  &#8211; Multi-AZ and cross-region architectures\n  &#8211; More comprehensive monitoring and alerting\n  &#8211; Backup\/DR strategies\n  &#8211; Security services and encryption usage<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a workload in AWS Well-Architected Tool, run a basic Well-Architected review, identify HRIs, capture a milestone, export\/share results, and then clean up.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Confirm access and region selection.\n2. Create a workload with core metadata and tags.\n3. Apply the AWS Well-Architected Framework lens and answer a subset of questions.\n4. Review risks\/HRIs and create an improvement plan.\n5. Create a milestone snapshot.\n6. (Optional) Use AWS CLI to list workloads via the API.\n7. Validate results and clean up by deleting the workload.<\/p>\n\n\n\n<p>This lab is designed to be safe and low-cost because AWS Well-Architected Tool itself is typically no-charge (verify). You will not deploy any infrastructure.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Prepare IAM access and choose a region<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Sign in to the <strong>AWS Management Console<\/strong>.<\/li>\n<li>In the top-right region selector, choose a region where AWS Well-Architected Tool is available (many organizations standardize on one region).<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a chosen region selected and can navigate the console.<\/p>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Confirm you have permissions:\n   &#8211; If you can open the AWS Well-Architected Tool console and see the landing page, you likely have at least read access.\n   &#8211; If you see <code>AccessDeniedException<\/code>, you need an admin or IAM owner to grant <code>wellarchitected:*<\/code> (or a least-privilege set).<\/li>\n<\/ol>\n\n\n\n<p>Open the service: https:\/\/console.aws.amazon.com\/wellarchitected\/<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> The AWS Well-Architected Tool console loads without permission errors.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a workload<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In AWS Well-Architected Tool, choose <strong>Workloads<\/strong>.<\/li>\n<li>Choose <strong>Create workload<\/strong>.<\/li>\n<li>\n<p>Fill out key fields (names may vary slightly):\n   &#8211; <strong>Name:<\/strong> <code>wa-lab-webapp<\/code>\n   &#8211; <strong>Description:<\/strong> <code>Lab workload for learning AWS Well-Architected Tool<\/code>\n   &#8211; <strong>Environment:<\/strong> <code>Development<\/code> (or <code>Production<\/code> if you want to simulate prod governance)\n   &#8211; <strong>Review owner:<\/strong> your email or team alias\n   &#8211; <strong>AWS Regions:<\/strong> select the region(s) your workload uses (for the lab, select your current region)\n   &#8211; <strong>Industry type<\/strong> and other metadata: set what is appropriate for the lab<\/p>\n<\/li>\n<li>\n<p>Add tags (recommended even for a lab):\n   &#8211; <code>Owner = &lt;your-name-or-team&gt;<\/code>\n   &#8211; <code>Environment = lab<\/code>\n   &#8211; <code>System = wa-training<\/code><\/p>\n<\/li>\n<li>\n<p>Choose <strong>Create<\/strong>.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> A new workload named <code>wa-lab-webapp<\/code> appears in your workloads list.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Open the workload and confirm the metadata and tags are visible.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Add the AWS Well-Architected Framework lens and start a review<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open the workload.<\/li>\n<li>Find the <strong>Lenses<\/strong> section.<\/li>\n<li>\n<p>Ensure the <strong>AWS Well-Architected Framework<\/strong> lens is applied\/selected (often the default).<br\/>\n   &#8211; If the console asks you to select lenses, choose the AWS Well-Architected Framework lens.\n   &#8211; If you see additional AWS lenses, you may add them, but for this lab stick to the framework lens.<\/p>\n<\/li>\n<li>\n<p>Start the review and begin answering questions. For a quick lab pass:\n   &#8211; Pick <strong>one pillar<\/strong> (for example, Security or Reliability).\n   &#8211; Answer a handful of questions honestly for a simple web app:<\/p>\n<ul>\n<li>For items you have not implemented, choose the option that indicates a gap (this will likely produce risks\/HRIs).<\/li>\n<li>Add a short note explaining assumptions (example: \u201cThis is a dev workload; no DR implemented yet.\u201d)<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have saved answers to several questions and the workload review shows progress.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Navigate back to the pillar overview and confirm the answered count increased.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Review identified risks (including HRIs) and generate an improvement plan<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the workload, open the <strong>Risks<\/strong> view or the <strong>High risk issues (HRIs)<\/strong> view (naming may vary).<\/li>\n<li>Review the flagged items.<\/li>\n<li>\n<p>For at least one HRI:\n   &#8211; Open the question.\n   &#8211; Read the recommended best practices.\n   &#8211; Add a note describing a remediation task (example: \u201cEnable centralized logging and define alerting for authentication failures.\u201d)\n   &#8211; If your workflow supports it, mark an owner or priority (options vary).<\/p>\n<\/li>\n<li>\n<p>Generate an improvement plan or report using the console option available (for example \u201cImprovement plan\u201d and\/or \u201cExport\/Download report\u201d).<br\/>\n   &#8211; If export formats (PDF\/JSON\/CSV) are offered, choose one suitable for your process.\n   &#8211; If you do not see export options in your region\/account, skip export and proceed\u2014feature availability can vary. <strong>Verify in official docs<\/strong>.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can see a prioritized list of risks\/HRIs and have a tangible output (improvement plan\/report) or at least a visible set of actionable items in the console.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Confirm at least one risk\/HRI is visible (if you answered in a way that indicates gaps).\n&#8211; Confirm notes were saved.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create a milestone snapshot<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the workload, find <strong>Milestones<\/strong>.<\/li>\n<li>Choose <strong>Create milestone<\/strong>.<\/li>\n<li>Enter:\n   &#8211; <strong>Milestone name:<\/strong> <code>baseline-review<\/code>\n   &#8211; <strong>Description:<\/strong> <code>Initial lab baseline review<\/code><\/li>\n<li>Create the milestone.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> A milestone named <code>baseline-review<\/code> appears, capturing the current review state.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Open the milestone and confirm it is tied to the workload and includes the review snapshot details.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6 (Optional): Use AWS CLI to confirm API access and list workloads<\/h3>\n\n\n\n<p>This is optional but useful for automation-oriented teams.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Ensure AWS CLI v2 is installed:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws --version\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Ensure you are authenticated and have a default region set (the same region you used in the console):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws configure list\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>List workloads (API names and output depend on AWS CLI version; verify the command group exists for your CLI build):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws wellarchitected list-workloads\n<\/code><\/pre>\n\n\n\n<p>If you use named profiles:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws --profile yourprofile --region us-east-1 wellarchitected list-workloads\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The CLI returns a list including <code>wa-lab-webapp<\/code>.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Confirm the workload name\/id appears in output.<\/p>\n\n\n\n<p><strong>Common issue:<\/strong> If the CLI says the command group doesn\u2019t exist, update AWS CLI v2 and verify that <code>wellarchitected<\/code> commands are available for your version. Also confirm you\u2019re using the correct region.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist to confirm the lab succeeded:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You can open the workload <code>wa-lab-webapp<\/code>.<\/li>\n<li>At least one pillar shows answered questions.<\/li>\n<li>The workload shows identified risks (and likely HRIs if you selected \u201cnot implemented\u201d style answers).<\/li>\n<li>A milestone named <code>baseline-review<\/code> exists.<\/li>\n<li>(Optional) <code>aws wellarchitected list-workloads<\/code> returns your workload.<\/li>\n<\/ul>\n\n\n\n<p>For deeper validation in governed environments:\n&#8211; Check <strong>AWS CloudTrail<\/strong> for <code>wellarchitected.amazonaws.com<\/code> events corresponding to workload creation\/updates (exact event names vary).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p><strong>1) AccessDenied \/ insufficient permissions<\/strong>\n&#8211; Symptom: Console shows permission errors, or API calls fail.\n&#8211; Fix:\n  &#8211; Ensure your role\/user has required <code>wellarchitected:*<\/code> actions (or least-privilege set).\n  &#8211; Verify permission boundaries\/SCPs in AWS Organizations aren\u2019t blocking the service.<\/p>\n\n\n\n<p><strong>2) Workload not visible after creation<\/strong>\n&#8211; Symptom: You created a workload but can\u2019t find it.\n&#8211; Fix:\n  &#8211; Confirm you are in the same <strong>AWS region<\/strong> where you created it.\n  &#8211; Confirm you\u2019re in the same AWS account (or the workload was shared to you).<\/p>\n\n\n\n<p><strong>3) Cannot share workload<\/strong>\n&#8211; Symptom: Sharing fails or invitation cannot be accepted.\n&#8211; Fix:\n  &#8211; Verify both accounts\/roles have necessary permissions.\n  &#8211; Confirm any org SCPs allow required Well-Architected actions.<\/p>\n\n\n\n<p><strong>4) CLI commands not found<\/strong>\n&#8211; Symptom: <code>aws: error: argument ... invalid choice<\/code>\n&#8211; Fix:\n  &#8211; Upgrade AWS CLI v2.\n  &#8211; Verify service command group availability for your installed version.\n  &#8211; Check the AWS CLI reference and the service API reference.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid cluttering your governance inventory:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In AWS Well-Architected Tool, open <code>wa-lab-webapp<\/code>.<\/li>\n<li>Remove sharing (if you shared it) to revoke access.<\/li>\n<li>Delete milestones if required by your org process (some workflows delete with workload; verify behavior).<\/li>\n<li>Choose <strong>Delete workload<\/strong>.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> The workload no longer appears in the workloads list.<\/p>\n\n\n\n<p>If you created a customer-managed IAM policy for the lab:\n&#8211; Detach it from users\/roles and delete it (only if it\u2019s not used elsewhere).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices (using the tool effectively)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Treat workload reviews as living artifacts:<\/strong> Update reviews after major architectural changes, incidents, or migrations.<\/li>\n<li><strong>Define workload boundaries clearly:<\/strong> One workload should represent a cohesive system with a clear owner.<\/li>\n<li><strong>Use milestones strategically:<\/strong><\/li>\n<li><code>baseline<\/code><\/li>\n<li><code>pre-launch<\/code><\/li>\n<li><code>post-launch-30d<\/code><\/li>\n<li><code>quarterly-review-YYYY-Q#<\/code><\/li>\n<li><strong>Focus on HRIs first:<\/strong> HRIs are designed to highlight the highest-priority gaps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>role-based access<\/strong> over long-lived IAM users.<\/li>\n<li>Grant least privilege:<\/li>\n<li>Separate roles for <strong>read-only reviewers<\/strong> vs <strong>workload editors<\/strong>.<\/li>\n<li>Restrict who can <strong>share workloads<\/strong> externally\/cross-account.<\/li>\n<li>Use AWS Organizations SCPs carefully:<\/li>\n<li>Don\u2019t block required governance tools, but limit risky actions in production accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use the tool to find cost inefficiencies, but evaluate recommendations with FinOps:<\/li>\n<li>Some reliability\/security improvements increase spend.<\/li>\n<li>Some performance improvements reduce spend via right-sizing and caching.<\/li>\n<li>Export improvement items and estimate cost impact per item before implementation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use review outcomes to drive:<\/li>\n<li>Load testing strategy<\/li>\n<li>Observability improvements (metrics, traces, logs)<\/li>\n<li>Scaling model selection (horizontal\/vertical, caching, async processing)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Tie HRI remediation to reliability targets:<\/li>\n<li>RTO\/RPO<\/li>\n<li>Error budgets<\/li>\n<li>Dependency mapping<\/li>\n<li>Use milestones to verify reliability posture improves after changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize an operating model:<\/li>\n<li>Who runs reviews (owner + architect + security)<\/li>\n<li>How often<\/li>\n<li>How HRIs translate into backlog items<\/li>\n<li>How completion is verified (milestone + evidence links)<\/li>\n<li>Keep notes actionable:<\/li>\n<li>Link to runbooks\/design docs (store links, not secrets).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent workload naming, e.g.:<\/li>\n<li><code>&lt;businessunit&gt;-&lt;system&gt;-&lt;env&gt;<\/code> \u2192 <code>payments-api-prod<\/code><\/li>\n<li>Standardize tags:<\/li>\n<li><code>Owner<\/code>, <code>Team<\/code>, <code>CostCenter<\/code>, <code>Environment<\/code>, <code>Criticality<\/code>, <code>DataClassification<\/code><\/li>\n<li>Define review SLAs:<\/li>\n<li>Tier-0\/Tier-1 workloads must have a milestone within 90 days<\/li>\n<li>HRIs must be addressed within X days (organizational policy)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Well-Architected Tool uses <strong>IAM-based authorization<\/strong>.<\/li>\n<li>Key security controls:<\/li>\n<li>Restrict write access to workload owners\/architects.<\/li>\n<li>Use read-only roles for auditors and stakeholders.<\/li>\n<li>Control sharing permissions to prevent unintended exposure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data is accessed over HTTPS\/TLS.<\/li>\n<li>For encryption at rest, AWS services typically use service-managed mechanisms; confirm specifics in the service security documentation. <strong>Verify in official docs<\/strong> for exact encryption\/KMS details applicable to AWS Well-Architected Tool.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Console and API are accessed via AWS regional endpoints over the internet.<\/li>\n<li>If you have strict network controls:<\/li>\n<li>Maintain allowlists for AWS console\/service endpoints.<\/li>\n<li>Verify whether private connectivity options (e.g., PrivateLink) exist for your region\/service\u2014do not assume.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not store secrets in:<\/li>\n<li>Workload descriptions<\/li>\n<li>Question notes<\/li>\n<li>Improvement plan exports<\/li>\n<li>Instead:<\/li>\n<li>Reference secret locations (e.g., \u201cstored in Secrets Manager under standard naming\u201d), without including secret values.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and retain <strong>CloudTrail<\/strong> logs for governance:<\/li>\n<li>Identify who created\/edited workloads and milestones.<\/li>\n<li>Track sharing actions.<\/li>\n<li>Centralize logs in a dedicated security account when operating at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Well-Architected Tool can support governance evidence (process evidence), but:<\/li>\n<li>It does not replace compliance tooling such as AWS Audit Manager or GRC platforms.<\/li>\n<li>Treat it as part of a broader control framework.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Over-permissive IAM policies granting <code>wellarchitected:*<\/code> to all developers in production accounts.<\/li>\n<li>Allowing unrestricted sharing without approvals.<\/li>\n<li>Storing internal architecture details that violate internal data classification rules.<\/li>\n<li>Treating tool outputs as \u201ccertification\u201d rather than guidance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations (practical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create separate roles:<\/li>\n<li><code>WellArchitectedReviewerReadOnly<\/code><\/li>\n<li><code>WellArchitectedWorkloadEditor<\/code><\/li>\n<li><code>WellArchitectedAdmin<\/code> (restricted)<\/li>\n<li>Require tags for ownership and data classification.<\/li>\n<li>Require milestones before production launch for critical workloads.<\/li>\n<li>Review shared workload access quarterly.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because AWS services evolve, confirm details in the latest docs. Common gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional nature:<\/strong> Workloads are managed in the region you select. Teams often \u201close\u201d workloads by switching regions in the console.<\/li>\n<li><strong>Not a remediation engine:<\/strong> The tool highlights issues but does not automatically fix infrastructure.<\/li>\n<li><strong>Quotas exist:<\/strong> Limits on workloads, milestones, lenses, shares, etc. Use Service Quotas and official docs to confirm.<\/li>\n<li><strong>Consistency requires process:<\/strong> Without organizational standards (naming, tagging, cadence), the tool becomes a set of one-off reviews.<\/li>\n<li><strong>Lens updates over time:<\/strong> AWS may update lens content; treat reviews as periodic, not once-and-done.<\/li>\n<li><strong>Export\/report expectations:<\/strong> Report formats and export options can vary; don\u2019t build fragile automation without validating outputs in your environment.<\/li>\n<li><strong>Sharing governance:<\/strong> Sharing is powerful but can create unintended access paths if not controlled.<\/li>\n<li><strong>Notes can become stale:<\/strong> Encourage teams to update notes when architecture changes; stale rationale is a common source of confusion.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>AWS Well-Architected Tool is a governance\/review workflow. Alternatives vary: some provide operational checks, some provide compliance evidence, and some are manual processes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>AWS Well-Architected Tool<\/strong><\/td>\n<td>Structured architecture reviews on AWS<\/td>\n<td>Framework-aligned questions, HRIs, milestones, sharing, API automation<\/td>\n<td>Does not auto-remediate; requires process discipline; regional context<\/td>\n<td>You need repeatable architecture reviews and governance artifacts<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Trusted Advisor<\/strong><\/td>\n<td>Continuous best-practice checks for AWS accounts<\/td>\n<td>Automated checks; quick wins; integrates with support plans<\/td>\n<td>Scope is checks-based; not a full review workflow<\/td>\n<td>You want automated account-level checks alongside reviews<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Config<\/strong><\/td>\n<td>Configuration recording and compliance rules<\/td>\n<td>Detect drift; enforce policies; evidence<\/td>\n<td>Requires setup; not an architecture review framework<\/td>\n<td>You need continuous compliance\/drift detection and policy enforcement<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Security Hub<\/strong><\/td>\n<td>Security posture aggregation and findings<\/td>\n<td>Central security findings; standards alignment<\/td>\n<td>Security-focused; not full architecture review<\/td>\n<td>You need continuous security visibility and findings management<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Audit Manager<\/strong><\/td>\n<td>Audit evidence collection<\/td>\n<td>Evidence automation and reporting<\/td>\n<td>Audit-focused; not architecture decision guidance<\/td>\n<td>You need compliance evidence collection and audit readiness<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Control Tower<\/strong><\/td>\n<td>Landing zone governance<\/td>\n<td>Guardrails, account factory, baseline controls<\/td>\n<td>Not an architecture review tool<\/td>\n<td>You need multi-account governance foundations<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Advisor (Microsoft Azure)<\/strong><\/td>\n<td>Best-practice recommendations in Azure<\/td>\n<td>Automated recommendations<\/td>\n<td>Azure-specific; different framework<\/td>\n<td>You are primarily on Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Active Assist \/ Architecture Framework guidance<\/strong><\/td>\n<td>Recommendations in Google Cloud<\/td>\n<td>Automated insights and guidance<\/td>\n<td>GCP-specific; different workflow<\/td>\n<td>You are primarily on GCP<\/td>\n<\/tr>\n<tr>\n<td><strong>Manual checklists \/ spreadsheets \/ internal review boards<\/strong><\/td>\n<td>Cloud-agnostic reviews<\/td>\n<td>Fully customizable; no vendor dependency<\/td>\n<td>Hard to scale; inconsistent; limited audit trail unless engineered<\/td>\n<td>You need cloud-agnostic governance and can invest in internal tooling<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Regulated multi-account organization standardizing governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services company has 200+ AWS accounts. Architecture reviews are inconsistent across teams, and auditors want evidence of ongoing oversight for critical workloads.<\/li>\n<li><strong>Proposed architecture (process architecture):<\/strong><\/li>\n<li>Standardize one region for AWS Well-Architected Tool reviews.<\/li>\n<li>Use AWS Organizations and IAM roles to separate:<ul>\n<li>Workload owners (edit)<\/li>\n<li>Central architects (review\/edit)<\/li>\n<li>Security auditors (read-only)<\/li>\n<\/ul>\n<\/li>\n<li>Require:<ul>\n<li>A baseline milestone for every tier-1 workload<\/li>\n<li>Quarterly milestone updates<\/li>\n<li>HRI remediation tracking in the corporate backlog tool (export + ticket creation)<\/li>\n<\/ul>\n<\/li>\n<li>Use CloudTrail centralized logging for auditability.<\/li>\n<li><strong>Why AWS Well-Architected Tool was chosen:<\/strong><\/li>\n<li>Aligns directly to AWS Well-Architected Framework.<\/li>\n<li>Provides milestones and a consistent review structure.<\/li>\n<li>Enables controlled sharing for cross-team reviews.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Consistent review process across accounts.<\/li>\n<li>Reduced production risk due to prioritized HRI remediation.<\/li>\n<li>Clear audit trail of review cadence and improvements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Rapid growth with minimal governance overhead<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup\u2019s AWS footprint grows quickly (serverless APIs + managed databases). Incidents increase due to missing operational processes and unclear ownership.<\/li>\n<li><strong>Proposed architecture (process architecture):<\/strong><\/li>\n<li>Create one workload per product domain.<\/li>\n<li>Run a review before each major release.<\/li>\n<li>Use milestones: <code>pre-release<\/code> and <code>post-release<\/code>.<\/li>\n<li>Track HRIs in GitHub Issues with a simple label convention.<\/li>\n<li><strong>Why AWS Well-Architected Tool was chosen:<\/strong><\/li>\n<li>Lightweight and typically no-charge for the tool.<\/li>\n<li>Provides immediate structure without building internal governance software.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster identification of reliability and security gaps.<\/li>\n<li>Better engineering habits (monitoring, runbooks, backups).<\/li>\n<li>Reduced incident rate as high-risk items are addressed systematically.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is AWS Well-Architected Tool the same as the AWS Well-Architected Framework?<\/strong><br\/>\nNo. The Framework is the set of principles and pillars; AWS Well-Architected Tool is the managed service that helps you run reviews using lenses based on the framework.<\/p>\n\n\n\n<p>2) <strong>Does AWS Well-Architected Tool deploy or change AWS resources?<\/strong><br\/>\nNo. It records review information and recommendations. You implement changes in your own workloads.<\/p>\n\n\n\n<p>3) <strong>Is AWS Well-Architected Tool free?<\/strong><br\/>\nAWS commonly states the tool is provided at no additional charge. Always verify current pricing statements on official AWS pages: https:\/\/aws.amazon.com\/well-architected\/<\/p>\n\n\n\n<p>4) <strong>Is AWS Well-Architected Tool regional or global?<\/strong><br\/>\nIt is a regional service in practice (you select a region). Standardize a region for your organization unless you have data residency requirements.<\/p>\n\n\n\n<p>5) <strong>What is a \u201cworkload\u201d in the tool?<\/strong><br\/>\nA workload is the unit you review\u2014typically an application, platform component, or system with an owner and defined scope.<\/p>\n\n\n\n<p>6) <strong>What is a \u201clens\u201d?<\/strong><br\/>\nA lens is a set of questions and best practices for a particular perspective (the core lens is the AWS Well-Architected Framework lens). You can also create custom lenses.<\/p>\n\n\n\n<p>7) <strong>What are HRIs (High-Risk Issues)?<\/strong><br\/>\nHRIs are the highest priority risks identified based on your answers, intended to help teams focus remediation efforts.<\/p>\n\n\n\n<p>8) <strong>Can I create custom lenses for internal standards?<\/strong><br\/>\nYes, AWS Well-Architected Tool supports custom lenses. Establish governance for lens ownership, versioning, and quality.<\/p>\n\n\n\n<p>9) <strong>Can I share a workload review with another AWS account or team?<\/strong><br\/>\nThe tool supports sharing for collaboration. Use least privilege and review shared access periodically.<\/p>\n\n\n\n<p>10) <strong>Can I automate reporting across many workloads?<\/strong><br\/>\nYes. Use the AWS Well-Architected Tool API to list workloads, retrieve reviews, and build internal reporting. API reference: https:\/\/docs.aws.amazon.com\/wellarchitected\/latest\/APIReference\/Welcome.html<\/p>\n\n\n\n<p>11) <strong>How often should we run reviews?<\/strong><br\/>\nCommon patterns: pre-launch, after major architecture changes, after incidents, and quarterly for critical workloads. Choose a cadence aligned to workload criticality.<\/p>\n\n\n\n<p>12) <strong>Does the tool integrate directly with Jira\/ServiceNow?<\/strong><br\/>\nNot as a guaranteed native integration. Many teams export improvement items and create tickets manually or with custom automation.<\/p>\n\n\n\n<p>13) <strong>Should we store sensitive data in review notes?<\/strong><br\/>\nNo. Avoid secrets and sensitive identifiers in notes. Reference secured documents\/locations instead.<\/p>\n\n\n\n<p>14) <strong>How do milestones help?<\/strong><br\/>\nMilestones snapshot your review state so you can prove progress, compare changes over time, and avoid losing historical context.<\/p>\n\n\n\n<p>15) <strong>Can we use AWS Well-Architected Tool for non-AWS workloads?<\/strong><br\/>\nThe framework is AWS-oriented, and the tool is an AWS service. You can document conceptual architectures, but it is best suited for workloads running on AWS.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS Well-Architected Tool<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS Well-Architected Tool User Guide<\/td>\n<td>Core concepts, workflows, and definitions<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS Well-Architected Tool \u2013 \u201cWhat is\u2026\u201d<\/td>\n<td>Quick orientation and scope<\/td>\n<\/tr>\n<tr>\n<td>API reference<\/td>\n<td>AWS Well-Architected Tool API Reference<\/td>\n<td>Required for automation, IAM scoping, and integrations<\/td>\n<\/tr>\n<tr>\n<td>Framework<\/td>\n<td>AWS Well-Architected Framework<\/td>\n<td>Explains pillars, design principles, and best practices behind the tool<\/td>\n<\/tr>\n<tr>\n<td>Landing page<\/td>\n<td>AWS Well-Architected (product page)<\/td>\n<td>High-level overview and current references (also check pricing statements)<\/td>\n<\/tr>\n<tr>\n<td>Regional availability<\/td>\n<td>AWS Regional Services List<\/td>\n<td>Validate region availability and planning<\/td>\n<\/tr>\n<tr>\n<td>Pricing estimation<\/td>\n<td>AWS Pricing Calculator<\/td>\n<td>Estimate indirect costs (logging, automation, remediation)<\/td>\n<\/tr>\n<tr>\n<td>Videos<\/td>\n<td>AWS YouTube Channel (search \u201cWell-Architected Tool\u201d)<\/td>\n<td>Walkthroughs, demos, and best-practice talks (verify recency)<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>AWS Architecture Center<\/td>\n<td>Patterns and reference architectures to implement improvements<\/td>\n<\/tr>\n<tr>\n<td>Governance<\/td>\n<td>AWS Organizations documentation<\/td>\n<td>Useful for multi-account governance patterns that pair with reviews<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<p>Direct links:\n&#8211; User Guide: https:\/\/docs.aws.amazon.com\/wellarchitected\/latest\/userguide\/what-is-aws-well-architected-tool.html<br\/>\n&#8211; API Reference: https:\/\/docs.aws.amazon.com\/wellarchitected\/latest\/APIReference\/Welcome.html<br\/>\n&#8211; AWS Well-Architected Framework: https:\/\/docs.aws.amazon.com\/wellarchitected\/latest\/framework\/welcome.html<br\/>\n&#8211; AWS Well-Architected (landing): https:\/\/aws.amazon.com\/well-architected\/<br\/>\n&#8211; AWS Architecture Center: https:\/\/aws.amazon.com\/architecture\/<br\/>\n&#8211; AWS Pricing Calculator: https:\/\/calculator.aws\/  <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following providers may offer training related to AWS, cloud architecture, DevOps, SRE, and governance. Verify current course syllabi and delivery modes on their websites.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, architects, SREs, platform teams<\/td>\n<td>AWS\/DevOps practices, governance, operational readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Engineers and managers<\/td>\n<td>DevOps, SCM, cloud fundamentals and practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud\/ops practitioners<\/td>\n<td>Cloud operations, automation, governance concepts<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations, reliability engineers<\/td>\n<td>Reliability, incident management, operational excellence<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops\/SRE and automation teams<\/td>\n<td>AIOps concepts, monitoring\/automation practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites are presented as training resources\/platforms (verify current offerings and credentials on each site).<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify scope)<\/td>\n<td>Engineers, DevOps learners<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps and cloud training (verify course list)<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps services\/training (verify offerings)<\/td>\n<td>Teams seeking hands-on help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify scope)<\/td>\n<td>Ops\/DevOps practitioners<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These organizations may provide consulting related to AWS, DevOps, cloud governance, and architecture reviews. Verify service details and case studies directly with each company.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact offerings)<\/td>\n<td>Architecture reviews, delivery enablement, platform guidance<\/td>\n<td>Set up an architecture review program; operational readiness improvements<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps\/cloud consulting and training (verify exact offerings)<\/td>\n<td>DevOps transformation, governance processes, skills enablement<\/td>\n<td>Implement review cadence; build automation around reporting<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact offerings)<\/td>\n<td>CI\/CD, automation, reliability practices<\/td>\n<td>Convert HRIs into remediation roadmap; improve incident response workflows<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before AWS Well-Architected Tool<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS fundamentals: IAM, VPC basics, EC2, S3, RDS, Lambda<\/li>\n<li>Core operational services: CloudWatch, CloudTrail<\/li>\n<li>Basic architecture concepts: availability, fault tolerance, scaling, backups<\/li>\n<li>Security essentials: least privilege, encryption basics, logging\/auditing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after AWS Well-Architected Tool<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Implementing recommendations with AWS services:<\/li>\n<li>Reliability: Multi-AZ patterns, DR strategies, backup\/restore testing<\/li>\n<li>Security: Security Hub, GuardDuty, IAM Access Analyzer, KMS patterns<\/li>\n<li>Operations: Observability (metrics\/logs\/traces), incident response, runbooks<\/li>\n<li>Cost: tagging strategy, budgets, cost allocation, right-sizing<\/li>\n<li>Governance at scale:<\/li>\n<li>AWS Organizations and Control Tower (landing zones)<\/li>\n<li>AWS Config rules and conformance packs<\/li>\n<li>Policy-as-code approaches (IaC + guardrails)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Solutions Architect \/ Cloud Architect<\/li>\n<li>DevOps Engineer \/ Platform Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Security Engineer \/ Cloud Security Architect<\/li>\n<li>Cloud Governance \/ FinOps practitioner<\/li>\n<li>Technical Program Manager (architecture governance programs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>AWS certifications change over time; verify current names and paths on the official AWS Training and Certification site: https:\/\/aws.amazon.com\/certification\/<br\/>\nTypical relevant cert tracks include:\n&#8211; Architect-focused certifications (associate\/professional)\n&#8211; Security specialty (if applicable)\n&#8211; DevOps engineer-focused certifications<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a portfolio of 5 workloads and run baseline reviews for each.<\/li>\n<li>Create a custom lens representing your team\u2019s production readiness checklist.<\/li>\n<li>Build a small script using the API to:<\/li>\n<li>list workloads<\/li>\n<li>detect workloads without a milestone in the last N days (time-based governance)<\/li>\n<li>export a simple report to CSV for leadership<\/li>\n<li>Run a \u201cgame day\u201d and then update the review based on lessons learned, capturing a milestone.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Well-Architected Framework:<\/strong> AWS\u2019s set of architectural best practices organized into pillars (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability).  <\/li>\n<li><strong>AWS Well-Architected Tool:<\/strong> The AWS managed service that helps you conduct and track Well-Architected reviews using lenses.<\/li>\n<li><strong>Workload:<\/strong> A reviewed system\/application entity in the tool.<\/li>\n<li><strong>Lens:<\/strong> A question set used to evaluate a workload (AWS-provided or custom).<\/li>\n<li><strong>Pillar:<\/strong> A best-practice domain in the framework (e.g., Security, Reliability).<\/li>\n<li><strong>Best practice:<\/strong> Recommended design or operational approach represented in lens questions.<\/li>\n<li><strong>Risk level:<\/strong> Severity\/priority categorization derived from answers.<\/li>\n<li><strong>HRI (High-Risk Issue):<\/strong> A top-priority risk flagged by the tool based on answers.<\/li>\n<li><strong>Milestone:<\/strong> A point-in-time snapshot of a workload review used for tracking progress.<\/li>\n<li><strong>Sharing:<\/strong> Granting other principals\/accounts access to a workload review for collaboration.<\/li>\n<li><strong>IAM (Identity and Access Management):<\/strong> AWS service controlling authentication and authorization for the tool.<\/li>\n<li><strong>CloudTrail:<\/strong> AWS auditing service that logs API activity (useful for governance evidence).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>AWS Well-Architected Tool (AWS) is a Management and governance service that helps teams run consistent architecture reviews using AWS best practices. It matters because it turns the AWS Well-Architected Framework into an actionable, repeatable process: define workloads, answer lens questions, prioritize HRIs, and track progress using milestones.<\/p>\n\n\n\n<p>Cost-wise, the tool itself is typically provided at no additional charge (verify on official AWS pages), but implementing recommendations can change your AWS bill\u2014especially for resilience, logging, and security controls. Security-wise, use IAM least privilege, control workload sharing, and rely on CloudTrail for auditability.<\/p>\n\n\n\n<p>Use AWS Well-Architected Tool when you need structured reviews, governance evidence, and portfolio-level consistency. Combine it with operational services (CloudWatch, Config, Security Hub) to implement and sustain improvements. Next, learn to automate reviews and reporting with the AWS Well-Architected Tool API and integrate the improvement plan into your engineering backlog and governance cadence.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Management and governance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,33],"tags":[],"class_list":["post-272","post","type-post","status-publish","format-standard","hentry","category-aws","category-management-and-governance"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/272","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=272"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/272\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}