Most beginner AWS incidents aren't sophisticated attacks. They're leaked access keys, an unprotected root user, or a forgotten resource running up a bill. These steps close the common gaps before you build anything.
1. Protect the root user
The root user can't be restricted by IAM policies, so treat it as break-glass only.
- Enable MFA (a hardware key or passkey is better than SMS or an authenticator app).
- Confirm no root access keys exist. Delete any you find.
- Use a dedicated, monitored email address.
- Never use root for daily work.
2. Use IAM Identity Center, not IAM users
Long-lived IAM user keys are the most common way credentials leak. IAM Identity Center gives you short-lived credentials through SSO, and the CLI supports it directly (
aws configure sso). Create an admin permission set for yourself and a separate read-only one for browsing.3. Set a budget alert immediately
Security includes availability and cost. Create an AWS Budget with email alerts at a low threshold. Unexpected spend is often the first visible sign of compromised credentials, such as crypto-mining instances.
4. Turn on logging before you need it
- CloudTrail: Event history only covers 90 days of management events. Create a multi-Region trail delivering to a dedicated S3 bucket for long-term retention.
- Enable log file validation so you can detect tampering.
- Restrict the log bucket so that day-to-day roles can't delete logs.
5. Enable threat detection
- GuardDuty analyzes CloudTrail, VPC Flow Logs, and DNS logs for suspicious behavior. It's a single toggle with a trial period for new accounts.
- IAM Access Analyzer flags resources shared outside your account, such as public S3 buckets or cross-account roles.
6. Lock down S3
New buckets block public access by default, but verify it at the account level too (S3 → Block Public Access settings). Enable default encryption and avoid public bucket policies unless you're deliberately hosting a public site.
7. Apply least privilege from day one
Avoid
AdministratorAccess and "Resource": "*" for anything beyond your admin role. Start narrow, then widen based on access denied errors. Access Analyzer can generate policies from actual CloudTrail activity, which is much better than guessing.8. Restrict Regions you don't use
If you use AWS Organizations, a Service Control Policy denying unused Regions reduces your attack surface and makes anomalies easier to spot. Attackers often spin up resources in Regions you never look at.
Quick checklist
| Control | Service | Done when |
|---|---|---|
| Root protected | IAM | MFA on, no root keys |
| Human access | IAM Identity Center | SSO working, no IAM user keys |
| Cost guardrail | AWS Budgets | Alert email confirmed |
| Audit trail | CloudTrail | Multi-Region trail to S3, validation on |
| Detection | GuardDuty, Access Analyzer | Both enabled |
| Data exposure | S3 | Account-level Block Public Access on |
What this doesn't cover
This is a baseline, not a security program. It doesn't address network segmentation, secrets management, incident response, or multi-account design, and each of those is a topic of its own. Automating this baseline with infrastructure as code (Terraform or CloudFormation) is the logical next step, because a manual checklist drifts.
A blunt note before you publish: "Secure your new account" is a crowded topic, and a generic version won't stand out on Builder Center. To make it worth reading, add something only you can supply: screenshots from your own account, a real misconfiguration you deliberately created and detected with GuardDuty, or the exact CloudTrail event it produced. Evidence from a hands-on lab is what separates this from a documentation summary. I also kept the claims general, so verify current free-trial terms and console labels before publishing, since AWS changes them often.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article