AWS Security Review Checklist: Complete Self-Assessment Guide

Every AWS breach starts with a misconfiguration someone missed. I've seen it in security reviews: one overly permissive IAM role, one security group with 0.0.0.0/0, one S3 bucket with public access. These aren't sophisticated attacks. They're basic misconfigurations that appear in 90% of accounts and violate AWS security best practices.

This AWS security review checklist is the exact one I use for paid assessments. Now it's yours.

But there's a reason companies still hire me. The checklist identifies problems. Professional experience determines which problems actually matter for your specific environment, how to remediate without breaking things, and what architectural patterns prevent these issues from recurring.

This AWS security review checklist follows the AWS Well-Architected Security Pillar, which organizes security into seven best practice areas: security foundations, identity and access management, detection, infrastructure protection, data protection, incident response, and application security. I've organized this checklist into the domains that matter most for practical security assessments.

By the end of this guide, you'll be able to systematically assess your AWS security posture, prioritize findings by risk level, and remediate issues with specific steps. Whether you're preparing for a compliance audit, doing proactive security hygiene, or validating your current controls, this checklist gives you a structured approach.

How to Use This Checklist

Before diving into specific checks, let me explain how this assessment is structured. Understanding the approach helps you get maximum value from your time investment.

Each checklist item includes a risk level indicator, specific instructions on what to check, what a "pass" looks like, what a "fail" looks like, and remediation steps. I've organized items by security domain, but you should start with the critical items across all domains before working through high and medium priorities.

Time Estimates by Depth Level

Your time investment depends on what you need to accomplish.

Quick Security Scan (1-2 hours): Critical items only across all domains. This catches the misconfigurations most likely to result in a breach. Good for monthly spot-checks or when you need fast validation.

Standard Security Review (4-8 hours): All checklist items at a reasonable depth. You'll check configurations, review findings, and document issues. Good for quarterly assessments or pre-audit preparation.

Comprehensive Assessment (2-3 days): Full checklist plus remediation implementation. You'll not only identify issues but fix them and verify the fixes. Good for annual deep dives or post-incident hardening.

Multi-account environments multiply these estimates. A standard review of 10 accounts takes 40-80 hours unless you've configured centralized security services with aggregated findings.

Required Tools and Access

Before starting, ensure you have the necessary permissions and tools configured.

IAM Permissions: At minimum, you need the SecurityAudit AWS managed policy attached to your IAM role. This provides read-only access to security configurations across services. For a comprehensive review, ViewOnlyAccess combined with SecurityAudit covers most scenarios.

AWS CLI: Many checks are faster via CLI than console. Configure your CLI with the appropriate profile:

aws sts get-caller-identity

This confirms your identity and permissions before you begin.

Security Services: Several items require specific services to be enabled. If they're not already running, enable them now:

• AWS Security Hub (aggregates findings from multiple sources)
• AWS Config (tracks configuration compliance)
• Amazon GuardDuty (threat detection)
• AWS CloudTrail (API activity logging)

For AWS accounts on Business Support or higher, AWS Trusted Advisor provides additional security checks that complement this assessment.

Risk Level Indicators Explained

Each checklist item has a risk indicator that helps you prioritize.

[CRITICAL]: Immediate action required. These represent active security risks that attackers could exploit today. Missing MFA on root, public S3 buckets, security groups with 0.0.0.0/0 for SSH. Fix these before doing anything else.

[HIGH]: Fix within 30 days. Significant exposure that increases your attack surface or violates security best practices. Unencrypted data, missing logging, overly permissive IAM policies.

[MEDIUM]: Address within a quarter. Best practice deviations that improve your security posture but don't represent immediate exploitable risk. Defense-in-depth enhancements, documentation improvements.

[LOW]: Nice to have. Enhancements that provide marginal security improvement. Address these when you have capacity.

Pre-Assessment: Scope and Inventory

You can't assess what you don't know exists. Before running through checklists, document what you're reviewing. This scoping phase ensures nothing falls through the cracks.

Document Your AWS Footprint

Start by mapping your environment. This information shapes how you approach the assessment.

Account Inventory:

• How many AWS accounts are you assessing? List account IDs and their purposes.
• Are accounts organized under AWS Organizations? Document the OU structure.
• Which account is your management account? (It has different security considerations.)

Regional Usage:

• Which AWS regions contain active resources?
• Do you have resources in regions you don't expect? (This could indicate compromise.)

Key Services in Use:

• Compute: EC2, Lambda, ECS, EKS?
• Storage: S3, EBS, EFS?
• Databases: RDS, DynamoDB, ElastiCache?
• Networking: VPC, CloudFront, API Gateway?

Integration Points:

• Third-party tools with AWS access
• CI/CD pipelines deploying to AWS
• SaaS applications with IAM roles

Essential Security Tools to Enable First

Some security tools need to run before the assessment to provide useful data. If these aren't enabled, turn them on now and schedule your assessment for when they've collected baseline data.

AWS Security Hub: Aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and Config. Enable with the AWS Foundational Security Best Practices standard at minimum. Security Hub provides a security score and prioritized findings that make assessments dramatically faster.

aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-east-1

AWS Config: Records configuration changes and evaluates compliance against rules. Enable recording for all resource types in all regions. Without Config, you lose visibility into what changed and when.

Amazon GuardDuty: Continuous threat detection analyzing CloudTrail, VPC Flow Logs, and DNS logs. Enable in all regions. GuardDuty findings often surface issues this checklist helps you investigate.

