Cloud Logging and Audit Trail Guide: CloudTrail and Activity Logs

When a cloud incident happens, the first question is "what did this identity do?", and the answer is only as good as the audit trail you configured before it started. Every major cloud records control plane activity by default, but the defaults are short, data access is mostly off, organisation-wide coverage takes deliberate setup, and an attacker with the right permissions can quietly narrow what gets recorded. This guide goes deeper than the Log Management and Retention Guide on one topic: the cloud audit trail itself. It covers AWS CloudTrail (management and data events, organisation trails, event selectors, log file integrity validation and CloudTrail Lake), the Azure Activity log and Microsoft Entra audit and sign-in logs, Google Cloud Admin Activity and Data Access audit logs and aggregated sinks, SaaS audit logs, tampering detection and retention. It is for cloud security, detection and audit teams.

Key takeaways

• Defaults are not an audit trail. CloudTrail Event history keeps 90 days of management events per account, the Azure Activity log 90 days, Entra audit and sign-in logs 7 or 30 days, and Google's _Default bucket 30 days.
• Data access is opt-in everywhere. CloudTrail data events, Azure resource logs and Google Data Access audit logs (except BigQuery) are off by default, so "who read the data" is usually unanswerable unless you chose to record it.
• Centralise at the organisation level. An AWS organisation trail, Azure diagnostic settings deployed to every subscription by policy plus Entra diagnostic settings, and a Google aggregated sink at the organisation give coverage that new accounts and projects inherit automatically.
• Attackers tamper quietly. Stopping a trail is noisy; changing an event selector, excluding one role, or editing a sink filter is not. ATT&CK tracks this as T1685.002 Disable or Modify Cloud Log, and every logging configuration change should alert.
• Compliance grade means provable. A governance-grade audit log is complete, attributable, time-synchronised, encrypted, retained for a defined period and protected by integrity validation or immutable storage in an account the workload owners cannot administer.

What each cloud records by default

All three clouds separate control plane activity (changes to resources and permissions) from data plane activity (reading and writing the data inside them).

AWS CloudTrail in depth

Organisation trail

An organisation trail (AWS spells it organization trail) logs every account in an AWS Organizations organisation. It must be created from the management account or a delegated administrator, and AWS states that users in member accounts "do not have sufficient permissions to delete organization trails, turn logging on or off, change what types of events are logged". Accounts that join the organisation start logging automatically, and log files land in one S3 bucket under a folder named with the organisation ID and subfolders per account ID. Console-created organisation trails are multi-Region; a separate trail is needed in each AWS partition. Use a delegated administrator in a dedicated log archive account and keep the bucket there. See the AWS Security Guide for the wider multi-account design.

Management, data and network activity events

• Management events: control plane calls such as CreateUser, AttachRolePolicy, RunInstances or PutBucketPolicy. Log read and write management events on the organisation trail.
• Data events: data plane operations, often high volume, and billed separately. Prioritise S3 object-level events for buckets holding sensitive data, Lambda Invoke for sensitive functions and DynamoDB item-level events for regulated tables.
• Network activity events: a newer category that CloudTrail Lake supports alongside management and data events; evaluate it for VPC endpoint activity where you need it.

Event selectors

Trails use basic or advanced event selectors; event data stores and most newer resource types require advanced selectors. Advanced selectors filter on fields including eventCategory, resources.type, readOnly, eventName, resources.ARN, eventSource, eventType, sessionCredentialFromConsole and userIdentity.arn, with operators such as Equals, StartsWith and NotStartsWith. AWS documents excluding a scanner role with userIdentity.arn NotStartsWith to cut noise, and excluding the s3lifecycle.amazonaws.com and s3-authn-errors.amazonaws.com event sources. The same mechanism is the basis of CloudTrail selector tampering: a selector that excludes one role's ARN blinds the trail to that role while the trail still reports as logging. Keep selector definitions in infrastructure as code and alert on every change.

CloudTrail Lake

CloudTrail Lake stores events in immutable event data stores, queryable with SQL, with retention up to 3,653 days on the one-year extendable pricing option or 2,557 days on the seven-year option. It accepts CloudTrail management, data and network activity events, Insights events, AWS Config configuration items, Audit Manager evidence and non-AWS events through integrations, and supports organisation event data stores. AWS states that CloudTrail Lake "will no longer be open to new customers starting May 31, 2026"; existing customers continue as normal. New adopters should plan on an organisation trail to S3 queried with Amazon Athena, or a central log platform.

Azure Activity log and Microsoft Entra logs

