Key Takeaways
- CloudWatch Logs is the other half of AWS logging. Sources that do not write to S3, Lambda, RDS audit logs, application and some VPC logs, publish here.
- Wazuh pulls CloudWatch log groups directly through its AWS module's CloudWatch Logs service, reading events and applying rules.
- Choose log groups by value: application and API logs, Lambda function logs, RDS audit logs, and any VPC Flow Logs configured to CloudWatch.
- CloudWatch is the route to serverless and managed services you cannot install an agent on, making it essential for Lambda and RDS visibility.
- Mind cost and volume: ingest the log groups that carry security signal, not every group, and tune what you alert on.
Why CloudWatch Logs Matters
AWS has two main logging destinations: S3, where audit and infrastructure services like CloudTrail and Config write, and CloudWatch Logs, where application, serverless and many managed-service logs land. If you only collect the S3 sources, you miss a large and important category: the logs from the workloads you actually run.
CloudWatch Logs is where your Lambda functions write their output, where applications on EC2 and ECS can ship logs, where Amazon RDS publishes database audit and error logs, and where VPC Flow Logs can be directed. For managed and serverless services that cannot run a Wazuh agent, CloudWatch is the only way to get their telemetry into your SOC. That makes the CloudWatch integration essential, not optional.
How Wazuh Collects CloudWatch Logs
The Wazuh AWS module includes a CloudWatch Logs service that reads events from specified log groups. You configure it with the log group name (or groups), the AWS region, and the credentials, and Wazuh periodically retrieves new log events, parses them, and runs them through the rules engine. It tracks its position so it collects only new events on each run.
Because CloudWatch log content varies by source (JSON from some services, plain text from applications), you often pair collection with decoders suited to the log format. For well-known sources like RDS audit logs or VPC Flow Logs, the structure is predictable and rules can target specific fields. For custom application logs, you may write custom decoders so Wazuh extracts the fields you want to alert on. As always, use a least-privilege IAM principal with read access to just the log groups you collect.
Need Your AWS Connected to Wazuh?
Codesecure specialises in Wazuh cloud monitoring: CloudTrail, CloudWatch, Config, VPC Flow Logs, S3, EC2, RDS and MongoDB Atlas, wired into one SOC with least-privilege IAM and tuned detections. ISO/IEC 27001:2022 certified delivery, named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
See Cloud SOC Services →Which Log Groups to Ingest
CloudWatch can hold a huge number of log groups, and ingesting all of them is neither affordable nor useful. Select by security value.
- RDS audit and error logs: database logins, failures and (with the audit option) query activity, the route to RDS monitoring.
- Lambda function logs: execution, errors and any security-relevant output from serverless code.
- Application and API logs: your own services shipping to CloudWatch, including authentication and access events.
- VPC Flow Logs where configured to CloudWatch rather than S3.
- Route 53 resolver and other service logs relevant to your detections.
Detecting Threats in CloudWatch Data
What you detect depends on the source. From RDS audit logs, alert on failed database logins, logins from unexpected hosts, and privilege changes, bringing managed databases into the same detection coverage as self-hosted ones. From Lambda logs, watch for errors that indicate abuse, unexpected outbound activity, and signs that function code is being exploited or misused.
From application logs, detect the same authentication and access anomalies you would anywhere: brute force, access from unusual locations, and application-level attacks. Because all of this now lives in Wazuh alongside CloudTrail and VPC Flow Logs, you can correlate across layers, for instance a CloudTrail credential anomaly with suspicious application activity on the same workload. The value is not just collecting CloudWatch, but correlating it with the rest of the account.
Managing Cost and Volume
CloudWatch ingestion has a cost dimension that S3-based collection does not always share, both in AWS (API calls to read log events) and in your Wazuh storage. High-volume log groups, verbose application debug logging or chatty Lambda output, can generate significant data for little security value. The discipline is the same as on-premise log management: collect what carries signal.
Prioritise the security-relevant log groups, set appropriate log levels at the source where you control them, and in Wazuh separate storage from alerting so you keep forensic history without alerting on routine events. Review periodically which groups justify ingestion. Done well, CloudWatch collection gives essential visibility into serverless and managed workloads at a controlled cost.
Cloud Logs Flowing But No Detections?
Collecting CloudTrail or VPC Flow Logs is only step one. Our SOC lead will review your AWS log coverage and detection gaps on a 30-minute free scoping call. No obligation, no slideware.
Book a Free Scoping Call →CloudWatch and S3 Together
CloudWatch Logs and the S3-based sources are complementary, and a complete AWS monitoring setup uses both. S3 collection brings in the audit and infrastructure trail (CloudTrail, Config, GuardDuty), while CloudWatch brings in the workload and managed-service telemetry (Lambda, RDS, applications). Together they cover both the control plane and the data plane of your AWS environment.
In practice you configure both paths in the Wazuh AWS module and let the detections work across them. A mature cloud SOC built on Wazuh pulls CloudTrail and Config from S3, RDS and Lambda from CloudWatch, VPC Flow Logs from whichever destination you chose, and correlates all of it. The service-specific guides in this series detail each source; CloudWatch is the path that unlocks the managed and serverless half.
Frequently Asked Questions
How does Wazuh collect AWS CloudWatch Logs?
The Wazuh AWS module includes a CloudWatch Logs service that reads events from specified log groups. You configure it with the log group name, region and credentials, and Wazuh periodically retrieves new events, parses them and applies rules. It tracks its position so only new events are collected each run. Use least-privilege read access scoped to those log groups.
What is the difference between Wazuh collecting from S3 and CloudWatch?
AWS writes logs to two destinations. Audit and infrastructure services (CloudTrail, Config, GuardDuty) typically write to S3, which Wazuh reads with the aws-s3 path. Application, serverless and managed-service logs (Lambda, RDS audit, applications, sometimes VPC Flow Logs) land in CloudWatch Logs, which Wazuh reads with the CloudWatch Logs path. A complete setup uses both.
How do I monitor AWS Lambda with Wazuh?
Lambda functions write their logs to CloudWatch Logs, so you collect the relevant Lambda log groups with the Wazuh CloudWatch Logs integration. You can then detect execution errors that indicate abuse, unexpected outbound activity and signs of exploited function code, correlated with the rest of your AWS telemetry in Wazuh.
Which CloudWatch log groups should I ingest into Wazuh?
Choose by security value: RDS audit and error logs, Lambda function logs, your application and API logs (including authentication events), and VPC Flow Logs if they are directed to CloudWatch. Avoid ingesting every group, since high-volume verbose logging adds cost for little security signal. Review periodically which groups justify collection.
Does collecting CloudWatch Logs with Wazuh cost extra?
There is a cost dimension from AWS API calls to read log events and from the Wazuh storage the data consumes, so high-volume log groups can be expensive for little value. Manage it by ingesting only security-relevant groups, setting appropriate log levels at the source, and separating storage from alerting in Wazuh so you keep history without alerting on routine events.
Can Codesecure configure CloudWatch Logs collection in our Wazuh?
Yes. Codesecure sets up the Wazuh CloudWatch Logs integration, selects the right log groups, writes decoders for custom application logs, and builds detections across Lambda, RDS and application telemetry, correlated with your other AWS sources. ISO/IEC 27001:2022 certified delivery with named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
See Your Serverless And Managed AWS Workloads
Codesecure connects CloudWatch Logs to Wazuh so your Lambda, RDS and application telemetry reaches the SOC, with detections correlated across your whole AWS account. Delivered by named OSCP, CEH and CISSP consultants at a controlled ingestion cost.