AWS CloudTrail: Records all AWS API calls. Create an organization trail if using AWS Organizations, or at minimum a multi-region trail in each account. Log file validation must be enabled.

Multi-Account vs Single Account Scope

The assessment approach differs based on your account structure.

Single Account: Apply this checklist directly. All items are relevant.

Multi-Account with Organizations: Centralized controls (SCPs, organization trails, delegated administrators) apply at the organization level. Individual account checks still apply to each member account. Use Security Hub with cross-account aggregation to view findings centrally.

If you're managing multiple accounts, your AWS Organizations best practices configuration directly impacts security. Review organization-level controls in addition to individual account settings.

For guidance on multi-account identity management, see AWS IAM Identity Center.

Identity and Access Management Checklist (15 Items)

IAM misconfigurations cause more breaches than any other category. In security reviews I conduct, IAM issues appear in nearly every environment. One overly permissive policy can expose your entire AWS account.

This section covers root account security, IAM user and role configuration, and credential management. Start here because IAM is where the highest-risk misconfigurations live.

Root Account Security (4 items)

The root user has unrestricted access to everything in your account. No IAM policy, no SCP, nothing can limit it. Root account compromise means complete account compromise.

[CRITICAL] Root account has MFA enabled

• How to check: Console > IAM > Security recommendations, or:

  aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'
  
• Pass: Returns 1 (MFA enabled)
• Fail: Returns 0 (MFA not enabled)
• Remediation: Enable hardware MFA (YubiKey or FIDO security key) on the root account immediately. Virtual MFA is acceptable but hardware MFA is strongly preferred for root. AWS offers free MFA security keys to eligible US account owners.

[CRITICAL] Root account has no access keys

• How to check: Console > IAM > Security recommendations, or check root user's security credentials
• Pass: No access keys exist for root user
• Fail: Access keys present (active or inactive)
• Remediation: Delete root access keys immediately. There is no legitimate reason for root access keys to exist. Any workload can use IAM roles. If you "need" root keys, you're doing something wrong.

[HIGH] Root account not used in last 90 days

• How to check: Console > IAM > Credential report, or:

  aws iam generate-credential-report
  aws iam get-credential-report --query 'Content' --output text | base64 -d | grep '<root_account>'
  
• Pass: password_last_used is older than 90 days or "N/A"
• Fail: Recent root usage indicates operational use of root credentials
• Remediation: Stop using root for daily operations. Create IAM users or roles for all administrative tasks. Root should only be used for account recovery and specific tasks that require root (like changing support plans or closing the account).

[MEDIUM] Alternate contacts configured

• How to check: Console > Account Settings > Alternate contacts
• Pass: Billing, Operations, and Security contacts are configured with valid email addresses (not the root email)
• Fail: Alternate contacts missing or using root email
• Remediation: Configure contacts with group distribution lists (e.g., security@company.com) so AWS notifications reach the right people even when individuals leave the organization.

IAM User and Role Configuration (6 items)

Most environments rely too heavily on IAM users with long-term credentials. Roles with temporary credentials are more secure and should be the default.

[CRITICAL] All IAM users with console access have MFA enabled

• How to check: Console > IAM > Users, filter by console access, or:

  aws iam list-users --query 'Users[*].UserName' --output text | xargs -I{} aws iam list-mfa-devices --user-name {}
  
• Pass: Every user with password-enabled login has at least one MFA device
• Fail: Users with console access but no MFA
• Remediation: Require MFA for all console users. Use IAM policies with aws:MultiFactorAuthPresent conditions for sensitive operations. Better yet, migrate to IAM Identity Center with enforced MFA.

[HIGH] No IAM users have administrative access (use roles instead)

• How to check: Console > IAM > Users, check attached policies, or:

  aws iam list-users --query 'Users[*].UserName' --output text | xargs -I{} sh -c 'echo "User: {}"; aws iam list-attached-user-policies --user-name {}'
  
• Pass: No users have AdministratorAccess or equivalent broad policies
• Fail: IAM users with admin access for daily operations
• Remediation: Create IAM roles for administrative tasks. Use IAM Identity Center permission sets. Humans should assume roles, not have direct admin policies attached. This creates an audit trail and allows MFA enforcement.

[HIGH] IAM password policy meets complexity requirements

• How to check: Console > IAM > Account settings, or:

  aws iam get-account-password-policy
  
• Pass: Minimum 14 characters, requires uppercase, lowercase, numbers, symbols, password expiration within 90 days
• Fail: Weak password policy or no policy configured
• Remediation: Update the password policy:

  aws iam update-account-password-policy \
    --minimum-password-length 14 \
    --require-symbols \
    --require-numbers \
    --require-uppercase-characters \
    --require-lowercase-characters \
    --max-password-age 90 \
    --password-reuse-prevention 24
  

[HIGH] No inline policies on IAM users (use managed policies)

• How to check: Console > IAM > Users > select user > Permissions tab, or:

  aws iam list-users --query 'Users[*].UserName' --output text | xargs -I{} sh -c 'echo "User: {}"; aws iam list-user-policies --user-name {}'
  
• Pass: No inline policies; all permissions via managed policies
• Fail: Users with inline policies
• Remediation: Convert inline policies to customer managed policies. Managed policies are easier to audit, update, and reuse. Inline policies hide permissions and make reviews harder.

[MEDIUM] IAM Access Analyzer enabled and findings reviewed

