01
High risk, low effort
Example: No MFA on the root user, or an S3 bucket open to the public
Approach: Fixed first, often as one change to an organization-wide policy.
AWS Well-Architected
AWS Well-Architected review and alignment
A Well-Architected review is only useful if the risks it finds get fixed. Agnotic Technologies runs the review against the lenses that fit your workload, records it in the AWS Well-Architected Tool, ranks the high and medium risk issues and fixes them in milestones your team can review again.
Lens choiceRecorded in the WA ToolRisk-ranked backlogMilestone re-reviews
Trusted by global innovators
Well-Architected
What is an AWS Well-Architected review and alignment?
An AWS Well-Architected review checks a workload against AWS best practice questions and lists its high and medium risk issues; alignment is fixing them. Agnotic Technologies picks the lenses that fit the workload, records the review in the Well-Architected Tool, ranks the risks into a backlog and remediates them in milestones you can re-review.
The review is the start, not the deliverable. Most of the value is in the remediation that follows and in the milestone that shows it was done.
A broader cloud assessment, landing zone design or a move to AWS sits with cloud consulting and AWS migration. Deep cost pillar work sits with cloud cost optimization.
Lens choice
Which Well-Architected lens fits your workload?
The Framework lens applies to every workload. We add the AWS lens that matches what the workload does, because each one brings its own questions and improvement plan.
| Workload type | Lens to add | What it adds to the review | Evidence a reviewer asks for |
|---|---|---|---|
| Workload holding health data | Healthcare Industry Lens | Healthcare design principles and best practices across the six pillars | PHI data flow diagram, list of services covered by the AWS BAA, encryption settings and access logs |
| Payments or banking | Financial Services Industry Lens | Financial services design principles and best practices across the six pillars | Resilience and recovery tests, key management, audit trail and data residency decisions |
| Multi-tenant SaaS | SaaS Lens | Tenant isolation, data partitioning, noisy neighbours, onboarding and tenant tiers | The isolation model, per-tenant usage and cost data and cross-tenant access tests |
| Serverless API or event processing | Serverless Applications Lens | Common serverless scenarios and the practices that keep them reliable | Function permissions, concurrency and timeout settings, retries and dead-letter handling |
| Generative AI feature | Generative AI Lens | Practices for building generative AI workloads on AWS | Model and prompt evaluation records, data access boundaries, guardrails and cost per request |
Custom lenses add your own questions, such as internal engineering standards, and run in the same Tool beside the AWS lenses.
Review workflow
How does a review run in the Well-Architected Tool?
Recording the review in the Tool keeps the findings, the improvement plan and the milestones in one place your team can reopen.
1.
Define the workload
Create the workload record with its accounts, Regions, environment and the lenses to apply, so findings stay tied to one system.
Define2.
Answer the questions
Work through each lens with the engineers who built the system, checking answers against the accounts rather than memory.
Review3.
Record the risks
The Tool flags high and medium risk issues from the answers; we add notes on the evidence behind each one.
Record4.
Save a baseline milestone
Save the starting state as a milestone, so later progress is measured against it.
Baseline5.
Fix and re-review
Work the backlog, update the answers and save a new milestone after each batch of fixes.
ImproveRemediation backlog
How do we rank the risks the review finds?
The Tool says which issues are high or medium risk. It does not say which to fix first, so we rank each one by risk and effort.
02
High risk, high effort
Example: A single Availability Zone database behind a production workload
Approach: Planned as its own piece of work with a tested failover and a maintenance window.
03
Medium risk, low effort
Example: No alarms on queue depth or error rates
Approach: Batched with other quick fixes, so each milestone closes a visible group of issues.
04
Medium risk, high effort
Example: An older service with no automated deployment or rollback
Approach: Scheduled against product work, or accepted with a written reason and a review date.
Cloud audit
What does a cloud audit for optimisation and performance turn into?
Findings only matter once they become tasks. These are typical remediation tasks we take on after a review.
Reliability
- Multi-AZ databases
- Backups with restore tests
- Health checks and auto recovery
- Service quotas watched before limits
Performance efficiency
- Instance and storage right-sizing
- Caching for hot reads
- Load tests before scaling changes
- Newer instance families
Security
- Organization-wide CloudTrail
- IAM roles instead of user keys
- Encryption with AWS KMS keys
- GuardDuty and Security Hub CSPM
Operational excellence
- Infrastructure as code
- Runbooks for common alerts
- Deployment rollback
- Dashboards per service
What changes when the workload holds health data?
When a workload holds health data, we map each security pillar finding to the HIPAA Security Rule safeguard it affects, so one remediation backlog serves both the review and your HIPAA risk analysis.
We add the Healthcare Industry Lens to the review and tag findings with safeguards such as access control, audit controls or transmission security.
Running PHI environments day to day, with runbooks and monthly reporting, sits with our cloud managed services for healthcare.
Re-review cadence
When should a workload be reviewed again?
A review describes the system on the day it was done. We re-review when one of these happens.
- A new Region, account structure or landing zone change
- A move to a new compute model, such as containers or serverless
- A new class of data arrives, such as payment card or health data
- A major incident or a failed recovery test
- A new AWS lens becomes relevant to the workload
- At least once a year for production workloads, even when nothing large has changed
Who asks for a Well-Architected review?
Teams preparing for growth
A check of reliability and performance before a launch, a large customer or a traffic peak.
Startups after their first year on AWS
AWS Well-Architected alignment for startups is usually about closing the security and recovery gaps left by a fast first build.
Health and financial products
A review with the healthcare or financial services lens ahead of a customer or regulator review.
SaaS companies onboarding larger tenants
The SaaS Lens applied to tenant isolation, noisy neighbours and per-tenant metrics.
Teams that inherited an AWS estate
A clear list of what is risky, what is fine and what to fix first.
Scope
What drives the scope of a Well-Architected review?
We do not publish prices. These are the factors we size on the scoping call.
Number of workloads
Each workload gets its own record, lenses and milestones.
Lenses applied
Each added lens brings its own questions and improvement plan.
Access to engineers and accounts
Answers checked against the accounts take longer than interviews alone, and they are more accurate.
Remediation share
Whether we only run the review, or also fix the high and medium risk issues afterwards.
Health or payment data
Mapping findings to HIPAA safeguards or PCI DSS requirements adds a column to every finding.
Re-review schedule
One review, or a review followed by milestone re-reviews after each batch of fixes.
References
Which AWS references do we review against?
The framework, lenses and rules behind the review and the remediation backlog.
AWS Well-Architected FrameworkAWS Well-Architected ToolHealthcare Industry LensFinancial Services Industry LensSaaS LensHIPAA Security Rule
Facts and sources
Facts behind Well-Architected reviews
Definitions from the AWS Well-Architected documentation and the HIPAA Security Rule that shape how we run and record a review.
The AWS Well-Architected Framework has six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.
Source: AWS Well-Architected Framework: the pillars of the FrameworkIn the AWS Well-Architected Tool, the Framework lens is applied automatically to every workload, more lenses can be added, and each lens has its own questions, best practices, notes and improvement plan.
Source: AWS Well-Architected User Guide: using lensesAWS defines a high risk issue as an architectural or operational choice that might result in significant negative impact to a business, and a medium risk issue as one with a lesser impact.
Source: AWS Well-Architected User Guide: glossaryA milestone in the AWS Well-Architected Tool records the state of a workload at a point in time, and AWS suggests saving more milestones as the workload changes to measure progress against the improvement plan.
Source: AWS Well-Architected User Guide: milestonesThe HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information.
Source: 45 CFR 164.308(a)(1)(ii)(A) (eCFR)
Frequently Asked Questions
It depends on how many workloads and lenses are in scope and how quickly the engineers who know the system are available. We agree the workload list and the remediation scope on the scoping call.
The review records the current state and lists the high and medium risk issues. Alignment is the remediation that closes them, shown by a later milestone with fewer open risks.
Yes. Most engagements continue into remediation: we work the ranked backlog with your team, update the answers in the Tool and save a milestone after each batch of fixes.
The Framework lens applies to every workload; add the Healthcare Industry Lens when it holds health data. We also map security findings to HIPAA Security Rule safeguards so the backlog supports your risk analysis.
Largely. A cloud audit for optimisation and performance checks cost, performance, reliability and security against best practice, which is what a Well-Architected review records. Using the Tool means the findings and their fixes are tracked.
Yes, once the product has real users. A short review often finds security and recovery gaps from the first build, which are easier to fix before the next stage of growth.
AI tools may help summarize configuration exports or draft remediation code, but an engineer checks every answer in the review against the accounts, and every fix is tested before release.