AWS Security Audit: What Gets Checked and When You Need One

Your AWS account has 847 IAM policies. Do you know which ones grant public access to your production database?

That number isn't hypothetical. It's what I've seen in real AWS environments, and it illustrates why security audits exist. One misconfigured policy buried in that pile could expose your entire customer database to the internet.

The challenge is straightforward: AWS gives you incredible power to build, but that power comes with complexity. Between IAM policies, security groups, S3 bucket configurations, encryption settings, and logging requirements, it's nearly impossible to manually track your security posture across even a moderately sized AWS environment.

By the end of this guide, you'll understand exactly what an AWS security audit is (and isn't), what gets examined, and whether you should handle it yourself or bring in professionals. I'll also clear up the confusion between audits, security reviews, and penetration tests, because these terms get mixed up constantly.

If you haven't yet established AWS account security fundamentals, that foundation directly impacts what audits will find.

What is an AWS Security Audit?

An AWS security audit is a systematic evaluation of your AWS environment to verify that security controls, policies, and procedures are operating effectively and meeting your compliance requirements. Think of it as a comprehensive cloud security audit focused specifically on AWS services and configurations.

That definition sounds simple, but there's more to it. AWS Audit Manager defines controls as "policies, procedures, and activities" that organizations implement to manage risk. An audit verifies these controls are actually working, not just that they exist on paper.

The outcome is a formal assessment that demonstrates your security posture to stakeholders, whether that's your board, your customers, or regulatory bodies.

How Audits Differ from General IT Assessments

If you've been through traditional IT audits, AWS audits will feel different. Three characteristics set them apart.

Automated evidence collection. AWS Audit Manager automatically collects and organizes evidence from AWS services rather than requiring someone to manually screenshot configurations and gather documents. This changes the audit experience dramatically.

Continuous monitoring capability. Unlike periodic audits where someone checks your systems once a year, AWS tools enable ongoing assessment of your security posture. You can know your current state at any moment, not just during audit season.

Cloud-native approach. Audits leverage AWS service logs, configuration data, and API activity rather than traditional infrastructure artifacts. This means more comprehensive coverage with less manual effort.

The Shared Responsibility Model in Audits

Before diving into what gets audited, you need to understand what you're actually responsible for. AWS operates under a Shared Responsibility Model, and audit scope follows this boundary precisely.

AWS handles security OF the cloud. This includes the physical infrastructure, hardware, software, networking, and facilities that run AWS services. You don't audit this, AWS does, and they provide compliance certifications to prove it.

You handle security IN the cloud. This means your customer data, identity and access management, application configuration, operating systems, network configuration, and encryption choices. Every single audit check focuses on this side of the equation.

Here's a practical example: AWS secures the physical data center where your RDS instance runs. But you're responsible for the IAM policies that determine who can connect to that database. The audit examines your policies, not AWS's data center locks.

This distinction matters because it defines exactly what a security audit will examine in your environment.

Security Audit vs Security Review vs Penetration Test

I see these three terms used interchangeably, and that confusion leads organizations to do the wrong activity for their situation. Let me clear this up.

Security audits verify compliance with specific standards through evidence collection. They're structured around compliance frameworks (SOC 2, ISO 27001, PCI DSS, HIPAA) and produce formal assessment reports for stakeholders or regulators. The key tool here is AWS Audit Manager with prebuilt frameworks for 30+ compliance standards.

Security reviews assess your overall security posture against industry best practices. They evaluate configuration and architecture against the AWS Well-Architected Security Pillar, identify misconfigurations and optimization opportunities, and focus on recommendations rather than compliance evidence. You'd use AWS Security Hub, Trusted Advisor, and the Well-Architected Tool for this.

Penetration tests are fundamentally different. They actively attempt to exploit vulnerabilities by simulating real-world attacks. Ethical hackers try to break into your systems, document what they find, and show you the actual impact of vulnerabilities. Most AWS services allow penetration testing without prior approval (EC2, RDS, CloudFront, Aurora, API Gateway, Lambda, Lightsail, Elastic Beanstalk).

The key distinction: Penetration tests attempt to EXPLOIT systems. Security audits and reviews ANALYZE configurations and evidence. This is a critical difference when deciding what your organization needs.

When to Use Each Approach

Given your situation, which approach do you need?

Use a security AUDIT when:

• You need compliance certification (SOC 2, ISO 27001, PCI DSS)
• Customers or investors demand formal proof of your security controls
• Regulatory requirements mandate periodic assessments
• You need third-party validation for stakeholder confidence

Use a security REVIEW when:

• You want regular security posture checks between formal audits
• You're preparing for an upcoming compliance audit
• You need to identify improvement opportunities
• Your team wants to assess current state without the formality of an audit

