Nobody's Watching
The Data Plane.
A side-by-side field reference for AWS CloudTrail, Azure Activity/AD logs, and GCP Cloud Audit Logs: log source types, equivalent field names across all three platforms, the events worth alerting on, and the logging gap almost every environment leaves open by default.
Log Source Overview
Three platforms, three names for the same basic split: control-plane activity that's always logged, and data-plane activity that usually isn't.
AWS, Azure, GCP — What Actually Gets Logged
AWS CloudTrail ├── Management events — control-plane API calls (IAM changes, EC2 launches), logged by default ├── Data events — data-plane operations (S3 object reads, Lambda invocations), NOT logged by default, must be explicitly enabled and costs extra └── Insights events — CloudTrail's own anomaly detection on API call volume/rate Azure Activity Log + Azure AD Logs ├── Activity Log — subscription-level control-plane operations (resource create/update/delete) ├── Azure AD Sign-in Logs — every authentication attempt, success or failure, with location/device/risk data └── Azure AD Audit Logs — directory changes: role assignments, app registrations, conditional access edits GCP Cloud Audit Logs ├── Admin Activity — API calls that modify configuration, always logged, cannot be disabled ├── Data Access — reads/writes to user data, disabled by default in many services ├── System Event — Google-initiated changes, not caused by a user action └── Policy Denied — a request rejected by a security policy (e.g. VPC Service Controls), high-signal for probing
Key Fields Across Platforms
The same four concepts, spelled differently on every platform.
FIELD
Event / Operation Name
What action was performed
AWS:
eventName. Azure: operationName. GCP: protoPayload.methodName.FIELD
Source IP
Where the request originated
AWS:
sourceIPAddress. Azure: callerIpAddress. GCP: requestMetadata.callerIp.FIELD
Identity / Actor
Who or what made the call
AWS:
userIdentity (type, ARN, accountId). Azure: identity / authenticationInfo. GCP: authenticationInfo.principalEmail.FIELD
Request Details
What was actually requested
AWS:
requestParameters. Azure: properties. GCP: protoPayload.request.High-Signal Events To Alert On
Not everything in the audit log is worth an alert. This is.
AWS
Access Keys, Console Login, AssumeRole
And any root activity at all
CreateAccessKey on an account that doesn't normally provision keys, ConsoleLogin with MFAUsed: "No", AssumeRole into a different account than usual, and any root account API activity whatsoever.AZURE
Risky Sign-In, Privileged Role Assignment
And Conditional Access changes
A sign-in from an atypical location or impossible travel flagged by Identity Protection, a new role assignment on a privileged role (Global Admin, Owner), or a Conditional Access policy modified or disabled.
GCP
IAM Bindings, Service Account Keys, Policy Denied
Persistence and reconnaissance both live here
An IAM policy binding added at the project or org level, a service account key created (a common long-lived-credential persistence mechanism), or a Policy Denied event on a sensitive resource.
Common Pitfalls
The same gap shows up under a different name on all three platforms.
PITFALL
Data Events Are Opt-In And Cost Extra
The most common cloud logging gap, full stop
Many environments only have management events enabled. That means S3 object-level reads or Lambda invocation activity has zero audit trail unless someone deliberately turned on data events, which cost extra and are easy to skip.
PITFALL
Region And Retention Scoping
A trail configured for one region doesn't see the rest
A multi-region AWS account needs CloudTrail configured per region or a dedicated organization trail. Activity outside the "home" region can go completely unlogged without anyone noticing until it matters.
PITFALL
Assuming Management-Plane Covers Data-Plane
Not AWS-specific, all three platforms share this gap
This is the single most common cloud logging gap across every platform, not just AWS. Control-plane logging being enabled says nothing about whether data-plane activity is visible at all.
PITFALL
Sign-In Logs And Audit Logs Are Separate
Azure AD specifically
Azure AD Sign-in Logs and Audit Logs are separate log types with separate retention settings. Pulling only one misses half the identity picture: authentication events on one side, directory changes on the other.