CIS AWS Benchmark Checklist
An interactive AWS security hardening checklist built around the control sections of the CIS AWS Foundations Benchmark — Identity & Access Management, Storage, Logging, Monitoring and Networking. Tick each control Done, Not yet or N/A, then score your coverage per section and overall and get a prioritized remediation plan you can copy or download. Everything runs in your browser; nothing is uploaded.
Identity & Access Management
Root account protection, MFA, password policy and key hygiene.
- CriticalMFA is enabled for the root account
The root user has unrestricted access to the entire account. Protect it with a hardware or virtual MFA device so a leaked root password alone cannot be used.
- CriticalThe root account has no active access keys
Delete any root access keys. Programmatic access should come from least-privileged IAM roles or users, never from root credentials.
- HighThe root account is not used for everyday tasks
Reserve root strictly for the handful of operations that require it. Day-to-day work should use IAM identities with scoped permissions.
- HighMFA is enabled for every IAM user with console access
Any human login should require a second factor. Enforce MFA for all users that have a console password.
- MediumThe IAM password policy requires a length of at least 14 characters
Set an account password policy with a strong minimum length and complexity/reuse rules so console passwords resist guessing.
- HighAccess keys are rotated every 90 days or fewer
Long-lived keys that never rotate widen the window of a leaked credential. Rotate on a schedule and remove keys that are past it.
- MediumCredentials unused for 90+ days are disabled or removed
Dormant users, passwords and access keys are attack surface with no benefit. Disable or delete anything idle beyond your threshold.
- MediumPermissions are granted through groups or roles, not attached directly to users
Attaching policies to individual users makes access hard to audit. Assign permissions via groups and roles instead.
- HighNo custom policy grants full administrator ("*:*") access unnecessarily
Avoid Action "*" on Resource "*" in custom policies. Scope every grant to the specific actions and resources a workload needs.
Storage — S3 & encryption
Public-access blocks, encryption at rest and in transit.
- CriticalS3 Block Public Access is enabled at the account and bucket level
Turn on all four Block Public Access settings so a misconfigured ACL or bucket policy cannot silently expose data to the internet.
- HighS3 buckets have default encryption enabled
Enable default server-side encryption so every new object is encrypted at rest without relying on each uploader to request it.
- MediumS3 buckets deny non-HTTPS (non-TLS) requests
Add a bucket policy condition that denies requests where aws:SecureTransport is false, so objects are never fetched over plaintext.
- HighEBS volumes are encrypted (encryption-by-default enabled)
Enable account-level EBS encryption by default so new volumes and snapshots are encrypted at rest.
- HighRDS instances and snapshots are encrypted at rest
Managed databases often hold the most sensitive data. Ensure storage encryption is enabled on RDS instances and their snapshots.
- MediumVersioning (and MFA Delete) is enabled on sensitive buckets
Versioning protects against accidental or malicious overwrites and deletes; MFA Delete adds a second factor to destructive actions on critical buckets.
Logging — CloudTrail & Config
Account-wide audit trails, log integrity and configuration history.
- CriticalCloudTrail is enabled in all regions
A multi-region trail captures API activity everywhere, including regions you do not normally use, so attacker activity in an unused region is still recorded.
- HighCloudTrail log file validation is enabled
Log file integrity validation lets you detect whether trail log files were tampered with or deleted after delivery.
- MediumCloudTrail logs are encrypted with KMS
Encrypt trail log files with a KMS key so the audit record itself is protected and access to it is controlled and logged.
- CriticalThe CloudTrail S3 bucket is not publicly accessible
The bucket holding your audit logs must never be public. Confirm Block Public Access and a restrictive bucket policy.
- MediumAccess logging is enabled on the CloudTrail S3 bucket
Server access logging on the trail bucket records who read the logs, which matters during an incident investigation.
- HighAWS Config is enabled in all regions
Config records resource configuration changes over time, giving you the before/after history needed for drift detection and investigations.
Monitoring — metric filters & alarms
CloudWatch metric filters and alarms on security-relevant events.
- HighAn alarm fires on unauthorized API calls
A metric filter and alarm on unauthorized (AccessDenied) API activity surfaces probing and misconfigured access early.
- HighAn alarm fires on console sign-in without MFA
Alert when a console login succeeds without multi-factor authentication, which can indicate a weak or compromised identity.
- CriticalAn alarm fires on root account usage
Any use of the root account is rare and high-stakes. Alarm on it so a human can confirm it was expected.
- MediumAn alarm fires on IAM policy changes
Alerting on changes to policies, users, groups and roles catches both mistakes and privilege-escalation attempts.
- HighAn alarm fires on CloudTrail configuration changes
Disabling or reconfiguring CloudTrail is a classic way to blind defenders. Alarm on any change to the trail itself.
- MediumAn alarm fires on security group, NACL or route table changes
Network control changes can open the account to the internet. Alarm on changes to security groups, network ACLs and route tables.
Networking — security groups & VPC
Ingress exposure, default-deny security groups and flow logs.
- CriticalNo security group allows 0.0.0.0/0 to port 22 (SSH)
Open SSH to the whole internet invites brute-force and exploitation. Restrict port 22 to known management ranges or use a bastion / SSM.
- CriticalNo security group allows 0.0.0.0/0 to port 3389 (RDP)
Internet-exposed RDP is heavily scanned and attacked. Restrict port 3389 to specific sources or remove it entirely.
- MediumThe default security group of every VPC denies all traffic
The default security group should allow no inbound or outbound traffic, and no resource should rely on it, so nothing is exposed by accident.
- HighVPC flow logs are enabled for all VPCs
Flow logs capture accepted and rejected traffic metadata, which is essential for detecting and investigating network-level activity.
- HighNo other security group exposes a broad 0.0.0.0/0 ingress unnecessarily
Review every rule that allows the whole internet inbound. Keep only the ports that genuinely need public access (e.g. 443 on a load balancer).
- MediumVPC peering route tables follow least-access
Peering route tables should route only the specific CIDR ranges required, not blanket access between entire VPCs.
Runs entirely in your browser — nothing is uploaded. Your answers, the score and the remediation plan are computed locally with JavaScript and never leave this page, so you can assess a real AWS account without sending anything to a server.
What this tool is
- A free, interactive AWS security hardening checklist organized by the control sections of the CIS AWS Foundations Benchmark: Identity & Access Management, Storage, Logging, Monitoring and Networking.
- Tick each control Done, Not yet or N/A. You get a coverage percentage per section and an overall score — N/A controls are excluded from the denominator, so they never penalize you.
- Un-met controls become a remediation plan sorted by priority (critical first), with a plain-language explanation of why each one matters.
- Copy the scored report to your clipboard or download it as a .txt — useful for a readout, a ticket backlog or a point-in-time snapshot.
- Everything runs in your browser. No account data, answers or scores are ever uploaded — safe to assess a real AWS account offline.
What the CIS AWS Foundations Benchmark covers
The CIS AWS Foundations Benchmark is a consensus set of security configuration recommendations for Amazon Web Services from the Center for Internet Security. Rather than memorize it, this tool walks you through its major control sections with a representative set of well-known controls in each, so you can see at a glance where your account is hardened and where the gaps are.
The sections, briefly
- Identity & Access Management. Protecting the root account with MFA and no access keys, enforcing a strong password policy, requiring MFA for users, rotating keys, and avoiding broad administrator grants.
- Storage — S3 & encryption. Blocking public access to S3, enabling default encryption at rest for S3, EBS and RDS, requiring TLS, and protecting sensitive buckets with versioning.
- Logging — CloudTrail & Config. Enabling CloudTrail in all regions with log file validation and encryption, keeping the trail bucket private, and turning on AWS Config for a configuration history.
- Monitoring — metric filters & alarms. CloudWatch metric filters and alarms for security-relevant events such as root usage, console sign-in without MFA, unauthorized API calls and changes to IAM, CloudTrail and network controls.
- Networking — security groups & VPC. Keeping SSH and RDP off the open internet, locking down default security groups, enabling VPC flow logs, and reviewing broad ingress rules and peering routes.
How to use it
Go section by section and mark each control Done, Not yet or N/A. Use the per-section "Mark all" shortcuts to move quickly, then click Score & generate report. You get a coverage percentage for each section and an overall score, plus a remediation plan that lists every un-met control, critical ones first, with a short explanation of the risk. Copy it into a ticket, share it as a readout, or download it as a point-in-time snapshot.
Accuracy note: the controls here are based on publicly known CIS control themes and are described in our own words. This tool deliberately does not print versioned CIS recommendation ID numbers (such as "1.14"), because those are tied to a specific Benchmark release and change between versions. It is a fast, private gap review and prioritization aid — not a formal audit and not a substitute for evaluating your live configuration. For exact, versioned control IDs, consult the official CIS AWS Foundations Benchmark PDF.
Frequently asked questions
What is the CIS AWS Foundations Benchmark?
The CIS AWS Foundations Benchmark is a widely used set of security configuration recommendations for Amazon Web Services, published by the Center for Internet Security. It groups controls into areas such as Identity & Access Management, storage and encryption, logging, monitoring and networking, and for each one describes a recommended hardened setting (for example, enabling MFA on the root account or ensuring CloudTrail is on in all regions). It is a consensus baseline that many organizations map their AWS security posture against, and it underpins the CIS checks you will see in tools like AWS Security Hub.
Does this tool connect to my AWS account?
No. This is a self-assessment checklist, not a scanner. Nothing connects to AWS and no credentials are requested or used. You answer each control yourself based on what you know about your environment, and the coverage score and remediation plan are computed entirely in your browser. Because nothing is uploaded, it is safe to use while reviewing a real production account. To automatically evaluate live AWS settings you would use a CSPM scanner or AWS Security Hub; this tool is for a fast, private, human-driven gap review.
Why are there no CIS recommendation numbers like "1.14"?
Deliberately. CIS recommendation ID numbers are tied to a specific Benchmark version and they change between releases, so a number printed here could be wrong for the version you are using. To avoid giving you a false reference, this tool describes each control in plain language and groups controls by the Benchmark sections rather than citing versioned IDs. For the exact, authoritative control IDs that match your environment, download the official CIS AWS Foundations Benchmark PDF for the version you are assessing against.
How is the coverage percentage calculated?
For each section, coverage is the number of controls you marked Done divided by the number of applicable controls, where applicable means every control except the ones you marked N/A. So if a section has six controls and you mark three Done, coverage is 50%. If one of those six is N/A and three of the remaining five are Done, coverage is 60% (3 of 5). Unanswered controls and ones marked Not yet count toward the denominator but not the numerator, so they lower your score until you address them. The overall score aggregates met and applicable counts across every section the same way.
Is passing this checklist the same as being CIS compliant?
No. This is a representative selection of well-known controls meant for a fast gap review and prioritization exercise — it is not the complete Benchmark and it does not verify anything against your live configuration. Real CIS compliance means assessing every applicable recommendation in the official Benchmark against your actual AWS settings, usually with an automated tool, and keeping evidence. Use this checklist to find and prioritize gaps quickly, then confirm against the official CIS AWS Foundations Benchmark PDF and a scanner such as AWS Security Hub.