Use a PENETRATION TEST when:

• You're launching new features or applications
• You've made major changes to your architecture
• You want to validate that security controls actually work under attack
• You need to simulate real-world threat scenarios

Many organizations use all three. Reviews for continuous improvement, audits for compliance certification, and pen tests for validation. They serve different purposes and shouldn't be confused.

What Gets Audited in an AWS Security Audit?

Now that you understand what an audit is, let's examine what specifically gets checked. AWS security audits typically focus on five core domains: IAM, VPC/Network, S3, Encryption, and Logging.

Each domain has specific checks based on real security risks. Remember that 847 IAM policies example? The same complexity problem applies to every domain. Security groups multiply, S3 buckets proliferate, and encryption configurations vary across services. An audit cuts through this complexity systematically. For a complete checklist covering all five domains with 55+ specific checks, see our AWS security review checklist.

Identity and Access Management (IAM)

IAM is where the 847 policies problem lives, and it's often where the most critical findings emerge. One overly permissive policy can grant database access to attackers, which is why IAM gets scrutinized heavily.

Audit focus areas:

• User and role permissions (verification of least privilege)
• Root account usage and protection (MFA enabled, minimal usage)
• Access key age and rotation (credentials rotated within 90 days)
• Password policies (minimum length, complexity, expiration)
• MFA adoption rates across users and roles
• Cross-account access and trust relationships
• Unused credentials and permissions

Common findings audits discover:

• Users with administrative access lacking MFA
• Root user access keys that exist (they shouldn't)
• Access keys older than 90 days without rotation
• Overly permissive policies granting broad access
• Unused IAM users, roles, or credentials
• Policies allowing unrestricted KMS key decryption

IAM Access Analyzer is particularly powerful here. It uses automated reasoning (called Zelkova technology) to mathematically analyze IAM policies. This isn't pattern matching, it's formal verification that can identify external access, internal access patterns, and unused permissions. The external access analysis is free, which makes it an excellent starting point for any organization.

If you're looking to strengthen your IAM foundation before an audit, review your centralized identity management approach. Proper identity architecture makes audit findings significantly more manageable.

VPC and Network Security

Overly permissive security groups are one of the most common AWS security issues. Audits examine your network configurations to ensure resources aren't exposed unnecessarily.

Audit focus areas:

• Security group rules (especially 0.0.0.0/0 inbound rules)
• Network ACL configurations
• VPC Flow Logs enablement
• Public subnet configurations
• VPC endpoints for reducing internet exposure
• Route table configurations

Common findings:

• Security groups allowing unrestricted access (0.0.0.0/0) on critical ports like SSH (22), RDP (3389), or database ports
• Missing VPC Flow Logs for traffic analysis
• Resources in public subnets that should be private
• Network ACLs with overly permissive rules
• Unused or improperly configured security groups

Security groups vs Network ACLs: Security groups are stateful, instance-level virtual firewalls that support allow rules only. Network ACLs are stateless, subnet-level firewalls supporting both allow and deny rules. Both work together for defense-in-depth, and audits check both layers.

One practical step you can take immediately: find unused security groups in your environment. Cleaning these up reduces attack surface and simplifies audit findings.

Amazon S3 Security

S3 misconfigurations have caused some of the highest-profile cloud data breaches in recent years. Because of this history, S3 security gets particular attention during audits.

Audit focus areas:

• Public access configurations (S3 Block Public Access settings at account and bucket level)
• Bucket policies and their scope
• Access Control Lists (AWS recommends disabling ACLs entirely)
• Encryption at rest configuration
• Versioning and Object Lock for data protection
• Server access logging

Common findings:

• Buckets with public access despite Block Public Access settings (yes, this happens when bucket policies override account settings)
• Buckets without encryption enabled
• Bucket policies granting overly broad access
• Missing versioning for critical data
• Buckets lacking access logging

IAM Access Analyzer for S3 identifies buckets accessible outside the AWS account, including publicly accessible buckets and those shared with other AWS accounts. It displays access granted through bucket policies, ACLs, Multi-Region Access Point policies, or access point policies.

Encryption (At Rest and In Transit)

Encryption is your last line of defense. If other controls fail and attackers access your data, encryption ensures that data remains protected. Audits verify encryption is properly implemented across your environment.

Encryption at rest - what gets checked:

• Amazon S3: SSE-S3 (Amazon-managed keys), SSE-KMS (AWS KMS keys)
• Amazon EBS: Encryption using AWS KMS keys with 256-bit AES encryption
• Amazon RDS: Database encryption using KMS keys
• Amazon DynamoDB: Encryption at rest (enabled by default, but audits verify it)

Key audit checks:

• EBS volumes and snapshots encrypted
• RDS databases using encryption at rest
• S3 buckets with default encryption enabled
• KMS key policies preventing public access
• CloudWatch Logs configured with KMS encryption

Encryption in transit:

• TLS 1.2 or higher for all communications
• HTTPS endpoints for API calls
• Certificate validation for load balancers and CloudFront distributions
• VPC endpoints for private AWS service access without internet transit

The principle here is straightforward: encrypt everything. Audits verify you've actually done it.

Logging and Monitoring

Without proper logging, you can't investigate incidents or prove compliance during audits. Logging is both a security control and the evidence trail that audits rely on.

AWS CloudTrail records all AWS API calls and user activity across accounts. It's the foundation of AWS audit trails.

What CloudTrail logs:

• Management events (control plane operations like creating, modifying, deleting resources)
• Data events (resource operations like S3 object access, Lambda invocations)
• Insights events (unusual API activity patterns)
• Network activity events (API activity through VPC endpoints, currently in preview)

CloudTrail best practices that audits verify:

• CloudTrail enabled in all AWS Regions
• Multi-Region trails for comprehensive coverage
• Log file integrity validation enabled (to detect tampering)
• Integration with CloudWatch Logs for real-time monitoring
• Logs stored in dedicated S3 bucket with strict access controls
• MFA Delete enabled on CloudTrail S3 buckets
• SSE-KMS encryption for log files

VPC Flow Logs capture IP traffic data for VPCs, subnets, or individual network interfaces. They help diagnose overly restrictive or permissive security group and NACL rules.

Service-specific logging also matters: S3 Server Access Logs, RDS and Aurora audit logs, ELB Access Logs, and CloudFront Access Logs all provide visibility that audits may examine depending on your compliance requirements.

A recent feature worth noting: CloudTrail aggregated events consolidates high-volume data events into 5-minute summaries, simplifying analysis while preserving essential insights for security teams.

DIY vs Professional Audit: Which Approach Do You Need?

This is the question everyone has but no security content actually answers. All the guides assume you'll do it yourself. Let me give you honest guidance on when each approach makes sense.

When DIY Auditing Works

DIY auditing is appropriate and effective in several scenarios.

When it makes sense:

• Early-stage startups without formal compliance requirements
• Internal AWS security assessments and continuous monitoring
• Pre-compliance preparation before engaging external auditors
• Organizations with strong internal security teams
• Regular security posture reviews between formal audits

AWS tools available for DIY:

• AWS Security Hub: Automated security checks against compliance standards, security scoring, centralized findings
• AWS Config: 300+ managed rules for configuration compliance, automated remediation capabilities
• IAM Access Analyzer: Free external access analysis, paid unused access and internal access analysis
• Amazon GuardDuty: Threat detection and anomaly identification
• AWS Trusted Advisor: Security recommendations (requires Business Support or higher for full access)
• CloudTrail: Activity logging and audit trail

DIY cloud security audit process:

1. Define scope (accounts, regions, services, compliance requirements)
2. Enable audit tools (Security Hub, Config, GuardDuty, CloudTrail, Access Analyzer)
3. Baseline security posture (run initial scans using our security review checklist, document current state, identify critical findings)
4. Remediate high-priority issues first
5. Implement continuous monitoring (automated alerts, scheduled reports)
6. Document findings and track remediation status
7. Establish regular review cadence (weekly/monthly posture reviews)

Advantages of DIY:

• Cost-effective for organizations without compliance mandates
• Continuous rather than point-in-time assessment
• Builds internal security expertise
• Faster iteration and remediation cycles

Limitations:

• No external validation or certification
• May miss complex architectural security issues
• Requires internal security expertise
• Not acceptable for regulatory compliance requirements

When You Need Professional Help

Professional audits become necessary in clear situations.

When required:

• Regulatory compliance mandates (SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP)
• Customer or partner contractual requirements
• Preparing for IPO or acquisition due diligence
• Post-incident validation of security improvements
• Annual compliance attestation requirements

Types of professional audits:

• SOC 2 Type I: Point-in-time assessment of control design
• SOC 2 Type II: Operating effectiveness over 3-12 months (this is what most enterprises require)
• ISO 27001 Certification: Information Security Management System assessment
• PCI DSS Assessment: Required for organizations handling payment card data
• HIPAA Assessment: Required for covered entities and business associates handling protected health information

Cost reality: External auditor fees range from $15,000 to $150,000+ depending on scope and framework. Add internal resource time for evidence preparation and remediation. This is a significant investment, but it's necessary when compliance certification is required.

The key advantage: External validation that DIY simply cannot provide. When customers or regulators require third-party attestation, internal assessments won't satisfy the requirement.

When You Need a Professional Security Review

Beyond the DIY vs professional audit decision, certain situations specifically trigger the need for professional help. Let me walk through the common triggers.

Compliance Triggers

Regulatory requirements create non-negotiable audit needs:

• Healthcare: HIPAA compliance required for handling protected health information (PHI)
• Financial Services: PCI DSS for payment processing, SOC 2 for financial data handling
• Government: FedRAMP for federal agency cloud services, FISMA for federal information systems
• International: GDPR for EU data handling, ISO 27001 for global operations
• Industry-Specific: NIST 800-171 for defense contractors

Customer and partner requirements:

• Enterprise customers demanding SOC 2 Type II reports
• Partners requiring ISO 27001 certification for integration
• Vendor security questionnaires requiring third-party validation
• Security riders in sales contracts mandating annual audits

Business milestones:

• Preparing for Series A+ funding rounds (investors demand security assurance)
• Pre-IPO security and compliance readiness
• Merger and acquisition due diligence

AWS Audit Manager includes frameworks for these standards with varying levels of automated vs manual controls. For example, SOC 2 has 15 automated + 46 manual controls across 20 control sets. ISO 27001:2013 Annex A has 21 automated + 93 manual controls across 35 control sets.

Growth and Business Signals

Sometimes the trigger isn't a specific compliance requirement but organizational signals indicating you've outgrown DIY approaches.

Organizational indicators:

• Inability to answer customer security questionnaires confidently
• Multiple security incidents or near-misses in the past year
• Security recommendations consistently deprioritized
• No dedicated security role (security handled ad-hoc)
• Audit findings or failed compliance assessments

Risk factors:

• Regulatory enforcement actions in your industry
• Security breaches at peer companies
• Elevated threat actor interest in your industry
• Cyber insurance policy requirements

Post-incident triggers:

• Data breach affecting customer or employee data
• Ransomware or significant malware infection
• Unauthorized access to production systems
• Compliance violations discovered during operations

Post-incident professional reviews serve specific goals: root cause analysis with independent perspective, validation that security gaps have been addressed, documentation for regulatory reporting, insurance claim support, and restoration of stakeholder trust.

Technical Complexity Signals

Your AWS environment's complexity also drives the need for professional help.

Technical indicators:

• Managing 50+ AWS accounts across multiple organizations
• Processing sensitive data (PII, PHI, payment information)
• Multi-region deployments with complex architectures
• Hybrid or multicloud environments
• Critical infrastructure supporting 10,000+ users

If you're dealing with large multi-account environments, your AWS Organizations governance setup directly impacts audit complexity. Proper account structure and policy frameworks make audits more manageable.

Internal capability assessment:

• No AWS Certified Security Specialty holders on team
• Limited experience with compliance frameworks
• Unable to interpret or implement AWS security best practices
• Struggling to keep pace with AWS security feature releases

Build vs buy decision:

• Build: Invest in training, certifications, hire AWS Security Specialty holders
• Buy: Engage AWS Professional Services or AWS Security Competency Partners
• Hybrid: Internal security operations with external audit and advisory support

Key Takeaways

Let me summarize what you need to know about AWS security audits.

An AWS security audit systematically evaluates your environment to verify security controls are effective. It differs from general IT audits through automated evidence collection, continuous monitoring capability, and cloud-native approach.

Audits differ from reviews and pen tests. Audits verify compliance through evidence collection. Reviews assess posture against best practices. Penetration tests actively exploit vulnerabilities. Choose based on your specific needs.

Five core domains get audited: IAM (where the 847 policies problem lives), VPC and network security, S3 configurations, encryption (your last line of defense), and logging (your evidence trail).

DIY works for internal assessments and continuous monitoring. Professional audits are required when you need compliance certification, customer validation, or third-party attestation.

Trigger events for professional help include compliance requirements, business milestones (funding, IPO), post-incident review needs, and technical complexity beyond your team's capability.

Remember those 847 IAM policies from the beginning? An AWS security assessment systematically works through that complexity, identifying which policies pose real risk and which are operating correctly. Without that systematic approach, you're guessing about your security posture.

Your next step depends on your situation:

• If you need compliance certification: Start by enabling AWS Audit Manager and selecting your target framework. The automated evidence collection will reveal how much preparation you need before engaging external auditors.

• If you want to assess your current posture: Enable Security Hub today. Within an hour, you'll have a security score and prioritized list of findings across your AWS environment.

• If you're growing fast and security feels reactive: Consider a professional security review to establish your baseline. An experienced assessment identifies architectural issues that automated scans miss, creating a roadmap for building internal capabilities.

If you're facing compliance requirements or want an expert assessment of your AWS security posture, reach out about a security review. Sometimes having experienced eyes on your environment reveals issues that automated tools miss.