operations
Who made this change? Reading your cloud's change record
30 Sept 2026 · 4 min read · Zaysa
Something in your cloud account is different from yesterday. A load balancer is gone, a database got bigger, a firewall rule appeared. The first question is always the same: who did that, and how?
Every large cloud keeps a record that can answer it. The records have different names, keep data for different lengths of time and have different blind spots. Knowing them before you need them saves a lot of guessing during an incident.
The four records
| Cloud | Where the record lives | Kept by default | Tells you who |
|---|---|---|---|
| AWS | CloudTrail event history | 90 days of management events | Yes |
| Azure | Activity Log | 90 days | Yes |
| Google Cloud | Cloud Audit Logs, Admin Activity | 400 days | Yes |
| DigitalOcean | Actions on each resource | No fixed period stated | No, the public API does not say |
AWS: CloudTrail
CloudTrail records API calls. The event history is on by default and covers management events, which are the calls that create, change or delete resources. Each event carries the identity that made the call, the time, the source address and the tool used, so you can tell a console click from a Terraform run.
Two things to know:
- Event history is per region. A change made in another region will not show up where you are looking.
- Data events, such as reads and writes of objects in a bucket, are not recorded unless you create a trail for them.
If you need more than 90 days, create a trail that delivers to a bucket you own.
Azure: Activity Log
The Activity Log records operations on resources in a subscription: who started it, what the operation was and whether it succeeded. The caller is a user's sign-in name or, for automation, the identifier of a service principal. That second case is worth a moment: an identifier on its own tells you an application did it, and you then need to look up which application that is.
The Activity Log covers the management side. What happens inside a resource, for example queries against a database, is in that resource's own logs.
Google Cloud: Cloud Audit Logs
Admin Activity audit logs are always on and cannot be switched off. They record who changed configuration, and they are kept for 400 days, the longest default of the three.
Data Access logs are a separate stream. They are off by default for most services and kept for a shorter time, because they can be very large.
One detail that surprises people: a lot of changes in a Google Cloud project are made by Google's own service agents on your behalf. When a cluster resizes a subnet, the record names the service agent, not a person. That is accurate, and it means the real question becomes what asked the service to do it.
DigitalOcean: actions
DigitalOcean's API lists the actions taken on a resource, such as a resize, a reboot or a snapshot, with the time each one started. It does not say which team member or token started it. The security history in the DigitalOcean control panel is the place to look for that.
Why "nothing found" is often the right answer
When you compare two snapshots of an account and look for the person behind each difference, many differences will have no matching event. That is normal:
- Deleting a network removes its subnets. There is one event, on the network.
- A managed service creates and removes resources of its own.
- The change happened before the start of the retention window.
A tool that shows a name next to every change is guessing. "No event found in this window" is more useful than a confident wrong answer.
How Zaysa uses these records
In Cloud History you pick two snapshots of an account and see what was added, removed and modified. "Who made these changes?" then looks up each change in that cloud's own record and shows the identity, the action, the time and the tool when the cloud has them. When the cloud has no record, Zaysa says so. For DigitalOcean it says plainly that the provider does not report who made a change.
