A new AWS account is not safe simply because it is empty. Before the first workload goes live, close the three failure paths that matter most: account takeover, leaked long-lived keys, and unintended public access.

CONTROL 01Treat the root user as a recovery mechanism

The root user can reach every resource and billing control in the account. It has no place in daily operations. Give it a strong password and MFA, then remove any root access keys after confirming they are not in use.

CONTROL 02Give people temporary credentials, not IAM user keys

AWS recommends that human users assume roles and work with temporary credentials. For multi-account environments, use IAM Identity Center and permission sets. Do not build a process that depends on copying access keys into laptops, chat messages, or shared documents.

• Separate read-only work from privileged change access.
• Use aws configure sso for CLI sessions.
• Attach IAM roles to workloads instead of embedding user credentials.

CONTROL 03Remove administrator access from the daily path

Default sessions should carry limited permissions. Assume a separate administrator role only when a change requires it. Keep emergency access outside the normal path and alert whenever it is used. Reduce permissions using observed API activity and IAM Access Analyzer validation, not policy names alone.

CONTROL 04CloudTrail is not something to enable after an incident

Without an API record, you cannot establish where an incident began or how far it reached. Create a trail that covers every Region and deliver logs to a tightly controlled S3 bucket. Separate the log archive account from workload accounts when the environment allows it.

aws cloudtrail describe-trails --include-shadow-trails
aws cloudtrail get-trail-status --name <TRAIL_NAME>

Check more than the trail’s existence. Verify IsLogging, multi-Region coverage, log file validation, and access to the destination bucket.

CONTROL 05Enable GuardDuty in every Region

An attacker does not have to stay in the Region your team uses. An unused Region can still host credential abuse and anomalous API activity. Enable a detector in every Region, then route high-severity findings into the system where someone will own the response.

aws guardduty list-detectors --region ap-northeast-2

CONTROL 06Block public S3 access at the account boundary

Unless public storage is an explicit requirement, enable all four account-level S3 Block Public Access controls. The account boundary narrows the path for an accidental bucket policy or ACL to expose data.

aws s3control get-public-access-block --account-id <ACCOUNT_ID>

Confirm that BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets are all true.

CONTROL 07Keep looking for external access

Enable IAM Access Analyzer to identify resources shared with external accounts or the internet. If access is intentional, do not simply archive the finding. Record the owner, approval, and business reason so the exception remains reviewable.

aws accessanalyzer list-analyzers --type ACCOUNT

The final five-minute check

This is not a mature security program. It is the starting line. Skip it, and later investments in WAF, SIEM, or CSPM will not compensate for basic account takeover and public-access failures.