To secure AWS resources, start with identity: use temporary credentials and multifactor authentication, protect the root user, and grant least privilege. Then block unintended public access to storage, record activity with CloudTrail, and check findings regularly. AWS publishes these practices in its IAM and S3 documentation.
What do AWS's IAM best practices say first?
AWS's list opens with credentials. In order, it says to require human users to use federation with an identity provider and temporary credentials, require workloads to use temporary credentials through IAM roles, require MFA, update access keys when long-term credentials are unavoidable, and protect root user credentials.
For the second and third group, it says to apply least-privilege permissions. Start with AWS managed policies and move toward tighter ones, use IAM Access Analyzer to generate least-privilege policies based on access activity, and regularly review and remove unused users, roles, permissions, policies and credentials. It also recommends policy conditions to restrict access further, and checking public and cross-account access with Access Analyzer.
For multi-account setups, AWS suggests permissions guardrails across accounts, and permissions boundaries to delegate permission management within an account.
How do you prevent accidentally public storage?
Amazon S3's Block Public Access feature gives settings at the access point, bucket, account and AWS Organizations levels. AWS says new buckets, access points and objects do not allow public access by default, but users can change bucket policies, access point policies or object permissions to allow it. Block Public Access settings override those policies, so you can set a control that holds regardless of how a resource is created. There are four independent settings that can be combined.
The practical move is to turn Block Public Access on at the account level, and at the organization level if you use Organizations, then make any exceptions deliberate and documented. Use IAM Access Analyzer for S3 to review buckets that are public.
Why does logging matter, and what does CloudTrail give you?
CloudTrail records actions taken by a user, role or AWS service as events, including actions in the console, command line, SDKs and APIs. AWS describes three ways to record events. Event history is a searchable, immutable record of the past 90 days of management events in a Region, available automatically with no charge for viewing. CloudTrail Lake is a managed data lake for storing and querying events for audit and security, with retention you choose, up to about seven or ten years depending on the pricing option. A trail delivers events to S3 for longer-term storage.
Ninety days is often too short. If an incident is discovered after four months, Event history alone will not hold the evidence. Set up a trail or event data store that covers all Regions and all accounts, and protect the log destination from deletion.
What does a typical mistake look like?
Constructed example. A developer creates an IAM user with an access key to let a script upload files, and gives it full S3 access. The key is committed to a repository. Anyone who finds it can read every bucket in the account. With the practices above, the script would run under a role with temporary credentials, scoped to one bucket and one prefix, and a key would never exist to leak.
How to check or apply this
- Turn on MFA for the root user and follow AWS's guidance for protecting its credentials.
- Sign in through an identity provider and temporary credentials instead of long-lived IAM users.
- Give workloads roles, not stored keys. Search your repositories for committed keys.
- Review IAM Access Analyzer findings, remove unused access and tighten broad policies.
- Enable S3 Block Public Access at the account level, and review any public bucket.
- Enable a multi-Region CloudTrail trail or event data store, and send it to a protected location.
- Use infrastructure as code, so these settings are repeatable and reviewable.
- Revisit the list quarterly, since new services and teams add new exposure.
Quick check
Are long-term IAM user access keys ever acceptable?
AWS lists them only for use cases that require long-term credentials, and says to update those keys when needed. For people and for workloads running on AWS, prefer temporary credentials.
Does CloudTrail Event history replace a trail?
No. Event history covers the past 90 days of management events in a Region. For longer retention or other event types, create a trail or an event data store.
Sources
- AWS IAM User Guide, Security best practices in IAM
- Amazon S3 User Guide, Blocking public access to your Amazon S3 storage
- AWS CloudTrail User Guide, What is AWS CloudTrail
Last reviewed: 18 October 2026.