• How to check: Console > IAM > Access Analyzer, or:

  aws accessanalyzer list-analyzers
  
• Pass: Analyzer exists and active findings have been reviewed
• Fail: No analyzer configured or unreviewed findings
• Remediation: Create an Access Analyzer:

  aws accessanalyzer create-analyzer --analyzer-name account-analyzer --type ACCOUNT
  
  Review findings weekly. Access Analyzer identifies resources shared with external accounts, unused permissions, and overly broad policies.

[MEDIUM] Permissions boundaries implemented for sensitive roles

• How to check: Review IAM roles used by development teams or automation
• Pass: Roles that can create other roles have permission boundaries preventing privilege escalation
• Fail: Roles can create new roles with any permissions
• Remediation: Implement permission boundaries for delegated administration. This prevents teams from granting themselves more access than intended. See AWS documentation on permissions boundaries.

Credential Management (5 items)

Long-term credentials (access keys) are a significant attack surface. Temporary credentials through roles are always preferred.

[HIGH] Access keys rotated within 90 days

• How to check: Console > IAM > Credential report, or:

  aws iam generate-credential-report
  aws iam get-credential-report --query 'Content' --output text | base64 -d
  
• Pass: No active access keys older than 90 days
• Fail: Keys older than 90 days in use
• Remediation: Rotate keys following AWS guidance: create new key, update applications, verify new key works, disable old key, delete old key after grace period. Better: migrate to IAM roles and eliminate access keys entirely.

[HIGH] Unused IAM users removed (no activity in 90+ days)

• How to check: Credential report password_last_used and access_key_*_last_used columns
• Pass: All users show activity within 90 days
• Fail: Users with no activity for 90+ days
• Remediation: Disable inactive users first (allows recovery if needed), then delete after confirmation. Implement user lifecycle processes that deactivate accounts when employees leave.

[HIGH] Unused access keys disabled or deleted

• How to check: Credential report access_key_*_last_used_date columns
• Pass: No active keys unused for 90+ days
• Fail: Active keys with no recent usage
• Remediation: Deactivate unused keys:

  aws iam update-access-key --user-name USER_NAME --access-key-id ACCESS_KEY_ID --status Inactive
  
  Delete after confirming nothing breaks.

[MEDIUM] IAM roles used instead of access keys for applications

• How to check: Review applications and services for credential sources
• Pass: EC2 uses instance profiles, Lambda uses execution roles, ECS uses task roles, external services use IAM Roles Anywhere
• Fail: Applications using long-term access keys in config files or environment variables
• Remediation: Migrate to IAM roles. For workloads outside AWS (CI/CD, on-premises), use IAM Roles Anywhere with X.509 certificates or OIDC federation.

[MEDIUM] No credentials stored in code or environment variables

• How to check: Code scanning, environment variable review, Secrets Manager usage
• Pass: Credentials retrieved from Secrets Manager or Parameter Store at runtime
• Fail: Credentials in source code, config files, or environment variables
• Remediation: Use AWS Secrets Manager for database credentials and API keys. Use Parameter Store for non-sensitive configuration. Implement CodeGuru Reviewer or git-secrets to prevent credential commits.

Network Security Checklist (12 Items)

Network security determines what can communicate with what. A single misconfigured security group can expose your database to the entire internet. These checks verify your network perimeter is properly protected.

VPC Configuration (4 items)

Proper VPC design creates layers of defense. Resources should be segmented by security zone with network controls between them.

[HIGH] Production workloads in private subnets

• How to check: Console > VPC > Subnets, verify subnet route tables, or identify EC2 instances in subnets with internet gateway routes
• Pass: Application servers, databases, and sensitive workloads have no direct internet gateway route
• Fail: Production resources in subnets with 0.0.0.0/0 route to internet gateway
• Remediation: Move resources to private subnets. Use NAT Gateway for outbound internet access. Use Application Load Balancer in public subnets to route traffic to private resources.

[MEDIUM] VPC Flow Logs enabled for all VPCs

• How to check: Console > VPC > Your VPCs > select VPC > Flow Logs tab, or:

  aws ec2 describe-vpcs --query 'Vpcs[*].VpcId' --output text | xargs -I{} aws ec2 describe-flow-logs --filter Name=resource-id,Values={}
  
• Pass: Every VPC has flow logs enabled
• Fail: VPCs without flow logs
• Remediation: Enable flow logs for each VPC:

  aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-xxxx --traffic-type ALL --log-destination-type cloud-watch-logs --log-group-name vpc-flow-logs
  
  Flow logs are essential for security investigation and GuardDuty threat detection.

[MEDIUM] Multiple Availability Zones used

• How to check: Review subnet configuration across AZs
• Pass: Resources distributed across at least 2 AZs
• Fail: All resources in single AZ
• Remediation: Create subnets in multiple AZs. Configure Auto Scaling groups and load balancers for multi-AZ. This improves both availability and security (limits blast radius).

[LOW] VPC endpoints configured for AWS service access

• How to check: Console > VPC > Endpoints
• Pass: Gateway endpoints for S3 and DynamoDB; interface endpoints for commonly used services
• Fail: All AWS API calls traverse internet gateway
• Remediation: Create VPC endpoints for frequently accessed AWS services. This reduces internet exposure and often improves latency. Start with S3 (gateway endpoint, free) and security services like CloudTrail, Security Hub.

Security Groups and NACLs (5 items)

