Run a Well-Architected review: a AWS guide for developers

Run a Well-Architected review

Most teams I've worked with push code to production, monitor for errors, and call it a day. But what separates resilient systems from ones that fail under load or cost thousands monthly in wasted resources? A structured architecture review. AWS's Well-Architected Tool provides a free, guided framework that forces you to ask the hard questions: Is my database design optimal? Am I handling failures gracefully? Can I explain my security posture to auditors? This is day 87 of our AWS journey, and today we're learning how to run a proper well-architected review that catches architectural debt before it becomes a crisis.

What the Well-Architected Tool actually does

The AWS Well-Architected Tool isn't marketing speak—it's a structured questionnaire that maps to five pillars: operational excellence, security, reliability, performance efficiency, and cost optimization. Each pillar has best practices, and the tool walks you through questions designed to surface risks in your workload.

Think of it like a code review but for infrastructure. When I conducted reviews at my previous SaaS company, we discovered that our microservices were logging to CloudWatch without retention policies, costing us $400/month unnecessarily. The review also revealed we had no automated failover for our primary RDS instance—a single instance failure would mean manual intervention during an incident.

The tool lives in the AWS console and is completely free. You define a workload (your e-commerce platform, CRM backend, whatever you're building), answer a structured set of questions, and AWS generates a report highlighting high-risk, medium-risk, and low-risk issues. No charge, no hidden agenda.

Using the Well-Architected Tool in the console

Getting started is straightforward. Navigate to the AWS Well-Architected Tool in the console—you'll find it under "Management and Governance" services or search directly for it.

Once there, create a new workload by providing:

• Workload name: Something descriptive like "production-payment-service" or "mobile-backend-v2"
• Description: A brief overview of what this workload does
• Environment: Production, staging, or development
• Regions: Which AWS regions this runs in
• AWS account IDs: The accounts involved in this workload

After creating the workload, you'll see five tabs representing the Well-Architected pillars. Start with one pillar and work through systematically. Don't rush through the questions—they're written to make you think critically about your decisions.

Here's what you'll encounter: questions like "How do you monitor your workload to ensure it is behaving as expected?" or "How do you design your workload to protect against DDoS attacks?" Each question has multiple choice answers, and you select the ones that apply to your current setup.

Answering questions per workload

This is where the review gets real. Let me walk you through a practical example using a ride-hailing platform backend I worked on.

Under the Security pillar, one question asks: "How do you manage credentials and secrets?" Your options might include hardcoded in code (risky), environment variables, AWS Secrets Manager, or parameter store. We selected Secrets Manager and noted that we rotate keys every 30 days.

For each answer you select, AWS asks follow-up questions. If you say you're using Secrets Manager, they'll ask if you're enabling automatic rotation, if you're using VPC endpoints to access it, and whether you're auditing access through CloudTrail.

The power here is that these questions force you to be specific. Vague answers like "we have security" don't work. You have to say exactly how you're implementing each practice.

Here's a real scenario: Under Reliability, a question asks about your disaster recovery strategy. You can choose: RPO (Recovery Point Objective) of 24 hours, 1 hour, 15 minutes, or real-time. For our payment service, we chose 15 minutes because losing more than 15 minutes of transaction data would require manual reconciliation and customer contact.

That answer immediately tells us we need:

• Automated RDS backups every 15 minutes (or continuous backup with point-in-time recovery)
• Read replicas in another region for quick failover
• A tested runbook for promoting a read replica to primary
• Automated alerts if replication lag exceeds 5 minutes

When you answer "we don't currently have this in place," the tool flags it. You're not hiding from AWS—you're documenting your current state honestly.

Getting a list of high and medium risks

Once you complete all five pillars, the tool generates a risk report. High-risk items are typically architectural gaps that could cause outages, data loss, or major security vulnerabilities. Medium risks are inefficiencies that increase cost, degrade performance, or create operational burden.

For our payment service, the high-risk items included:

• No automated failover for the primary database (manual intervention required)
• Secrets stored in environment variables in Lambda, not using Secrets Manager
• No VPC Flow Logs, so we couldn't audit network traffic during incidents

Medium risks included:

• CloudWatch alarms weren't configured with SNS notifications to ops (we were checking dashboards manually)
• No automatic scaling configured for the API Gateway, even though we have spiky traffic patterns
• Database backups weren't encrypted with a customer-managed KMS key

The tool doesn't just list problems—it links to AWS documentation and shows you remediation paths. For the secrets issue, it gave us specific steps: create a secret in Secrets Manager, update Lambda code to fetch from there, and test in staging first.

I prioritize high-risk items for the next sprint and distribute medium risks across the roadmap over the next quarter. You'll never eliminate all medium risks (the tradeoff between perfect architecture and shipping features is real), but high risks demand attention.

Interpreting results and prioritizing fixes

The report shows you the percentage of best practices implemented per pillar. You might see something like:

• Operational Excellence: 60%
• Security: 75%
• Reliability: 55%
• Performance Efficiency: 80%
• Cost Optimization: 40%

This gives you a heatmap of where your architecture needs work. Low percentages don't mean failure—they highlight opportunities. In my experience, cost optimization is often the weakest area because teams focus on "does it work" before "does it cost too much."

For each risk, create a ticket in your backlog with acceptance criteria. Example: "Enable automatic failover for production RDS: Set up read replica in us-east-1b, configure failover cluster enabled, test failover in staging, document runbook, train on-call team."

Revisit every six months

Architecture reviews aren't a one-time exercise. AWS releases new services, your traffic patterns change, your team grows, and your codebase evolves. A review that was valid six months ago might miss new risks today.

I schedule well-architected reviews as a recurring event every six months on my team's calendar. We treat it like a major incident postmortem—everyone involved in the workload attends. Before the meeting, I export the previous review to see what we fixed and what we deferred.

Typically, we find that:

• Some medium risks have been fixed (great)
• Some medium risks are still there (need to re-prioritize or accept the risk)
• New issues emerge based on changes to the system
• Best practices have shifted (AWS introduced new services or updated recommendations)

For example, six months after our first review, AWS released AWS Backup, which simplified our backup strategy. We updated the review to use that service, which reduced operational overhead.

Another example: after a scaling incident where we hit API Gateway throttling limits, we revisited the performance efficiency section and discovered we hadn't considered burst capacity during seasonal peaks. This led to implementing auto-scaling policies for our DynamoDB tables.

Common mistakes

Rushing through the questionnaire: Teams sometimes fill it out without deep thought just to get a report. That's waste. The value is in the thinking. Take an hour per pillar minimum.

Ignoring medium-risk items completely: Not everything needs to be fixed immediately, but you should have a conscious decision and a plan. "We're accepting the risk of no VPC Flow Logs for now because we're focused on reliability" is fine. "We didn't notice the VPC Flow Logs issue" is bad.

Not involving the right people: A cloud architect answering for a system they don't operate daily will miss context. Include the on-call engineer, the developer who knows the code patterns, and the person who handles incidents.

Forgetting to export and track over time: The console interface is fine for the first review, but comparing across six-month intervals requires data. Export reports as PDFs or JSON to track progress.

Treating it as a compliance checkbox: Some teams run a review once, store the report, and move on. That defeats the purpose. Treat it as input to your engineering roadmap, not an audit.

Key takeaways

• The Well-Architected Tool is a free, structured framework to identify architectural gaps across five pillars: operational excellence, security, reliability, performance efficiency, and cost optimization.
• Create a workload, answer questions honestly per pillar, and the tool generates a risk report that prioritizes high-risk and medium-risk issues with remediation paths.
• Use high-risk findings to drive sprint planning immediately; distribute medium risks across the roadmap. Not all medium risks need to be fixed, but they should be conscious decisions.
• Revisit every six months because architecture is living—new services, traffic patterns, and team knowledge shift your baseline.
• Involve operators and on-call engineers in the review, not just architects, to surface real-world operational gaps that questionnaires might miss.
• Export reports over time to track progress and celebrate improvements; this gives you data for retrospectives and helps justify architecture investments to leadership.