AWS Account Security Scan: Step-by-Step Security Assessment Guide

TL;DR

An AWS account security scan is a structured review of IAM configuration, S3 bucket permissions, network security groups, logging coverage, and cross-account trust relationships to catch misconfigurations before attackers do. The highest-impact checks, in priority order: enable MFA on the root account and stop using it day-to-day, enable S3 Block Public Access at the account level, enforce CloudTrail logging in every region, eliminate security groups open to 0.0.0.0/0 on administrative ports, and audit IAM policies for wildcard (*:*) permissions. Most of these checks take under 10 minutes each via the AWS CLI, and a focused first-pass review covering the highest-impact items can be completed in about 30 minutes.

What this is

AWS breaches rarely start with a novel exploit against AWS's own infrastructure — they start with basic configuration hygiene that nobody got around to fixing. A temporary IAM permission granted during a development sprint that became permanent. A security group opened for a "quick test" on port 22 or 3389 that's still open to the entire internet eight months later. An S3 bucket policy that grants public read access because someone needed to share one file and never scoped it down afterward. Security researchers running paid AWS assessments consistently report finding the same handful of misconfigurations in the large majority of accounts they review.

Definition: An AWS account security scan is a systematic review of an AWS account's configuration — IAM users, roles, and policies; S3 bucket and object access settings; VPC network security (security groups, NACLs); logging and monitoring coverage (CloudTrail, GuardDuty); and cross-account trust relationships — checked against AWS security best practices to identify misconfigurations independent of any software vulnerability. The scan covers configuration your organization controls under AWS's shared responsibility model, not the security of AWS's underlying physical and virtualization infrastructure, which AWS itself is responsible for.

The distinction matters because AWS's own infrastructure is generally considered highly secure and independently audited — the scan is entirely about how your organization configured the account layered on top of that infrastructure, which is where nearly all real-world incidents originate.

This guide walks through exactly how to run that review — an AWS account security scan — from the account-level controls that matter most through to the CLI commands that verify each one.

Why it matters

Under the shared responsibility model, AWS secures the cloud infrastructure itself, while the customer is responsible for security in the cloud — meaning IAM configuration, S3 permissions, network rules, and logging are entirely the customer's responsibility. That is exactly why misconfiguration, not a platform flaw, is the overwhelming source of real-world AWS incidents. Amazon S3 remains the most commonly misconfigured AWS service and the source of numerous high-profile data breaches, precisely because a single bucket policy or ACL error is enough to expose data broadly. A compromised root credential with no MFA is complete, unrestricted account takeover. Wildcard permissions on a service role — like an EC2 instance role or Lambda execution role — mean a single compromised workload can be chained into privilege escalation and full account takeover. And an attacker operating in an unmonitored region specifically to avoid detection is a well-documented technique, so a CloudTrail configuration scoped to only your "primary" regions leaves that gap wide open.

How it works

An AWS account security scan works by checking the configuration your organization controls against AWS security best practices, independent of any software vulnerability. The scan covers IAM users, roles, and policies; S3 bucket and object access settings; VPC network security (security groups, NACLs); logging and monitoring coverage (CloudTrail, GuardDuty); and cross-account trust relationships.

There are three ways to run the same scan, and most mature AWS security programs use a combination of them.

	Manual CLI/Console Review	AWS Native (Security Hub, GuardDuty, Access Analyzer)	Third-Party CSPM
Setup time	None — AWS CLI access only	Minutes — enable services, some ongoing cost	Requires connecting via IAM role/API
Coverage	Whatever the reviewer specifically checks	Broad, AWS-specific, updated with new AWS services	Often broader, frequently multi-cloud
Detects public S3 buckets/objects	Yes, with correct commands	Yes, via Access Analyzer for S3	Yes, typically with additional context
Detects IAM policy over-permissioning	Yes, but labor-intensive to review at scale	Partially — IAM Access Analyzer flags external access	Often yes, with least-privilege recommendations
Detects cross-account trust misconfigurations	Only if specifically checked	Partially	Often yes, explicitly
Continuous drift detection	No — point-in-time only	Yes, via GuardDuty/Security Hub findings feed	Yes, typically with alerting
Compliance framework mapping (SOC 2, HIPAA, PCI DSS)	Manual cross-referencing required	Security Hub supports standard framework packs	Usually yes, often more comprehensive
Cost	Free (engineer time only)	AWS service costs (typically modest)	Subscription cost
Best for	Initial baseline, single-account environments	Ongoing native monitoring within AWS	Multi-account, multi-cloud, or compliance-heavy environments

Native tools (GuardDuty, Security Hub, IAM Access Analyzer) provide continuous baseline monitoring, supplemented by either periodic manual deep-dives or third-party CSPM for cross-account correlation and broader compliance mapping.

Detection and response

