AWS Security Audit Checklist: The Complete 2026 Guide

Security misconfigurations remain the leading cause of cloud breaches. Gartner has consistently predicted that the vast majority of cloud security failures will be the customer's fault — not the provider's. An AWS security audit is not optional—it is a fundamental practice that every organization running workloads on AWS must perform regularly. Whether you are a startup managing a handful of EC2 instances or an enterprise with hundreds of accounts, a structured audit process is the single most effective way to identify and remediate vulnerabilities before attackers exploit them.

This guide provides a complete, actionable checklist you can use to audit your AWS environment in 2026. We cover every critical domain: identity and access management, storage security, networking, logging, data protection, and compliance governance. Each section includes specific checks you can perform using the AWS console, CLI, or automated tooling.

Why Regular AWS Security Audits Matter

AWS operates under a shared responsibility model. Amazon secures the underlying infrastructure—the physical data centers, hypervisors, and managed service internals—but you are responsible for everything you configure on top of that infrastructure. This means your IAM policies, S3 bucket settings, security group rules, and encryption configurations are entirely your responsibility.

Regular security audits help you:

• Identify configuration drift – Infrastructure changes over time. Developers create temporary access keys, test security groups get left open, and bucket policies accumulate exceptions. Audits catch this drift before it becomes a vulnerability.
• Meet compliance requirements – Frameworks like SOC 2, HIPAA, PCI DSS, and GDPR all require periodic security assessments. A structured audit gives you the evidence you need.
• Reduce blast radius – By finding overly permissive policies and unnecessary access, you shrink the attack surface an adversary can exploit if they gain a foothold.
• Build institutional knowledge – The audit process forces your team to document what exists, why it exists, and whether it still needs to exist.

We recommend performing a comprehensive audit at least quarterly, with continuous monitoring in between. If you need expert assistance, explore our AWS security consulting services to get a thorough, professional assessment.

1. IAM Security Checklist

Identity and Access Management is the foundation of AWS security. A misconfigured IAM policy can expose your entire account. Start your audit here.

Root Account Protection

• Enable MFA on the root account. Use a hardware MFA device (such as a YubiKey) rather than a virtual MFA app. The root account has unrestricted access to every resource, and compromising it means total account takeover.
• Remove all root account access keys. There is no legitimate reason to have programmatic access keys on the root account. Run aws iam get-account-summary and verify that AccountAccessKeysPresent is zero.
• Restrict root account usage. The root account should only be used for the small number of tasks that require it, such as changing account settings or closing the account. All other work should use IAM users or roles.

MFA and Password Policies

• Require MFA for all human users. Enforce MFA at the IAM policy level using a condition key like aws:MultiFactorAuthPresent. Do not rely solely on user compliance.
• Set a strong password policy. Require minimum 14 characters, uppercase, lowercase, numbers, and symbols. Set password expiration to 90 days and prevent reuse of the last 24 passwords. Note: NIST SP 800-63B recommends against mandatory periodic password rotation unless there is evidence of compromise. The above recommendations may be required for specific compliance frameworks such as PCI DSS.
• Audit MFA enrollment. Run aws iam generate-credential-report and check the mfa_active column for every user. Any user without MFA is a risk.

Least Privilege Access

• Review all IAM policies for wildcard permissions. Search for policies containing "Action": "*" or "Resource": "*". These grant far more access than any user or service needs.
• Use IAM Access Analyzer. Enable Access Analyzer in every region to identify resources shared with external entities. It will flag S3 buckets, IAM roles, KMS keys, Lambda functions, and SQS queues that are accessible from outside your account.
• Review unused permissions. Use IAM Access Analyzer’s policy generation feature to create least-privilege policies based on actual usage from CloudTrail logs. Our IAM Activity Tracker tool can also help you identify unused permissions across your accounts.
• Audit cross-account access. List all IAM roles with trust policies that allow AssumeRole from external accounts. Verify each one is intentional and necessary.

Access Key Management

• Identify and rotate old access keys. Access keys older than 90 days should be rotated. Keys older than 180 days should be deactivated immediately pending investigation.
• Remove unused access keys. The credential report shows the access_key_last_used_date for each key. Any key not used in the last 90 days should be deactivated and then deleted.
• Prefer IAM roles over access keys. EC2 instances, Lambda functions, and ECS tasks should all use IAM roles for authentication rather than embedded access keys.

2. S3 Security Checklist

Amazon S3 is the most commonly misconfigured AWS service and the source of many high-profile data breaches. Audit every bucket in your account.

