Audit Trails for Cloud Changes: What to Record and Keep

An audit trail is a chronological, tamper-resistant record of actions: who or what acted, on which resource, when, with what request, and with what result. It answers incident questions (“what changed before this broke”), cost questions (“who launched this”), and compliance questions (“show me every privileged change last quarter”).

What the cloud providers record for you

Each provider has a control-plane log, and each has defaults that surprise people:

• AWS CloudTrail event history is a viewable, searchable, downloadable, immutable record of the past 90 days of management events. For anything older, you need a trail or a CloudTrail Lake event data store. Trails and event data stores log management events by default, but not data events.
• Google Cloud Audit Logs always write Admin Activity logs; you cannot configure, exclude, or disable them. Data Access audit logs are disabled by default except for BigQuery. The _Required log bucket keeps its entries for 400 days, not configurable, while the _Default bucket keeps 30 days by default.
• Azure Activity Log records control-plane operations such as creating a VM or changing a Key Vault access policy, and retains events for 90 days before deleting them. Longer retention needs a diagnostic setting that sends entries elsewhere. Microsoft notes that preserving resource creator information is a common reason to extend retention, since it is only available in the activity log. Data-plane resource logs are not collected unless you configure them.

The practical rule: decide your retention period first, then configure trails, sinks, and diagnostic settings to meet it, because the defaults range from 30 days to 400 depending on provider and log type.

What provider logs miss

Provider logs record API calls. They do not record intent. A StopInstances call from an automation role says nothing about which schedule fired, which override suppressed a start, or which approval allowed a delete. Any tool that acts on your cloud needs its own trail that captures the decision, not just the API call.

What ZopNight records

• Every mutating request. ZopNight’s gateway logs all POST, PUT, PATCH, and DELETE requests per organization, with both request and response bodies. The audit log page offers server-side filtering by method, resource, status, and user, plus search, and shows human-readable descriptions, such as cron expressions rendered in plain language.
• Every state change and its cause. State history records each start and stop with a timestamp, and shows whether a schedule (which one), a user action (which user), or an override triggered it.
• Assistant activity. Calls made through the MCP server are audited too, including read calls, with a source marker so they can be told apart.
• Recommendation history. Each recommendation carries a timeline of generated, viewed, applied, dismissed, reopened, and closed events.

Filtered audit logs can be exported to CSV as a background job, which suits evidence collection for SOC 2 or ISO 27001 audits. These exports are not persisted, so if the export is interrupted you re-run it.

Making a trail useful

• Keep the provider log and the tool log for the same period, so a cloud API call can be matched to the decision behind it.
• Require a reason on manual overrides and exceptions; the reason is the part auditors ask about.
• Review destructive actions separately from routine ones. Pair this with role-based access control so that only a few roles can perform them.

Related: activity log sync and resource ownership detection, which reuse the same provider logs for cost work.