Most AWS environments look good on the surface: apps are running, users aren’t complaining, bills get paid.
Then something small breaks, or something expensive keeps running when it shouldn’t.
Here’s the thing:
- Problems in AWS don’t always show up early
- Costs don’t always make sense straight away
- Risks don’t send you a warning email first
The AWS Well-Architected Review is less about fixing disasters and more about avoiding them in the first place.
Think of it like a regular check-up; you don’t wait until something is seriously wrong, you check things while they’re still manageable.
Because once things get messy in the cloud, they get messy quickly.
Considering a shift to the cloud, but finding it a bit daunting? Worry no more: On-Premises to Cloud Migration: A Practical Guide
What Is an AWS Well-Architected Review?
An AWS Well-Architected Framework Review is a structured way to look at your cloud setup and ask a simple question:
“Is this actually set up in a way that makes sense?”
Not just technically. Operationally, financially, and from a risk point of view.
It’s based on six pillars (we’ll get into those shortly), but at a high level, the review looks at:
- How your systems are built
- How they’re managed day to day
- Where the risks are hiding
- Where you’re overspending without realising
What it’s not:
- Not a sales pitch for new tools
- Not a pass or fail exam
- Not a 200-page report no one reads
What it is:
- A practical assessment
- A clear list of what’s working
- A clear list of what needs attention
When Should I Conduct an AWS Well-Architected Review?
Short answer: earlier than you think.
Most people wait until something goes wrong. That’s understandable. But it’s also avoidable.
Here are the common moments where the review makes the most sense:
After Things Grew… Quickly
- New apps got added
- Teams made changes on the fly
- Documentation didn’t keep up
Result: You’ve got a working system. But no one’s fully sure how it all fits together.
Before Compliance Audits
Common in:
- Healthcare
- Finance
- Nonprofits handling sensitive data
Typical situation:
- Access controls are inconsistent
- Logging isn’t where it should be
- Policies exist… somewhere
Better to sort this before someone asks questions.
After a Close Call
- Outage that nearly caused real damage
- Security issue that got caught just in time
- Backup that didn’t behave the way you expected
These warning signs are worth paying attention to.
When Costs Feel Off
- Bills going up without a clear reason
- Resources running that no one owns
- “We’ll clean that up later” becoming permanent
AWS is very good at continuing to charge you. Quietly.
When You Just Want a Straight Answer
Sometimes it’s simpler than all that. You just want to know:
- Is this set up properly?
- Are we carrying unnecessary risk?
- Are we spending more than we should?
If you’re looking to conduct a broader cloud review, security is always a solid place to start: Cloud Security Audit: Why Your Business Needs It
How the AWS Well-Architected Review Works
An AWS Well-Architected Review is not a dramatic cloud intervention. No one storms into the room, points at your VPC, and starts yelling.
It is a structured review of a specific workload. The goal is simple:
- Understand how the environment is built
- Find the weak spots
- Work out what matters most
- Turn that into a remediation plan people can follow
That last part matters. A review is only useful if it leads to sensible next steps.
Start With the Workload, Not the Whole Universe
The first job is to define what you are reviewing. That sounds obvious, but it is also where plenty of teams go sideways.
A good review does not begin with:
- Every AWS account
- Every app
- Every server
- Every possible future scenario
It begins with one workload. That could be:
- A client-facing web app
- An internal line-of-business system
- A data platform
- A Microsoft 365 integration environment
- A disaster recovery setup
The reason is simple: you need boundaries. If you review “the whole cloud,” you end up with a giant pile of half-useful observations and no clear plan.
A good scope answers a few basic questions up front:
- What does this workload do?
- Who uses it?
- What happens if it fails?
- What data does it handle?
- What AWS services does it depend on?
Without that, the review becomes a lot of guesses dressed up as process (not ideal.)
Bring In the People Who Know How It Works
The next step is gathering input from the people closest to the workload. That usually includes:
- Cloud or infrastructure staff
- Security leads
- Application owners
- Operations staff
- Finance or procurement stakeholders where cost is a concern
Why so many people? Because cloud problems rarely sit neatly in one box.
A technically sound design can still be painful to support. A cheap setup can be risky. A secure configuration can slow the team down if no one can operate it properly.
The review works best when it reflects how the workload behaves in real life, not how the diagram looked the day it was first built.
This is often where the useful truths come out:
- “That backup job exists, but no one tests restores.”
- “Yes, that role has admin rights. It was meant to be temporary.”
- “We know those instances are oversized. We just never went back to clean it up.”
- “The failover process is documented. Somewhere.”
None of this is unusual. Most environments carry a bit of history. Some carry a lot.
Walk Through the Framework Questions Properly
This is the core of the AWS Well-Architected Framework Review. AWS provides a structured set of questions across six pillars:
- Operational excellence
- Security
- Reliability
- Performance efficiency
- Cost optimization
- Sustainability
The review team works through those questions and assesses how the workload currently operates.
The point is not to race through the questionnaire and declare victory. The point is to uncover what the current design is doing well and where it is exposed.
The questions usually surface issues in three categories:
- Design gaps: The architecture was never set up to handle a specific risk or requirement.
- Process gaps: The technical controls exist, but the supporting process is weak or missing.
- Visibility gaps: The team cannot easily see what is happening, what is failing, or what is costing too much.
That distinction matters, because the fix depends on the cause.
For example:
- A missing backup policy is a design gap.
- A backup policy that exists but is never tested is a process gap.
- Backups running successfully while restores fail without anyone noticing is a visibility gap.
Same area, different problem, different fix.
Record Risks in Plain Language
Once the review questions are complete, the findings need to be written up in a way people can use. That means simple, clear language.
Not:
- “Suboptimal multi-account governance posture with inconsistent IAM federation maturity”
More like:
- “Access is managed inconsistently across accounts, which increases the chance of excessive permissions and weak offboarding.”
People should be able to read the findings and understand:
- What the issue is
- Why it matters
- What could happen if nothing changes
- What the likely fix looks like
A good Well-Architected Review AWS process does more than identify technical flaws. It connects them to business impact.
For example:
- A nonprofit may risk service disruption during a fundraising campaign
- A healthcare business may face gaps around data access and auditability
- A finance team may struggle with privilege control and evidence collection
- A warehouse operation may lose visibility into systems that support fulfilment
That is the difference between a useful review and a long document that lives in a folder forever.
Score the Findings by Risk and Effort
Not every issue deserves the same urgency. Some items are serious and need immediate action. Others are worth fixing, but do not belong at the top of the pile.
A sensible review will sort findings into practical bands, such as:
- High priority
- Security exposures
- Single points of failure
- Missing backup or restore controls
- Obvious cost waste with immediate impact
- Medium priority
- Weak monitoring
- Inconsistent tagging
- Manual deployment steps
- Underused automation
- Lower priority
- Long-term efficiency improvements
- Cleanup work with limited immediate risk
- Design refinements that matter more at larger scale
This step matters because most teams do not have unlimited time or budget. They need a clear order of attack.
The best remediation plans balance:
- risk reduction
- ease of implementation
- operational benefit
- budget reality
That means some fixes happen now, some get scheduled, and some are noted for later.
That is not failure. That is prioritization.
Turn the Findings Into a Remediation Plan
This is where the review starts paying for itself.
A proper remediation plan should include:
- The issue
- The risk level
- The recommended action
- Who owns it
- When it should happen
- Any dependencies or blockers
It should also separate quick wins from larger projects.
Quick wins might include:
- Enabling MFA for privileged users
- Deleting idle resources
- Tightening a permissive security group
- Turning on logging that should have been on already
- Tagging resources properly for cost tracking
Larger remediation projects might include:
- Redesigning network segmentation
- Implementing cross-region disaster recovery
- Moving from manual deployments to CI/CD
- Replacing long-lived credentials with centralised identity controls
- Re-architecting an application tier for resilience
You want the team to leave the review with a list they can work from, not just a list they can worry about.
Looking for more ways to optimize your IT costs? We understand, and we’re with you: IT Cost Reduction Strategies: Reduce Waste Without Sacrificing Security
The Six Pillars of the AWS Well-Architected Framework
The six pillars are the backbone of any AWS Well-Architected Review. Not because AWS says so. Because most cloud problems fall into the same six buckets.
Usually, when something goes sideways, it’s one of these:
- The team can’t run it cleanly
- The setup is too open
- It breaks at the worst time
- It slows down when it matters most
- It costs more than anyone expected
- It’s quietly wasting resources in the background
The pillars just give you a structured way to call that out without turning it into a blame game.
1. Operational Excellence
This is about how well your team can actually run the thing.
Not in theory. Not on a diagram. In real life, on a busy Tuesday.
You’re looking at:
- How changes are made
- How issues are handled
- How much is documented versus “just ask Dave”
Reality check questions:
- Can your team deploy changes without stress?
- Can they fix issues quickly?
- If one key person disappears for a week, does everything fall apart?
Example: Nonprofit organization
A nonprofit has a donor platform in AWS. It works, no major complaints.
But under the hood:
- Deployments are manual and inconsistent
- Alerts fire constantly, so people ignore them
- Documentation is patchy at best
- Only one person really knows how it all fits together
Nothing is broken. It’s just… fragile.
Common issues
- Changes made directly in production
- Alerts that are either too loud or too quiet
- No clear runbooks for common problems
- Same issues happening more than once
Fixes that actually help
- Document the stuff you repeat often
- Standardize deployments and rollbacks
- Tune alerts so they mean something
- Review incidents and learn from them
If operations are messy, everything else becomes harder (including sleep.)
2. Security
Security is about who can access what, and whether that makes sense. Spoiler: it often doesn’t.
You’re looking at:
- Access control
- Data protection
- Logging
- Exposure to the outside world
Reality check questions:
- Does everyone have more access than they need?
- Is MFA actually enforced, or just “recommended”?
- If something suspicious happens, would you even know?
Example: Healthcare
A healthcare provider runs systems in AWS that handle sensitive data.
The review finds:
- Some users have broad admin access “just in case”
- MFA is inconsistent across accounts
- Logs exist but no one reviews them
- Old accounts are still hanging around
This is a classic case of “we’ll tighten that later.”
Common issues
- Overly broad permissions
- Shared credentials still in use
- Inconsistent encryption settings
- Logs that no one looks at
Fixes that actually help
- Apply least privilege properly
- Enforce MFA for anything important
- Remove old accounts and credentials
- Centralize logging and actually review it
If everyone has admin access, no one really does. It just feels like they do.
3. Reliability
This is about what happens when things break. Because they inevitably will, it’s Murphy’s Law.
You’re looking at:
- Failover
- Backups
- Recovery
- Dependencies
Reality check questions:
- What happens if a region goes down?
- Can you restore from backup, or just hope you can?
- Has anyone tested recovery properly?
Example: Manufacturing
A warehouse relies on AWS for inventory and logistics.
The review finds:
- Everything runs in a single region
- Backups exist but aren’t tested
- Failover is “we’ll figure it out”
- Dependencies are poorly understood
It works fine. Until it really doesn’t.
Common issues
- Single points of failure
- Untested backups
- No clear recovery process
- Scaling that breaks under pressure
Fixes that help
- Remove single points of failure where it matters
- Test backups like you actually need them
- Define and document recovery steps
- Plan for failure instead of hoping it won’t happen
Backups are only useful if they work, not just exist.
4. Performance Efficiency
This is about whether your system is doing its job without dragging its feet.
You’re looking at:
- Resource sizing
- Scaling
- Service choices
- Architecture decisions
Reality check questions:
- Are you using the right services, or just the familiar ones?
- Does the system handle peak load without struggling?
- Are you throwing bigger servers at problems instead of fixing them?
Example: Growing SMB
A business has a client portal that’s getting slower as usage grows.
The review finds:
- Instances are either too big or too small
- No real auto-scaling in place
- Database queries are doing too much work
- Old design decisions are still hanging around
Classic “it worked before” situation.
Common issues
- Over-reliance on general-purpose instances
- Missing or poorly configured auto-scaling
- Inefficient database usage
- No use of caching where it would help
Fixes that actually help
- Right-size compute resources
- Implement proper scaling policies
- Optimize database queries
- Use managed services where it makes sense
Throwing more compute at a problem works until the bill shows up. You want to amend things before then.
5. Cost Optimization
This is where things get… interesting. Because AWS will happily keep charging you for things you forgot existed.
You’re looking at:
- Resource usage
- Idle capacity
- Cost visibility
- Commitment strategies
Reality check questions:
- Do you know what’s driving your bill?
- Are you paying for things no one owns anymore?
- Are non-production systems running 24/7 for no reason?
Example: Nonprofit group
A nonprofit sees AWS costs creeping up.
The review finds:
- Dev environments running all the time
- Unused storage still hanging around
- Over-provisioned resources “just in case”
- Tagging that doesn’t tell you anything useful
Nothing dramatic. Just steady waste.
Common issues
- Idle or underused instances
- Unattached storage and old snapshots
- No clear ownership of resources
- Lack of cost monitoring discipline
Fixes that actually help
- Shut down or schedule non-essential workloads
- Clean up unused resources regularly
- Improve tagging for visibility
- Use savings plans where it makes sense
AWS billing is polite. It won’t complain, it will just keep going.
6. Sustainability
This one sounds like a nice optional extra. It’s not. It’s really about efficiency. And yes, that usually means cost too.
You’re looking at:
- Resource utilization
- Workload scheduling
- Data lifecycle
- Architectural efficiency
Reality check questions:
- Are systems running when no one is using them?
- Are you using more compute than needed?
- Is data being kept forever just because it can be?
Example: Multi-site business
A business runs multiple workloads across AWS.
The review finds:
- Systems running 24/7 with predictable idle time
- Outdated instance types still in use
- Data growing without lifecycle policies
- Jobs running longer than they need to
No single issue, just a lot of quiet inefficiency.
Common issues
- Always-on workloads with low utilization
- Outdated resource choices
- Uncontrolled data growth
- Inefficient processing jobs
Fixes that actually help
- Schedule workloads around real usage
- Review and update instance types
- Apply data lifecycle policies
- Reduce unnecessary processing
Sustainability is what happens when you stop wasting things. Turns out, that’s good for your systems and your budget.
More concerned about security? We recommend the nation’s leading standard: NIST Cybersecurity Framework: Implementation Guide for SMBs
Why The Pillars are Stronger Together
These pillars don’t live in isolation.
- Poor operations lead to security mistakes
- Weak reliability leads to rushed, expensive fixes
- Bad performance decisions increase cost
- No cost visibility makes everything worse
An AWS Well-Architected Framework Review works because it looks at the whole picture.
Not just “is this secure?”
But:
- Is it secure in a way we can maintain?
- Is it reliable without being overbuilt?
- Is it efficient without cutting corners?
That’s where things start to feel under control again.
Prioritizing What to Fix (Because You Can’t Do Everything at Once)
Here’s where most reviews fall over. You end up with a long list of issues, and no clear idea what to do first.
Not everything deserves immediate attention. Some things are urgent, some things are annoying, some things can wait.
If you treat them all the same, nothing gets done.
A Simple Way to Prioritize
You don’t need a complicated scoring system. You need something practical.
Think in three buckets:
Fix now
- Security risks that expose data or access
- Single points of failure in critical systems
- Backups that don’t actually restore
- Obvious cost waste with immediate impact
These are the “don’t leave this for next quarter” items.
Fix soon
- Monitoring gaps that hide problems
- Inconsistent configurations across environments
- Manual processes that should be automated
- Performance issues starting to affect users
Important, but not urgent enough to derail everything else.
Plan properly
- Architecture improvements that need design work
- Large-scale refactoring projects
- Long-term cost optimization efforts
- Platform modernization initiatives
These need time, planning, and usually budget.
If You Want a Second Set of Eyes…
If you’ve made it this far, you probably already have a sense of where things stand. Maybe nothing’s obviously broken. But a few things feel… loose.
That’s usually the moment to take a proper look.
StrikeWorks isn’t here to overcomplicate things or sell you a tech stack you didn’t ask for. We sit in the middle with you and keep things grounded.
We’ve been through enough AWS Well-Architected Framework Reviews to spot patterns quickly:
- The things that look fine but aren’t
- The things that feel urgent but can wait
- The fixes that give you the biggest return for the least effort
If that’s useful, we’ll step in and work through it with you.