Cloud logging and monitoring: what to log, how long to keep it and when to alert

Cloud logging and monitoring is how a team finds out what happened in a cloud account: who signed in, who changed a setting, which application read a secret, and when. Without logs, a misconfiguration or compromised account can go unnoticed, and an investigation has little to work with. This guide explains what to log, how the Azure activity log and AWS CloudTrail work, why retention matters, how alerts fit in, and what the ACSC’s event logging guidance describes.

Why it matters

Logs answer the questions that matter after something goes wrong: what changed, from where, by whom, and whether data was accessed. The ACSC’s Cloud computing security for tenants guidance lists obtaining and “promptly” analysing “detailed time-synchronised logs and real-time alerts for the tenant’s cloud service accounts” among its general mitigations.

The ACSC’s Best practices for event logging and threat detection, first published in August 2024 with international partner agencies, sets out four key considerations:

1. an enterprise-approved logging policy
2. centralised log collection and correlation
3. log integrity, including secure log storage
4. a detection strategy for relevant threats.

The ACSC notes the guidance is aimed at medium to large organisations and assumes a basic understanding of event logging, but the ideas scale down.

What to log

The ACSC guidance says that for cloud environments, organisations log “all control plane operations, including API calls and end user logins.” It also describes useful log entries as having an accurate timestamp, event type, user ID where relevant, and the command executed.

In practice, cloud logs fall into a few groups:

• Sign-in and identity logs: who signed in, from where, with which method, and failed attempts. In Microsoft 365 and Entra these are covered in Microsoft 365 audit logs and alerts.
• Control plane (management) logs: creating, changing and deleting resources, role assignments and policies. This is the Azure activity log and AWS CloudTrail management events.
• Data plane logs: reading or writing the data itself, such as reading a Key Vault secret or downloading a stored file. These usually have to be turned on separately.
• Workload logs: operating system, web server and application logs, which the ACSC’s tenants guidance also lists.

The ACSC notes that logging responsibility depends on the service model: IaaS places more logging duties on the customer, and SaaS shifts more to the provider. See the shared responsibility model.

What the Azure activity log records

Microsoft describes the activity log as recording management operations on Azure resources, “like creating a virtual machine, changing a key vault access policy, or Resource Manager deployment errors.”

Key facts from Microsoft’s documentation:

• It doesn’t capture data plane activity such as reading a Key Vault secret; that needs resource logs.
• It “doesn’t typically capture read operations”, and entries appear within 3 to 20 minutes.
• Azure retains activity log events for 90 days and then deletes them, with no charge during that period.
• To keep entries longer, Microsoft describes creating a diagnostic setting that sends them to a Log Analytics workspace, Azure Storage or Event Hubs. Microsoft says Log Analytics retention can be increased up to 12 years, with charges only for retention beyond the 90-day default.
• In a Log Analytics workspace, activity log data lands in the AzureActivity table and can be used for log alerts with more complex logic than activity log alerts.

How to export the Azure activity log for longer retention

Based on Microsoft’s instructions (checked October 2026). Portal menus can change; Microsoft’s activity log guide has the latest steps.

1. In the Azure portal, open the Azure Monitor menu and select Activity log.
2. Select Export Activity Logs.
3. Create a diagnostic setting that sends the activity log to a destination such as a Log Analytics workspace, Azure Event Hubs or Azure Storage.
4. Disable any legacy configuration for the activity log; Microsoft describes log profiles as the legacy export method.

What AWS CloudTrail records

AWS describes CloudTrail as capturing “a record of AWS account activities.”

• Event history shows “the last 90 days of management events for your AWS account for the current AWS Region.” AWS describes it as viewable, searchable, downloadable and immutable.
• Trails capture ongoing events and deliver “management and data events to Amazon S3”, optionally also to CloudWatch Logs. A trail can cover one account or many accounts through AWS Organizations.
• CloudTrail Lake is a managed store for querying events, kept in read-only form.
• CloudTrail Insights builds a baseline of normal API call volumes and error rates and generates an insight event when activity falls outside typical patterns.

How to look up recent activity in CloudTrail event history

Based on AWS’s instructions (checked October 2026). AWS’s event history guide has the latest steps.

1. Open the CloudTrail console and, in the navigation pane, choose Event history. The most recent events are shown first.
2. The default filter is Read only set to false. To include read events too, choose X at the right of the filter.
3. Choose an attribute to filter on and enter its full value, such as Event name with ConsoleLogin. AWS notes CloudTrail “can’t filter on a partial value.”
4. Choose an event name to see its details, select up to five events to compare side by side, or download the results as a CSV or JSON file.

Event history is for the current Region only, so activity elsewhere needs checking separately or a multi-Region trail.

How long to keep logs