• Activity log at scale: a diagnostic setting on the highest management group exports management group events for the whole hierarchy, but subscription activity needs a diagnostic setting on each subscription. Deploy it with Azure Policy so new subscriptions are covered, add a tenant-level setting for events such as subscription creation, and retire legacy log profiles.
• Resource logs: data plane logs are not collected by default. Use Azure Policy to deploy diagnostic settings for Key Vault, Storage, SQL and other sensitive services so new resources are covered.
• Entra categories: route AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs and MicrosoftGraphActivityLogs through an Entra diagnostic setting. Non-interactive and workload identity sign-ins are where token replay and abused app credentials show up. See the Microsoft Azure Security Guide.
• Latency: Activity log entries usually arrive within 3 to 20 minutes, which matters for detection SLAs.
• Retention cost: the Activity log has no Log Analytics ingestion charge and retention is billed only beyond 90 days, so keeping it long is cheap.

Google Cloud audit logs and aggregated sinks

• Admin Activity and System Event: always written, cannot be configured, excluded or disabled, and routed by the unmodifiable _Required sink to the _Required bucket for 400 days.
• Data Access: enable at the organisation level for services that hold sensitive data, choosing among ADMIN_READ, DATA_READ and DATA_WRITE. DATA_READ on high-volume services is where cost explodes, so enable it selectively. Reading these logs requires the Private Logs Viewer role.
• Aggregated sink: create an organisation-level sink with includeChildren to route every project's audit logs to a central log bucket, BigQuery dataset, Cloud Storage bucket or Pub/Sub topic. An intercepting sink (interceptChildren) stops child projects routing those logs themselves; use it only if the central copy is the system of record.
• Least privilege: creating sinks needs Logging Admin or Logs Configuration Writer on the organisation or folder. Restrict those roles, because editing a sink filter is a quiet way to drop logs.

See the Google Cloud Security Guide.

SaaS audit logs, streaming and export

SaaS tenants hold much of the data that matters and their audit logs are often the weakest link. Microsoft Purview Audit (Standard) is on by default with 180 days of retention; Audit (Premium) keeps Entra, Exchange, OneDrive and SharePoint records for one year and adds events such as MailItemsAccessed. Records from non-user entities such as service principals are kept for a fixed year. The Office 365 Management Activity API exports audit data for longer retention and SIEM analysis. Treat audit log streaming (pushing events continuously to Event Hubs, Pub/Sub, EventBridge or a log platform) as the default and periodic audit log export as a fallback, because export jobs fail silently. For other SaaS platforms, record during procurement which events are logged, retention, API rate limits and any premium licence needed. See the SaaS Security Guide.

Building a tamper-proof, compliance-grade audit trail

Log file validation proves a delivered log file was not modified or deleted after delivery, and can assert that no files were delivered for a period. It cannot prove events were never filtered out by a selector before delivery, which is why configuration monitoring matters as much as integrity. Run validation (the AWS CLI validate-logs command) on a schedule and before evidence is handed to an investigator or auditor.

CloudTrail tampering and logging evasion: detection