Hypothesis: the account carries at least one of the baseline misconfigurations — root without MFA, no account-level S3 Block Public Access, CloudTrail missing in some regions, a security group open to 0.0.0.0/0 on an administrative port, or a wildcard IAM policy — and each can be confirmed or rejected with a specific CLI check.

Evidence that confirms or rejects each hypothesis:

• Root MFA: aws iam get-account-summary and check AccountMFAEnabled.
• Access keys: aws iam generate-credential-report and inspect LastUsedDate — keys showing "None" (never used) or unused for 30+ days should be deactivated, verified safe, then deleted.
• IAM policy over-permissioning: IAM Access Analyzer identifies policies granting access to external principals; review service roles specifically.
• S3: aws s3control put-public-access-block with all four settings enabled (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) at the account level; then audit individual buckets with aws s3api get-public-access-block and aws s3api get-bucket-policy-status to confirm no documented exceptions have drifted out of scope.
• CloudTrail: confirm logging to a centralized, access-restricted S3 bucket across every region the account can operate in, with log file validation enabled and the destination bucket itself public-access blocked with appropriate access logging of its own.
• Network: audit security groups for rules allowing 0.0.0.0/0 on SSH (22), RDP (3389), and database ports (3306, 5432, 1433).
• Database and other exposed services: query RDS instances for PubliclyAccessible: true; extend the same review to API Gateway endpoints without authentication, Lambda function URLs left public, and EC2 instances with public IPs that don't need them.
• Federation: verify every cross-account and federated trust relationship is scoped to the specific principal that needs it, not a broad wildcard set "once and forgotten."

What to do

1. Confirm root account MFA and stop using root day-to-day. Verify MFA is enabled on the account root user (aws iam get-account-summary and check AccountMFAEnabled), and confirm the root account isn't used for routine operations — the root user should be locked away for account-level tasks only (like closing the account or changing support plans), with all day-to-day administrative work performed through IAM Identity Center or a scoped IAM role instead.
2. Move off long-lived IAM user access keys. Migrate human access to IAM Identity Center (AWS SSO) integrated with your identity provider, and for workloads (EC2, Lambda, ECS), always prefer IAM roles over embedded access keys. For any access keys that must remain, audit LastUsedDate via aws iam generate-credential-report — keys showing "None" (never used) or unused for 30+ days should be deactivated, verified safe, then deleted.
3. Audit IAM policies for wildcard permissions. Review IAM policies for overly broad grants — "Action": "*" or "Resource": "*", and service-level wildcards like "s3:*" applied where only a handful of specific actions are actually needed. Use IAM Access Analyzer to identify policies granting access to external principals, and review service roles specifically.
4. Enable S3 Block Public Access at the account level. Run aws s3control put-public-access-block with all four settings enabled (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) at the account level — this single control overrides individual bucket policies and ACLs. Even with the account-level block enabled, audit individual buckets with aws s3api get-public-access-block and aws s3api get-bucket-policy-status to confirm no documented exceptions have drifted out of scope.
5. Enforce CloudTrail logging in every region. Confirm CloudTrail is enabled and logging to a centralized, access-restricted S3 bucket across every region your account can operate in, not just the regions you actively deploy to. Confirm log file validation is enabled to detect tampering, and that the destination bucket itself has public access blocked and appropriate access logging of its own.
6. Review security groups for overly permissive network access. Audit security groups for rules allowing 0.0.0.0/0 on administrative ports — SSH (22), RDP (3389), and database ports (3306, 5432, 1433) are the highest-risk findings. Cross-reference against actual usage: a security group open to the world on a port with no legitimate business reason for external access should be restricted to specific IP ranges, a bastion host, or a VPN/Direct Connect path instead.
7. Check for publicly accessible RDS instances and other exposed services. Query RDS instances for PubliclyAccessible: true and confirm each has a specific, documented business justification — most database instances should never be directly internet-reachable, with access instead routed through application servers or a controlled bastion. Extend this same review to other commonly-exposed services: API Gateway endpoints without authentication, Lambda function URLs left public, and EC2 instances with public IPs that don't need them.
8. Enable GuardDuty and Security Hub for continuous monitoring. Enable Amazon GuardDuty for continuous threat detection across account activity, network traffic, and DNS logs, and AWS Security Hub to aggregate findings across GuardDuty, IAM Access Analyzer, and other AWS security services into a single view with compliance framework mapping (Security Hub supports standard packs aligned to frameworks like CIS AWS Foundations, PCI DSS, and NIST). This is the step that shifts the scan from a one-time review into ongoing coverage.
9. Audit cross-account trust relationships and OIDC federation. Review IAM role trust policies for cross-account access and OIDC federation trust policies used for CI/CD (GitHub Actions, GitLab CI, and similar). A documented pattern in recent audits found a substantial majority of accounts using GitHub OIDC federation had a trust policy scoped too broadly — allowing any repository within an organization, or in worse cases any GitHub repository at all, to assume a role rather than restricting it to the exact repository and branch that legitimately needs it. Verify every cross-account and federated trust relationship is scoped to the specific principal that needs it.
10. Apply Service Control Policies and establish a recurring cadence. For multi-account AWS Organizations, apply Service Control Policies (SCPs) as account-wide guardrails — preventing entire categories of risky action (disabling CloudTrail, leaving specific regions unrestricted, detaching required security services) regardless of what individual IAM policies within an account might otherwise allow. Finally, schedule this review on a recurring cadence — a quarterly deep review, supplemented by continuous native monitoring (Step 8), is the realistic minimum for most organizations.