Public Access Settings

• Enable S3 Block Public Access at the account level. This is a single setting that prevents any bucket in the account from being made public, regardless of individual bucket policies or ACLs. Enable it unless you have a documented, approved exception.
• Audit individual bucket public access settings. Even with account-level blocking, review each bucket. Run aws s3api get-public-access-block --bucket BUCKET_NAME for every bucket.
• Check for public bucket policies. Use aws s3api get-bucket-policy-status to identify buckets with policies that grant public access.

Encryption and Data Protection

• Enable default encryption on all buckets. Use SSE-S3 at minimum; SSE-KMS provides superior key management and audit capabilities. Run aws s3api get-bucket-encryption for each bucket.
• Enforce encryption in transit. Add a bucket policy condition that denies any request where aws:SecureTransport is false. This ensures all access uses HTTPS.
• Enable versioning on critical buckets. Versioning protects against accidental deletion and provides an audit trail of changes. Combine with Object Lock for ransomware protection.

Access Logging and Monitoring

• Enable S3 server access logging. Direct logs to a dedicated logging bucket. This creates a record of every request made to your buckets.
• Enable CloudTrail data events for S3. This captures API-level activity (GetObject, PutObject, DeleteObject) for audit and forensic purposes.
• Consider Amazon Macie. Macie uses machine learning to discover, classify, and protect sensitive data stored in S3. It is particularly valuable for compliance-regulated environments.

3. Network Security Checklist

Network misconfigurations remain a significant vector for cloud breaches. Your VPC architecture must enforce defense in depth.

VPC Configuration

• Use multiple VPCs or accounts for workload isolation. Production, staging, and development environments should be in separate VPCs at minimum, ideally separate accounts managed through AWS Organizations.
• Deploy workloads in private subnets. Only load balancers, NAT gateways, and bastion hosts should have public IP addresses. Application servers, databases, and internal services belong in private subnets.
• Remove the default VPC. The default VPC in each region has overly permissive settings. Unless you are using it intentionally, delete it to prevent accidental resource deployment in an insecure network. Note that some AWS services and console wizards expect a default VPC to exist. You can recreate it with aws ec2 create-default-vpc if needed.

Security Groups

• Audit security groups for unrestricted inbound access. Search for rules with source 0.0.0.0/0 or ::/0. The only acceptable use of these sources is for public-facing web servers on ports 80 and 443, behind a load balancer.
• Check for overly permissive port ranges. Security groups should allow only the specific ports needed. A rule allowing ports 0-65535 is never acceptable.
• Remove unused security groups. Unused security groups create confusion and can be accidentally attached to new resources.
• Use security group references instead of IP addresses. When one AWS resource needs to communicate with another, reference the target’s security group rather than its IP address.

VPC Flow Logs

• Enable VPC Flow Logs on all VPCs. Flow Logs capture metadata about network traffic (source, destination, ports, protocol, action). Send them to CloudWatch Logs or S3 for analysis.
• Monitor for rejected traffic patterns. A high volume of rejected connections may indicate reconnaissance or lateral movement attempts.
• Review Network ACLs. NACLs provide a stateless layer of defense at the subnet level. Ensure they are not inadvertently blocking legitimate traffic or allowing unnecessary access.

4. Logging and Monitoring Checklist

You cannot secure what you cannot see. Comprehensive logging and monitoring are non-negotiable for a secure AWS environment.

AWS CloudTrail

• Enable CloudTrail in all regions. Create an organization-level trail if you use AWS Organizations. Ensure the trail captures management events and, for sensitive accounts, data events as well.
• Enable CloudTrail log file validation. This creates a digital signature for each log file, allowing you to detect if logs have been tampered with.
• Send CloudTrail logs to a centralized, locked-down S3 bucket. The bucket should be in a dedicated security account with a bucket policy that prevents deletion, and S3 Object Lock enabled.

Amazon CloudWatch

• Create CloudWatch alarms for critical security events. At minimum, set alarms for: root account usage, IAM policy changes, security group changes, NACL changes, CloudTrail configuration changes, and S3 bucket policy changes.
• Use CloudWatch Logs Insights. Write queries to detect anomalous patterns such as unusual API calls, access from unexpected IP addresses, or large data transfers.

Amazon GuardDuty

