AWS Well-Architected Review - how to prepare and what we actually review

What is an AWS Well-Architected Review

WAFR is a structured review of your AWS cloud architecture based on 6 pillars:

1. Operational Excellence - how you manage and monitor systems
2. Security - protecting data, credentials, and infrastructure
3. Reliability - resilience to failure, recovery from incidents
4. Performance Efficiency - effective use of compute resources
5. Cost Optimisation - eliminating waste, aligning spend to value
6. Sustainability - minimising environmental impact

The review is conducted by a certified AWS Partner (like Devopsity - in the programme since 2024). Results are recorded in the AWS Well-Architected Tool, where AWS can see them and offer incentives (currently a 10% discount on resources linked to remediation work).

The problem with “typical” WAFR

Let’s be direct: many Well-Architected Reviews in the industry are theatre. Here’s why:

A 2-3 hour review. The partner races through the questionnaire, ticks answers in the tool, and generates a report. Zero depth, zero business context.

Focus on HRI count, not impact. Until late 2025, AWS offered a $5,000 credit coupon for remediation if a review found ≥45% high-risk items. This created a pathology: partners and clients optimised for HRI count (to get the coupon), not for actual risk.

Reports without actionable recommendations. “We recommend implementing Multi-AZ” - with no context on whether that makes sense for a dev environment costing $200/month.

No connection to business priorities. The standard WAFR asks about technical best practices but doesn’t tie them to business priorities: what’s critical to revenue, what blocks regulatory compliance, what generates the highest cost.

What a proper WAFR should look like

Preparation (before the review)

Before the partner shows up to the first meeting, they should know:

From you:

• Architecture - a diagram (even drawn on a napkin), list of key AWS services, number of environments
• Priorities - what matters more: cost, security, reliability? Where does it hurt most?
• Regulatory context - are you subject to SOC 2, ISO 27001, NIS2, PCI DSS?
• Planned changes - migration, scaling, new product? This shifts the review perspective

Documents to prepare:

• Access to AWS accounts (a read-only IAM role is sufficient for the review)
• List of people for interviews (architect, ops/SRE, security, finance)
• Existing architecture documentation (if any)
• Last 12 months of AWS billing (Cost Explorer export - ideally)

The review process

What you get at the end

1. Report with prioritised findings - each item with business impact assessment and remediation effort estimate
2. AWS WA Tool update - findings officially recorded, visible to AWS
3. Remediation plan - top 5-10 findings with specific steps to execute
4. Qualification for 10% discount - after implementing fixes, AWS offers a discount on related resources

Where the standard WAFR falls short

The standard review covers breadth - 6 pillars, hundreds of questions, a general picture. But for most organisations the problem isn’t “lack of knowledge about everything” - it’s depth in one specific area.

Typical situations:

• A CTO says: “our AWS bill grows 20% per quarter and nobody knows why” - they need a deep cost analysis, not the generic Cost Optimisation pillar
• A team is preparing for 10x traffic on Black Friday - they need full reliability and scale-readiness analysis, not the question “do you have Multi-AZ?”
• A company faces a SOC 2 audit in 3 months - they need detailed security analysis with control mapping, not a list of HRIs

That’s why we extend the standard WAFR with focused deep-dive reviews - concentrated on one area but much deeper than the standard pillar.

FinOps deep-dive - when the bill is problem number one

The standard Cost Optimisation pillar asks: “do you use Savings Plans?”, “do you monitor unused resources?”. Important questions, but they don’t answer: where exactly is money leaking and why.

Our FinOps deep-dive covers:

Billing analysis (not just Cost Explorer)

# Export detailed billing for 12 months
aws ce get-cost-and-usage \
  --time-period Start=2025-06-01,End=2026-06-01 \
  --granularity MONTHLY \
  --metrics BlendedCost UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output json > billing-12mo.json

