Detecting anomalies in cloud accounts does not require a full SOC. A small set of high-signal alerts and consistent logging can catch most real incidents without overwhelming your team.
This guide outlines practical detection steps that work for lean teams.
1. Start with the highest-signal events
Not all events are equal. Focus on actions that indicate real risk.
High-signal events:
- Root user login
- IAM policy changes
- Access key creation
- CloudTrail or GuardDuty disabled
Reference:
- AWS: CloudTrail event history: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html
2. Enable GuardDuty and review findings
GuardDuty catches many common attack patterns.
Practical steps:
- Enable GuardDuty in all regions.
- Route findings to a central alert channel.
- Review critical findings daily or weekly.
Reference:
3. Detect unusual access patterns
Access anomalies often show up before data loss.
Practical steps:
- Alert on logins from new locations.
- Track login times outside normal working hours.
- Monitor failed login spikes.
4. Watch for privilege escalation
Attackers often escalate privileges once inside.
Practical steps:
- Alert on new admin role creation.
- Monitor changes to trust policies.
- Track role assumptions by unknown principals.
Reference:
- AWS: IAM Access Analyzer: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
5. Monitor data exfiltration signals
Exfiltration often looks like unusual outbound traffic.
Practical steps:
- Alert on large S3 data downloads.
- Monitor unusual egress traffic volumes.
- Watch for new public endpoints.
Reference:
- AWS: S3 server access logs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html
5a. Use the right log sources
Detection fails when you only look at one log stream.
Practical steps:
- Use CloudTrail for API activity.
- Use VPC Flow Logs for traffic signals.
- Use service logs (S3 access, RDS logs) for data access.
6. Use CloudWatch for alert routing
Keep alerting simple and consistent.
Practical steps:
- Route alerts to a single shared channel.
- Use severity labels for triage.
- Keep alert rules short and reviewed.
Reference:
- AWS: CloudWatch alarms: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html
6a. Add an example alert set
Start with a short list of alerts you can actually manage.
Example alerts:
- Root user login
- New access key created
- IAM policy attached to a user
- S3 bucket made public
- CloudTrail stopped
7. Build a short response playbook
Detection is only useful if response is quick.
Practical steps:
- Document immediate containment steps.
- Define who investigates and who communicates.
- Keep the playbook to one page.
8. Review alerts monthly
Alerts should improve over time.
Practical steps:
- Remove noisy alerts.
- Add alerts for new systems and services.
- Review false positives and adjust thresholds.
9. Establish a baseline for normal activity
Anomaly detection works best when you know what “normal” looks like.
Practical steps:
- Record normal login times and regions.
- Track average data transfer volumes.
- Note which roles are used daily versus rarely.
10. Add account-level guardrails
Guardrails make anomalies easier to spot.
Practical steps:
- Use Config rules for high-risk changes.
- Alert on new public endpoints.
- Monitor for changes to logging settings.
Reference:
- AWS: Config rules: https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html
11. Build a starter response path
Detection is only useful if response is fast.
Starter plan:
- Assign an on-call owner for alerts.
- Define containment steps for access abuse.
- Keep a one-page runbook with contact info.
12. Common pitfalls
These issues reduce the value of detection.
Pitfalls:
- Alerting on every event instead of high-signal events
- No clear owner for alerts
- Alert rules that are never reviewed
13. Starter plan for a small team
If you are new to detection, keep the first month focused.
Starter plan:
- Enable GuardDuty and CloudTrail everywhere
- Add five high-signal alerts
- Create a one-page response runbook
14. Retain logs for investigations
Detection is only half the job; you also need evidence.
Practical steps:
- Keep CloudTrail logs for at least 90 days.
- Store logs in a central, access-controlled account.
- Document how to retrieve logs during an incident.
15. Investigation questions to keep handy
Good questions speed up triage.
Questions:
- Which identity performed the action?
- Was this action seen before in the account?
- What data or resources were touched?
Quick checklist
- GuardDuty enabled in all regions
- High-signal alerts defined and routed
- IAM and root access changes monitored
- Data egress alerts in place
- Response playbook documented
Closing thought
Anomaly detection works when it is focused. A small set of high-signal alerts and a clear response path will catch most real issues without overload.
If you want help tuning detection or building alerting that fits your team, we can help. We focus on practical detection that supports fast response. Reach out through our consulting page to start a quick conversation.