Key Takeaways
- AWS telemetry does not reach your SOC by itself. You must deliberately connect CloudTrail, Config, VPC Flow Logs and other sources to Wazuh.
- Wazuh ingests AWS logs two main ways: the aws-s3 module reads service logs that AWS writes to S3 buckets, and the CloudWatch Logs integration pulls log groups directly.
- Most AWS services deposit logs into S3 (CloudTrail, Config, VPC Flow Logs, ELB, WAF, GuardDuty), which Wazuh polls, decodes and applies rules to.
- Use least-privilege IAM: a dedicated IAM user or role with read-only access to the specific log buckets and CloudWatch log groups, never broad admin keys.
- Onboard in priority order: CloudTrail first (the control-plane audit trail), then GuardDuty, Config, VPC Flow Logs and service-specific logs.
Why You Must Connect AWS to Your SOC
AWS generates an enormous amount of security-relevant data: every API call, every configuration change, every network flow, every sign-in. The problem is that this data lives inside AWS and does not appear in the on-premise or endpoint logs a SOC traditionally watches. Without deliberately connecting AWS to your SIEM, you are blind to exactly the activity that matters most in the cloud: credential abuse, misconfiguration, and data access.
Under the shared responsibility model, AWS secures the cloud infrastructure while you secure what you run in it, and that includes detecting threats to your workloads and identities. Wazuh is a practical way to meet that responsibility because it can ingest the full range of AWS log sources and correlate them with the rest of your estate, giving one place to detect and investigate across cloud and on-premise.
How Wazuh Ingests AWS Logs
Wazuh integrates with AWS primarily through its AWS module, configured on the Wazuh manager (or a dedicated agent). The module has two main collection paths. The first and most common is the aws-s3 path: many AWS services are configured to write their logs into an S3 bucket, and Wazuh periodically reads new objects from that bucket, parses them, and runs them through its rules.
The second path is CloudWatch Logs: Wazuh can pull log events directly from CloudWatch log groups, which is how you collect sources that publish to CloudWatch rather than S3, such as RDS audit logs, Lambda logs and some VPC Flow Log configurations. Between these two paths, Wazuh can reach almost every AWS log source. The module is configured with the bucket or log group, the log type, and the credentials to use.
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 →AWS Services That Log to S3
A large set of AWS security services deposit their logs into S3, where the Wazuh aws-s3 module collects them. Knowing which these are helps you plan the integration.
- CloudTrail: the audit trail of all AWS API activity. The single most important source.
- AWS Config: resource configuration state and compliance against rules.
- VPC Flow Logs: network flow records (can go to S3 or CloudWatch).
- GuardDuty: managed threat-detection findings.
- ELB / ALB access logs and AWS WAF logs: application-layer traffic and attacks.
- Macie and Inspector: data-classification and vulnerability findings.
- S3 server access logs: object-level access to your buckets.
IAM: Least-Privilege Access for Wazuh
The integration needs AWS credentials, and getting this right is a security decision in itself. Create a dedicated IAM principal for Wazuh, either an IAM user with access keys or, better, an IAM role that Wazuh assumes. Grant it only read access to the specific log buckets and CloudWatch log groups it needs, plus the minimal GuardDuty or Config read permissions where relevant. Never give Wazuh broad administrative keys.
Scope the S3 bucket policy and the IAM policy to the exact resources: the log bucket ARNs and object paths, and the specific log groups. If your logs live in a central logging account (a common and recommended pattern), use cross-account role assumption so Wazuh reads from the logging account with a tightly scoped role. Treat the Wazuh credentials as sensitive, rotate them, and store them securely in the module configuration rather than in plain scripts.
What to Onboard First
You do not connect everything at once. Onboard in order of value. CloudTrail first: it is the control-plane audit trail and the foundation of cloud detection, covering IAM abuse, unauthorised actions and root usage. GuardDuty next if you use it, because its findings are high-signal and ingesting them into Wazuh unifies them with your other detections.
Then add Config for configuration drift and compliance, VPC Flow Logs for network-level detection, and the service-specific sources (S3 access, ELB, WAF, RDS audit via CloudWatch) relevant to your workloads. This staged approach gets the highest-value detection live quickly and keeps each onboarding step verifiable, rather than turning on a firehose you cannot yet tune.
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 →Unifying Cloud and On-Premise Detection
The real value of integrating AWS with Wazuh, rather than using each AWS console separately, is unification. Once CloudTrail, VPC Flow Logs and the rest flow into Wazuh, they share the same rules engine, dashboards, alerting, cases and compliance reporting as your endpoints, servers and other cloud and SaaS platforms. You can correlate a suspicious CloudTrail action with endpoint activity by the same user, or a VPC flow anomaly with a GuardDuty finding.
This unified view is what turns scattered cloud signals into coherent incidents, and it avoids the trap of a separate, unwatched cloud console. Mapping AWS detections to MITRE ATT&CK and routing them into a case-management workflow completes the picture, so a cloud incident is handled with the same process and the same team as everything else. The service-specific guides in this series go deeper on each source.
Frequently Asked Questions
How does Wazuh collect logs from AWS?
Wazuh uses its AWS module in two main ways. The aws-s3 path reads logs that AWS services write to an S3 bucket (CloudTrail, Config, VPC Flow Logs, GuardDuty, ELB, WAF and more), polling the bucket for new objects. The CloudWatch Logs path pulls events directly from CloudWatch log groups, used for sources like RDS audit logs and Lambda. Both parse the data and run it through Wazuh rules.
What IAM permissions does Wazuh need for AWS?
Create a dedicated IAM user or role for Wazuh with least-privilege, read-only access scoped to the specific log buckets and CloudWatch log groups it reads, plus minimal GuardDuty or Config read permissions where used. Never give it broad administrative keys. If logs live in a central logging account, use cross-account role assumption with a tightly scoped role.
Which AWS service should I connect to Wazuh first?
CloudTrail first. It is the audit trail of all AWS API activity and the foundation of cloud threat detection, covering IAM abuse, unauthorised actions and root account usage. After CloudTrail, add GuardDuty findings if you use it, then AWS Config, VPC Flow Logs and the service-specific logs relevant to your workloads.
Can Wazuh ingest AWS GuardDuty findings?
Yes. GuardDuty findings can be delivered to an S3 bucket (or via CloudWatch), from which Wazuh collects them with its AWS module. Ingesting GuardDuty into Wazuh unifies AWS's managed threat-detection findings with your other detections, so they appear in the same dashboards, alerting and case workflow rather than in a separate console.
Do I need the Wazuh agent on AWS, or just the module?
Both, for different things. The AWS module (on the manager) collects cloud service logs like CloudTrail and VPC Flow Logs. The Wazuh agent, installed on EC2 instances, collects OS-level telemetry (logins, processes, file integrity) from inside the instances. Managed services like RDS cannot run an agent, so you monitor them through their logs via CloudWatch instead.
Can Codesecure set up the full Wazuh AWS integration for us?
Yes. Codesecure specialises in Wazuh cloud monitoring and connects your AWS account end to end: CloudTrail, Config, VPC Flow Logs, GuardDuty, S3, EC2, RDS and more, with least-privilege IAM and tuned detections mapped to MITRE ATT&CK. ISO/IEC 27001:2022 certified delivery with named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
Bring Your Entire AWS Account Into One SOC
Codesecure connects AWS to Wazuh end to end, CloudTrail, Config, VPC Flow Logs, GuardDuty, S3, EC2 and RDS, with least-privilege IAM and detections mapped to MITRE ATT&CK. Cloud and on-premise in one pipeline, delivered by named OSCP, CEH and CISSP consultants.