• Enable GuardDuty in all regions and all accounts. GuardDuty analyzes CloudTrail, VPC Flow Logs, and DNS logs to detect threats including compromised instances, reconnaissance, and credential exfiltration.
• Review and act on findings. GuardDuty findings should be routed to a security team via SNS or EventBridge. High-severity findings require immediate investigation.
• Enable GuardDuty S3 protection and EKS protection. These add-on features provide deeper visibility into S3 access patterns and Kubernetes audit logs.

AWS Config

• Enable AWS Config in all regions. Config records the configuration of your AWS resources over time, providing a timeline of changes for forensic analysis.
• Deploy Config rules for security baselines. Use the AWS managed rules for common checks: s3-bucket-public-read-prohibited, iam-root-access-key-check, encrypted-volumes, and restricted-ssh.
• Use conformance packs. AWS provides pre-built conformance packs for CIS Benchmarks, NIST, PCI DSS, and other frameworks.

5. Data Protection Checklist

Protecting data at rest and in transit is a core requirement of virtually every compliance framework and a fundamental security best practice.

Encryption at Rest

• Encrypt all EBS volumes. Enable default EBS encryption in each region using aws ec2 enable-ebs-encryption-by-default. This ensures every new volume is automatically encrypted.
• Encrypt RDS instances and snapshots. Enable encryption when creating RDS instances. Note that you cannot encrypt an existing unencrypted RDS instance in place—you must create a snapshot, copy it with encryption enabled, then restore from the encrypted copy.
• Encrypt DynamoDB tables. DynamoDB supports encryption at rest with AWS-owned keys (default), AWS-managed keys, or customer-managed KMS keys.
• Audit KMS key policies. Review who has access to your KMS keys. A compromised KMS key policy can render encryption useless by granting decryption access to unauthorized principals.

Encryption in Transit

• Enforce TLS 1.2 or later on all endpoints. Configure ALBs, API Gateways, and CloudFront distributions to require TLS 1.2 at minimum.
• Use ACM for certificate management. AWS Certificate Manager provides free TLS certificates and handles automatic renewal, eliminating the risk of expired certificates.

Secrets Management

• Store all secrets in AWS Secrets Manager or SSM Parameter Store. Never embed secrets in code, environment variables, or configuration files.
• Enable automatic rotation. Secrets Manager supports automatic rotation for RDS, Redshift, and DocumentDB credentials. Configure rotation for at least every 90 days.
• Audit secret access patterns. Use CloudTrail to monitor who is accessing secrets and when. Unexpected access patterns may indicate compromise.

6. Compliance and Governance Checklist

Governance controls ensure that security policies are enforced consistently across your entire AWS environment, not just in the accounts you remember to check.

AWS Organizations and SCPs

• Use AWS Organizations. Organizations provides centralized management of multiple AWS accounts, with consolidated billing, centralized CloudTrail, and Service Control Policies.
• Implement Service Control Policies (SCPs). SCPs set the maximum permissions for accounts in your organization. Use them to prevent actions like disabling CloudTrail, leaving specific regions, or creating unencrypted resources.
• Separate workloads into dedicated accounts. Use separate accounts for production, development, staging, security tooling, and logging. This provides hard isolation boundaries.

Compliance Monitoring

• Use AWS Security Hub. Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and Config into a single dashboard. It scores your environment against CIS Benchmarks and other standards.
• Use AWS Audit Manager. Audit Manager automates evidence collection for compliance assessments, supporting frameworks including SOC 2, HIPAA, GDPR, and PCI DSS.
• Schedule regular access reviews. At least quarterly, review who has access to what, whether that access is still needed, and whether it aligns with the principle of least privilege.

Next Steps: From Checklist to Action

A checklist is only valuable if you act on its findings. After completing your audit, prioritize remediations by severity: address critical findings (such as public S3 buckets, root account access keys, and unrestricted security groups) immediately, then work through high and medium findings systematically.

Automate as much as possible. AWS Config rules, GuardDuty, and Security Hub can continuously monitor your environment and alert you to new issues before they become breaches. Infrastructure as Code tools like Terraform and CloudFormation ensure that your security configurations are consistent and repeatable.

If your team lacks the bandwidth or expertise to conduct a thorough audit, our AWS security consulting services can help. We perform comprehensive security assessments, deliver detailed findings with prioritized remediation plans, and help your team implement the fixes. Our consultants bring years of experience securing AWS environments across industries including healthcare, fintech, SaaS, and e-commerce.

Security is not a one-time event. Build audit procedures into your operational rhythm, and your AWS environment will be significantly more resilient against the threats of 2026 and beyond.