Start with identity and logging, then turn on threat detection and a central findings view. In AWS terms that means tight IAM policies, CloudTrail, GuardDuty and Security Hub CSPM, followed by data protection and checks on the code you deploy. The order matters more than the number of services.
Why identity first?
In AWS, almost every action is an API call authorized by IAM. A single over permissive role or leaked access key can undo every other control. Begin with the root account locked behind multi factor authentication and unused, then use roles with short lived credentials instead of long lived keys, and give each workload only the actions it needs.
IAM Access Analyzer helps here by reporting resources shared outside your account or organization, which catches open buckets and cross account trust you forgot about.
What should record what happens?
Turn on CloudTrail so API activity is recorded across accounts and regions, and send the logs to a separate, locked down account. When something goes wrong, those logs answer who did what and when. Without them an investigation relies on guessing.
What does threat detection add?
Amazon GuardDuty is a threat detection service that analyzes sources such as CloudTrail events, VPC flow logs and DNS logs to flag suspicious activity, for example calls from unusual locations or instances talking to known malicious hosts. It is useful early because it needs little setup compared with building detections yourself.
How do findings come together?
AWS Security Hub CSPM (cloud security posture management, the current name in AWS documentation) collects findings from AWS services and integrated partners and checks your configuration against security standards, giving one place to see and prioritize issues. It does not fix anything by itself, so someone has to own the queue.
Constructed example: a small team's first week
A five person startup has one AWS account and growing customer data. Day one, they enable multi factor authentication on root and create named roles for engineers. Day two, CloudTrail goes on organization wide, writing to a second account. Day three, GuardDuty and Security Hub are enabled and the first findings include a storage bucket readable by anyone and an access key unused for ten months. Both get fixed in an hour.
None of that required buying anything beyond the AWS services themselves. It required doing them in a sensible order.
What comes after the basics?
Add encryption with managed keys for storage and databases, backups with separate permissions, and network controls such as private subnets and restrictive security groups. Then look at the software you ship. Cloud configuration is only half of the attack surface. The libraries in your containers and functions carry vulnerabilities that no cloud setting fixes. Safeguard covers that side with dependency scanning, reachability analysis and policies that can gate a build, and it complements the AWS services rather than replacing them.
What about cost and noise?
Each service you enable adds findings and, in most cases, a usage charge, so check the current AWS pricing page for each one before you switch it on across every account. Start in your most important account, tune what you see, and expand. A short list of findings that people read beats a long list nobody opens.
It also helps to agree severity rules up front. Decide which finding types page someone at night, which go to a weekly review, and which you accept with a written reason. Without that, the first week's flood of results ends in a muted channel.
How to check or apply this
- Lock the root user with multi factor authentication and stop using it day to day.
- Replace long lived access keys with roles. Delete keys unused for 90 days.
- Enable CloudTrail in all regions and ship logs to a dedicated account.
- Enable GuardDuty and Security Hub CSPM in every account and region you use.
- Run IAM Access Analyzer and fix every external sharing finding you did not intend.
- Encrypt storage and databases, and restrict backup deletion.
- Assign an owner and a weekly time slot to the findings queue.
Quick check
Does Security Hub CSPM fix problems automatically?
No. It collects findings and checks configuration against standards. Fixing is up to your team, or to automation you build.
Is turning on every AWS security service a good plan?
Not without owners. Each service creates findings, and unreviewed findings add noise. Enable in order and staff the queue.
Sources
Last reviewed: 18 October 2026.
