Reviewing architecture against best practice
Lesson 3 of 3 in Compliance and Audit Evidence.
Config can tell you that every volume is encrypted. It cannot tell you that the architecture puts the database in a public subnet behind a security group that happens to be closed today, or that nobody has thought about how this workload would be isolated during an incident. Some questions are about resources, and automation answers those perfectly. Some are about design, and a human has to answer them.
Three instruments answer the design question, and the exam separates them by cadence and by what they can see.
The AWS Well-Architected Tool is the point-in-time design review: a structured set of questions about a workload, answered by the people who built it, producing risks and an improvement plan. AWS Trusted Advisor is the advisory snapshot: a standing set of account-level checks across cost, performance, security, fault tolerance, quotas and operations. Security Hub and Config are the continuous automated layer from the last two lessons — every resource, every day, scored against standards.
Picking between them is a matter of asking what the stem is actually measuring.
The assurance ladder — each layer assumes the ones beneath it
- Advisory checks — Trusted Advisor
A standing set of account-level checks across six categories, refreshed periodically — unrestricted security group ports, public S3 permissions, MFA on the root user, exposed access keys, public RDS and EBS snapshots, CloudTrail logging, load balancer listener security. Broad, generic and cheap to read; a sensible first look at an account you have just inherited, and nowhere near a compliance programme.
- Continuous automated checks — AWS Config + Security Hub
Every recorded resource, evaluated against rules and security standards, aggregated across accounts and scored. This is the layer that catches the resource created at 2am by somebody who did not read the standard, and the layer that produces most of your audit evidence. It measures configuration, not judgement — see Config rules and remediation.
- Point-in-time design review — Well-Architected Tool
The questions no API can answer: how is least privilege established, how would you contain a compromised credential, what is the data classification, how do you validate the pipeline. Answers become high-risk and medium-risk issues with an improvement plan, and a milestone freezes the review so the next one shows progress rather than starting over.
- Audited evidence — Audit Manager + Artifact
The top rung is not another opinion — it is proof a third party will accept: dated, sourced, per-control evidence that your controls operated over a period, plus AWS’s own audit reports for the controls you inherited. Everything beneath this rung becomes the raw material it collects.
The Well-Architected Tool's mechanics are worth knowing precisely, because the exam asks about the vocabulary rather than the content of the framework.
You define a workload — a name, its environment, its Regions, the account ids it spans — and apply one or more lenses. The base lens is the AWS Well-Architected Framework itself with its six pillars; the lens catalog adds domain-specific lenses (serverless, SaaS, machine learning, data analytics, IoT, financial services, generative AI); and a custom lens lets you encode your own standard as questions and best practices, then share it with other accounts or the whole organization so every team is reviewed against the same bar.
You then work through the questions. Each best practice you have not implemented becomes a risk, and the tool classifies the serious ones as high-risk issues, each linked into an improvement plan with prescriptive guidance. Save a milestone and you have an immutable snapshot: the next review shows the delta, which is how a review becomes a programme instead of an annual ritual. Workloads and lenses can be shared with other accounts, with an OU, or across the organization, and the tool can surface relevant Trusted Advisor checks inside a review so the automated signal informs the human answer.
For the Security Pillar specifically, the review walks the same ground this whole certification does: identity and access management, detection, infrastructure protection, data protection, incident response, and application security. A review that finds "we have no documented way to isolate a compromised instance" is finding something no Config rule was ever going to.
| Instrument | What it measures | Cadence | Output | Sees design intent? |
|---|---|---|---|---|
Well-Architected Tool | A workload’s design against the pillars (and any lens you apply) | Point-in-time, repeated at milestones | High- and medium-risk issues plus an improvement plan | Yes — it is the only one that does, because humans answer it |
Trusted Advisor | A standing set of account-level checks across six categories | Periodic refresh; advisory | Flagged checks with recommended actions, and an organizational view on Business/Enterprise support | No — account-level heuristics |
Security Hub | Posture against security standards, aggregated across accounts and Regions | Continuous | Findings, control status and a security score | No — control pass/fail |
AWS Config | Resource configuration against rules, plus the configuration history | Continuous (change-triggered or periodic) | COMPLIANT / NON_COMPLIANT per resource, optional remediation | No — resource state |
Trusted Advisor's security checks are the ones to recognise in a stem: unrestricted security group ports, S3 bucket permissions allowing public or authenticated-user access, IAM use (no IAM users or roles configured at all), MFA on the root user, exposed access keys, public RDS and EBS snapshots, CloudTrail logging not enabled, and load balancer listener security. If that list feels like an overlap with Security Hub's controls, it is — and the difference is in how you consume them. Security Hub evaluates every resource continuously, scores it against a named standard, and feeds findings into workflows. Trusted Advisor is a periodically refreshed advisory read of the account.
Support-plan detail, because it decides whether an answer is even available: a core subset of security checks and the service quota checks are available on every support plan, while the full check set, programmatic access through the AWS Support and Trusted Advisor APIs, automatic refresh, notifications and the organizational view require Business, Enterprise On-Ramp or Enterprise support. A stem that says "we are on Developer support and need programmatic, organization-wide checks" is steering you to Security Hub and Config, not to Trusted Advisor.
What a custom lens actually contains
A lens is a document: pillars, questions, choices (the best practices), risk rules that decide when an answer is high or medium risk, and improvement-plan text with your own links. Authoring one is how a security team turns "our standard" from a wiki page into something that gets asked at review time, in the same tool and the same workflow as the AWS lens.
Share it with an OU or the organization and every team is measured against the same questions. Milestones then make the comparison honest over time, team by team.
Where Trusted Advisor fits once you have Security Hub
Mostly as a second pair of eyes on things that are not resource configuration: service quotas you are about to hit, load balancer listener security, exposed access keys, support-plan-level advice. On Enterprise Support, Trusted Advisor Priority surfaces recommendations curated with your account team, which is an organizational signal rather than a technical one.
What it should not be is your compliance evidence. It is a periodic advisory read with no per-resource history, no standard mapping and no finding workflow — three things an auditor will want.
Why a review and a dashboard disagree
They are measuring different things, and both can be right. A workload can score 100% in Security Hub and carry three high-risk issues from a Well-Architected review, because the controls that passed were about configuration while the risks were about design — no runbook for credential compromise, no tested restore, no data classification.
The inverse also happens: a clean review and a falling security score, because the design is sound and the implementation drifted. Treat them as complementary instruments. A question offering only one of them when the stem describes the other is the distractor.
Reading the security score honestly
Security Hub computes the score from enabled, applicable controls, so disabling failing controls raises the score without improving anything. Any serious use of the number comes with the list of disabled controls beside it.
And the score says nothing about threats: a perfect posture score alongside an active GuardDuty UnauthorizedAccess finding is entirely possible, because posture and threat detection answer different questions. Governance is about knowing which instrument answers which question — which is the thread running through this whole domain.
Key terms: AWS Well-Architected Tool, Lens (Well-Architected), High-risk issue (HRI), AWS Trusted Advisor, AWS Security Hub (CSPM)
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.