Cloud Audit Logs: What They Record and Why They Matter
What cloud audit logs record, how AWS CloudTrail, Google Cloud Audit Logs, the Azure Monitor activity log, and Alibaba Cloud ActionTrail differ, and how to retain, search, protect, and alert on them.
An audit log is the record of who did what to a cloud account: which identity called which API, from which address, at what time, and whether the call succeeded. It is the evidence you need after a leaked key, the proof an auditor asks for, and the fastest way to answer “who deleted that server”. Every major provider produces one, but the defaults differ in what is captured and how long it is kept. This guide explains what audit logs record, how AWS CloudTrail, Google Cloud Audit Logs, the Azure Monitor activity log, and Alibaba Cloud ActionTrail each work, and what to do so the logs are there when you need them.
What an audit log records
Each entry answers the same set of questions. The principal: the user, role, service account, or API key that made the call. The action: the API operation, such as creating an instance or changing a firewall rule. The target: the resource the action applied to. The context: source IP address, user agent, timestamp, region, and the request parameters. The outcome: success, or an error code such as access denied. Entries are written by the platform itself, not by your application, so they cannot be skipped by code you deploy.
Providers split logs into two planes. Management or control plane events cover changes to configuration and resources and are recorded by default everywhere. Data plane events cover access to the contents of resources, such as reading an object from a storage bucket or a row from a database, and are usually off by default because of their volume and cost. Turn them on selectively for the buckets and datasets that hold sensitive data.
CloudTrail, Cloud Audit Logs, the Azure activity log, and ActionTrail
AWS CloudTrail records management events in every region and shows the most recent 90 days in the console’s event history without any setup. For longer retention you create a trail that delivers log files to an S3 bucket, optionally to CloudWatch Logs for alerting, and optionally across every account in an AWS Organization. Data events for S3 objects, Lambda invocations, and DynamoDB tables are enabled per trail and billed separately. CloudTrail Lake adds a queryable store for investigations, and log file validation produces digests that prove files were not altered after delivery.
Google Cloud Audit Logs are part of Cloud Logging and come in four types. Admin Activity logs record configuration changes and are always on. System Event logs record actions Google’s own systems take, such as a live migration, and are always on. Data Access logs record reads and writes of user data and are off by default except for BigQuery. Policy Denied logs record requests blocked by a policy. The always on types are kept in a required log bucket for a retention period set by Google; the rest land in the default bucket with a shorter retention unless you configure a sink to Cloud Storage, BigQuery, or Pub/Sub. Aggregated sinks at the organization or folder level collect every project’s logs in one place.
The Azure Monitor activity log is the subscription level record of control plane operations: every deployment, role assignment, and resource change made through Azure Resource Manager. It is kept by the platform for 90 days and exported through a diagnostic setting to a Log Analytics workspace, a storage account, or Event Hubs for longer retention and querying. Data plane logging on Azure is configured per resource through resource logs, and sign in and directory changes are recorded separately in Microsoft Entra ID’s audit and sign in logs.
Alibaba Cloud ActionTrail records operations performed by the Alibaba Cloud account and its RAM users through the console, API, and SDKs. The console shows recent events, and a trail delivers the full record to an Object Storage Service bucket or Simple Log Service for retention and search. Multi account trails through Resource Directory collect events across an organisation.
| Provider | Service | Enabled by default | Long term storage |
|---|---|---|---|
| AWS | CloudTrail | Management events, 90 day event history | Trail to S3, CloudWatch Logs, or CloudTrail Lake |
| Google Cloud | Cloud Audit Logs | Admin Activity and System Event logs | Sinks to Cloud Storage, BigQuery, or Pub/Sub |
| Azure | Azure Monitor activity log | Subscription control plane events, 90 days | Diagnostic setting to Log Analytics, storage, or Event Hubs |
| Alibaba Cloud | ActionTrail | Recent account and RAM user operations | Trail to OSS or Simple Log Service |
Retention periods and defaults are set by each provider and change over time; confirm the current figures in the provider’s documentation when you design your retention policy.
Retention and export
The built in retention windows are long enough to investigate last week and too short for a compliance review or a breach discovered months later. Export to durable storage on day one: an S3 bucket, a Cloud Storage bucket, an Azure storage account, or an OSS bucket in a dedicated logging account or project that the production identities cannot write to or delete from. Apply an object lock or retention policy so logs cannot be removed inside the retention window, and use a lifecycle rule to move old files to a cheaper storage class rather than deleting them.
Keep exported logs searchable. Raw log files in a bucket are cheap to store and slow to query. A queryable layer such as CloudTrail Lake, BigQuery, Log Analytics, or Simple Log Service costs more but turns “what did this key do in March” into a query rather than a download.
What to look for in the logs
- New IAM users, service accounts, access keys, or tokens, especially outside working hours.
- Changes to IAM policies, role assignments, or organisation policies that widen access.
- Logging itself being stopped, a trail deleted, a sink removed, or a diagnostic setting disabled.
- Activity in regions your team does not use, which often signals a compromised credential.
- Bursts of access denied errors from one principal, which look like someone probing permissions.
- Security group, firewall, or network ACL changes that open ports to the internet.
- Bulk deletion of instances, snapshots, or buckets.
- Console logins without MFA or from new locations.
Turn the most important of these into alerts. CloudWatch metric filters, Cloud Logging alerting policies, Azure Monitor alert rules, and Simple Log Service alerts can each notify a channel within minutes of a matching event, and the small set above catches most credential misuse early.
Protecting the logs themselves
An attacker who gains admin access will look for the audit trail first. Store logs in a separate account or project with a narrow set of readers and no writers other than the logging service. Deny the production roles permission to stop trails, delete sinks, or change diagnostic settings, and alert on any attempt. Enable log file validation on CloudTrail and equivalent integrity controls elsewhere. Review who can read the logs, because audit logs contain resource names, IP addresses, and sometimes request parameters that are sensitive on their own. When taking over an existing account, reading the audit log for the past weeks is one of the first steps in the cloud account handover checklist.
Where to go next
Audit logging is available on every account listed in the marketplace, and the export configuration above is a first day task. See the product pages for Google Cloud accounts, Azure accounts, and Alibaba Cloud accounts for the variants on offer, each described by its label.
Logs show what a credential did; API keys and secrets management covers keeping credentials from leaking in the first place, and cloud account security essentials covers MFA and least privilege. The Cloud Library hub lists every security guide.