Cloud platforms can produce more log data than any team can read, and much of it is switched off by default or kept only briefly. Teams tend to respond in one of two ways. Some collect everything and run out of budget. Others enable the provider's native detection service and assume the work is done.
A monitoring strategy is a set of decisions: which questions must be answerable, which logs answer them, where those logs are kept, what is detected and who acts. This article sets out an order of work that holds across AWS, Azure and Google Cloud.
Start with the control plane
In the cloud, the most damaging actions are API calls: creating credentials, changing policies, exposing storage, deleting logs. Each of them passes through the provider's control plane, and the control plane is logged. That makes it the first thing to collect, in every account, subscription and project, and in every region.
- AWS. CloudTrail management events. Create an organization trail so that every account and region is covered, including accounts created later. The event history in the console is a convenience, not a retention plan.
- Azure. The Activity log records resource management operations for each subscription. Microsoft Entra ID sign-in and audit logs cover the identity side and are exported separately through diagnostic settings.
- Google Cloud. Cloud Audit Logs. Admin Activity logs are always written. Data Access logs are mostly off by default and are enabled per service.
Check coverage, not only configuration. Common findings are an account that was onboarded before the organization trail existed, a subscription with no diagnostic settings, or a trail that writes to a bucket nobody reads.
Add identity, then data, then workloads
Identity
A valid credential is the usual starting point for a cloud intrusion, so identity provider logs belong next to the control plane logs. With federated access, the sign-in happens in the identity provider and the role assumption happens in the cloud platform. An investigator needs both halves to get from a role session back to a person and a device.
Data events for the stores that matter
Object-level and record-level logging is high in volume and charged by volume. This covers S3 data events, Azure Storage resource logs and Google Cloud Data Access logs. Enable it selectively, for the few buckets, databases and file shares that hold regulated or business-critical data.
Key management and secrets services are the exception to the volume problem. Their logs are small and valuable, because they show who decrypted or read what, and they are worth collecting everywhere.
Workloads and Kubernetes
Virtual machines and container hosts need the same endpoint telemetry as any other server. For Kubernetes, the API server audit log is the control plane of the cluster. Managed services do not always deliver it by default: on Amazon EKS and Azure Kubernetes Service it has to be switched on and routed, while Google Kubernetes Engine writes to Cloud Audit Logs.
In the audit log, look for exec into running pods, creation of privileged pods, new bindings to the cluster-admin role, secret reads by unexpected service accounts and anonymous requests.
Network flow logs where they answer a question
Flow logs record connections, not content. They answer specific questions: did this instance talk to that address, how much data left, what else did a compromised host reach. If no detection uses them, keep them in low-cost storage and query them during investigations instead of streaming them into the SIEM.
Treat native detection services as inputs
Amazon GuardDuty, Microsoft Defender for Cloud and Google Security Command Center analyze provider telemetry and produce findings, including from sources that are awkward to collect yourself. Enable them across the whole organization and administer them from the security account. Then treat them as one input among several.
- Findings are generic. The service does not know your break-glass accounts, your approved regions, your deployment pipeline's role or which account is production.
- A finding needs routing, triage and an owner like any other alert. A finding in a console nobody opens is not monitoring.
- Coverage depends on which plans and protections are enabled. Those choices are often made for cost reasons and then forgotten.
- Misconfiguration findings and threat findings need different handling. The first go to an engineering backlog with an owner. The second go to the SOC queue.
Deciding which findings matter, and fixing the configurations behind them, is ongoing cloud security work and not a one-time setup task.
High-value detections to build first
A short list of detections on control plane and identity logs covers the actions that appear in a large share of cloud intrusions. Event names below are examples, not a complete list.
| Detection | Where it shows | Why it matters |
|---|---|---|
| Root or break-glass account use | CloudTrail events with a root user identity, including ConsoleLogin; Entra sign-ins for emergency access accounts |
These accounts should be silent. Any use is a planned event or an incident |
| New access key for a privileged identity | CreateAccessKey, CreateLoginProfile; Entra "Add service principal credentials"; service account key creation in Google Cloud |
A common persistence step |
| Logging disabled or a trail deleted | StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors; deleted Azure diagnostic settings; changed or deleted Google Cloud log sinks |
Visibility is lost before anything else happens |
| Public exposure of storage | PutBucketPolicy, PutBucketAcl, changes to S3 Block Public Access; public access changes on Azure storage accounts; SetIamPolicy granting allUsers |
A direct path to data exposure |
| IAM policy changes that grant admin | AttachUserPolicy, AttachRolePolicy, PutUserPolicy, PutRolePolicy, CreatePolicyVersion; Azure role assignments for Owner or User Access Administrator; SetIamPolicy adding owner roles |
Privilege escalation |
| Unusual region or service use | Management events in regions or services the organization does not use | Often the first visible sign of stolen credentials |
| Cross-account role assumption from unknown accounts | AssumeRole events where the calling account is not on the organization's account list |
Finds trust policies that are too broad |
Each detection needs three things before it is switched on: a list of expected actors such as pipeline roles, a severity, and a written first response step. Test each one by performing the action in a test account and confirming the alert arrives. That discipline is the core of detection engineering.
Centralize logs in a separate security account
Logs kept in the account that produced them can be deleted by whoever compromises that account. Multi-account and multi-subscription environments need a central design.
- A log archive that workload administrators cannot administer. On AWS, the organization trail delivers to a bucket in a dedicated account, with versioning and a retention lock. On Azure, Azure Policy deploys diagnostic settings to every subscription and sends them to a central workspace. On Google Cloud, an aggregated sink at the organization or folder level routes logs to a central project.
- A separate security tooling account. Analysts work here, and the native detection services are administered from here. Very few people need access to the archive itself.
- Guardrails on the pipeline. Use organization-level policy to stop member accounts from stopping the trail or deleting diagnostic settings, and alert when someone tries.
- Automatic enrollment. New accounts and subscriptions should receive logging, guardrails and detection services when they are created. That belongs in the landing zone built by the cloud engineering team, not in a checklist.
Control cost and volume deliberately
Cost is the reason monitoring gets switched off, so manage it as part of the design.
- Assign each log source a tier: real-time detection in the SIEM, a cheaper searchable tier, or archive only in object storage.
- Use selectors and filters at the source. CloudTrail advanced event selectors can limit data events to named buckets and to write operations.
- Drop what nothing uses, such as health probe traffic in flow logs or verbose fields that no detection or investigation reads.
- Set retention by purpose. Detection needs recent data close at hand. Investigation and regulation need a longer period in cheaper storage.
- Review ingestion by source every month. A new service or a debug setting can multiply volume without anyone noticing.
- Write down what you chose not to collect, so that the gap is a decision and not a surprise during an incident.
Decide who responds and with what permissions
An alert with no responder is a notification. Settle the following before the first serious alert arrives.
- Who triages. An internal SOC, the platform team or a managed SOC, and during which hours.
- Investigation access. A read-only role in every account, deployed as code, so analysts can look without asking.
- Containment access. A separate, time-bound role that can disable access keys, attach a deny policy, revoke role sessions, isolate an instance and snapshot disks.
- Authority. Playbooks for the top detections that state which containment actions the responder may take alone and which need the account owner.
- Ownership data. Every account and subscription carries an owner and a contact, so the analyst knows whom to call.
Where to start
- Verify that control plane logging covers every account, subscription, project and region, and that it lands in a separate log archive.
- Protect the log pipeline with organization-level guardrails and a detection for logging changes.
- Build the seven detections above with lists of expected actors, and test each by performing the action.
- Enable the native detection service across the organization and route its findings into the same queue as everything else.
- Create the investigation and containment roles, then run one exercise with a simulated leaked access key in a test account.