Most beginner AWS incidents are not sophisticated attacks. They are leaked access keys, an unprotected root user, or a forgotten resource quietly running up a bill. This guide closes the most common gaps before you build anything.
Who this is for: anyone who just created an AWS account. Time needed: about 60 minutes. Cost: mostly free or low-cost, but check current pricing and trial terms before you start.
1. Protect the root user
The root user cannot be restricted by IAM policies, so treat it as break-glass only.
- Enable MFA. A hardware key or passkey is stronger than SMS or an authenticator app.
- Check that no root access keys exist, and delete any you find.
- Use a dedicated email address that you actively monitor.
- Never use root for daily work.
📸 [Add screenshot: IAM dashboard showing root MFA active and zero root access keys]
2. Use IAM Identity Center instead of IAM users
Long-lived IAM user keys are one of the most common ways credentials leak. IAM Identity Center issues short-lived credentials through SSO, and the CLI supports it directly:
bash
1
aws configure ssoCreate two permission sets: one admin set for building, and one read-only set for browsing. Use the narrower one whenever you can.
3. Set a budget alert immediately
Cost is a security signal. Unexpected spend is often the first visible sign of compromised credentials, for example crypto-mining instances in a Region you never use. Create an AWS Budget with email alerts at a low threshold, and confirm the alert email actually arrives.
4. Turn on logging before you need it
Logs you did not enable cannot be recovered after an incident.
- CloudTrail: Event history only covers 90 days of management events. Create a multi-Region trail that delivers to a dedicated S3 bucket for long-term retention.
- Enable log file validation so tampering can be detected.
- Restrict the log bucket so day-to-day roles cannot delete logs.
📸 [Add screenshot: your trail configuration with multi-Region and log file validation enabled]
5. Enable threat detection
- Amazon GuardDuty analyzes CloudTrail events, VPC Flow Logs, and DNS logs for suspicious behavior. It can be enabled in a few clicks, and new accounts typically get a free trial period.
- 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 the account-level setting too (S3 → Block Public Access settings). Enable default encryption, and avoid public bucket policies unless you are deliberately hosting a public site.
7. Apply least privilege from day one
Avoid
AdministratorAccess and "Resource": "*" for anything beyond your admin role. Start narrow and widen based on access-denied errors. Access Analyzer can generate policies from real CloudTrail activity, which beats guessing.8. Restrict Regions you do not use
If you use AWS Organizations, a Service Control Policy that denies unused Regions reduces your attack surface and makes anomalies easier to spot. Attackers often launch 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 works, 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 |
Prove it works: a safe detection test
A control you have not tested is an assumption. GuardDuty can generate sample findings so you can see what an alert looks like without attacking anything:
- Open GuardDuty → Settings → Generate sample findings.
- Review the findings list and open one.
- Note which data source it relied on (CloudTrail, VPC Flow Logs, or DNS).
- Confirm you would actually receive a notification. If not, route findings to email or Slack through EventBridge and SNS.
📸 [Add screenshot: a sample finding and the notification you received]
[Optional: add your own result here. What did you expect to see, what actually appeared, and what surprised you?]
What this does not cover
This is a baseline, not a security program. It does not address network segmentation, secrets management, incident response, or multi-account design. Each is a topic of its own.
The logical next step is to automate this baseline with infrastructure as code (Terraform or CloudFormation). A manual checklist drifts over time, while code can be reviewed, versioned, and re-applied.
Key takeaways
- Protect root and stop using long-lived keys.
- Turn on logging and detection before anything else.
- Treat unexpected cost as a security signal.
- Test your alerts, because an untested alert is a guess.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article