Logging evasion ranges from the obvious (deleting a trail) to the subtle (adding a selector that drops one principal's events, disabling Data Access logs for one service, or editing a sink exclusion filter). Attackers often enumerate logging configuration first, reading trail status, event selectors, diagnostic settings or sinks to find blind spots, so reads of logging configuration by unusual principals are themselves worth alerting on. ATT&CK v20 records this as T1685.002 Disable or Modify Cloud Log under the Defense Impairment tactic (TA0112), including APT29 disabling Purview Audit on targeted accounts before stealing email.

Evaluate these alerts in the security account, where an attacker in a workload account cannot also disable them. See the Detection Engineering Guide.

Coverage gaps, fidelity, noise and correlation

• Audit log coverage gap: check every account, subscription, project and SaaS tenant against the central store weekly. Gaps usually come from accounts outside the organisation, partitions without a trail and SaaS tenants never onboarded.
• CloudTrail drift: use AWS Config rules such as multi-region-cloudtrail-enabled, cloud-trail-log-file-validation-enabled, cloud-trail-encryption-enabled and cloudtrail-s3-dataevents-enabled, and compare deployed selectors with the version in source control.
• Audit log fidelity: confirm events carry the real principal, source IP, user agent and request ID. Records for actions through a shared role or a third-party integration may name only the role session, so session names and source identity settings matter.
• CloudTrail event noise: reduce cost by excluding known high-volume, low-value sources with selectors, but document every exclusion with an owner, and never exclude by principal for identities with write access.
• Audit log correlation: join records on stable keys: AWS userIdentity.arn, accessKeyId and sourceIPAddress; Azure correlationId and caller; Entra correlationId and application ID; Google AuthenticationInfo principal and RequestMetadata.callerIp. CloudTrail correlation of an AssumeRole event with the actions taken under the session is how one identity is followed across accounts.

Many of the principals in these logs are non-human: roles, service principals, managed identities and service accounts. Baseline what each normally calls, from where, so a stolen key used from a new network stands out. See the Cloud Workload Identity Guide.

Implementation roadmap

1. Inventory (week 1): list accounts, subscriptions, projects, tenants and SaaS apps; record current logging, retention and destination for each.
2. Build the log archive (weeks 1 to 2): a dedicated account, subscription and project with restricted administrators, customer managed keys and immutable storage. Test Object Lock or bucket lock on a non-production bucket first, because compliance-mode locks cannot be reversed.
3. Turn on organisation coverage (weeks 2 to 3): organisation trail with read and write management events and log file validation; Azure Policy for subscription diagnostic settings plus management group, tenant and Entra settings; Google aggregated sink. Confirm a new test account or project appears automatically.
4. Add data access selectively (weeks 3 to 6): start with crown-jewel buckets, key vaults and databases. Pilot data events or Data Access logs on one project for two weeks, measure volume and cost, then expand. Roll back by removing the selector or audit config, which is immediate.
5. Stream SaaS and identity logs (weeks 4 to 8): Purview Audit via the Management Activity API, Entra sign-in categories and the audit APIs of other critical SaaS.
6. Protect the pipeline (weeks 6 to 8): tampering alerts from the table above, Config or policy drift rules, and service control or organisation policies that deny logging changes except from the logging pipeline role.
7. Prove it (ongoing): quarterly, run validate-logs, restore a sample of archived logs, and replay one incident scenario end to end.

Decision guidance

• Small estates: one organisation trail to S3 with Athena, Activity log and Entra logs to one Log Analytics workspace, a Google aggregated sink to one bucket. Add data events only for the few stores holding sensitive data.
• Large or regulated estates: a central log platform fed by streaming, immutable archive copies, data access logging driven by data classification, and documented retention per log type mapped to each regulation.
• Retention period: CIS Safeguard 8.10 sets a 90-day minimum; regulators and incident timelines usually justify at least one year searchable and longer in archive. Attacker dwell time, not storage cost, should set the floor.
• Hot versus archive: keep 90 days to a year hot for hunting; archive the rest in immutable object storage.

Measuring the audit trail

• Coverage: percentage of accounts, subscriptions, projects and SaaS tenants delivering audit logs centrally (target 100 per cent).
• Data access coverage: percentage of stores classified as sensitive with data events, resource logs or Data Access logs enabled.
• Delivery latency: median time from event to searchable in the central store, per source.
• Integrity checks: validation runs passed and days since the last successful validation.
• Tamper alerts: logging configuration changes detected, and the share made outside approved change.
• Retention conformance: sources meeting their documented retention period.

Common failure patterns

• Relying on 90-day Event history: intrusions found months later have no record of the initial access.
• No data events on the bucket that mattered: in the Codefinger S3 ransomware campaign stolen keys were used to re-encrypt objects; object-level activity is only visible with S3 data events.
• Audit logging tied to licence tier: the Storm-0558 intrusion was spotted through enhanced Microsoft 365 audit records that not every customer had at the time.
• Logs stored in the account they audit: an attacker with administrator access deletes the bucket or the key along with their tracks.
• Quiet selector or sink changes: teams alert on StopLogging but not on PutEventSelectors or sink filter edits.
• Non-human principals never baselined: in the AWS crypto-mining campaign compromised IAM credentials drove every step through control plane calls CloudTrail records, yet without a baseline of what each key normally does the first signal is often the bill. The same applies to unrouted service principal and managed identity sign-in logs.

Framework mapping

Practitioner checklist

• Create an organisation trail (multi-Region, read and write management events, log file validation, SSE-KMS) delivered to a separate log archive account.
• Deploy Activity log diagnostic settings to every subscription by Azure Policy, plus management group, tenant and Entra settings covering all sign-in categories and Graph activity logs.
• Create a Google organisation aggregated sink and enable Data Access logs for sensitive services.
• Enable data access logging for every store classified as sensitive.
• Protect archives with Object Lock, immutable blob policies or locked log buckets and customer managed keys.
• Alert centrally on StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors, diagnostic setting changes and sink updates.
• Manage selectors, sinks and diagnostic settings as code and detect drift.
• Stream Microsoft 365 and other SaaS audit logs and record each tenant's retention.
• Document retention per log type, at least 90 days and usually one year or more searchable.
• Validate log integrity and test restores quarterly.

Standards and references

• AWS: Creating a trail for an organization
• AWS: Logging data events
• AWS: Validating CloudTrail log file integrity
• Microsoft Learn: Activity log in Azure Monitor
• Microsoft Learn: Microsoft Entra data retention
• Google Cloud: Cloud Audit Logs overview
• Google Cloud: Aggregated sinks
• MITRE ATT&CK: T1685.002 Disable or Modify Cloud Log

Related NHI Mgmt Group resources: Log Management and Retention Guide · Cloud Incident Response Guide · SIEM Guide · Cloud Security Guide · Detection Engineering Guide