Five AWS security checks every small team should run this week

Most AWS security incidents at small companies don't involve anything exotic. They come from a handful of settings that were never switched on, or were switched off "temporarily". Here are five to check this week. None of them needs a big project.

1. Lock down the root user

The root user can do anything in the account, including close it. It should have MFA enabled and no access keys, and it should almost never be used.

Check under IAM → Dashboard → Security recommendations. If root has access keys, delete them. Day-to-day work should go through IAM Identity Center (SSO) or scoped roles.

2. Turn on GuardDuty everywhere you run anything

GuardDuty is AWS's managed threat detection. It watches CloudTrail, DNS and network flow logs for things like credential misuse and crypto-mining. It's cheap for small accounts and takes a minute to enable, but it only covers the regions you switch it on in.

Enable it in every region you use. If you have an AWS Organization, enable it once with a delegated administrator so that new accounts are covered automatically.

3. Make sure CloudTrail is recording, in every region

Without CloudTrail you can't answer "who did what, and when?" after something goes wrong. You want at least one multi-region trail that's logging to an S3 bucket only a few people can touch, with log file validation on.

Check under CloudTrail → Trails that a trail shows Multi-region: Yes and Logging: On.

4. Block public S3 access at the account level

Public S3 buckets are still one of the most common ways data leaks. S3 Block Public Access can be set for the whole account, not just per bucket, which stops anyone accidentally making a bucket public in future.

Turn on all four settings under S3 → Block Public Access settings for this account, unless a bucket genuinely has to be public. If one does, a CloudFront distribution in front of a private bucket is usually the better design.

5. Get long-lived access keys out of your CI/CD

An AWS access key stored in a CI system (GitHub Actions secrets, for example) is a password that never expires, often with broad permissions. If it leaks, so does your account.

GitHub Actions, GitLab and most other CI tools can use OIDC instead: the pipeline swaps a short-lived identity token for temporary AWS credentials, scoped to one repository and branch. There's no key left to steal. Start by listing IAM users that have access keys but no console password; those are usually the pipeline keys.

If you'd like a second pair of eyes, our fixed-price AWS Security Baseline Review covers all five of these and more, with a prioritised list of what to fix first.