Most common findings by risk category

Category	Common Finding	Typical Fix
Root/IAM	Root account without MFA; long-lived IAM user access keys	Enable root MFA; migrate to IAM Identity Center/SSO
IAM policies	Wildcard Action:* or Resource:* grants, often from dev-time shortcuts	Scope to specific actions/resources; review service roles specifically
Access keys	Keys unused for 30–90+ days still marked "Active"	Deactivate, verify, then delete unused keys
S3	Public buckets or objects; account-level Block Public Access not enabled	Enable Block Public Access at account level; audit individual bucket policies
Logging	CloudTrail enabled in only "primary" regions, not all regions	Enable CloudTrail across every region the account can operate in
Network	Security groups open to 0.0.0.0/0 on SSH/RDP/database ports	Restrict to specific IPs, bastion hosts, or VPN paths
Database	RDS instances marked publicly accessible with no documented reason	Disable public accessibility; route through application layer
Federation	Overly broad OIDC trust policies (any repo can assume role)	Scope trust policy to exact repository and branch

FAQ

How long does an AWS account security scan take? A focused first-pass review covering the highest-impact items (root MFA, S3 Block Public Access, CloudTrail coverage, open security groups) can be completed in about 30 minutes using the AWS CLI commands referenced in each step above. A comprehensive review covering all ten steps, including IAM policy audit and cross-account trust review, typically takes several hours depending on account complexity and the number of IAM policies and roles in use.

Is AWS itself insecure, or is this purely a configuration issue? AWS's underlying infrastructure is independently certified against numerous compliance frameworks and generally considered highly secure. Under the shared responsibility model, AWS secures the cloud infrastructure itself, while the customer is responsible for security in the cloud — meaning IAM configuration, S3 permissions, network rules, and logging are entirely the customer's responsibility, which is exactly why misconfiguration, not a platform flaw, is the overwhelming source of real-world AWS incidents.

What's the single highest-impact check to run first? Confirming S3 Block Public Access is enabled at the account level. A single setting override prevents any bucket in the account from being made public regardless of individual bucket policy mistakes, and S3 misconfiguration remains one of the most consistent sources of major data exposure incidents.

Why is CloudTrail coverage across all regions important if we only actively deploy to one or two? Attackers specifically look for unmonitored regions to operate in precisely because activity there won't generate alerts if logging is scoped only to your primary deployment regions — enabling CloudTrail account-wide, across every region, closes this specific blind spot regardless of which regions you actually use for production workloads.

Do AWS native tools like GuardDuty and Security Hub replace the need for a manual review? They significantly reduce ongoing manual effort by providing continuous monitoring, but an initial manual baseline review remains valuable for catching configuration issues (like overly broad IAM policies or cross-account trust misconfigurations) that native detection tools may not flag as explicitly, and periodic manual spot-checks help validate that native tooling coverage itself hasn't drifted (for example, GuardDuty accidentally disabled in a specific region).

How does this compare to a Google Workspace or Microsoft 365 tenant scan? The underlying goal is the same — catching configuration drift before attackers exploit it — but AWS's risk surface centers heavily on infrastructure-as-a-service concerns (IAM roles, network security groups, storage permissions) rather than the SaaS-specific identity and sharing concerns covered in Google Workspace and Microsoft 365/Entra ID tenant scans. Organizations using multiple platforms typically need all three reviews as part of a complete security posture.

Where this fits in a program

Sources

• Google Workspace Tenant Scan: Step-by-Step Security Assessment Guide — the parallel guide for Google Workspace tenants
• Microsoft 365 & Entra ID Tenant Scan: Step-by-Step Security Assessment Guide — the parallel guide for Microsoft cloud tenants
• What Is Cloud Security Posture Management (CSPM)? — the continuous discipline this scan feeds into
• What Is Zero Trust Architecture? — how least-privilege IAM design implements Zero Trust in AWS
• Trusteed Cloud Security & Compliance — continuous configuration monitoring across AWS, Azure, and GCP
• Trusteed Blog
• Start scanning for free
• Talk to an expert