AWS Well-Architected Security Review: What It Checks and Why It's Not Just a Scan

Most teams running workloads on AWS have GuardDuty enabled, Security Hub aggregating findings, and a vague sense that the score should probably be higher. What they usually don’t have is an answer to the question that actually matters: of the hundreds of findings on that dashboard, which ones would an attacker use, in what order, and what’s the fastest path to reducing that risk?

An AWS Well-Architected security review exists to answer that. It maps your environment against the Well-Architected Framework Security Pillar and the CIS AWS Foundations Benchmark, but the value isn’t the checklist — native tools already run checklists. The value is interpretation: which findings matter for your workload, how the small ones chain together, and a remediation plan an engineering team can execute rather than a report they file.

Why Cloud Risk Concentrates in Configuration

Moving to AWS didn’t shrink the attack surface — it changed its shape. The same flexibility that lets a team provision a database in a minute lets them provision it with a permissive security group, an over-scoped IAM role, and encryption left at the default. None of that requires an attacker to be sophisticated. It requires them to enumerate — and automated enumeration of public S3 buckets, exposed metadata endpoints, and wildcard IAM policies is a standard, low-effort part of how opportunistic attacks work.

The organizations that get breached in the cloud rarely got hit by a novel technique. They accumulated permissive IAM policies, a few misconfigured buckets, some unencrypted stores, sprawling security groups, and inconsistent logging — and then one of those became the foothold and the rest became the path.

What the Review Covers

Account structure and baseline. Organizations layout, OUs, service control policies, and whether a landing zone or Control Tower baseline is enforcing guardrails or was set up once and drifted.

IAM and access governance. Policies, roles, federation, and cross-account trust reviewed for least privilege. Wildcard permissions get flagged specifically — Action: "*" or Resource: "*" on anything that isn’t a deliberately scoped break-glass role is an outsized lateral-movement risk the moment any single credential leaks.

Network security. VPC design, security group and NACL rules, WAF coverage, and perimeter controls. The core question: what’s reachable from the internet that shouldn’t be, and how flat is the network once you’re inside a VPC?

Data protection. S3 bucket policies and public-access settings, encryption at rest and in transit verified rather than assumed, and KMS key management — rotation, grants, and who can decrypt what.

Logging and monitoring. CloudTrail coverage across all regions and accounts, Config rules, GuardDuty, and Security Hub. A misconfiguration that’s exploited with no audit trail is a far worse outcome than one that at least gets detected.

Compliance posture. Findings mapped to the Well-Architected Security Pillar and the CIS AWS Foundations Benchmark, producing a scorecard that’s meaningful to an auditor and a starting point for SOC 2 or ISO 27001 evidence.

The Part Native Tools Don’t Do

Security Hub gives you a finding: “S3 bucket allows public read.” It gives you another: “IAM role has wildcard permissions.” It gives you a third: “CloudTrail not enabled in eu-west-2.” Three medium-severity items in a list of two hundred.

The review connects them: the public bucket contains application config, the config references the role, the role can read a database with customer data, and the region with no CloudTrail is where the affected resources live — so an incident there would leave no trail. That’s not three medium findings. That’s one high-severity attack chain, and it moves to the top of the roadmap.

The Deliverable

• A cloud security posture assessment report with findings prioritised by business risk, not flat severity
• IAM least-privilege recommendations, with specific policy changes
• A network security and segmentation review
• A data protection and encryption gap analysis
• A CIS AWS Foundations Benchmark scorecard
• A 30/60/90-day remediation roadmap — owners, effort estimates, and Infrastructure-as-Code (Terraform / CloudFormation) for the fixes that support it

Getting Started

If an AWS environment has grown for more than a year without a structured review — beyond whatever the native dashboards happen to surface — the realistic expectation is that meaningful findings exist, and that at least one of them is a chain rather than a single misconfiguration. A cloud security configuration review surfaces them systematically, read-only throughout, and hands engineering a remediation plan they can actually run.