Checklist · Security
AWS Account Security Checklist
Opens with creditsAn AWS account security checklist for teams that run real workloads on AWS without a dedicated security team. It covers the root user, human and workload access, multi-account guardrails, CloudTrail and threat detection, S3 and data protection, EC2 and network exposure, and readiness for a leaked key, with an AWS CLI command or console check for each item.
Written by Tauseef Fayyaz8 chapters, 38 checksAbout 22 minReviewed 13 October 2026What you will learn
8 chapters · about 22 min
1The root userChecks that the one identity with unlimited power over the account is locked away, protected by MFA and watched.6 checks · 4 min
- 1The root user has MFA, ideally more than one device
- 2The root user has no access keys
- 3Root is used only for tasks that require it, and its email is a group address
- 4Root recovery channels are controlled by different people
- 5In AWS Organizations, member account root credentials are removed or restricted
- 6Any root sign-in or root API call sends an alert to a person
6 in this chapterOpen this chapter2Human accessChecks that people sign in through a central identity, get temporary credentials, use strong MFA and hold only the permissions they use.5 checks · 3 min
- 1People sign in through IAM Identity Center or another identity provider
- 2Every remaining IAM user with a console password has MFA
- 3Developers use the CLI with temporary credentials, not personal access keys
- 4Unused users, roles, keys and permissions are reviewed and removed
- 5Permissions are narrowed from broad managed policies toward least privilege
5 in this chapterOpen this chapter- Workload and pipeline accessChecks that applications and CI/CD get temporary credentials from roles, scoped to what they do, instead of stored access keys.4 checks · 2 minOpens with credits
- Accounts and guardrailsChecks that production is separated from everything else and that organization-wide guardrails stop the most dangerous changes.4 checks · 2 minOpens with credits
- Logging and threat detectionChecks that every API call is recorded somewhere it cannot be erased, and that suspicious activity reaches a person.6 checks · 3 minOpens with credits
- S3 and data protectionChecks that storage is private by default, encrypted, never exposed to the internet by accident, and backed up somewhere safe.5 checks · 3 minOpens with credits
- EC2, metadata and network exposureChecks that instances cannot leak their role credentials, and that nothing administrative is open to the whole internet.5 checks · 3 minOpens with credits
- Cost alerts and incident readinessChecks that you hear about abuse quickly, AWS can reach the right people, and the team knows what to do when a key leaks.3 checks · 2 minOpens with credits
About this checklist
This AWS account security checklist covers the settings that decide whether one leaked key or one public bucket becomes a bad week. Most AWS incidents that reach the news are not exotic: an access key committed to a repository, a root user without MFA, an S3 bucket opened "for a minute", or an instance whose metadata endpoint handed out its role credentials through an SSRF bug. Each of these has a specific setting that prevents it, and each can be checked in a few minutes.
The checks follow AWS's own guidance: the IAM security best practices, the root user best practices, the CloudTrail security best practices, the S3 Block Public Access and EC2 instance metadata documentation, and the security pillar of the AWS Well-Architected Framework. The first chapters deal with identity, because AWS recommends temporary credentials for people and workloads, phishing-resistant MFA and least privilege, and because a stolen credential is the most common way in. Later chapters cover logging and detection, data, compute and network exposure, and being ready when something does leak.
Each check has a severity (must, should or nice) and a concrete way to verify it, usually an AWS CLI command you can run with read-only permissions. If you use AWS Organizations, run the account-level checks in every account, not just the management account.
Common questions
What are the first things to secure in a new AWS account?
Add MFA to the root user and make sure it has no access keys, then stop using root. Set up IAM Identity Center for people, turn on a multi-Region CloudTrail trail and GuardDuty, enable S3 Block Public Access at the account level, set IMDSv2 as the default for EC2, and create a budget alert.
Should I use IAM users or IAM Identity Center?
AWS recommends that people use federation with an identity provider and temporary credentials, and it recommends IAM Identity Center for managing that across accounts. Keep IAM users only for specific cases that cannot use roles, such as some third-party tools, and protect them with MFA and key rotation.
What is IMDSv2 and why does it matter?
IMDSv2 is the session-based version of the EC2 instance metadata service. It requires a token obtained with a PUT request before metadata, including role credentials, can be read. That blocks the simple GET requests that SSRF bugs and misconfigured proxies can make. Instances accept both versions unless you require IMDSv2.
Is CloudTrail enabled by default?
CloudTrail Event history shows 90 days of management events without any setup, but AWS says it is not a permanent record and does not include every event type. For a lasting record, create a multi-Region trail, or an organization trail if you use AWS Organizations, that delivers logs to S3.
Are S3 buckets public by default?
No. New buckets, access points and objects do not allow public access by default. A bucket policy, access point policy or ACL can still grant it, which is why AWS recommends turning on all four Block Public Access settings at the account level as an override.
What should I do if my AWS access key is leaked?
Deactivate the key immediately, then check CloudTrail for what it did, including any new users, keys, roles or instances it created, and remove those. Replace the key with a role or temporary credentials where possible, and review your bill for unexpected resources.
Sources (8)
Checked against these, last on 13 October 2026.
- Security best practices in IAM, AWSdocs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
- Root user best practices for your AWS account, AWSdocs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html
- Security best practices in AWS CloudTrail, AWSdocs.aws.amazon.com/awscloudtrail/latest/userguide/best-practices-security.html
- Blocking public access to your Amazon S3 storage, AWSdocs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
- Configure the Instance Metadata Service options, AWSdocs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html
- Use the Instance Metadata Service to access instance metadata, AWSdocs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
- Security Pillar, AWS Well-Architected Framework, AWSdocs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html
- AWS Security Incident Response Guide, AWSdocs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Kubernetes Best PracticesRun workloads on Kubernetes that schedule well, survive restarts and node drains, and stay locked down: resources, probes, PDBs, Pod Security and RBAC.
- Terraform Best PracticesWrite Terraform that teams can review and change safely: file layout, version pinning, remote state with locking, secrets, modules, refactoring and tests.
- Secrets Management Best PracticesKeep API keys, passwords and tokens out of git, logs and browser bundles: secret managers, scanning, rotation, OIDC in CI and leak response.
Checklists
See all- Incident Response ChecklistPrepare for and handle production incidents: on-call, severity levels, declaring, roles, mitigation, security containment, status updates and blameless postmortems.
- Kubernetes Production ChecklistVerify a workload and its cluster before real traffic: requests and limits, probes, PDBs, spread, Pod Security, RBAC, network policies, secrets, images, autoscaling, upgrades and backups.
- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
Project structures
See all- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
- Kubernetes with Helm project structureA Helm chart repository for one app: the chart that
helm creategives you, grown into a tested, versioned package with per-environment values, unit tests, install tests in a kind cluster and releases to an OCI registry. For students who can write a Deployment by hand and want to know how a team organises charts. It is about the repo layout and what each file does, not about cluster design. - Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks.
Career questions
See all- Which cloud should I learn first: AWS, Azure or GCP?If you have no reason to choose otherwise, start with AWS: it has the largest market share and the most learning material. Choose Azure if the employers you want run on Microsoft, and GCP if you are heading into data and ML work at companies that use it. The concepts transfer, so the first cloud matters less than learning it properly.
- How do I practise on AWS, Azure or Google Cloud without getting a surprise bill?Use the free offer that fits you, set a budget alert before you create anything, tag every resource, build and destroy your labs with code, and run a five-minute check for the usual culprits, such as NAT gateways, load balancers, databases and public IPs, before you close your laptop.
- Are certifications like AWS or Google Cloud worth it for getting a tech job?It depends on the role. For cloud, DevOps, security and some data roles, a respected certification can help you get shortlisted, especially combined with a real project. For general software engineering roles, projects and skills matter far more. Do the certification to structure your learning, not as a replacement for building.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com