Most cloud security incidents do not start with an advanced attack. They start with something basic: an access key committed to a code repository, an administrator without multi-factor authentication, a storage bucket shared publicly by mistake, or logging that was never turned on, so nobody can tell what happened.
The good news is that a strong baseline is achievable for any AWS account, and most of it uses services AWS already provides. This guide covers the settings to check first.
1. Lock down the root user
The root user can do anything in the account, including closing it. Treat it like the master key:
- Enable MFA, ideally a passkey or hardware security key. AWS now requires MFA for root users across all account types, rolled out from 2024 to 2025, so make sure yours is set up and the device is stored safely.
- Do not create access keys for the root user. If any exist, delete them.
- Do not use root for daily work. Sign in only for the few tasks that genuinely require it.
- Keep the root email address on a mailbox that several trusted people can access, not one person's inbox.
2. Give people access through IAM Identity Center
Rather than creating long-lived IAM users with passwords and access keys, use AWS IAM Identity Center for human access:
- Connect it to your existing directory (such as Microsoft Entra ID or Google Workspace) so people sign in with their work account and MFA.
- Give access through permission sets that match real roles (read-only, developer, administrator).
- Users get temporary credentials for each session, so there are no long-lived keys to leak.
3. Apply least privilege
- Start from the minimum permissions a person or application needs and add only what is required.
- Use IAM roles for applications and AWS services instead of access keys wherever possible.
- Use IAM Access Analyzer to find resources shared outside your account and to help generate tighter policies from actual usage.
- If you use multiple accounts with AWS Organizations, use service control policies to set guardrails, such as preventing anyone from disabling logging.
4. Turn on logging everywhere
You cannot investigate what you did not record:
- AWS CloudTrail records API activity in your account. Create a trail that covers all Regions and sends logs to a dedicated, protected S3 bucket.
- AWS Config records how your resources are configured over time, and can flag changes that break your rules.
- Set retention periods for your logs that match your security and compliance needs.
5. Turn on threat detection
- Amazon GuardDuty continuously analyses activity for signs of compromise, such as unusual API calls, credentials used from unexpected places, or instances talking to known malicious addresses.
- AWS Security Hub brings findings together and checks your account against security standards, giving you a prioritised list of what to fix.
Make sure findings go somewhere a person will see them, such as email or your ticketing system. Detection nobody reads is not detection.
6. Keep storage private by default
- S3 Block Public Access should be on at the account level. AWS turns it on by default for new buckets, but check existing buckets and the account setting.
- Encrypt data at rest. New S3 objects are encrypted by default; also enable encryption for EBS volumes and databases.
- Use bucket policies that grant access to specific roles, not to everyone.
7. Protect the network edge
- Review security groups so that only the ports you need are open, and only to the sources that need them. Administrative ports such as SSH and RDP should not be open to the whole internet.
- Prefer AWS Systems Manager Session Manager for server access instead of opening SSH or RDP at all.
- Put internet-facing web applications behind a load balancer and consider AWS WAF to filter common attacks.
8. Manage secrets properly
Never keep passwords or API keys in code or configuration files. Use AWS Secrets Manager or Systems Manager Parameter Store, give applications access through IAM roles, and rotate secrets regularly. Scan your code repositories for accidentally committed secrets.
9. Back up and plan for recovery
Use AWS Backup to protect databases, volumes and file systems on a schedule, store copies in a separate account or Region where it matters, and test restores. Ransomware and accidental deletion are recovery problems as much as security ones.
10. Make it continuous
Security is not a one-off project. Review Security Hub findings regularly, keep infrastructure in code so changes are reviewed, remove unused accounts and permissions, and revisit this baseline whenever you add new services.
A short checklist
- Root user has MFA and no access keys
- People sign in through IAM Identity Center with MFA
- Applications use roles, not long-lived keys
- CloudTrail covers all Regions; AWS Config is on
- GuardDuty and Security Hub are on, and findings reach a person
- S3 Block Public Access on; encryption at rest enabled
- No SSH or RDP open to the internet
- Secrets stored in Secrets Manager or Parameter Store
- Backups scheduled and a restore has been tested
Where to start
If you are not sure who has administrator access to your AWS account, or whether logging is on in every Region, start there. If you would like a security review of your AWS environment and a practical plan to close the gaps, book a free consultation.