What an AWS Well-Architected review actually checks

If a review has been booked and you are the person who has to answer for the account, this is what is coming and how much of it you can settle in advance.

What a Well-Architected review actually is

Two things worth getting right, because most write-ups get both wrong.

It is a conversation, not an audit. AWS's own words: "The process for reviewing an architecture is a constructive conversation about architectural decisions, and is not an audit mechanism." Nobody is issuing a pass mark. The output is a shared understanding of the trade-offs you have made and a list of the risks you have decided to accept or fix.

The tool is free. The AWS Well-Architected Tool costs nothing. It walks the questions, records your answers, and produces an improvement plan with the high-risk items called out. If a consultancy is charging you for the tool rather than for the expertise around it, that is worth a question.

The six pillars

AWS defines exactly six. In their order:

The reliability and cost pillars are where most accounts lose points, and they are also the two with the highest proportion of questions that have a factual answer rather than a judgement.

The half you can answer before the meeting

A reviewer will not take "we think it's fine" for these. Every one is a Describe* call away, and running them yourself turns an hour of the session into thirty seconds.

Reliability — is anything a single point of failure?

# Auto Scaling groups pinned so they cannot grow
aws autoscaling describe-auto-scaling-groups \
  --query 'AutoScalingGroups[?MinSize==MaxSize].[AutoScalingGroupName,MinSize,MaxSize]' \
  --output table

# RDS instances with no standby
aws rds describe-db-instances \
  --query 'DBInstances[?MultiAZ==`false`].[DBInstanceIdentifier,DBInstanceClass]' \
  --output table

# Target groups with no healthy target
for tg in $(aws elbv2 describe-target-groups --query 'TargetGroups[].TargetGroupArn' --output text); do
  aws elbv2 describe-target-health --target-group-arn "$tg" \
    --query "TargetHealthDescriptions[?TargetHealth.State=='unhealthy']" --output text | grep -q . \
    && echo "unhealthy targets: $tg"
done

A note on that last one, because it is the question people answer wrongly: unhealthy is not the same as unused. A target reading unused / Target.NotInUse belongs to a group wired to no load balancer — it is serving nothing, which is a tidiness problem, not an outage. Only unhealthy means a registered target is failing its check. Filter on the state, not on "anything that is not healthy", or you will walk into the review with four emergencies and one real one.

Security — what is reachable, and is anything unencrypted?

# Security groups open to the world
aws ec2 describe-security-groups \
  --query "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]].[GroupId,GroupName]" \
  --output table

# Publicly accessible databases
aws rds describe-db-instances \
  --query 'DBInstances[?PubliclyAccessible==`true`].DBInstanceIdentifier' --output table

# Unencrypted volumes
aws ec2 describe-volumes \
  --query 'Volumes[?Encrypted==`false`].[VolumeId,Size]' --output table

Cost optimization — what is billing for nothing?

# Elastic IPs attached to nothing
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' --output table

# Volumes attached to nothing
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType]' --output table

Each of those is worth running across every region, not just the one you work in. The forgotten resources are, definitionally, in the region you forgot about. We wrote up the Elastic IP case in more detail — including why the advice you will find elsewhere is now out of date since AWS started charging for all public IPv4 addresses.

The half you cannot automate

This is where reviews earn their keep, and no tool — ours included — replaces it.

• "Why is it built this way?" The reviewer is testing whether the trade-off was chosen or inherited. There is no API for intent.
• "What is your recovery time objective, and when did you last prove it?" A script can see that backups exist. It cannot tell you whether a restore has ever been rehearsed, or whether the number in the runbook is one anybody agreed to.
• "What happens to this workload if that team leaves?" Operational excellence is mostly about people, and none of it is in an API.
• Performance efficiency and sustainability are almost entirely design questions. Whether your instance family suits your workload depends on what the workload does, which no amount of reading configuration reveals.

Any tool claiming to run a Well-Architected review for you is describing the mechanical subset and calling it the whole thing.

Where TellHound fits, precisely

We check a subset of this continuously, and it is worth being exact about which subset, because the honest boundary is the useful part.

Covered well: reliability, security, and cost optimization — the pillars whose questions have factual answers. Findings come with what is wrong, why it matters, the exact remediation and what acting costs.

Covered partly: operational excellence, through alarm coverage, log coverage, and end-of-life runtimes and engines.

Not covered: performance efficiency beyond obvious rightsizing candidates, and sustainability, which we do not assess at all. Neither appears in our scoring, and an account is never graded on a pillar we did not look at.

That last point matters more than the coverage: when a permission is missing, a metric is switched off, or an API returns nothing, the result is reported as unassessed, never quietly counted as a pass. A review you walk into holding a report that overstates your position is worse than walking in with nothing.

If you are the one running reviews for clients, this is the part that changes: the mechanical half stops being a week of scripting per engagement and becomes something you re-run per account, per month, with the findings already written up. The conversation — the part the client is actually paying you for — is unchanged.

The short version

• Six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability
• It is a conversation about trade-offs, not a pass/fail audit
• The AWS Well-Architected Tool is free — use it
• Roughly half the reliability, security and cost questions can be answered from the APIs before the meeting; run them yourself and spend the session on the half that needs a human
• Be suspicious of anything that claims to automate the other half, including us