---
{
  "title": "Cloud audit logs",
  "summary": "Control-plane and data-plane records answer different questions.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "AWS: Shared Responsibility Model",
      "url": "https://aws.amazon.com/compliance/shared-responsibility-model/"
    },
    {
      "title": "AWS CloudTrail: Logging data events",
      "url": "https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Cloud activity has more than one record

Cloud audit logs record actions performed through cloud services and management interfaces. They can show identities changing permissions, creating workloads, configuring storage, or requesting data. Their value depends on which service, account, region, event category, and collection settings are covered.

A crucial distinction is between management activity and data activity. Creating a storage bucket is a management action; reading an object from that bucket is a data action. A trail that answers who changed the bucket policy may not answer who downloaded a particular document. Provider defaults and supported event categories vary, so verify the actual configuration.

## Investigate an unexpected storage change

In a fictional organization, an alert reports that a storage policy became more permissive. The responder identifies the affected resource, the principal making the request, the event time, the policy change, and the recorded result. They compare the change with approved infrastructure work and the previous configuration.

The principal may be an assumed role or service identity rather than a human username. Trace the identity chain where the records support it. A deployment role could have been used by an approved pipeline, a developer's interactive session, or an unauthorized party with access to its credentials.

To investigate possible document access, the team checks whether relevant data events were enabled during the exposure window. Enabling them now improves future visibility but does not recreate missing historical events. Other records, such as application events or storage access logs, may help, subject to their own coverage and limitations.

## Preserve context across accounts

Use stable cloud resource identifiers and account or tenant identifiers when exporting evidence. Display names are convenient but may change or repeat. Preserve event times, ingestion times when relevant, and the query scope so another responder can reproduce the search.

Central storage can improve retention and protect records from a compromised workload, but it needs its own permissions and monitoring. Excessive access to audit archives can expose sensitive operational information. Changes to logging configuration deserve attention because they may alter what future investigations can establish.

## Test coverage before an incident

Choose a disposable test resource and an authorized test identity. Record one configuration change and one harmless data read. Locate each action in the expected log destination, noting delivery delay and required settings.

Document which questions each event answers and which it cannot answer. Do not conclude that a data read never occurred solely because the management log contains no such entry. [[cloud-incident-response]] relies on this distinction, while [[incident-timeline]] helps organize the actions that can actually be supported by evidence.

## Related concepts

- [[logs-and-telemetry]]
- [[cloud-storage-security]]