How secure is your AWS environment right now? Most businesses cannot answer this confidently. This self-assessment gives you a structured way to evaluate your security posture in under 15 minutes. Answer each question honestly, tally your score, and you will know exactly where you stand — and where to focus your effort.
For each question, give yourself 1 point for Yes and 0 points for No. Be honest — this assessment is for your benefit, not anyone else's.
1. Is MFA enabled on your root account?
Why it matters: The root account has unrestricted access to everything in your AWS account. Without MFA, a single compromised password hands over complete control to an attacker. This is the single highest-impact security control you can implement. If no: Stop reading and enable MFA on root right now. Use a hardware key if possible. Store the recovery codes in a physical safe.
2. Do all IAM users with console access have MFA enabled?
Why it matters: Phishing attacks target individual users. Without MFA, stolen credentials from a phishing email provide direct access to your AWS console. Attackers routinely harvest credentials from data breaches and try them against cloud consoles. If no: Enforce MFA through an IAM policy condition that denies all actions unless MFA is present. Give users a 24-hour deadline to set up their authenticator.
3. Is CloudTrail enabled in all regions?
Why it matters: CloudTrail is your audit log for every API call made in your account. If it is only enabled in your primary region, attackers can operate undetected in other regions — spinning up resources, exfiltrating data, or establishing persistence. If no: Create a multi-region trail that logs to a centralized S3 bucket with log file validation enabled.
4. Is GuardDuty active in your account?
Why it matters: GuardDuty continuously monitors for malicious activity using threat intelligence and machine learning. It detects compromised instances communicating with known bad IPs, unusual API calls, cryptocurrency mining, and credential exfiltration — all without any configuration. If no: Enable GuardDuty in all regions. It takes two clicks and costs pennies per million events analyzed.
5. Is S3 Block Public Access enabled at the account level?
Why it matters: Public S3 buckets have caused headline-grabbing breaches exposing millions of records. Account-level Block Public Access acts as a safety net that prevents any bucket from being made public regardless of individual bucket policies or ACLs. If no: Enable all four Block Public Access settings at the account level in S3 settings. If you genuinely need a public bucket (like website hosting), use CloudFront instead.
6. Are there no public security group rules allowing SSH or RDP from 0.0.0.0/0?
Why it matters: Security groups allowing SSH (port 22) or RDP (port 3389) from anywhere expose your instances to constant brute-force attacks. Automated scanners find these within minutes of creation. If no: Restrict SSH/RDP access to specific IP ranges. Better yet, remove these rules entirely and use AWS Systems Manager Session Manager for remote access — it requires no open inbound ports.
7. Is encryption at rest enabled for all storage services?
Why it matters: Unencrypted data in S3, EBS, and RDS can be read in plaintext if backups, snapshots, or underlying storage are accessed by unauthorized parties. Encryption at rest is a compliance requirement for most frameworks (SOC 2, HIPAA, PCI-DSS) and costs virtually nothing with AWS-managed keys. If no: Enable default encryption on S3 buckets (SSE-S3 or SSE-KMS), encrypt EBS volumes, and enable encryption for RDS instances and their snapshots.
8. Has your backup strategy been tested with an actual restore?
Why it matters: Backups that have never been tested are assumptions, not protection. Ransomware attacks specifically target backup configurations to ensure victims cannot recover. A backup is only valuable if you can prove it restores correctly within your required recovery time. If no: Schedule a monthly restore test. Use AWS Backup with a test restore plan that automatically validates backup integrity. Document your Recovery Time Objective (RTO) and verify you can meet it.
9. Do your IAM policies follow the principle of least privilege?
Why it matters: Over-permissioned users and roles expand the blast radius of any compromise. If a developer's credentials are stolen and they have full admin access, the attacker owns your entire account. Least privilege limits damage to only the specific resources that compromised credentials can reach. If no: Run IAM Access Analyzer to identify unused permissions. Review Access Advisor to see which services each principal has actually used. Tighten policies to match actual usage patterns.
10. Are there no long-lived access keys older than 90 days?
Why it matters: Old access keys are high-value targets. They may have been committed to repositories, stored in plaintext, or shared via insecure channels over time. The longer a key exists, the more opportunities for it to be leaked. If no: Generate an IAM credential report to identify all keys older than 90 days. Rotate or eliminate them. Replace access keys with IAM roles wherever possible.
11. Are VPC flow logs enabled?
Why it matters: Flow logs capture metadata about network traffic in your VPC — source, destination, ports, and whether traffic was accepted or rejected. Without them, you have no visibility into network-level activity and cannot investigate lateral movement or data exfiltration during an incident. If no: Enable VPC flow logs on all VPCs and send them to CloudWatch Logs or S3. Configure log format to include all available fields for maximum forensic value.
12. Are budget alerts configured?
Why it matters: Unexpected cost spikes are frequently the first indicator of compromised credentials. Attackers use stolen AWS access to launch cryptocurrency miners or large compute fleets, generating massive bills within hours. Budget alerts at 50%, 80%, and 100% of expected spend provide early warning. If no: Create AWS Budget alerts that notify your team via email and SNS. Set them on overall account spend and on specific high-cost services like EC2 and RDS.
13. Does your team have a documented incident response plan?
Why it matters: When a breach occurs, every minute of confusion increases damage. Without a plan, teams waste critical time figuring out who to contact, how to isolate compromised resources, and how to preserve evidence. A documented plan with clear roles and procedures reduces mean time to containment. If no: Create a runbook that covers: who owns incident response, how to isolate compromised credentials and resources, how to preserve CloudTrail and VPC flow log evidence, communication procedures, and escalation paths. Test it with a tabletop exercise.
14. Are your EC2 instances and managed services regularly patched?
Why it matters: Known vulnerabilities with public exploits are the most commonly used attack vector. Once a CVE is published, automated scanning for vulnerable systems begins within hours. Unpatched systems are trivially compromised using freely available exploit tools. If no: Implement AWS Systems Manager Patch Manager to automate patching on a defined schedule. For managed services like RDS, enable automatic minor version upgrades. Establish a process for emergency patching of critical vulnerabilities within 48 hours.
15. Has your AWS environment had a security review in the past 12 months?
Why it matters: AWS environments drift over time. New resources get created without following standards, permissions accumulate, and team members change. Annual reviews identify configuration drift, new attack surfaces, and opportunities to adopt newer security features that were not available during initial setup. If no: Schedule a comprehensive review that covers IAM policies, network configuration, encryption settings, logging coverage, and compliance with your organization's security standards.
Your Score
13–15 Points: Good Shape
Your security fundamentals are solid. Focus on the gaps you identified and consider advanced controls like permission boundaries, SCPs, and automated remediation. Schedule quarterly reviews to maintain this posture.
9–12 Points: Gaps to Address
You have some controls in place but meaningful gaps exist. Prioritize the missing items by impact — MFA, CloudTrail, and GuardDuty should come first as they are quick wins with outsized security benefit. Build a 30-day remediation plan.
Below 9 Points: Urgent Attention Needed
Your AWS environment has significant security exposure. Multiple critical controls are missing, which means a breach is more likely a matter of when than if. We recommend an immediate professional security review to identify and prioritize your highest-risk items. Do not wait for an incident to take action.
Regardless of your score, the important thing is awareness. Every "No" answer represents a specific, fixable gap. Start with the items that take the least effort and provide the most protection: MFA everywhere, enable GuardDuty, and turn on CloudTrail in all regions. These three actions alone dramatically reduce your attack surface.