# Identify top 5 fastest-growing services
jq '.ResultsByTime | map(.Groups[] | {service: .Keys[0], cost: .Metrics.BlendedCost.Amount}) | group_by(.service) | map({service: .[0].service, costs: map(.cost | tonumber)})' billing-12mo.json

Mapping costs to business intent

Every dollar spent on AWS should be traceable to business value. We create a map:

Architectural sources of excessive cost

We don’t just look for oversized instances. We look for architectural patterns generating disproportionate cost:

• Data transfer through NAT Gateway instead of VPC Endpoints
• Log retention in CloudWatch instead of S3 + Athena
• Multi-AZ databases on non-production environments
• Missing Spot Instances on interruption-tolerant workload
• Savings Plans purchased for wrong instance types or regions

Result: not “save 5% through right-sizing” but “save 30-40% by changing architectural patterns”.

More on our FinOps approach in the showback model implementation guide.

Reliability deep-dive - production readiness at scale

The standard Reliability pillar asks: “do you have backups?”, “do you test recovery?”. Our deep-dive goes further:

Identifying single points of failure (SPOF)

We map every architecture component for: what happens if this stops working?

Self-hosted vs managed - decision review

For every self-hosted component we assess: is running it yourself justified, or just historical? Typical findings:

• Self-hosted Redis → ElastiCache (HA + backup for $50/mo more, but no SPOF risk)
• Self-hosted Jenkins → GitHub Actions (zero maintenance, auto-scaling)
• Self-hosted Prometheus → Grafana Cloud (no OOM, no storage management)

Detailed comparison of managed vs self-managed in our managed services guide.

Load testing - not “whether” but “how”

We don’t ask “do you do load testing?”. We ask:

• What’s your target traffic for Black Friday / peak season?
• Does the architecture scale linearly or hit a cliff?
• Where’s the bottleneck: database, compute, network, API rate limit?
• Have you had a performance incident before? What caused it?

Security deep-dive - governance, network, data

The standard Security pillar asks: “do you encrypt data?”, “do you have MFA?”. Our deep-dive covers:

Organisation-level governance

• AWS Organizations - account structure, SCP policies, environment separation
• IAM Identity Center (SSO) - configuration, assignments, least privilege compliance
• Config Rules and conformance packs - automated drift detection
• CloudTrail - centralised logging, access analysis, anomaly detection

Network security

• VPC design: segmentation, Security Groups, NACLs, ingress/egress rules
• Public access: which resources are internet-facing and should they be?
• Outbound connections: is egress traffic controlled and monitored?

Data protection

• Encryption at rest and in transit
• Key management (KMS): rotation policies, access policies, audit
• Data classification: what’s sensitive, where is it, who has access

Compliance readiness

If you’re preparing for SOC 2, ISO 27001, NIS2, or DORA - we map findings directly to required controls:

How to choose the scope of your review

Not every organisation needs a deep-dive in all three areas simultaneously. Choose based on your current situation:

What happens after the review

A review without action is wasted time. Here’s how we ensure results translate to real change:

1. Immediate fixes (week 1-2) - top 3-5 HRIs we can fix straight away (e.g. disable Multi-AZ on staging, add VPC Endpoints, enable KMS rotation)
2. 30-60-90 day remediation plan - remaining findings with timeline and assigned owner
3. Milestone in AWS WA Tool - after each batch of fixes we create a milestone documenting progress
4. Discount qualification - AWS offers 10% off resources directly linked to remediation. We track this for you
5. Next cycle - WAFR isn’t a one-off. We recommend the next review in 3-6 months

Our perspective

At Devopsity we’ve been running Well-Architected Reviews since 2024. We’ve seen that the standard WAFR delivers value as a starting point - but real change comes from focused deep-dives targeting a specific pain: costs, reliability, or security.

If your AWS environment needs a review - whether a standard WAFR or a focused deep-dive in a specific area - check our Well-Architected Review service or book a free consultation.