Logging and monitoring in the cloud

Why cloud logs are different

In the cloud, many attacks never touch a server: the attacker logs in to the console or API with stolen credentials and changes settings, copies data or creates new keys. Server logs will not show this. Cloud audit logs, also called control-plane logs, record every management action in the account.

The main log sources

Other useful sources: network flow logs (VPC Flow Logs) showing connections, storage access logs, load balancer and WAF logs, and DNS query logs.

Reading a CloudTrail event

{
  "eventTime": "2026-03-14T03:12:45Z",
  "eventSource": "signin.amazonaws.com",
  "eventName": "ConsoleLogin",
  "userIdentity": { "type": "Root", "arn": "arn:aws:iam::111122223333:root" },
  "sourceIPAddress": "198.51.100.23",
  "responseElements": { "ConsoleLogin": "Success" },
  "additionalEventData": { "MFAUsed": "No" }
}

Events worth alerting on

Azure and Google have equivalent events with different names; the questions are the same: who did it, from where, with MFA or not, and was it expected?

$ aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=StopLogging --max-results 5
{
    "Events": []
}

Good practice

• Turn on audit logging for all accounts and all regions, sent to a separate, locked-down logging account that admins of the main account cannot delete.
• Keep logs long enough; in India CERT-In expects 180 days of logs.
• Send cloud logs to the SIEM so they can be correlated with endpoint and network logs.
• Turn on the provider's threat detection service; it is cheap compared with an incident.
• Set billing alerts: a sudden bill spike is sometimes the first sign of stolen keys.

Common mistakes

• Logs stored in the same account an attacker controls, so they can delete them.
• Data access logging (who read which file) left off for sensitive buckets.
• Ignoring time zones: cloud logs are in UTC.