AWS Security Checklist for Production Environments

There is no shortage of AWS security checklists. The problem with most of them is that they are flat lists of fifty items with equal weight, so teams spend a week on low-impact settings while the root account still has access keys.

This AWS security checklist is ordered by impact. The first section covers the controls that prevent account takeover and data exposure. Later sections cover detection, resilience and hygiene. Each item includes a way to check it, so you can verify your own environment instead of taking anyone's word for it.

If you want a quick self-assessment before reading the detail, our free AWS Security Quick Check asks ten yes/no questions and returns a score with the most important gaps.

1. Identity and access (do these first)

Most serious AWS incidents start with a credential: a leaked access key, an over-privileged role or an unprotected root user.

• Root user has MFA and no access keys. AWS now enforces MFA for root users, but older accounts and member accounts may not have it set up.
• In AWS Organizations, member account root credentials are removed using centralized root access management, so privileged root tasks are performed from the management account only.
• Humans sign in through IAM Identity Center (or your identity provider via SAML), not long-lived IAM users.
• No long-lived access keys for people. Where IAM users must exist, keys are rotated and unused keys deleted.
• CI/CD uses OIDC federation, not stored access keys. GitHub Actions, GitLab and others can assume a role directly.
• IAM Access Analyzer is enabled for external access findings, and its unused access findings are reviewed.

Check for root access keys and credential age:

aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'
# 0 means the root user has no access keys

aws iam generate-credential-report && sleep 5
aws iam get-credential-report --query Content --output text | base64 -d \
  | cut -d, -f1,4,8,9,10,11,14,15,16 | column -t -s,

The credential report shows every IAM user, whether they have a password, when their keys were last used and whether MFA is active. Any key unused for 90 days is a candidate for deletion.

Common mistake: a "temporary" admin user created during setup, still active two years later, with access keys on a former contractor's laptop.

2. Logging you can trust

If something goes wrong, you need to know what happened. That requires logs that an attacker cannot quietly turn off.

• An organization-wide CloudTrail trail covers all regions and all accounts.
• Trail logs go to a dedicated log archive account, with S3 Object Lock or tight bucket policies so production administrators cannot delete them.
• Log file validation is enabled on the trail.
• An SCP prevents stopping or deleting the trail.
• VPC Flow Logs are enabled at least for production VPCs.

aws cloudtrail describe-trails \
  --query 'trailList[].{Name:Name,MultiRegion:IsMultiRegionTrail,Org:IsOrganizationTrail,Validation:LogFileValidationEnabled}'

3. Data exposure

• S3 Block Public Access is on at the account level, not only per bucket. New buckets have it on by default, but older buckets and account settings may not.
• No RDS instances or snapshots are public.
• No public AMIs or EBS snapshots unless you intend to publish them.
• Encryption at rest is on for EBS (enable EBS encryption by default per region), RDS and EFS.
• KMS key policies are reviewed for who can decrypt, not just who can administer keys.

aws s3control get-public-access-block --account-id "$(aws sts get-caller-identity --query Account --output text)"

aws rds describe-db-instances \
  --query 'DBInstances[?PubliclyAccessible==`true`].DBInstanceIdentifier'

aws ec2 get-ebs-encryption-by-default

Run the RDS and EBS checks in every region you use. Exposure in a region nobody looks at is still exposure.

4. Network exposure

• No security groups allow SSH (22) or RDP (3389) from the internet. Use AWS Systems Manager Session Manager instead of bastion hosts with open ports.
• Databases and caches sit in private subnets with no route to an internet gateway.
• Internet-facing load balancers terminate TLS with modern policies, and HTTP redirects to HTTPS.
• AWS WAF protects public applications and APIs where the traffic profile justifies it.
• EC2 instances require IMDSv2. Set it as the account default per region so new instances inherit it.

aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].{Id:GroupId,Name:GroupName,Ports:IpPermissions[].FromPort}'

aws ec2 get-instance-metadata-defaults

The security group query returns every group with any rule open to 0.0.0.0/0. Some will be legitimate (a public load balancer on 443). Review the rest.

5. Threat detection

Prevention fails eventually. Detection tells you when.

• Amazon GuardDuty is enabled in every region and account, with a delegated administrator.
• AWS Security Hub is enabled with the AWS Foundational Security Best Practices standard, aggregated to one account.
• High-severity findings reach a person. A finding in a console nobody opens is not detection. Route them through EventBridge to Slack, email or your incident tool.
• AWS Config records resource changes so you can answer "when did this security group change?"
• Billing alerts exist. An unexpected cost spike is often the first sign of compromised credentials used for crypto-mining.

aws guardduty list-detectors
aws securityhub get-enabled-standards

Common mistake: GuardDuty enabled in the primary region only. Attackers using stolen keys often launch resources in regions you do not monitor.

6. Workloads and secrets

• Secrets live in AWS Secrets Manager or SSM Parameter Store, not environment variables baked into images, user data or Terraform state.
• Container images are scanned in the pipeline and in Amazon ECR.
• Patching is automated for EC2 (Systems Manager Patch Manager) or instances are replaced from fresh images.
• Lambda and ECS task roles follow least privilege, with no "Action": "*" statements.

If your infrastructure is defined in Terraform, many of these checks can run automatically on every pull request. See Terraform security best practices and policy as code for how to enforce them.

7. Resilience and recovery

Security includes being able to recover from ransomware, accidental deletion or a compromised account.

• AWS Backup plans cover production data, with copies in a separate account.
• Backup vaults use AWS Backup Vault Lock where retention must be guaranteed.
• Restores are tested. A backup you have never restored is a hope, not a control.
• A documented incident response runbook says who does what if credentials leak, including how to revoke sessions and rotate keys.

How to use this AWS security checklist

Work through sections 1 to 3 first. They cover the controls whose absence leads directly to account takeover or data exposure. Sections 4 and 5 reduce the chance of an incident going unnoticed. Sections 6 and 7 close the gaps that typically appear in customer security questionnaires and audits such as SOC 2.

Then make it repeatable. A checklist run once before a launch drifts within months. Encode what you can as Security Hub controls, AWS Config rules or CI policies, so a regression shows up as a finding rather than at the next review.

Getting an outside view

Checking your own environment is a good start, but it is easy to miss what you do not know to look for. Our AWS Security & Hardening Audit reviews an account against these areas and more, ranks findings by risk and includes the fixes. If you are working toward SOC 2, the SOC 2 Failing-Controls Fix Sprint focuses on the controls auditors flag. For ongoing work, see Cloud Security & DevSecOps.

Not sure where your environment stands? Start with a Free Engineering Assessment.