Cloud logging means recording activity in your cloud, such as who signed in, who changed permissions, and who opened or deleted data. Detection means using those records to look for suspicious behavior and raise alerts. If the right logs were not collected beforehand, detection and after-the-fact investigation are not possible. This article covers which log types to collect, what the major cloud providers record by default and for how long, and how to set things up so logs are usable for detection.

The layers of cloud logs

Before choosing what to collect, know that cloud operations come in two kinds. The first is the control plane, meaning creating, changing or deleting resources, such as creating a virtual machine or editing user permissions. The second is the data plane, meaning operations on the data inside a resource, such as reading a file in storage or fetching a secret from a key vault. Control plane logs are low in volume and high in value. Data plane logs are high in volume, so they are often not switched on automatically.

  • Identity: sign-ins, multi-factor authentication (MFA) and changes to accounts and permissions. See more in ITDR: Identity Threat Detection and Response
  • Management (control plane): who called which management operation on the cloud account, when and from where
  • Data (data plane): reads, writes or deletes in storage or databases, switched on only for the sensitive parts
  • Systems and network: logs from machines, apps and network connections inside the cloud
INFOGRAPHIC
Four layers of cloud logs
Cloud logs
enable what detection needs
Identity
sign-ins, MFA, permissions
Control plane
create, change, delete
Data plane
high volume, selective
Systems and network
machines, apps, traffic

What each provider records by default, and for how long

The points below were checked against each provider's own documentation on 27 October 2026. Defaults can change, so check the current documentation before planning with them:

  • AWS CloudTrail: every account can view Event history by default, covering the past 90 days of management events in each Region. To keep records longer than 90 days you must create a trail or a CloudTrail Lake event data store. Data events are not logged by default and cost extra
  • Azure Activity Log: records management operations on resources and keeps them for 90 days, then deletes them. For longer retention you must create a diagnostic setting that sends entries elsewhere. Data plane logs are in resource logs, which you configure yourself
  • Google Cloud Audit Logs: Admin Activity logs are always written and cannot be disabled. Data Access logs are off by default except for BigQuery, and must be enabled for other services. The _Required bucket keeps entries for 400 days and cannot be changed. The _Default bucket keeps them for 30 days
  • Microsoft Entra ID: sign-in and audit logs are kept for 7 days on the Free tier and 30 days on P1 and P2, and are separate from the Microsoft 365 Unified Audit Log, which is managed through Microsoft Purview

In short, defaults suit only short look-backs. If an incident is found after the retention period has passed, there is no log left to look at. How long to keep logs is your organization's decision, based on risk and the rules that apply to you. The sources we checked give no single standard number.

What to collect first

NSA and CISA, with international partners, published a set of SIEM and SOAR documents on 27 May 2025. One of the three is titled Priority Logs for SIEM Ingestion: Practitioner Guidance, and it is about deciding which logs to send into a SIEM (a system that collects and analyzes logs from many sources) first. We could not read the PDF directly, so we can only summarize it from CISA's description and a partner agency's summary page: the document groups logs by source type, including the major cloud providers, and advises tailoring collection to your organization and adding sources gradually rather than all at once.

The order below is our own suggestion, putting high-value, low-volume events first. It is not taken from the document above.

  • Sign-ins and changes to authentication: successful and failed sign-ins, and MFA being added or removed
  • Use of top-level admin accounts: the AWS root account or the Microsoft Global Administrator role, which should be used rarely, so every use needs a reason
  • Changes to permissions and keys: creating access keys (codes programs use to call the cloud), granting admin rights, and creating or editing machine accounts
  • Tampering with logging itself: stopping or deleting a trail, diagnostic setting or sink that ships logs out
  • Opening access paths: making storage public or opening cloud firewall rules to the whole internet
  • Access to sensitive data: switch on data plane logs only for the sensitive stores, because they cost extra and are high in volume

Turning logs into detections with MITRE ATT&CK

MITRE ATT&CK (a knowledge base of attacker techniques) has a Cloud Matrix covering four platforms: Office Suite, Identity Provider, SaaS and IaaS (rented machines and networks). Use it to choose what to write detections for, then work backwards to which logs you need to detect it. If the needed log is missing, the rule cannot work. SaaS apps your organization uses must also send their own logs in. See SaaS Security and SSPM: Looking After SaaS Apps.

  • Cloud accounts used abnormally: a successful sign-in after many failures, or from a place never seen before, matching the technique Valid Accounts: Cloud Accounts
  • Adding a way to stay in: adding new keys or roles to an account, matching Account Manipulation sub-techniques such as Additional Cloud Credentials and Additional Cloud Roles
  • Switching off protection or logging: turning off logs or security tools, matching the Defense Impairment tactic in ATT&CK v20, the version we viewed
  • Running commands on machines through the cloud's management service: matching the technique Cloud Administration Command, which can be seen in control plane logs
  • Moving data out: reading or copying large amounts of data from storage, which can only be detected if data plane logs are switched on

Setting it up step by step

This routine is our own arrangement drawn from the provider documentation and ideas above. It is not a single standard.

  • Switch on logging for every account and Region: create a trail or event data store in AWS, set a diagnostic setting in Azure, and enable Data Access audit logs in Google Cloud for the important services
  • Ship logs to a separate account: use an account or project just for logs that ordinary admins cannot delete from, because attackers often try to erase their tracks
  • Set the retention period: base it on risk and applicable rules, and check that it is long enough for your needs, since provider defaults can be shorter
  • Protect log integrity: turn on CloudTrail log file validation, which can tell whether log files were modified or deleted. Google Cloud's Cloud Audit Logs state that written entries are immutable
  • Send to the SIEM and test the rules: simulate an event in a test account, such as creating a new access key, and check that the rule really fires
INFOGRAPHIC
Setting up logging step by step
1
Switch on logging
every account and Region
2
Ship to a separate account
admins cannot delete
3
Set retention
by risk and rules
4
Protect integrity
detect tampering
5
Send to SIEM and test
simulate and confirm alerts

Once logs are gathered in one place, see SIEM, SOAR and XDR: How They Differ for choosing analysis tools.

Common mistakes

  • Relying on provider defaults: several services keep only 7 to 90 days, and there are no data plane logs
  • Switching on every log without choosing: costs rise and the team is swamped with alerts nobody reads
  • Keeping logs in the same account as the attacked system: an attacker with admin rights can delete them
  • Not checking that logs are still arriving: log shipping stops unnoticed while everyone believes detection is working
  • Never testing detection rules: a rule exists but never fires because the log it needs was not switched on
INFOGRAPHIC
Mistakes versus better practice

Mistake

  • Relying on defaults
  • Logs in the same account
  • Never testing rules

Better practice

  • Set your own retention
  • Keep a copy in a separate account
  • Simulate events and check alerts

Start today

  • Check that management logging is on in every account: confirm a trail or diagnostic setting covers all of them
  • Look at your current retention: compare it with the defaults listed above and see if it is too short
  • Pick the first 3 rules to build: for example use of a top-level admin account, logging being stopped, and a new access key being created
  • Move a copy of logs to a separate account: start with management logs and sign-in logs

To see where your monitoring and detection stand today, try the self-assessment.

References and further reading