Five findings that appear in almost every Well-Architected review

AWS Well-Architected reviews cover six pillars, but the findings cluster tightly. Across the environments we assess, the same five issues come up again and again — and almost never because the original architecture was careless. They are the result of drift: a temporary permission that became permanent, a service launched under deadline, a policy that was never revisited.

1. Over-permissive IAM roles

Wildcard permissions get granted during debugging and stay forever. The fix is not a big-bang policy rewrite; it is using IAM Access Analyzer and CloudTrail data to see what each role actually uses, then narrowing to that in stages with monitoring in place.

2. Backups that have never been restored

Snapshots run on schedule, so backup is considered solved. But an untested restore is an assumption. We ask teams to restore a production database into an isolated environment and time it. The result frequently exceeds the recovery time objective the business believes it has.

3. Single points of failure in the data tier

Application tiers are usually spread across availability zones, but the database often is not, because Multi-AZ was deferred to save cost during a pilot that quietly became production. It is one of the cheapest resilience upgrades available relative to the outage it prevents.

4. Logging that nobody reads

CloudTrail is enabled, logs land in a bucket, and nothing alerts on them. Detection requires routing security-relevant events to something that raises an alarm — GuardDuty findings, root account usage, security group changes on public-facing resources.

5. Undocumented manual configuration

One of the most common risks in an established environment is an undocumented setting applied through the console years earlier that nobody can now account for. Bringing infrastructure under Terraform or CloudFormation makes configuration reviewable and reproducible, and converts informal knowledge into documentation a new joiner can read.