Security groups are your primary network firewall. Misconfigurations here are among the most common and dangerous findings.

[CRITICAL] No security groups allow SSH (22) from 0.0.0.0/0

• How to check: Console > EC2 > Security Groups, filter for port 22 rules, or:

  aws ec2 describe-security-groups --filters Name=ip-permission.from-port,Values=22 Name=ip-permission.cidr,Values='0.0.0.0/0' --query 'SecurityGroups[*].[GroupId,GroupName]'
  
• Pass: No results returned
• Fail: Security groups with SSH open to internet
• Remediation: Remove 0.0.0.0/0 rules for SSH. Use AWS Systems Manager Session Manager instead, which requires no open inbound ports. If SSH must be used, restrict to specific bastion host or VPN IP ranges.

[CRITICAL] No security groups allow RDP (3389) from 0.0.0.0/0

• How to check: Same approach as SSH but for port 3389

  aws ec2 describe-security-groups --filters Name=ip-permission.from-port,Values=3389 Name=ip-permission.cidr,Values='0.0.0.0/0' --query 'SecurityGroups[*].[GroupId,GroupName]'
  
• Pass: No results returned
• Fail: Security groups with RDP open to internet
• Remediation: Remove 0.0.0.0/0 rules for RDP. Use Session Manager for Windows instance access. If RDP is required, use a bastion host in a separate VPC with restricted access.

[HIGH] Default security groups have no inbound or outbound rules

• How to check: Console > EC2 > Security Groups, filter for "default", or:

  aws ec2 describe-security-groups --filters Name=group-name,Values=default --query 'SecurityGroups[*].[VpcId,IpPermissions,IpPermissionsEgress]'
  
• Pass: Default security groups have no rules (empty IpPermissions arrays)
• Fail: Default security groups with rules (default allows all traffic within the group)
• Remediation: Remove all rules from default security groups. Create purpose-specific security groups for resources. Never use default security groups for actual workloads.

[MEDIUM] Security group rules documented with descriptions

• How to check: Review security group rules for Description field
• Pass: All rules have meaningful descriptions explaining their purpose
• Fail: Rules with empty or generic descriptions
• Remediation: Add descriptions to all security group rules explaining what traffic they allow and why. This helps during audits and incident investigation.

[MEDIUM] NACLs configured for additional subnet protection

• How to check: Console > VPC > Network ACLs
• Pass: Custom NACLs with appropriate rules for sensitive subnets
• Fail: Using only default NACL (allows all traffic)
• Remediation: Create custom NACLs for database and sensitive subnets. NACLs are stateless, so both inbound and outbound rules are needed. They provide defense-in-depth beyond security groups.

Internet-Facing Resources (3 items)

Resources exposed to the internet need additional protection layers.

[HIGH] AWS WAF configured for public-facing applications

• How to check: Console > WAF & Shield > Web ACLs, or:

  aws wafv2 list-web-acls --scope REGIONAL
  aws wafv2 list-web-acls --scope CLOUDFRONT
  
• Pass: WAF associated with all public-facing ALBs, API Gateways, and CloudFront distributions
• Fail: Internet-facing resources without WAF protection
• Remediation: Create WAF web ACLs with AWS Managed Rules (Core Rule Set, Known Bad Inputs). Associate with all public resources. Enable rate limiting to protect against volumetric attacks.

[MEDIUM] CloudFront distributions use HTTPS only

• How to check: Console > CloudFront > Distributions, check Viewer Protocol Policy
• Pass: All distributions configured for "Redirect HTTP to HTTPS" or "HTTPS Only"
• Fail: Distributions allowing HTTP
• Remediation: Update viewer protocol policy to redirect HTTP to HTTPS. Ensure custom SSL certificates are configured if using custom domains. Enforce minimum TLS 1.2.

[LOW] Shield Advanced considered for critical applications

• How to check: Console > WAF & Shield > AWS Shield
• Pass: Shield Advanced enabled for business-critical applications, or documented decision to accept Shield Standard protection
• Fail: No consideration of DDoS protection for critical applications
• Remediation: Evaluate Shield Advanced for applications where downtime has significant business impact. Shield Standard (free) protects against common attacks. Shield Advanced adds 24/7 DDoS Response Team access and cost protection.

Data Protection Checklist (10 Items)

Encryption is your last line of defense. If other controls fail and attackers access your data, proper encryption ensures they get encrypted garbage instead of readable customer data.

Encryption at Rest (4 items)

All data stored in AWS should be encrypted. Since January 2023, S3 encrypts new objects by default, but other services and legacy data need verification.

[HIGH] EBS encryption enabled by default

• How to check: Console > EC2 > Settings > EBS encryption, or:

  aws ec2 get-ebs-encryption-by-default
  
• Pass: EbsEncryptionByDefault: true
• Fail: EbsEncryptionByDefault: false
• Remediation: Enable account-wide EBS encryption:

  aws ec2 enable-ebs-encryption-by-default
  
  This applies to all new volumes. Existing unencrypted volumes require creating encrypted snapshots and new volumes.

[HIGH] RDS instances encrypted

• How to check: Console > RDS > Databases, check Encryption column, or:

  aws rds describe-db-instances --query 'DBInstances[*].[DBInstanceIdentifier,StorageEncrypted]'
  
• Pass: All instances show StorageEncrypted: true
• Fail: Unencrypted RDS instances
• Remediation: RDS encryption uses AES-256 and cannot be enabled on existing unencrypted instances. Create an encrypted snapshot, then restore to a new encrypted instance. Plan for migration and testing.

