You launched on AWS two years ago. The architecture was solid. Security was tight, costs were reasonable, and the team knew every moving part.
Fast forward to today. Three teams deploy independently. Someone spun up oversized instances “temporarily” six months ago. Your disaster recovery plan lives on a Confluence page nobody has opened since the initial build. And that S3 bucket? Public read access since a demo in Q2.
Nobody plans to build a mess. It just accumulates.
What the Well-Architected Framework actually is
We run Well-Architected Reviews regularly for Dutch enterprises, and what surprises most teams is that the framework is not a theoretical checklist. It’s a structured set of hard questions designed to surface the things you’ve been too busy to look at.
AWS organizes it around six pillars. You’ve probably seen the list before. But listing pillars is cheap. The value is in the questions each one forces you to answer honestly.
Operational Excellence Can your team respond to incidents without heroics? Are deployments automated and repeatable, or does someone SSH into a box at 2 AM? Do you learn from failures, or just fix and move on?
Security Who can access what, and how do you know? Is data encrypted at rest and in transit? Could you detect a breach right now, not tomorrow, not after someone notices something weird in CloudWatch?
Reliability What happens when a component fails? Have you actually tested failover, or are you hoping the runbook from 2024 still works? Can you scale without manual intervention?
Performance Efficiency Are you using the right resource types? When was the last time anyone checked whether those instance families still make sense? Are you running containers on oversized EC2 when Fargate would be half the cost?
Cost Optimization Do you know what each team spends, and why? Are you paying for resources nobody uses? Is your tagging strategy real, or a spreadsheet someone filled in once?
Sustainability Are you minimizing wasted compute? Could you run the same workload on fewer resources with smarter architecture choices?
Each pillar includes dozens of specific questions. They’re designed to find blind spots, the assumptions your team makes because nobody has verified them recently.
Why architectures drift
No one wakes up and decides to build a fragile, expensive, insecure environment. Drift is quieter than that.
A feature ships under deadline pressure. The team skips the architecture review because “it’s just a small change.” Multiply that by fifty deployments across three squads over eighteen months. Now your environment looks nothing like what was originally designed, and nobody can pinpoint the moment it went wrong.
What we see most often:
| Finding | What happens in practice |
|---|---|
| No DR testing | The disaster recovery plan exists. It was written during the initial build. It has never been executed. When the day comes, nobody knows if it works. Hope is not a recovery strategy. |
| Manual deployments | One team automated. Two others still deploy by hand. It’s only a matter of time before a manual push introduces something exciting into production. |
| Over-provisioned resources | That m5.4xlarge was sized for peak load that happened once. It runs at 12% CPU daily. Nobody downsized it because “it works.” It does, and it burns money doing it. |
| Missing encryption | Data at rest is encrypted in production but not in staging. Staging has production data in it. You see the problem. |
| No cost allocation | The AWS bill arrives. It’s higher than last month. Nobody can explain why with confidence. |
These aren’t edge cases. These are the most common findings across the enterprises we review.
How we run a Well-Architected Review
A review is not a checkbox exercise. It’s a structured deep dive into your workloads against the six pillars. No 200-page PDF that collects dust. Actual findings you can act on Monday morning.
Discovery
We start by understanding your landscape. What workloads are running? What’s business-critical? Who deploys what, and how? What does your team topology look like?
This isn’t about auditing your team. It’s about understanding context so the findings land as actionable recommendations, not abstract advice.
Workload analysis
We assess your architecture against the framework using the AWS Well-Architected Tool and Trusted Advisor. But the tooling is just the starting point. The real value is engineers sitting with your team, reviewing CDK and Terraform configurations, deployment pipelines, monitoring setup, IAM policies, networking, and cost structure. Asking the questions each pillar demands. Digging into the answers.
This is not a vulnerability scan. It’s not an automated report. It’s a conversation.
Findings report
You get a clear, prioritized report. Critical risks separated from medium-term improvements, separated from nice-to-haves.
Each finding states what the issue is, why it matters, and what to do about it. No ambiguity. No consultant-speak. If we can’t explain a finding in plain language, we haven’t understood it well enough ourselves.
Remediation roadmap
Findings without a plan are just anxiety. We deliver a prioritized roadmap: what to fix first, estimated effort, and the expected impact of each change.
Security gaps and single points of failure go to the top. Cost optimization gets sequenced by savings potential versus implementation effort. You walk away knowing exactly where to start and what to ignore for now.
What you actually get out of it
Reduced risk. You find the single points of failure, the unencrypted data stores, the IAM policies with *:* that someone added “temporarily” three years ago. The cost of prevention is a fraction of the cost of a breach or outage. Every CTO knows this intellectually. A review makes it concrete.
Lower AWS costs. Over-provisioned instances, unused Elastic IPs, forgotten snapshots, wrong pricing models. They add up faster than most teams realize. We typically see 10-30% savings on compute spend in the first optimization pass. Some teams stare at the numbers and wonder why they waited.
Stronger compliance posture. NIS2 is now enforceable in the Netherlands. GDPR audits are getting more granular every cycle. Dutch enterprises face real regulatory pressure to demonstrate security controls, and the window for getting your house in order is closing. A Well-Architected Review maps directly to these frameworks. It gives you documented evidence of your posture, or shows you exactly where the gaps are before a regulator does.
Faster incident response. When you know your architecture inside out (what fails, what recovers, what needs manual intervention), your team responds faster. Runbooks are based on reality, not the assumptions from the original build.
Confidence to scale. You can’t scale what you don’t understand. A review gives engineering leadership a clear picture of where the architecture stands and what needs to happen before the next growth phase.
When should you do one?
There’s no wrong time. But some moments make it especially valuable:
- Before a major migration or expansion. Know your baseline before you build on top of it.
- After rapid growth. If your team doubled or your workload tripled, your architecture almost certainly didn’t keep pace.
- Annually, as hygiene. AWS releases new services constantly. What was well-architected two years ago might not be today.
- After an incident. Something broke. A review helps you find the other things waiting to break.
- Ahead of compliance deadlines. NIS2 is in force. A Well-Architected Review gives you a head start on demonstrating your controls.
Your architecture has drifted
Your AWS environment is not static. Your business changes, your team changes, AWS itself changes. What was built right eighteen months ago has drifted. The only question is how far.
A Well-Architected Review gives you clarity. Not a sales pitch. Not a theoretical framework. A concrete assessment of where you stand and what to do next.
Book a Well-Architected Review with Forrict and find out where your AWS environment actually stands today.
Forrict
AWS expert and consultant at Forrict, specializing in cloud architecture and AWS best practices for Dutch businesses.
