Wazuh and Amazon Security Lake integration: what it connects and why teams build it
A security team that already runs Wazuh for endpoint monitoring, security analytics and vulnerability detection often also needs AWS security data in one place, normalized to a shared schema. Amazon Security Lake provides that central store, and the Wazuh integration connects the two in one of two roles. Wazuh can act as a source, sending its data into Security Lake in OCSF format, or as a subscriber, reading data that Security Lake already holds and analyzing it with Wazuh's decoders and rules. The team should decide which role it needs first, because each role leads to a different build, a different set of permissions and a different owner for ongoing operation.
The source role depends on a pipeline that the team builds and operates. In the path this topic covers, Wazuh data is transformed and delivered to Security Lake through Logstash and Lambda components. That means the team owns the transformation logic, the credentials, the error handling and the monitoring of the pipeline itself. Before any build starts, confirm the exact method against the Wazuh documentation for the release in use. The current release line is 4.14, and the team should check the documentation page for its own version and track the patch releases it applies, since guidance can change between them.
In the subscriber role, Wazuh reads data that is already in Security Lake and analyzes it. This suits a team whose AWS logs already land in Security Lake through AWS-native or third-party sources and that wants Wazuh's decoders, rules and dashboards applied to that data without copying it into the Wazuh indexer. The decisions here are which Security Lake sources and time ranges to analyze, how often analysis runs, and who holds the query permissions. Ask your own AWS team and any implementation partner to confirm how query and storage costs are billed, because those charges are set by AWS and rise with the volume of data read.
Teams build this integration for a few recurring reasons. They want Wazuh alerts and AWS service data to be searchable in the same shared schema, they want to avoid maintaining separate copies of the same events, and they want security analytics to reach other tools that already subscribe to Security Lake. Collecting AWS logs directly into Wazuh is covered on its own page, so this section focuses on the Security Lake path. A useful first check is whether the data the team needs already exists in Security Lake. If it does, the subscriber role may need less new pipeline work than a source build.
What you need in place before configuring Wazuh and Security Lake
Settle these items before any configuration starts, because they depend on each other. The Wazuh release line and your AWS account model determine which roles, network paths and certificates the pipeline needs. Confirm each item with the owner named on its card.
Wazuh release line and version
Choose the Wazuh release line the integration will run on. The current line is 4.14, and Wazuh lists its 4.14 patch releases in the release notes, so confirm the exact patch level you will deploy and check the integration documentation for that version. Record the version in your change plan, because integration steps and supported configurations can change between releases. Confirm this with the Wazuh release notes and your platform owner.
AWS accounts and Security Lake roles
Decide which AWS account holds Security Lake and whether your team operates it as the delegated administrator or consumes its data as a subscriber. That choice determines who can enable log sources, create subscribers and read the data, so the setup differs between the two paths. Confirm the current account model, Regions and source configuration in the AWS Security Lake documentation and with the team that owns your AWS organization.
IAM roles for the pipeline
Each component that writes or reads Security Lake data needs its own identity with only the permissions its step requires. Map the role the Wazuh-side pipeline uses to write data, the role subscribers use to read it, and any role needed to write into the Security Lake storage location. Review these permissions against the integration documentation and the AWS Security Lake documentation, and have your cloud security team approve the policies before deployment.
Network paths to AWS endpoints
Map every network path from the Wazuh server and any transport host to the AWS service endpoints in your chosen Region. Check outbound firewall rules, security groups, route tables and the DNS resolution these hosts depend on. Ask your network team which egress path is approved for production traffic and whether the traffic must stay on a private connection. Test each path from the actual host rather than from an administrator workstation.
Certificates and proxy requirements
Identify the certificate authority that signs your internal endpoints and confirm that every host in the pipeline trusts it. Find out whether outbound HTTPS traffic must pass through a corporate proxy, and if so, which proxy settings, exclusions and authentication the hosts need. Confirm these requirements with your security team and proxy owner, and check that the integration documentation covers the proxy options your environment uses.
Data scope and retention decisions
Decide which Wazuh alerts and event categories will go to Security Lake before building anything, since that choice sets the data volume consumers receive and the data classes your analysts can query. Agree retention for the Security Lake data and for the Wazuh indexer with the data owner, and record who may read each store. Confirm the available source categories and retention options in the AWS Security Lake documentation and against your internal data policy.
Source or subscriber: choosing the Wazuh role for Security Lake
Decide which Wazuh role you need before you design the pipeline, because the role sets the work. As a source, Wazuh alerts or events are transformed into the Open Cybersecurity Schema Framework (OCSF) and delivered into Amazon Security Lake, so other tools that query the lake can read them. As a subscriber, Wazuh reads data that already sits in the lake and uses it for analysis. Both roles touch the same lake, but they move data in opposite directions, so a team that picks the wrong one may build a pipeline that nobody needs.
Four questions drive the choice. First, which data must leave Wazuh: alerts only, or the raw events behind them. Second, whether existing consumers already query the lake, such as a SIEM, a data platform or a hunting team's queries, and what fields they expect. Third, who owns the AWS account and the pipeline, since a security team, a platform team and a data team may each hold part of the control path. Fourth, whether the team wants alerts or raw events in the lake, because raw events raise ingestion volume and make field mapping harder. Write the answers down and confirm each one with the people who run the lake and the AWS account.
You can implement one role first and add the other later. Many teams start as a source, because it puts Wazuh findings where existing lake consumers can use them, and add subscriber analysis once the data is stable. The choice changes three areas of work. Source delivery needs IAM permissions to write to the lake's ingestion path and a tested mapping from Wazuh fields to OCSF event classes. Subscriber analysis needs read and query permissions, plus a network path from the Wazuh server to the query service. Each role also adds its own access review and logging requirements, which the account owner should approve before the build starts.
Before you commit, ask the lake owner for the list of current consumers, the expected OCSF classes and the account boundary the pipeline may cross. Then run a short test with a sample set of alerts and confirm which fields arrive intact and which consumers can query them. The main risk is an unused source pipeline or a subscriber that reads data it is not allowed to hold. Record the chosen role, its owner and the review date in the design document so the decision can be revisited when consumers or accounts change.
How the Wazuh and Security Lake configuration runs, step by step
This sequence connects Wazuh to Amazon Security Lake in a controlled order, starting with scope and AWS identities and ending with a widened rule set that has passed a check at each stage. Each step closes with a result the team can record, so a fault traces to one component before the next is added. The outcome is a tested source or subscriber path that delivers OCSF-formatted data within the agreed scope.
Confirm the integration role and data scope
Decide whether Wazuh will act as a Security Lake source, sending OCSF-formatted events into the lake, or as a subscriber that reads lake data for analysis. The two paths need different AWS and Wazuh setup, so this decision comes first. Name the AWS accounts, Regions, log types and the owner of each, and record the Wazuh release line you run. The release notes list 4.14 as the current line, so confirm your version against the compatibility notes in the current Wazuh integration documentation. This step is done when a scope sheet names the direction, the data classes, an owner for each account and the Wazuh version.
Prepare AWS identities and Security Lake configuration
In the AWS account that hosts Security Lake, create the IAM roles and policies the chosen path requires. Then configure the custom source or subscriber as the AWS Security Lake documentation describes. Limit write access for a source to the Security Lake data location, and have the security team review trust relationships before anything connects. Check that the custom source or subscriber shows as active in the Security Lake console. Also confirm with a test principal that it can see the expected Region and source objects and nothing beyond them.
Set up the Wazuh pipeline components
Following the current Wazuh integration documentation, install the components that move events between Wazuh and Security Lake. For the source path these are a Logstash pipeline and an AWS Lambda function that writes to the lake. Use the exact component names, package versions and configuration keys in that documentation for your release, and avoid settings copied from older guides. Verify that each component starts without errors, that the Logstash pipeline reports as running, and that a manual test event reaches its input.
Configure Wazuh output or input and filters
Point the Wazuh side at the pipeline. For a source, set the output that forwards events. For a subscriber, set the input that reads lake data. Apply filters so that only the agreed rule groups, severity levels and agents are forwarded. Keep the filter files in version control with the rest of the configuration so every change is reviewed. Restart Wazuh services as the documentation describes, then send a known test alert. It is done when the alert appears at the pipeline and an out-of-scope test event is blocked by the filter.
Enable limited rules for a test window
Start with a small, named set of rules or event types, such as authentication events from a few test agents. Run them for a fixed test window that the data owner agrees to in writing. Keep the full ruleset off at this stage, because the volume stored in the lake and the cost that comes with it grow with what you send. Record event counts per source and per rule and compare them with the expected volume from the scope sheet. Note any decoder errors or dropped events in the Wazuh server and pipeline logs.
Confirm OCSF output and subscriber reads
Check that events land in Security Lake in OCSF format, using the schema the Security Lake documentation lists for the source. Confirm that a subscriber can read them. Query a sample of records through the subscriber's query engine, compare the mapped fields with the mapping in the Wazuh documentation, and log any field that is missing or has the wrong type. The step is complete when the sample query returns records for the test rules, the mapped fields hold the expected values, and subscriber access is read-only to the intended sources.
Widen scope in controlled increments
After the test window results match expectations and the data owner signs off, add rule sets, agents or log types one group at a time. Repeat the test window checks for each increase. Keep a change record that names what was added, who approved it and what the volume check showed. Confirm that the expanded scope shows the same clean counts, error rates and query results as the test set. Also rehearse the rollback steps from the Wazuh documentation on a non-production copy before you depend on them.
How Wazuh fields map to OCSF classes and Security Lake data
This table lists the mapping categories the team must confirm between Wazuh alert fields and the OCSF target used for Amazon Security Lake. Read each row as a question to answer for your release: which Wazuh field feeds which OCSF attribute, what transformation runs, and who signs off. Unmapped or renamed fields break downstream queries, so DeployOpen does not assert any mapping without checking the Wazuh integration documentation for the release in use and the OCSF schema version the team targets.
| Mapping category | Wazuh source fields | OCSF target and transformation | Validation owner |
|---|---|---|---|
| Identity | Decoded user fields in data.* (for example data.srcuser or data.dstuser, where a decoder sets them) | Actor user attribute, copied from the decoded name; confirm which decoders populate each field in the release in use | Security engineer who owns the decoders |
| Host | agent.id, agent.name and predecoder.hostname | Device or host attributes taken from the agent record; agent names can differ from the hostname the operating system reports | Platform engineer who runs the agents |
| Event time | timestamp on the alert | Event time attribute; convert to the format the schema requires and keep the original value for audit | Data engineer who owns the Logstash pipeline |
| Severity | rule.level | Severity attribute set through a documented lookup table; Wazuh levels must be translated before loading into Security Lake | SOC lead who approves detection thresholds |
| Source IP | data.srcip and agent.ip | Source endpoint attribute stored as an IP address type; check whether the decoder populates the field in the release in use | Network security engineer |
| Rule and category | rule.id, rule.description and rule.groups | Finding or event name, identifier and category; keep rule IDs stable so saved queries and detections still match | Detection engineer who maintains the rule set |
Securing the Wazuh to Security Lake path
The path from Wazuh into Amazon Security Lake moves security event data across a trust boundary, and the same data can describe hosts and people in detail. The cards below cover the identity, encryption, secrets, network, logging and change-control decisions that determine whether that path stays under your control.
Scope IAM roles to the lake
Give each component of the pipeline its own IAM role, limited to the Security Lake sources or subscribers it must touch and to the specific S3 locations it reads or writes. A Logstash host, a Lambda function and an analytics subscriber usually need different permissions, so a shared administrative credential should be treated as a finding. Review each role's actions and resources with your cloud team before go-live, and confirm them again after any pipeline change.
Encrypt data at rest and in transit
Wazuh alert files, intermediate buckets and the OCSF records delivered to the lake should all be encrypted at rest, with key ownership and rotation agreed up front. Every hop between the Wazuh server, the transformation layer and AWS should use encrypted transport. Confirm which keys are customer-managed and who can use or disable them, because key access is a separate control from bucket access.
Store pipeline credentials securely
The pipeline needs credentials for AWS and sometimes for the Wazuh side. Keep them in a dedicated secrets store, not in Logstash configuration files, Lambda environment variables in plain text or shell history. Limit which service identities can read each secret, and plan rotation and revocation steps so a leaked credential can be replaced without redeploying the whole pipeline.
Restrict network paths to AWS
Allow the Wazuh server and the transformation hosts to reach only the AWS endpoints the pipeline uses, and block all other outbound traffic from those hosts. Decide whether traffic should stay on private connectivity or cross the internet, and document the choice. Review inbound access to the Wazuh indexer and dashboard separately, since they hold the alert data the pipeline reads from.
Log pipeline activity
Record who or what changed the pipeline, when, and which data flowed through it. This includes AWS API activity for the pipeline roles and buckets, Logstash or Lambda execution logs, and failed deliveries. Keep these logs outside the pipeline's own write path so an attacker who alters the pipeline cannot also rewrite its history. Confirm with your security operations team where these logs are retained and who can read them.
Separate rule and pipeline changes
Detection rules in Wazuh and the transformation and delivery logic in the lake pipeline change for different reasons and should not be edited by the same people without review. Use separate approval paths, separate repositories or change records, and a second reviewer for changes that alter which events reach the lake. This keeps a single change from silently hiding alerts or altering the records that investigations depend on.
Agree lake data handling first
Security event data often contains hostnames, IP addresses, usernames and process details that count as personal or sensitive information under your own policies. Agree retention periods, who may query the lake, which subscribers may read which sources, and how access is reviewed before the pipeline carries production data. Changing these rules after go-live means reprocessing or deleting data that has already been delivered.
How to verify that Security Lake receives or returns the right data
Verification starts with a test plan that proves one known event travels the whole path: from a Wazuh agent or documented test rule, through the Logstash and Lambda stages, into the Security Lake custom source location. Pick a test event with a unique marker value in a field the team can search, such as a test username or a hostname that exists only in the test environment. Then confirm the event arrives with the OCSF event class that your mapping targets and with the required fields populated. Check the class and field names against the mapping your team built and the current OCSF schema version in use, not from memory, because a mapping written against one version can silently leave fields empty after an upgrade.
Next, query the marker event from the analytics tool your team uses, commonly Amazon Athena once the lake tables are registered in the AWS Glue Data Catalog. Confirm the query returns the event with the expected values in each field and that the record appears within the time window your operations team has agreed to. If the design includes subscriber mode, create a test subscriber with a dedicated identity and confirm it can read the same marker event. Then confirm it cannot read sources it was not granted. Record the subscriber's access policy as part of the test, since a subscriber that can read more than intended is a finding even when the data itself is correct.
Failure cases need the same discipline as the success path. Test expired credentials by using a test role or key with a short validity period, and confirm the failure appears in logs and alerts rather than disappearing. Stop the pipeline in a non-production account, for example by stopping the Logstash service or disabling the Lambda trigger, then confirm how events are buffered, retried or lost and how long the team takes to notice. Introduce a schema mismatch, such as a renamed field in a decoder or mapping, and check whether the event is rejected, written with empty fields, or dead-lettered. Each result should be written down with the behavior the owner expects, because the expected behavior is what the team will monitor in production.
Dropped or filtered events must be intentional. Compare event counts at three points for the same test window: at the Wazuh server, at the Logstash output and in the lake. Any gap should map to a documented filter, such as a rule level threshold or a Logstash condition, that a named owner has approved. Keep the test evidence together: test identifiers, timestamps, query exports, the version of each configuration file, the names of the people who approved the results, and the pass or fail outcome for each case. This record supports change control when the pipeline is modified and answers later audit requests. DeployOpen prepares this evidence for your environment, but auditors and certification bodies are the parties who assess it, so confirm early which evidence format your assessor expects.
Common failures when Wazuh and Security Lake do not match
This table lists the symptoms teams most often see when Wazuh output and Amazon Security Lake disagree, with the likely cause and the configuration check to run first. Read each row from left to right, starting with the symptom you observe, then work through the checks in order before changing the pipeline. The main takeaway is that most failures trace back to permissions, field mapping or filter scope, so check those before rebuilding the pipeline.
| Symptom | Likely cause | Fix: configuration check to run |
|---|---|---|
| No data arriving in the lake | IAM role or bucket policy denies the writer, such as the Logstash host or the Lambda execution role | Confirm the writing identity has the write permissions the Security Lake custom source setup requires, and that the bucket policy and any KMS key policy allow that identity. |
| No data arriving in the lake | Wrong AWS region or S3 bucket name in the output configuration | Compare the region and bucket values in the output block with the Security Lake region and the bucket Security Lake created for the custom source. |
| No data arriving in the lake | Network block between the Wazuh host and the AWS endpoints | Check egress rules, proxy settings and VPC endpoint routes from the host running Logstash or the Lambda function to the S3 and STS endpoints. |
| No data arriving in the lake | Pipeline stopped or never started after an upgrade | Confirm the Logstash service or Lambda trigger is running, then review the pipeline logs for the last successful write time. |
| Data arrives with missing or renamed fields | Mapping mismatch between Wazuh fields and the OCSF schema expected by Security Lake | Compare sample events in the lake with the OCSF mapping used in the transformation step, and correct field names in the mapping configuration. |
| Data arrives with missing or renamed fields | Schema version drift after a Wazuh or OCSF version change | Record the Wazuh release and the OCSF version the source declares, then confirm both still match the mapping you deployed and update the mapping as a tested change. |
| Duplicate events in the lake | Retries after timeouts write the same batch more than once | Review retry settings and batch sizes in the output configuration, and confirm the destination handles repeated writes as expected. |
| Duplicate events in the lake | Two pipeline paths send the same alerts, such as an existing forwarder plus the new integration | List every path that reads Wazuh alerts and remove or narrow the overlapping one so each alert reaches the lake once. |
| Alert floods in the lake or downstream tools | Forwarding filters are too broad, so low-level or noisy alerts pass through | Review the alert level threshold and rule group filters on the Wazuh side, and agree with the analytics team which levels belong in the lake. |
| Credential expiry stops writes | Temporary credentials or access keys used by the writer have expired or were rotated | Check the credential source and expiry settings, confirm the role used by the writer is assumed or refreshed automatically, and set an alert on failed writes. |
| Subscriber queries return nothing | Subscriber access was not granted for the custom source, or the subscriber points at a different source name | Verify the subscriber is registered for the Wazuh custom source, that the source name matches the one you configured, and that the query covers the correct time range. |
| Subscriber queries return nothing | Data is in the bucket but not in the table the subscriber reads, due to partition or table registration gaps | Confirm the source is registered in the Security Lake configuration and that recent partitions exist for the period you query. |
Questions buyers ask before they hire help for this integration
What drives the cost and effort of a Wazuh and Amazon Security Lake integration?
The main drivers are the number of data sources, the mapping work, how much of the pipeline you build and run yourself, and how much testing and handover the team needs. Each source sent to Security Lake must have its events converted to OCSF fields, so a few well-understood sources take far less effort than a long list of custom logs. Mapping effort grows when data owners disagree on field meanings or retention. Pipeline build covers the Logstash and Lambda components on the Wazuh side, plus IAM roles, storage and Security Lake configuration on the AWS side. Operation recurs: someone must watch the pipeline, update mappings after Wazuh or OCSF changes, and handle failures. Testing and handover are one-time costs that teams often underestimate. Ask any quote to show these areas separately.
Can our own team build this integration without outside help?
Yes, if your team already has working AWS and Wazuh skills and time to check the documentation against the versions you run. The work touches IAM policies, S3 and Security Lake settings, Wazuh server and Logstash configuration, and Lambda code, so one person rarely covers all of it. Check three things before deciding. First, can someone own the AWS side and the Wazuh side for the whole build period? Second, can the team test each step in a non-production account and confirm it against current documentation? Third, will anyone maintain the pipeline after go-live? Operation is the part most teams underestimate. Some teams keep the build in-house and ask for an outside review of the mapping or the test plan.
What do we need to provide before an integration project starts?
Plan for access, approvals and people before any build work begins. You need AWS account access with rights to create the roles, storage and Security Lake resources in the design, plus a named owner who can approve changes in that account. The Wazuh side needs administrative access to the server and indexer, and a way to change configuration and restart services. Network approval covers the paths between the Wazuh server, AWS endpoints and any Lambda networking, and security teams often must sign these off. Data owners must agree the field mapping and retention period for each source, because those choices determine what is stored and for how long. Finally, schedule a test window in which ingestion can be stopped, checked and restarted without disrupting production monitoring.
How long does the integration take, and what sets the timeline?
No fixed duration applies, because the timeline follows scope and change approval more than any standard figure. The number of sources, the number of mappings that need data-owner sign-off, and whether the pipeline is built in a new account or an existing one all change the schedule. Change approval often sets the pace. Network changes, IAM reviews and production change windows can each add waiting time that your project team does not control. Plan for review cycles throughout the project, not only at the start. A written scope should list the sources, the open mapping decisions, the environments to be built and the approval steps the client expects. Ask every proposal which items set its timeline, so you can see which delays you can influence.
Does the Wazuh software itself have a license fee?
No. The self-hosted Wazuh software is open source and carries no license fee. It is distributed under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library. Your recurring costs come from the infrastructure you run Wazuh on and the AWS services the pipeline uses, including Security Lake storage and processing, Lambda invocations and data transfer between them. These costs depend on your own usage, so model them from your expected event volume and current AWS rates. Wazuh Cloud is a separate managed service with its own plans, and this integration does not require it. Confirm current AWS pricing for every service you enable, because those rates change on their own schedule.
What should a fixed-scope quote for this integration include?
A fixed-scope quote should describe the work in the same terms as the scope, so you can compare it with an internal estimate. Look for the sources in scope, the OCSF mapping for each source, and the AWS and Wazuh components to be built, with the environments they run in. It should name the test plan, the acceptance criteria and who signs them off. Handover should be itemized, including runbooks, configuration files and the operational tasks your team will own. Check which items are excluded, such as ongoing monitoring, upgrades or sources added later. Confirm the client inputs the quote assumes, including access, approvals, data owner time and the test window, because a quote is only as firm as its assumptions. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
Can DeployOpen support the pipeline after handover is complete?
Yes, ongoing support, upgrades and continuous testing are available as retainers. The pipeline needs recurring attention because Wazuh ships patch releases regularly, and mappings, Lambda code and configuration may need updates after an upgrade. Decide before handover whether your team will own those tasks or buy a retainer. The choice depends on how many people you can spare, how often you expect to add sources, and how quickly you need fixes after a failure. Ask for the included responsibilities in writing. Confirm whether the retainer covers Wazuh upgrades, changes to AWS services, incident response on the pipeline and testing after each change, so you know which tasks remain with your team.
How DeployOpen scopes, builds and supports the Wazuh and Security Lake integration
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Wazuh and Amazon Security Lake integrations. Each engagement starts with a fixed scope agreed in writing, which settles the Security Lake role, data sources and OCSF path before any build begins, so the work matches your environment.
How we scope
- Confirm which Security Lake role applies: Wazuh as a custom source or as a subscriber analyzing data.
- Inventory the log sources, AWS accounts, Regions and Wazuh agents the integration must cover.
- Agree in writing on the OCSF mapping, data volumes, retention, and who operates each component.
How we build
- Stand up the Wazuh components in your environment, using the deployment method your scope specifies.
- Configure the Logstash pipeline or Lambda path that converts Wazuh alerts into OCSF events.
- Test each stage with sample alerts, checking field mapping, Security Lake partitions and access permissions.
How we hand over
- Deliver architecture notes, IAM policies, pipeline configuration and runbooks in your repositories.
- Walk your operations and security staff through alert flow, failure modes and query examples in Security Lake.
- Document the checks that confirm events arrive, so your team can repeat them after changes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Wazuh upgrades and mapping changes against the release notes before they reach production.
- Confirm with your auditors which Security Lake evidence they need, since DeployOpen does not issue attestations.
