Compliance-first delivery
What an AWS Well-Architected review involves
An AWS Well-Architected review examines one workload against the six pillars of AWS’s Well-Architected Framework: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. A reviewer works through the framework’s questions with your team, checks the answers against the actual AWS account, records high- and medium-risk issues in the free AWS Well-Architected Tool, and produces a prioritised improvement plan. Good AWS Well-Architected review services also estimate the effort for each fix.
The review is free to run yourself. What you pay for is judgement and follow-through
Anyone can open the AWS Well-Architected Tool in the console and answer its questions; AWS does not charge for it. Teams that do it alone tend to end up with optimistic answers (“yes, we have backups”) and a long list of risks nobody owns. AWS Well-Architected review services are worth paying for when an experienced reviewer tests the answers against the real account (when was the last restore test?), separates the issues that matter from the noise, and leaves you with a plan your team will actually work through.
There is one thing you should know before choosing a provider. AWS runs a Well-Architected Partner Program, and customers who review and remediate through a partner can sometimes receive AWS credits towards the fixes. Radiatus is not an AWS partner. Our review uses the same framework and the same tool, in your account, but we cannot unlock partner funding. If credits matter more than who does the work, use a Well-Architected Partner; you can find them in AWS’s Partner Solutions Finder.
A review sits naturally before other work: before handing operations to a provider (see AWS managed services in India), before a big launch, after an incident, or ahead of a security audit. It draws on our cloud infrastructure and technology consulting practices.
What a Well-Architected review checks, pillar by pillar
The framework asks questions in six pillars. These are the issues we most often find in Indian startup and mid-size AWS estates, with the usual fix and its typical size.
| Pillar | Common finding | Usual fix | Typical effort |
|---|---|---|---|
| Operational excellence | Changes made by hand in the console; no runbooks; alarms nobody owns | Infrastructure as code for the workload, runbooks for paging alarms, alarm owners | Weeks |
| Security | Long-lived access keys, root user without hardware MFA, broad IAM policies, public storage | IAM Identity Center with MFA, scoped roles, key removal, storage policies, GuardDuty and Security Hub on | Days to weeks |
| Reliability | Single-AZ database, backups never restored, no tested recovery plan | Multi-AZ where it matters, AWS Backup plans with copies, a timed restore drill | Days to weeks |
| Performance efficiency | Instance types chosen years ago, no load testing, chatty database queries | Right-sizing on metrics, newer instance families, caching, a load test before launch | Days |
| Cost optimisation | Idle resources, no tags, commitments bought on a guess, oversized non-production | Tagging, budgets and anomaly alerts, schedules for non-production, commitments for the baseline | Days |
| Sustainability | Always-on capacity for spiky load, data kept forever | Autoscaling, storage lifecycle rules, efficient instance families | Days |
The cost and sustainability fixes often pay for the review. The security and reliability fixes are usually the ones that matter most.
Self-review, facilitated review or partner review?
| Self-review in the tool | Independent facilitated review (Radiatus) | AWS Well-Architected Partner | |
|---|---|---|---|
| Cost | Free tool; your team’s time | Fixed fee agreed after scoping | Set by the partner; may be offset by AWS credits under programme terms |
| Answers checked against the account | Only if you do it | Yes | Yes |
| Report location | Your account | Your account | Your account, shared with the partner |
| AWS remediation credits | No | No; we are not a partner | Possibly, if the workload and remediation meet the programme’s current terms |
| Best for | Small teams with strong AWS skills | Teams wanting an independent view and help with fixes | Teams for whom credits are a deciding factor |
Ask any partner for the current credit terms in writing: eligibility, which issues count and what share must be fixed. Terms change, and a partner is the right source for them.
Which lens should you use?
Lenses add questions for specific kinds of workload. The AWS Lens Catalog is built into the tool at no extra cost. The ones we use most:
- Serverless: Lambda, API Gateway, Step Functions and event-driven designs.
- SaaS: tenant isolation, onboarding, metering and noisy-neighbour risks; useful with our SaaS development work.
- Generative AI: model choice, prompt and data security, evaluation, cost per request and traceability for AI workloads. AWS has since added lenses for agentic AI and responsible AI.
- Machine Learning: data pipelines, training and model deployment.
- Industry lenses such as financial services, for regulated workloads.
We run the core framework plus at most one or two lenses per review. More than that turns a focused review into a questionnaire marathon.
How to choose the workload to review
A review covers one workload: an application and the AWS resources it runs on. Pick the one where a failure or a breach would hurt most, usually the customer-facing production system that earns revenue. Avoid reviewing “the whole account”; the answers blur and nobody owns the actions. If you have several important workloads, review the most critical first, fix its high-risk issues, then repeat the exercise for the next one with a milestone in the tool so progress is visible.
What an illustrative findings summary looks like
Illustrative, not from a client review.
| # | Finding | Risk | Fix | Effort | Owner |
|---|---|---|---|---|---|
| 1 | Production database in one Availability Zone; last restore never tested | High | Enable Multi-AZ; schedule and time a restore drill | 2–3 days | Platform lead |
| 2 | CI pipeline uses a long-lived access key with admin rights | High | OIDC role scoped to the repository and environment; delete the key | 1–2 days | DevOps |
| 3 | No alarms on checkout errors or latency | High | Alarms on user-facing symptoms routed to on-call, with runbooks | 3 days | Backend lead |
| 4 | Non-production running 24/7 at production size | Medium | Schedules and right-sizing for non-production | 1 day | DevOps |
| 5 | No cost allocation tags | Medium | Tag policy and cost categories by product and environment | 2 days | Finance with DevOps |
What we need from your team
- A technical owner of the workload and one or two engineers for the review sessions.
- Read-only access to the AWS account through a named role, so answers can be checked against reality.
- Architecture diagrams if they exist; we will draw one if they do not.
- Recent incidents, the current AWS bill breakdown and any audit or customer requirements.
After the review: turning findings into fixes
A review that ends as a PDF is wasted. We record the improvement plan in the Well-Architected Tool, rank the high-risk issues by impact and effort, and propose a short remediation sprint for the top items. You can run the sprint yourselves, have us do it, or mix both. When the fixes land, we record a milestone in the tool so the next review starts from evidence, not memory. Cost findings can be tracked month by month in AWS Cost Explorer or our CloudMonitor dashboard, and our FinOps playbook explains the method.
India-specific checks we add to the framework
The framework is global. For workloads run from India, or holding Indian users’ data, we add a few questions the standard set does not ask directly:
- CERT-In logging. Are logs from all relevant systems kept for a rolling 180 days within Indian jurisdiction, as the April 2022 CERT-In directions require, and can the team report an incident within six hours?
- Two Indian regions. With AWS regions in Mumbai and Hyderabad, can backups and disaster recovery stay inside India, and has a recovery into the second region ever been tested?
- Personal data. Is personal data mapped, minimised and protected in line with India’s DPDP Rules, most of which apply from 13 May 2027? Our DPDP checklist lists the duties.
- Billing and accounts. Is the account set up under AWS India with GST details, and does the organisation structure separate production from everything else?
Questions to ask any Well-Architected review provider
- Will you check our answers against the account, or take them on trust?
- Will the review be recorded in the Well-Architected Tool in our own account?
- Are you an AWS Well-Architected Partner, and if so, what credit terms apply to us today?
- Which lens would you use for this workload, and why?
- Do we get effort estimates for each fix, and can you do the fixes?
- What access do you need, and how is it removed afterwards?
When is a Well-Architected review a waste of money?
- When the architecture will be replaced within months; review the new design instead.
- When nobody has time to act on the findings for the next quarter.
- When the only goal is credits and the provider cannot unlock them.
- When it is run as a checkbox, with answers taken on trust and no account access.
- When the same high-risk issues from the last review are still open; fix those first and review again afterwards.
AWS Well-Architected review services
Four engagements. All of them record their results in the AWS Well-Architected Tool in your account, so the work stays with you.
Fixed-scope workload review
The problem
You want an independent view of one important workload across all six pillars, without a months-long consulting project.
How we do it
Scoping, review sessions with your engineers, checks of the answers against the account through read-only access, and a findings summary and improvement plan in the tool, ranked by risk and effort.
What you get
- Review recorded in your AWS account
- Findings summary with evidence
- Ranked improvement plan with effort
- Readout with your team
Review plus remediation sprint
The problem
Previous reviews produced reports, and the high-risk issues are still open.
How we do it
The review, followed by a fixed-scope sprint in which our engineers fix the top high-risk issues with your team, as code and through your review process, then a milestone recorded in the tool.
What you get
- Review and plan
- High-risk fixes delivered as code
- Milestone showing progress
- Handover notes
Generative AI and SaaS lens reviews
The problem
You run an AI feature or a multi-tenant SaaS on AWS, and the generic questions miss your real risks.
How we do it
The core review plus the Generative AI or SaaS lens: tenant isolation, prompt and data security, evaluation, cost per request and noisy-neighbour risks, with fixes specific to those designs.
What you get
- Core framework plus one lens
- Tenant or AI-specific findings
- Cost per request or per tenant view
- Prioritised fixes
Baseline before a handover or migration
The problem
Operations are moving to a new team or provider, or the workload is about to grow fast, and nobody agrees on the current state.
How we do it
A review that sets a documented baseline both sides accept: what is fine, what is risky and what must be fixed before or after the handover.
What you get
- Agreed baseline in the tool
- Pre-handover must-fix list
- Risks accepted in writing
- Input to the operations scope
How a review runs
Typical for one workload. Larger workloads add sessions, not stages.
Scope and access
Pick the workload, agree which lens if any, and set up a named read-only role in the account.
Review sessions
Two or three sessions with your engineers through the framework’s questions, with answers checked against the account between sessions.
Findings and plan
High- and medium-risk issues recorded in the tool, with evidence, a fix and an effort estimate for each, and a readout with your team.
Fix and record
A remediation sprint by your team, ours or both, then a milestone in the tool showing what changed.
A cloud product we run ourselves
We operate our own software on AWS and other clouds, so cost, security and reliability findings are things we deal with too.
Guides and related pages
Guides
Questions about AWS Well-Architected reviews
It is a structured review of one workload against AWS’s Well-Architected Framework, which covers six pillars: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. The result is a list of high- and medium-risk issues and an improvement plan, usually recorded in the free AWS Well-Architected Tool.
Yes. The tool is available in the AWS Management Console at no charge, including the official lenses in its Lens Catalog. What costs money is people’s time, whether your own team’s or a reviewer’s, and the work to fix what the review finds.
AWS has offered credits through its Well-Architected Partner Program to customers who review and remediate with a partner and meet the programme’s terms. Radiatus is not an AWS partner, so we cannot unlock those credits. If credits are important to you, ask a Well-Architected Partner for the current terms in writing.
For one workload, our plan is about two weeks: review sessions in the first week, with answers checked against the account between them, then findings, the improvement plan and a readout in the second. Larger workloads or added lenses take a little longer.
Operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. Each pillar has its own questions and best practices, and lenses add more for specific workloads such as serverless, SaaS, machine learning and generative AI.
It is an official lens in the Well-Architected Tool with questions specific to generative AI workloads, such as model selection, prompt and data security, evaluation, traceability and cost. AWS has since added lenses for agentic AI and responsible AI. We use the lens that fits your workload alongside the core framework.
We charge a fixed fee agreed after scoping and do not publish rates. The fee depends on the workload’s size, how many lenses you want and whether you want a remediation sprint afterwards. The AWS tool itself is free.
Read-only access through a named role, yes. Checking answers against the real configuration is what separates a useful review from a questionnaire. We never ask for root credentials or long-lived keys, and the role is removed when the review ends.
Want an independent look at your most important AWS workload?
Tell us what the workload does, roughly how big it is and what worries you most. A senior engineer will reply with a proposed scope, the lens we would use and a fixed fee.