Cloud audit logging across accounts
The logs you get without asking record who changed your configuration and, in most services, nothing at all about who read your data. Retention on the default view is short, commonly around ninety days depending on the provider and service, which is often less than the time it takes to find out you have a problem. That combination produces the most common cloud investigation outcome: a clear record of the settings being changed, and no way to say whether anything was taken.
What do the default cloud logs not tell you?
They do not tell you what was read. Every major provider records management activity by default, so the creation of a role, the modification of a policy or the deletion of a resource appears in an audit trail without any configuration. Data access, meaning the actual reads and writes against objects, rows and messages, is a separate log category, is off by default in most services, and is charged by volume. The reason for that default is cost, and the consequence is a permanent blind spot in exactly the place a regulator will ask about.
They also expire sooner than people assume. The built-in, immediately searchable history is typically a few months, and beyond that you have only what you deliberately exported to storage. Since the interval between a compromise and its discovery is frequently longer than that, the practical effect is that the most important part of the timeline has already aged out by the time anybody looks for it.
The third gap is attribution. A trail will faithfully record that a role performed an action, and if several engineers assume the same role, the record does not say which human it was unless you configured session identity to be propagated. Establishing that a specific person did a specific thing is a configuration decision made in advance, not something an investigator can recover afterwards.
Which logs exist, and which are off by default?
The categories below behave differently enough that treating logging as one project is why estates end up with both gaps and duplicated ingestion costs. Enable the first, be selective with the second and third, and check the defaults for your provider rather than assuming, since they change.
| Log type | What it records | Usual default | Why you need it |
|---|---|---|---|
| Management or admin activity | Configuration changes through the API | On, with limited retention | The core audit trail, and the first thing an attacker changes |
| Data access | Reads and writes of your actual data | Off in most services | The only way to answer whether data was taken |
| Identity sign-in | Authentications, factors used, source | On in the directory, retention varies by licence | Detecting credential abuse and impossible travel |
| Network flow | Connections between addresses, allowed and denied | Off | Establishing what talked to what during an incident |
| Resolver queries | Names workloads looked up | Off | Cheap detection of command and control and exfiltration |
| Service-specific audit | Database statements, queue operations, key use | Varies, often off | Attribution inside a managed service |
| Application logs | Whatever your code emits | Your decision | Business context nothing else has |
Why must the destination be a different account?
Because an attacker who holds administrative credentials in an account can delete that account's logs, and a log an attacker can edit is not evidence. The single most valuable structural decision in cloud logging is to send everything to a dedicated archive account whose only job is to receive and retain, where the source accounts have permission to write and no permission to read, modify or delete.
Combine that with two supporting controls. Organisation-level policy that denies disabling the trail or altering its destination, which holds even against an account administrator, and object-level retention on the archive bucket so that objects cannot be deleted before their retention expires even by an administrator of the archive account itself. Providers offer these mechanisms specifically for this purpose, and configuring them takes an afternoon.
Access to the archive should be narrower than access to production, which sounds obvious and is frequently reversed in practice, because the log archive is treated as a technical convenience rather than as the store of record. It usually contains identifiers, addresses and request metadata about your customers, so it deserves the same data classification treatment as any other sensitive store, including a decision about how long you are entitled to keep it.
What actually breaks during an investigation?
Time and identity, in that order. Logs from different services arrive with different timestamp conventions and different delivery delays, and an investigator building a timeline across four sources will spend real hours reconciling them. Standardise on coordinated universal time everywhere at ingestion, and record delivery lag per source, because a five-minute delay changes the interpretation of an ordering that looked causal.
Then attribution through assumed roles and service actions. Cloud services perform actions on your behalf, so a trail contains entries where the actor is a service rather than a person, and a chain of role assumptions can obscure the origin unless the original identity is carried forward. Configure that propagation now, and adopt a session naming convention, otherwise every investigation begins with a guess about which engineer was on which role.
The third failure is retention shorter than your detection window. If it commonly takes weeks or months to notice an intrusion, thirty days of searchable logs guarantees that the interesting part is gone. Choose retention from your realistic time to detect rather than from a compliance minimum, and keep the cheap, queryable archive long even if the fast searchable tier is short.
How do you stop cost deciding this for you?
Tier deliberately instead of choosing between everything and nothing. Keep a short hot window in whichever search tool your responders actually use, thirty days is usually enough, and land the full stream in object storage with a query-in-place engine for the long tail. That arrangement costs a fraction of ingesting everything into an analytics platform and preserves the ability to answer questions about last year, which is the requirement people discover too late.
Be selective where volume is enormous and value is uneven. Data access logging on every object store in the estate is rarely affordable or useful; on the three stores holding personal data, credentials or intellectual property it is both. Flow logging on every subnet produces enormous volume; on the subnets containing your data services it is proportionate. Selectivity documented with a reason survives budget review far better than an all-or-nothing position.
Then remove duplication, which is the commonest source of avoidable cost. Estates frequently collect the same events twice, once through the platform and once through an agent, and forward both into an expensive tier. Audit what you are already paying to store before adding a source, and check retention settings on each, since the default in a managed logging service is often longer and more expensive than anybody chose.
What can you test this week?
Pick a configuration change made about six weeks ago and reconstruct it end to end: which identity, which human behind that identity, from which address, at what time, and what else that session did in the following hour. Do it without asking the person who made the change. The exercise takes an hour and reliably exposes whether you have logs or an assumption about logs.
Then attempt to disable logging in a non-production account using an administrator credential. If it works, your audit trail is only as trustworthy as the account it describes. If organisation policy blocks it, you have the property that makes the record evidence, and you will have confirmed it rather than assumed it.
Finally, ask the question that decides your data access logging policy: for your most sensitive store, could you produce a list of every read in the last ninety days. If not, decide now whether that is acceptable, write the decision down with the reason, and revisit it the day you handle a subject access request or a suspected breach, because those are the moments the answer becomes expensive.
Common questions
- Do cloud audit logs show who accessed my data?
- Not by default. The trail enabled without configuration records management activity, meaning changes to configuration such as policies, roles and resources. Data access logging, which records the actual reads and writes of objects, rows and messages, is a separate category that is off by default in most services because it is charged by volume. Without it you cannot answer whether data was taken during an incident.
- How long are cloud audit logs kept?
- The immediately searchable default history is short, commonly around ninety days depending on provider and service, and some providers keep admin activity longer. Beyond that window you only have what you exported to storage deliberately. Since intrusions are often discovered months later, retention should be chosen from your realistic time to detect rather than from a compliance minimum, with a cheap queryable archive holding the long tail.
- Why should cloud logs go to a separate account?
- Because an administrator in an account, including an attacker who has become one, can delete that account's logs, and a log the subject can edit is not evidence. Send everything to a dedicated archive account with write-only access from the sources, deny disabling the trail through organisation-level policy, and apply object retention so entries cannot be removed early even by an archive administrator.
- Why can we not tell which person performed an action?
- Because the trail records the role that acted, and if several engineers assume the same role, the entries look identical unless you configured the original identity to be carried forward into the session. Cloud services also act on your behalf, producing entries whose actor is a service. Both are configuration decisions made in advance; an investigator cannot recover the missing attribution afterwards.
- How do you control the cost of cloud security logging?
- Tier rather than choose. Keep a short hot window, often thirty days, in the tool your responders use, and land the full stream in object storage with a query-in-place engine for the long tail. Be selective where volume is large and value uneven, enabling data access logs on your few most sensitive stores rather than everywhere. Then remove duplicate collection, which is the most common avoidable cost.
- What is the best test of whether cloud logging works?
- Reconstruct a real change made about six weeks ago without asking the person who made it. Establish which identity acted, which human was behind it, from which address, at what time, and what else that session did. Teams that believe their logging is adequate usually fail this at the attribution step or find the retention window has already closed on the record they need.
