Cloud audit logging compared: CloudTrail, vTrail, Google Cloud Audit Logs and Azure Activity Log

What a cloud audit log records

Every useful audit record answers six questions: who (authenticated identity and the account or project it belongs to), what (the operation), on what (the target resource or path), when (a UTC timestamp), from where (source IP and client) and with what result (status or error). The services below differ less in these basics than in scope, retention, export and integrity.

Feature comparison

Values are qualitative and taken from each provider’s documentation. “Unverified” means the provider has not published enough detail to confirm the feature — it does not mean the feature is absent.

AWS CloudTrail

CloudTrail records management events for every account by default and shows 90 days of them in event history. Trails deliver events to S3 and optionally CloudWatch Logs; data events such as S3 object reads and Lambda invocations are opt-in and charged. CloudTrail Lake stores events for SQL queries, and log-file integrity validation produces signed digest files that prove a delivered log has not been altered.

Google Cloud Audit Logs

Google separates audit logs into Admin Activity (always written, no charge), Data Access (off by default except for BigQuery), System Event and Policy Denied logs. Admin Activity logs are retained for 400 days in the _Required bucket. Sinks route logs to Cloud Storage, BigQuery or Pub/Sub.

Azure Activity Log

The Activity Log records subscription-level control-plane operations from Azure Resource Manager and keeps them for 90 days. Diagnostic settings export to Log Analytics, Storage or Event Hubs. Data-plane activity is captured in resource logs, which are configured per resource type.

PortvMind vTrail

vTrail records cloud management activity on PortvMind Cloud so that an organisation can identify which user performed which operation, when and with what outcome. The provider-supplied event model includes the authenticated user, project and authorisation scope together with HTTP request metadata. The full field model and its mapping to other formats are shown below.

{
  "event_time": "",
  "request_id": "",
  "http_method": "",
  "full_path": "",
  "http_status": null,
  "client_ip": "",
  "user_agent": "",
  "auth_user_id": "",
  "auth_user_name": "",
  "auth_project_id": "",
  "auth_scope": "",
  "service_id": "",
  "route_id": "",
  "request_time": null
}

Choosing an audit-logging approach

• Default coverage is not enough for data access. If you need to know who read an object or a secret, enable data events explicitly and budget for them.
• Export early. Default retention windows are shorter than most compliance regimes require; route events to storage you control.
• Protect integrity. Use integrity validation where offered, or write to object storage with object lock or equivalent write-once controls.
• Normalise. If you use more than one cloud, map events to a common schema — the audit event model on this site shows one such mapping.

Methodology

Features are assessed against the definitions in the cloud auditing methodology using official documentation only. No performance or latency measurements of logging pipelines are made.

Limitations

• Feature availability can vary by region, edition or account tier.
• Information about vTrail is provider-supplied.
• Pricing of audit logging is described qualitatively; volumes and rates change.

Conclusion

The large clouds have converged on a similar model: control-plane events on by default, opt-in data events, export to customer-controlled storage. vTrail covers the core of that model — identity-attributed management API activity — and the comparison will become complete once its retention, export and integrity features are publicly documented.