[HIGH] S3 default encryption configured on all buckets

• How to check: Console > S3 > select bucket > Properties > Default encryption, or:

  aws s3api list-buckets --query 'Buckets[*].Name' --output text | xargs -I{} sh -c 'echo "Bucket: {}"; aws s3api get-bucket-encryption --bucket {} 2>&1'
  
• Pass: All buckets have default encryption configured (SSE-S3 or SSE-KMS)
• Fail: Buckets without default encryption (legacy buckets created before January 2023)
• Remediation: Enable default encryption:

  aws s3api put-bucket-encryption --bucket BUCKET_NAME --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'
  

[MEDIUM] Customer managed KMS keys for sensitive workloads

• How to check: Review KMS key usage for sensitive data stores
• Pass: Sensitive data encrypted with customer managed keys (you control key policy)
• Fail: Relying solely on AWS managed keys for data requiring strict access control
• Remediation: Create customer managed KMS keys for sensitive workloads. This provides audit trails via CloudTrail, fine-grained access control via key policies, and cross-account sharing capabilities.

Encryption in Transit (3 items)

Data moving between systems needs protection from interception and tampering.

[HIGH] S3 bucket policies require HTTPS (aws:SecureTransport)

• How to check: Review bucket policies for SecureTransport condition, or use Config rule s3-bucket-ssl-requests-only
• Pass: All buckets have policies denying requests without SecureTransport
• Fail: Buckets accessible over HTTP
• Remediation: Add this policy to all buckets:

  {
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::BUCKET", "arn:aws:s3:::BUCKET/*"],
    "Condition": {"Bool": {"aws:SecureTransport": "false"}}
  }
  

[HIGH] RDS connections use SSL/TLS

• How to check: Review RDS parameter groups for rds.force_ssl parameter, check application connection strings
• Pass: SSL/TLS enforced at database level or all applications use SSL connections
• Fail: Unencrypted database connections possible
• Remediation: For PostgreSQL, set rds.force_ssl=1 in parameter group. For MySQL, set require_secure_transport=ON. Update application connection strings to use SSL and verify certificates.

[MEDIUM] Load balancers terminate TLS with modern security policies

• How to check: Console > EC2 > Load Balancers > select ALB > Listeners, or:

  aws elbv2 describe-listeners --load-balancer-arn ALB_ARN --query 'Listeners[*].[Protocol,SslPolicy]'
  
• Pass: HTTPS listeners using ELBSecurityPolicy-TLS13-1-2-2021-06 or newer
• Fail: HTTP only or outdated TLS policies (TLS 1.0, 1.1)
• Remediation: Update listener security policy to enforce TLS 1.2 minimum. TLS 1.3 preferred for modern applications. Remove HTTP listeners unless needed for redirect-only.

S3 Bucket Security (3 items)

S3 misconfigurations have caused some of the highest-profile cloud data breaches. These checks are critical.

[CRITICAL] S3 Block Public Access enabled at account level

• How to check: Console > S3 > Block Public Access settings for this account, or:

  aws s3control get-public-access-block --account-id $(aws sts get-caller-identity --query Account --output text)
  
• Pass: All four settings enabled (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets)
• Fail: Any setting disabled
• Remediation: Enable all Block Public Access settings at account level:

  aws s3control put-public-access-block --account-id ACCOUNT_ID --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
  
  This prevents accidental public bucket creation. For buckets that legitimately need public access, use CloudFront with Origin Access Control instead.

[HIGH] No buckets with public access (unless explicitly required)

• How to check: Console > S3, check "Access" column, or use IAM Access Analyzer for S3
• Pass: No buckets show "Public" or "Objects can be public" (except documented exceptions)
• Fail: Buckets with public access that shouldn't be public
• Remediation: Review each public bucket. Most public buckets should use CloudFront instead. If public access is required, document the business justification and ensure Block Public Access is still enabled at account level (bucket-level settings override).

[MEDIUM] S3 versioning enabled for critical buckets

• How to check: Console > S3 > select bucket > Properties > Bucket Versioning
• Pass: Versioning enabled for buckets containing important data
• Fail: Critical data in non-versioned buckets
• Remediation: Enable versioning to protect against accidental deletion and ransomware:

  aws s3api put-bucket-versioning --bucket BUCKET_NAME --versioning-configuration Status=Enabled
  
  Consider S3 Object Lock for compliance requirements preventing even root from deleting objects.

Logging and Detection Checklist (8 Items)

Without proper logging, you can't investigate incidents or detect threats. These services form your security visibility foundation.

CloudTrail Configuration (3 items)

CloudTrail records every AWS API call. It's the foundation of AWS audit trails and essential for security investigation.

[CRITICAL] CloudTrail enabled with multi-region trail

• How to check: Console > CloudTrail > Trails, or:

  aws cloudtrail describe-trails --query 'trailList[*].[Name,IsMultiRegionTrail,IsOrganizationTrail]'
  
• Pass: At least one trail with IsMultiRegionTrail: true
• Fail: Single-region trails only or no trails
• Remediation: Create a multi-region trail:

  aws cloudtrail create-trail --name organization-trail --s3-bucket-name cloudtrail-logs-bucket --is-multi-region-trail --enable-log-file-validation
  aws cloudtrail start-logging --name organization-trail
  
  For AWS Organizations, create an organization trail for all accounts.

[HIGH] CloudTrail log file validation enabled

• How to check: Console > CloudTrail > Trails > select trail, check Log file validation
• Pass: LogFileValidationEnabled: true
• Fail: Log file validation disabled
• Remediation: Enable log file validation when creating trail or update existing trail. Validation uses SHA-256 digests to detect log tampering.

[HIGH] CloudTrail logs encrypted with KMS

• How to check: Console > CloudTrail > Trails > select trail, check KMS key
• Pass: Trail configured with KMS encryption key
• Fail: Using S3-managed keys (SSE-S3) or no encryption
• Remediation: Update trail to use KMS encryption. This provides additional access control through key policy and audit trail of who accessed logs.

Security Monitoring Services (3 items)

These services analyze logs and configurations to detect threats and misconfigurations automatically.

[HIGH] GuardDuty enabled in all regions

• How to check: Console > GuardDuty, check each region, or:

  for region in $(aws ec2 describe-regions --query 'Regions[*].RegionName' --output text); do
    echo "Region: $region"
    aws guardduty list-detectors --region $region
  done
  
• Pass: Detector exists in every region
• Fail: GuardDuty disabled in some regions
• Remediation: Enable GuardDuty in all regions. Attackers can operate in any region, and disabled regions create blind spots. Enable all protection plans (S3, EKS, Malware, RDS, Lambda).

[HIGH] Security Hub enabled with AWS Foundational Security Best Practices

• How to check: Console > Security Hub > Security standards
• Pass: Security Hub enabled with FSBP standard active
• Fail: Security Hub disabled or no standards enabled
• Remediation: Enable Security Hub with default standards:

  aws securityhub enable-security-hub --enable-default-standards
  
  Review your security score weekly and address Critical and High findings.

[MEDIUM] AWS Config enabled with recording in all regions

• How to check: Console > Config > Settings, or:

  aws configservice describe-configuration-recorder-status
  
• Pass: Configuration recorder recording in all regions
• Fail: Config not enabled or limited regions
• Remediation: Enable Config with all resource types. Deploy conformance packs for automated compliance checking against CIS Benchmarks and AWS Foundational Best Practices.

Alerting and Response (2 items)

Detection without alerting is just logging. You need to know when threats are detected.

[HIGH] CloudWatch alarms for critical security events (root login, unauthorized API calls)

• How to check: Console > CloudWatch > Alarms, review security-related alarms
• Pass: Alarms configured for root login, IAM changes, CloudTrail configuration changes, security group changes
• Fail: No security event alarms
• Remediation: Create metric filters and alarms for critical events. At minimum: root account usage, IAM policy changes, CloudTrail modifications, failed console logins, security group changes. Route alerts to SNS topics monitored by your security team.

[MEDIUM] GuardDuty findings routed to Security Hub with automated notifications

• How to check: Security Hub shows GuardDuty findings, EventBridge rules for findings
• Pass: GuardDuty findings appear in Security Hub, high-severity findings trigger notifications
• Fail: No integration or alerting for findings
• Remediation: GuardDuty integrates with Security Hub automatically when both are enabled. Create EventBridge rules to route high and critical findings to SNS for immediate notification:

  {
    "source": ["aws.securityhub"],
    "detail-type": ["Security Hub Findings - Imported"],
    "detail": {"findings": {"Severity": {"Label": ["CRITICAL", "HIGH"]}}}
  }
  

Compute Security Checklist (10 Items)

Compute resources, including EC2 instances, Lambda functions, and containers, run your workloads. Misconfigurations here can expose your applications and data.

EC2 Instance Security (4 items)

EC2 instances require configuration beyond the defaults to be secure.

[HIGH] IMDSv2 required on all instances (IMDSv1 disabled)

• How to check: Console > EC2 > Instances > select instance > Actions > Instance settings > Modify instance metadata options, or:

  aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,MetadataOptions.HttpTokens]'
  
• Pass: All instances show HttpTokens: required
• Fail: Instances with HttpTokens: optional (allows IMDSv1)
• Remediation: IMDSv1 is vulnerable to SSRF attacks. Require IMDSv2:

  aws ec2 modify-instance-metadata-options --instance-id i-xxxx --http-tokens required --http-endpoint enabled
  
  Set account-wide default for new instances via EC2 settings.

[HIGH] No EC2 instances with administrative IAM roles

• How to check: Review instance profiles for attached policies

  aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,IamInstanceProfile.Arn]' --output text | grep -v None
  
  Then check each role for admin policies.
• Pass: No instance roles have AdministratorAccess or equivalent
• Fail: Instances with admin IAM roles
• Remediation: Replace admin policies with specific permissions needed for the workload. Use IAM Access Analyzer to generate least-privilege policies based on actual usage.

[MEDIUM] Systems Manager Session Manager used instead of SSH keys

• How to check: Review how teams access instances, check for SSH key pairs in use
• Pass: Session Manager is primary access method, SSH keys eliminated or minimized
• Fail: SSH keys distributed to team members for instance access
• Remediation: Configure Session Manager for instance access. Install SSM Agent (pre-installed on Amazon Linux 2+). Create IAM policies allowing ssm:StartSession. Session Manager provides audit logging and eliminates exposed SSH ports.

[MEDIUM] Amazon Inspector scanning enabled

• How to check: Console > Inspector > Account management
• Pass: Inspector enabled for EC2, ECR, and Lambda scanning
• Fail: Inspector not enabled or scanning disabled
• Remediation: Enable Inspector for continuous vulnerability scanning. Inspector scans for OS vulnerabilities, application dependencies, and network exposure. Integrates with Security Hub for centralized findings.

Lambda Function Security (3 items)

Lambda functions have unique security considerations around runtime versions and IAM permissions.

[HIGH] All functions using supported runtimes

• How to check: Console > Lambda > Functions, check Runtime column, or:

  aws lambda list-functions --query 'Functions[*].[FunctionName,Runtime]'
  
• Pass: All functions use runtimes in standard support (not deprecated)
• Fail: Functions using deprecated runtimes (Python 3.7, Node.js 14, etc.)
• Remediation: Upgrade functions to supported runtimes. Deprecated runtimes receive no security patches. Review AWS Lambda runtime support policy for current deprecation schedule.

[HIGH] Lambda functions have least privilege IAM roles

• How to check: Review Lambda execution role policies for each function
• Pass: Functions have specific permissions for their needs (e.g., specific DynamoDB tables, specific S3 buckets)
• Fail: Functions with * resources or broad service permissions
• Remediation: Refine IAM policies to specific resources. Use IAM Access Analyzer to identify unused permissions. Common mistake: dynamodb:* when function only needs GetItem on one table.

[MEDIUM] Lambda code scanning enabled in Inspector

• How to check: Console > Inspector > Account management > Lambda scanning
• Pass: Lambda standard scanning and Lambda code scanning enabled
• Fail: Code scanning not enabled
• Remediation: Enable Lambda code scanning to identify vulnerabilities in custom code, not just dependencies. This catches security issues in your application logic.

Container Security (3 items)

Container environments add layers that each need security attention.

[HIGH] ECR image scanning enabled

• How to check: Console > ECR > Repositories > select repo > Scan on push
• Pass: Scan on push enabled, or Inspector scanning configured for ECR
• Fail: No image scanning
• Remediation: Enable scan on push for all repositories. Better: enable Inspector enhanced scanning which rescans as new CVEs are published, not just at push time.

[HIGH] EKS clusters using supported Kubernetes versions

• How to check: Console > EKS > Clusters, check Kubernetes version
• Pass: All clusters on supported versions (check Amazon EKS Kubernetes versions)
• Fail: Clusters on deprecated versions
• Remediation: Plan cluster upgrades to supported versions. Deprecated versions don't receive security patches. EKS supports versions for approximately 14 months after release.

[MEDIUM] Container images scanned in CI/CD before deployment

• How to check: Review CI/CD pipeline configuration
• Pass: Pipeline fails on critical vulnerabilities before images reach production
• Fail: Images deployed without scanning or without failing on findings
• Remediation: Integrate Inspector or ECR scanning into CI/CD. Set thresholds to fail builds on critical vulnerabilities. This shifts security left and catches issues before production.

Prioritizing Your Findings

You've run through the checklist and found issues. Now what? Not everything needs fixing immediately. Risk-based prioritization ensures you address the most dangerous issues first.

The framework below helps you decide what to fix now versus what can wait. This is based on actual risk, not just the severity label I've assigned.

Risk-Based Prioritization Framework

When evaluating each finding, consider four factors:

Severity: How bad is the potential impact if this is exploited? Root account without MFA is severe because it enables complete account takeover. An unused security group is less severe because it's not currently attached to anything.

Exploitability: How easy is this to exploit? A security group allowing SSH from 0.0.0.0/0 is trivially exploitable. An overly permissive IAM policy requires an attacker to already have some access.

Exposure: Is this resource publicly accessible? A misconfigured public S3 bucket is more urgent than a misconfigured internal S3 bucket.

Compliance Impact: Will this fail an audit? If you have SOC 2 certification to maintain, compliance-related findings have business urgency beyond pure security risk.

Critical Items (Fix Immediately)

These findings represent active security risks. Drop everything and fix these today.

• Root account without MFA: One password away from complete account compromise
• Security groups with 0.0.0.0/0 for SSH (22) or RDP (3389): Brute force attacks begin within minutes of exposure
• Publicly accessible S3 buckets with sensitive data: Data breaches happen from exactly this misconfiguration
• CloudTrail disabled or single-region only: You can't investigate what you can't see
• IAM access keys for root user: Should never exist

High Priority (Fix Within 30 Days)

Significant exposure that increases attack surface or violates critical best practices.

• Unencrypted RDS databases or EBS volumes: Data at rest without protection
• IAM users without MFA: Credential compromise risk
• Access keys not rotated in 90+ days: Increased window of exposure if compromised
• GuardDuty not enabled in all regions: Detection blind spots
• Default security groups in use: Overly permissive default rules
• Unsupported Lambda runtimes: No security patches available

Medium and Low Priority Items

These improve your security posture but don't represent immediate exploitable risk.

• VPC endpoints not configured: Defense-in-depth enhancement
• Security group rules without descriptions: Documentation improvement
• S3 versioning not enabled: Data protection enhancement
• Shield Advanced not evaluated: DDoS protection consideration

Resource Constraints Guidance

If you're a small team with limited time, focus exclusively on Critical items first. A single engineer can address critical findings across one account in 2-4 hours.

For larger teams, parallelize: one person on IAM, one on network, one on data protection. Use Security Hub findings to track progress and verify remediation.

Compliance-Specific Items

If you're working toward specific compliance certifications, certain checklist items map directly to compliance requirements. This section helps you prioritize based on your compliance needs.

SOC 2 Alignment

SOC 2 Trust Service Criteria focus on security, availability, processing integrity, confidentiality, and privacy. Key checklist items for SOC 2:

• Security: IAM MFA, access key rotation, CloudTrail logging, encryption at rest and in transit
• Availability: Multi-AZ deployments, backup configurations
• Confidentiality: S3 Block Public Access, KMS encryption, security group restrictions

AWS Audit Manager provides pre-built frameworks for SOC 2 with 15 automated and 46 manual controls. Access SOC reports via AWS Artifact to verify AWS's compliance with their portion of shared responsibility.

HIPAA Considerations

If handling Protected Health Information (PHI), additional requirements apply:

• Business Associate Agreement (BAA): Must be in place with AWS before processing PHI
• HIPAA-eligible services only: Not all AWS services are covered. Use only services listed in AWS HIPAA eligible services
• Encryption requirements: PHI must be encrypted at rest and in transit
• Access logging: Comprehensive audit trails for all PHI access

AWS Audit Manager includes HIPAA frameworks with automated evidence collection.

PCI DSS Requirements

For payment card data processing:

• Network segmentation: Cardholder data environment must be isolated
• Encryption: TLS 1.2+ for transmission, encryption at rest for stored card data
• Logging: Comprehensive audit trails with tamper protection
• Access control: Strict least privilege for cardholder data access

AWS maintains PCI DSS Level 1 Service Provider certification. Access the Attestation of Compliance (AOC) via AWS Artifact.

CIS AWS Foundations Benchmark

The CIS Benchmark provides specific, actionable security recommendations. Security Hub includes the CIS AWS Foundations Benchmark standard with automated checks.

• Level 1: Basic security hygiene applicable to all organizations
• Level 2: Additional controls for sensitive environments

Enable the CIS standard in Security Hub for automated compliance checking:

aws securityhub batch-enable-standards --standards-subscription-requests '{"StandardsArn":"arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0"}'

When DIY Isn't Enough

I've given you the complete checklist I use for security reviews. You can absolutely run through this yourself and improve your security posture significantly. But let me be honest about when DIY approaches hit their limits.

Signs You Need Professional Help

Complex multi-account environments (10+ accounts): The checklist scales, but the effort multiplies. Aggregating findings, understanding cross-account dependencies, and coordinating remediation across teams requires experience and tooling beyond what most internal teams have.

Compliance audit preparation with tight timelines: If you need SOC 2 certification in 90 days, learning compliance requirements while implementing them is risky. Experienced practitioners know the shortcuts and pitfalls.

Previous security incident requiring forensic analysis: Post-incident analysis requires skills most teams don't maintain. Preserving evidence, building timelines, identifying root cause, and validating remediation completeness benefit from external expertise.

Findings you don't know how to remediate: The checklist tells you what's wrong, but some remediations require architectural changes. Migrating from IAM users to IAM Identity Center, redesigning VPCs for proper segmentation, or implementing least privilege at scale are projects, not tasks.

Lack of internal security expertise: If your team is excellent at development and operations but doesn't have security specialists, external review catches what internal teams miss. Security requires different thinking patterns than building features.

What Professional Reviews Include Beyond This Checklist

This checklist covers configuration-level security. Professional reviews go deeper:

Custom threat modeling for your architecture: Understanding how your specific application architecture creates attack surfaces that generic checklists miss.

Architecture review and recommendations: Not just "is this misconfigured" but "is this the right architecture." Sometimes the right fix is redesign, not reconfiguration.

Compliance gap analysis with remediation roadmap: Mapping your current state to compliance requirements and creating prioritized plans that account for dependencies and effort.

Penetration testing and vulnerability assessment: Actively attempting to exploit vulnerabilities to validate controls work under attack. The checklist finds misconfigurations, pen tests find exploitable vulnerabilities.

Ongoing monitoring and response setup: Moving from point-in-time assessment to continuous security operations.

Next Steps

If you've worked through this checklist and found issues you're confident remediating, that's excellent. Most organizations can handle the foundational items internally.

If you've found findings that concern you, have compliance timelines to meet, or want validation that you haven't missed something, consider a professional AWS security audit to understand your options.

For organizations that want expert assessment of their AWS security posture, I conduct comprehensive security reviews that identify misconfigurations, compliance gaps, and architectural weaknesses this checklist can't catch.

Key Takeaways

You now have the complete checklist I use for professional security reviews. Let me summarize what matters most.

Start with the critical items. Root MFA, no 0.0.0.0/0 for SSH/RDP, S3 Block Public Access at account level, CloudTrail in all regions. These prevent the misconfigurations that cause actual breaches.

Enable the detection foundation. Security Hub, GuardDuty, Config, and CloudTrail form your security visibility layer. Without them, you're flying blind.

Document findings and create a remediation roadmap. Track what you found, prioritize by risk, and schedule fixes. A finding without a remediation plan is just awareness.

Schedule regular reviews. Quarterly for stable environments. After significant infrastructure changes. Before compliance audits. After security incidents. Security posture degrades over time as new resources are created and configurations drift.

Know when to get help. DIY works for many organizations, especially for foundational security. But compliance requirements, complex environments, and post-incident analysis often benefit from experienced practitioners.

Your immediate action: Run through the critical items in the IAM and Network sections today. It takes less than an hour and addresses your highest risks. Then schedule time for the full checklist.

Have questions about specific findings or want to discuss what you discovered? Drop a comment below.