AWS logging and detection: CloudTrail, CloudWatch, GuardDuty and Security Hub
In short: CloudTrail records who did what through the AWS API, CloudWatch stores logs and metrics and raises alarms, GuardDuty spots suspicious behaviour, AWS Config tracks resource changes, and Security Hub gathers findings in one place. Turn them on in every account and region, protect the logs, and alert on high-value events.
Why cloud logging is different
In the cloud almost everything is an API call: starting a server, changing a firewall rule, reading a secret. That is good news for defenders, because a full record of those calls exists if you switch it on and keep it safe. Attackers know this, so one of their first moves is often to disable logging. Your design must make that hard and noisy.
What each service does
| Service | Role | Example question it answers |
|---|---|---|
| AWS CloudTrail | Audit log of management (and optionally data) API events | Who deleted this security group, and from which IP? |
| Amazon CloudWatch | Metrics, log storage, metric filters and alarms | Has CPU or error rate spiked? Did a log line match a pattern? |
| Amazon GuardDuty | Managed threat detection using CloudTrail, VPC Flow Logs, DNS logs and more | Is an instance talking to a known crypto-mining pool? |
| AWS Config | Inventory and change history; rules check compliance | Which buckets are not encrypted? What did this SG look like last week? |
| AWS Security Hub | Collects findings and runs security standard checks | What are my highest-severity issues across accounts? |
| Amazon Detective | Graph-based investigation of findings | What else did this role do around the time of the alert? |
CloudTrail keeps 90 days of management events in Event history by default, but for real protection create a trail (an organisation trail in AWS Organizations) that delivers logs to a central S3 bucket in a separate log archive account.
Events worth alerting on
- Any root user sign-in or API call.
StopLogging,DeleteTrailor changes to GuardDuty and Config.- Console sign-ins without MFA, and repeated failed sign-ins.
- New IAM users, new access keys or policies granting
*:*. - Security groups opened to
0.0.0.0/0on admin ports. - Resources launched in regions you do not use.
A baseline for every account
- Create an organisation-wide CloudTrail trail with log file validation, delivered to a log archive account.
- Protect the log bucket with Object Lock or tight policies, and encrypt with KMS.
- Enable GuardDuty in all accounts and regions with a delegated administrator.
- Enable AWS Config recording and Security Hub with a standard such as AWS Foundational Security Best Practices or the CIS AWS Foundations Benchmark.
- Turn on VPC Flow Logs for important networks.
- Send high-severity findings to your ticketing system or a SIEM, and write a short runbook for each.
Tip: detection only works if someone reacts. Start with a handful of high-value alerts that always get a response, rather than hundreds that everyone ignores.
Practice
Which service would show who changed a security group yesterday?
Why store CloudTrail logs in a separate account?
GuardDuty reports an instance querying a crypto-mining domain. What are sensible first steps?
Key takeaways
- CloudTrail records API activity; protect it in a separate log account.
- CloudWatch handles metrics, logs and alarms.
- GuardDuty detects threats; Config tracks changes; Security Hub centralises findings.
- Alert on root use, logging changes, new keys and open admin ports.
- Enable everything in every account and region you use.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.