5 Quick Things You Can Do in Your AWS Account to Become Instantly More Secure

If you run workloads on AWS, you can make a real difference to your security posture in under an hour. None of the steps below need new tooling or a change to your architecture. They close the gaps that attackers, and automated scanners, check for first.

1. Lock away the root user

The root user can do anything in your account, including closing it. It should almost never be used.

• Turn on multi-factor authentication for root. A hardware key or passkey is best.
• Delete any access keys that belong to root. Root should never make API calls.
• Use an administrator role or IAM Identity Center for day-to-day work instead.

You can confirm whether root still has keys from the IAM credential report:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode

Look at the <root_account> row: access_key_1_active and access_key_2_active should both be false.

2. Turn on CloudTrail in every region

When something goes wrong, CloudTrail is how you find out what happened. Without it, an incident investigation starts with a blank page.

Create a multi-region trail with log file validation, so you can prove the logs haven't been tampered with:

aws cloudtrail create-trail \
  --name account-trail \
  --s3-bucket-name my-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation
aws cloudtrail start-logging --name account-trail

If you use AWS Organizations, an organisation trail created in the management account covers every member account at once.

3. Block public access to S3 at the account level

Public buckets remain one of the most common causes of cloud data leaks. Newer buckets have Block Public Access switched on by default, but older buckets and older accounts often don't.

Enabling it at the account level overrides any individual bucket that has been made public by mistake:

aws s3control put-public-access-block \
  --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

If you genuinely need to serve public files, put them behind CloudFront with origin access control rather than opening the bucket.

4. Switch on GuardDuty and IAM Access Analyzer

Two managed services give you a lot of coverage for very little effort.

• GuardDuty watches CloudTrail, VPC flow logs and DNS logs for signs of compromise, such as credentials used from unusual locations or instances talking to known malicious hosts.
• IAM Access Analyzer tells you which resources, including buckets, roles and KMS keys, can be reached from outside your account.

aws guardduty create-detector --enable
aws accessanalyzer create-analyzer --analyzer-name account-analyzer --type ACCOUNT

Both are regional, so enable them in every region you use, not just your default one.

5. Replace long-lived access keys

Access keys attached to IAM users don't expire. They end up in laptops, CI variables and, eventually, public repositories.

• Move people to IAM Identity Center, which issues short-lived credentials.
• Give workloads IAM roles instead of keys: instance profiles for EC2, task roles for ECS, IRSA or Pod Identity for EKS.
• Use the credential report from step 1 to find keys that haven't been used in 90 days, and delete them.

Keep it that way

Each of these fixes takes minutes. The harder part is making sure they stay fixed as your team adds accounts, regions and people. That's what continuous posture management is for: Nulink Cloud checks every one of these settings on every scan and tells you, with the owner attached, when something drifts.