Wazuh AWS security monitoring

Start with CloudTrail, add GuardDuty findings second, and bring in AWS Config and VPC flow logs only after the first two have named owners and a tested triage path. The ranking weighs three things: the detection value of each log type on its own, how much data it produces, and which team will read the resulting alerts. For a first phase, the best choice is usually the log that someone will act on during the first week of alerts, not the one that looks most comprehensive on paper.

CloudTrail records API activity across the account, including console sign-ins, role assumptions, IAM policy changes and changes to logging itself. Those events cover many of the behaviors a cloud security team needs to see first, such as a trail being stopped or new access keys being created. Its volume is moderate for most accounts, and the people who act on it are usually the cloud security or platform engineers who already administer IAM. Before enabling it, confirm with your AWS administrators whether an organization trail already exists, because a second trail can duplicate events and add storage cost.

GuardDuty comes second because its findings are already triaged by AWS, which keeps volume low and gives a small response group a quick signal. AWS Config comes third. It provides configuration history and evidence for compliance baselines, and the platform team that owns those baselines is the natural reader. VPC flow logs rank last for the first phase. They produce the largest volume of the four, their value depends on whether a network or SOC team has rules to read them, and storage and ingestion cost grow with traffic. For each of these, check whether the data is already collected by another tool so that Wazuh does not become a second copy.

Starting with one account and one region narrows the first phase to a small set of log streams. That makes it possible to measure daily event counts, check which events match decoders and rules, and confirm that alerts reach the right people before scope grows. The cost is that activity moving across accounts or regions may go unseen until expansion, so plan the expansion as a separate change with its own review. Before any of this, confirm the exact log types the aws-s3 module parses against Wazuh's current documentation for your release, then test each one on a sample bucket with representative log files before enabling it in production.

The main driver of ingestion volume is what you connect, not how long the integration runs. Each AWS account and region you include adds its own set of log sources, and each log type you enable adds a stream with its own volume profile. CloudTrail, GuardDuty, AWS Config and VPC flow logs differ sharply in how much they produce, so enabling a service because it sounds useful can change the indexer footprint more than adding a second account. Start by listing every account, region and log type in scope, then mark which streams the security team will actually query. That list is the input to every other estimate in this section.

Two AWS-side factors decide how much data reaches the bucket and how hard the aws-s3 module works to read it. VPC flow logs are often the largest stream because they record traffic at the network interface level, so busy subnets, NAT gateways and chatty workloads push volume up quickly. Bucket layout matters too. The number of objects a bucket accumulates, and how many of them are new since the last run, shapes listing and read work even when total bytes look modest. The polling interval and the number of buckets each module instance watches set how often that work recurs. Ask the team to report object counts per prefix, not only total storage size.

Keep two budgets separate in planning. AWS-side charges cover what AWS bills for: log delivery, S3 storage and requests, data transfer, and the charges for the services that generate the logs. Wazuh-side sizing covers the infrastructure you run: the indexer storage that holds alerts and archived data, the retention period you set, the Wazuh server cluster needed to decode and analyze events, and the hosts that run the integration. A saving on one side can add cost on the other. Filtering a noisy stream at the Wazuh side reduces indexer load, but the AWS bill for writing and storing those logs stays the same unless you change what AWS delivers. Confirm both budgets against AWS pricing for your regions and Wazuh sizing guidance for the release you deploy.

Do not size from generic guidance. Measure a sample period that covers normal business activity and at least one known peak, then extrapolate. For each enabled stream, record bytes and object count per day from bucket metrics or AWS billing data, and the events indexed on the Wazuh side over the same window. Compare indexed size against raw size to learn how much decoding expands each stream. Apply the retention period you intend to set, then add headroom for growth in accounts, regions and traffic. Repeat the measurement after the first month, because early numbers often reflect a new environment that has not yet grown.

When you request a quote, ask the implementation partner to state these assumptions in writing: accounts, regions, enabled log types, measured daily volume per stream, retention period, polling settings and the cluster size the design depends on. Ask which items are one-time work, such as the initial sizing and build, and which recur, such as storage growth, AWS charges and capacity reviews as sources change. A quote that does not name its volume assumptions cannot be checked later. Agree on a re-measurement point, for example after the first full retention cycle, and decide who owns the response if actual volume moves outside the sized range.

Each AWS log source should pass its own end-to-end test before the team treats it as collected. A module that starts without errors or an empty bucket that receives files does not prove that events reach the Wazuh indexer. The test follows one known event through five checkpoints: the event is generated in AWS, the object lands in the expected prefix of the bucket, the Wazuh server reads it through the aws-s3 module, the decoded event appears in the indexer and dashboard with the expected fields, and a test alert fires for a rule the team chose.

Design the trigger for each source so it is harmless and easy to find. For CloudTrail, a tagged change to a disposable test resource, made by a known IAM role, gives a unique identifier to search for. For GuardDuty, confirm whether the service offers sample findings in your account and which findings type you will use. VPC flow logs and AWS Config deliver on their own schedules, so confirm the expected delivery interval for each service in its AWS documentation and build the wait into the test plan. Record the trigger time, the account, the Region, the expected object key and the fields you expect to see in a test sheet before you start.

The alert checkpoint should use a rule the team already intends to act on, such as a sign-in by the root user or a change to an IAM policy, so the test also checks the path a real detection would take. Confirm the rule ID, the alert level and where the alert appears in the dashboard. When the event is in the indexer but a field is missing or has the wrong value, the cause is usually in decoding or field mapping rather than in the bucket or IAM permissions. Note that discrepancy in the test record and fix it before you move to the next source.

Store each test result as dated evidence. Keep the test sheet, the exported query results or screenshots, the test identifiers, the Wazuh server and indexer versions, and the bucket policy and IAM role version in use. Repeat the affected tests after any IAM policy change, any bucket change such as its name, Region, encryption or lifecycle rules, any Wazuh upgrade such as moving between 4.14 patch releases, and any change to a log source setting. Evidence from these runs helps your internal reviewers and external auditors see how collection was checked, though the auditors decide what evidence is sufficient for an assessment.