The ACSC’s guidance says that “default log retention periods are often insufficient”, that retention reflects system risk because intrusions can go undetected for long periods, and that logs “crucial in confirming an intrusion and its impact” are prioritised for longer retention. It describes hot and cold storage tiers to balance cost and capacity.

Ninety days of default history in both Azure and AWS can therefore be shorter than an investigation needs. Exporting logs to separate storage is also how the ACSC’s “secure storage” consideration is met: the guidance describes protecting logs “from unauthorised modification and deletion” and limiting access to people with a justified need.

Which events to alert on

Logs nobody reads don’t help much in the moment. Alerts turn specific events into notifications. Examples drawn from the sources:

• Root or owner sign-ins. AWS’s root user best practices describe tracking and alerting on root user sign-in and use.
• Secret access and failed authentication. Microsoft’s Key Vault guidance describes Azure Monitor alerts for suspicious access patterns or failed authentication attempts.
• Unusual behaviour. The ACSC describes behavioural analytics that flag things such as off-hours logins, impossible travel or unexpected log clearing, and notes flagged behaviour may be legitimate and needs investigating.
• Configuration changes. Microsoft describes activity log alerts for being “proactively notified when an event occurs”, such as a role assignment.

The ACSC also stresses consistent time: a trusted, synchronised time source across systems, with UTC preferred, so events from different systems line up.

A fictional example

Aisha runs IT for a small accounting practice, ledger.example. An alert fires on a Saturday: a new owner role assignment in the Azure subscription. Because she exported the activity log to a Log Analytics workspace months earlier, she can see who made the change, from which account and when, and match it with sign-in logs. It turns out to be a contractor working on a planned project, so she records it. If it hadn’t been, her incident response plan and the ACSC hotline were the next steps.

Things to watch for

• Relying on 90-day defaults. Both Azure and AWS delete default history after 90 days.
• Management logs only. Reading a secret or downloading a file usually needs data plane logging turned on separately.
• Logs stored where an attacker can delete them. The ACSC describes protecting logs from unauthorised modification and deletion.
• One Region only. CloudTrail event history covers the current Region.
• Alert fatigue. Too many low-value alerts get ignored; the ACSC describes a detection strategy focused on relevant threats.
• Clock drift. Inconsistent timestamps make correlation hard.

Common questions

What should be logged in a cloud environment?

The ACSC’s event logging guidance says that for cloud environments, organisations log all control plane operations, including API calls and end user logins. In practice, the usual groups are sign-in and identity logs, management logs such as the Azure activity log and AWS CloudTrail, data access logs for sensitive resources, and workload logs. The ACSC describes useful entries as having an accurate timestamp, event type, user ID and the command executed. See what to log.

How long does Azure keep the activity log?

Microsoft says Azure retains activity log events for 90 days and then deletes them, with no charge during that period. A diagnostic setting can send them to a Log Analytics workspace, Azure Storage or Event Hubs, and Microsoft says Log Analytics retention can be extended up to 12 years, with charges only beyond the 90-day default. How to export the Azure activity log has Microsoft’s portal steps.

How long does AWS CloudTrail keep events?

AWS says CloudTrail event history shows the last 90 days of management events for the current Region, and describes it as viewable, searchable, downloadable and immutable. Trails deliver ongoing management and data events to Amazon S3, where they are kept according to the bucket’s settings, and a trail can cover many accounts through AWS Organizations. See what AWS CloudTrail records.

How long should logs be kept?

There’s no single number. The ACSC says default log retention periods are often insufficient, because intrusions can go undetected for long periods, and that retention reflects the system’s risk. Logs needed to confirm an intrusion and its impact are prioritised for longer retention. The ACSC also describes hot and cold storage tiers to balance cost, and protecting logs from unauthorised modification and deletion. See how long to keep logs.

Which cloud events are worth setting alerts for?

Examples from the sources include root or owner sign-ins, which AWS describes tracking and alerting on, and failed authentication to secrets, which Microsoft’s Key Vault guidance covers. Others are configuration changes such as a new role assignment, and unusual behaviour like off-hours logins or impossible travel, which the ACSC describes flagging. The ACSC also describes a detection strategy focused on relevant threats, to avoid alert fatigue. See which events to alert on.

What do I do if I spot suspicious activity in my cloud logs?

The ACSC notes that flagged behaviour may be legitimate and needs investigating, so the logs are used to work out who made a change, from which account and when. If it isn’t legitimate, the ACSC takes reports through ReportCyber and runs a 24/7 hotline on 1300 CYBER1 (1300 292 371). Our one-page incident response plan template can help a team prepare. See the fictional example for how this can play out.

Where to get official help

• The ACSC publishes the event logging guidance and runs ReportCyber and the 24/7 hotline (1300 CYBER1, 1300 292 371).
• Microsoft Learn: the Azure activity log.
• AWS: viewing CloudTrail event history.