SIEM on Amazon OpenSearch Service collects AWS logs and normalises them to ECS
A solution for collecting, correlating and visualizing multiple types of logs to help investigate security incidents.
At a glance
- What is it?
- SIEM on Amazon OpenSearch Service is an AWS sample solution that pulls logs from multiple AWS accounts into OpenSearch through S3 and a Lambda function, normalises them to the Elastic Common Schema, and gives a security team a dashboard for correlation. It deploys in about half an hour, and its two rough edges are the default t3.medium.search instance size and the experimental status of field normalisation and threat enrichment.
- Who is it for?
- SIEM on Amazon OpenSearch Service suits a security team that wants a working SIEM on AWS without writing an ingestion pipeline, and it does not suit an organisation that needs multi cloud coverage or a production sized cluster out of the box, since the template ships a t3.medium.search instance that the documentation tells you to replace.
- Can I use it commercially?
- Yes. MIT-0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 67 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A log pipeline from S3 into an OpenSearch dashboard
SIEM on Amazon OpenSearch Service is a solution for collecting multiple types of logs from multiple AWS accounts, correlating them and visualising them to help investigate security incidents. It is published in the AWS samples organisation, its primary language is Python, and its licence is MIT-0.
The mechanism is straightforward once you see it. Log sources deliver to a specified Amazon S3 bucket, and a purpose-built AWS Lambda function automatically loads those logs into SIEM on OpenSearch Service. From there the logs are visible in a dashboard and can be correlated across sources. The Lambda function is the moving part: it reads from the bucket, normalises the records and indexes them.
Deployment is the other half of the appeal. The solution is packaged for AWS CloudFormation and for the AWS Cloud Development Kit, and the documentation states that deployment takes about 30 minutes. The repository also ships separate deployment guides for advanced cases, including deploying inside an Amazon VPC and deploying on OpenSearch Serverless, so the sample is a starting point with documented escape hatches rather than a single rigid template.
The audience is a security team on AWS. The value is in the plumbing: collecting logs from a fleet of accounts into one searchable place is unglamorous work that every team has to do before any detection rule can be written.
Which log sources are actually covered
The supported log type table is long and organised by AWS service category, and it is the document to check before deploying anything.
In the security, identity and compliance group the coverage includes CloudHSM audit logs, Amazon GuardDuty findings, Amazon Inspector findings, Microsoft AD from AWS Directory Service, AWS WAF Web ACL traffic information for both WAF and WAF Classic, AWS Security Hub findings along with the findings it aggregates from GuardDuty, Macie, Inspector and IAM Access Analyzer, and AWS Network Firewall flow logs and alert logs.
Management and governance logs cover AWS CloudTrail log events and CloudTrail Insight events, AWS Config configuration history, configuration snapshots and config rules, and Trusted Advisor check results. Networking is well served: CloudFront standard access logs and real-time logs, VPC DNS query logs from Route 53 Resolver, VPC Flow Logs version 5 for Amazon VPC and version 6 for Transit Gateway in text or Parquet format, and access logs for application, network and classic load balancers, plus Client VPN connection logs.
Storage, database and analytics are covered too: FSx for Windows audit logs, S3 access logs, RDS engine audit logs for Aurora on MySQL and PostgreSQL, RDS for MariaDB, MySQL and PostgreSQL, ElastiCache for Redis slow logs, OpenSearch Service audit logs and MSK broker logs.
The compute and container entries carry caveats. Linux logs arrive through CloudWatch Logs as /var/log/messages and /var/log/secure, and Windows Server 2012, 2016 and 2019 system and security event logs arrive the same way. The Amazon ECS entry, which uses FireLens, is listed as framework only, which is the clearest signal in the table that ECS log support is partial.
Everything is normalised to the Elastic Common Schema
The point of normalising is correlation. If the GuardDuty record and the CloudTrail event use different field names for the same concept, no query can join them, and every investigation becomes a manual exercise in translation.
SIEM on Amazon OpenSearch Service addresses this by normalising supported logs in accordance with the Elastic Common Schema. A separate document in the repository, the supported log types page, carries a correspondence table between the original field names and the normalised ones, so you can look up what a source field became. The correlation features are then the reason to care about the schema, since queries can span services that never shared a field naming convention.
The caveat is stated without much hedging. The documentation marks the support as experimental and says that the field type, the normalisation and something in the future may change. For a security team, that means a detection rule written today may need revisiting when the schema shifts, and it is worth treating the correspondence table as a versioned contract rather than a fixed mapping.
The project also accepts contributions of new log types, and the repository already carries two contributed integrations, TrendMicro Deep Security and an Okta audit log, each with its own documentation. That is the mechanism to use if your security stack includes a product the table does not list.
Location and threat enrichment, and the price of IoC volume
Two enrichment features add context to the raw records, and both come with a cost or a dependency.
The first is geolocation. The solution can add country information and latitude and longitude for each IP address, and it does this by downloading and using the GeoLite2 Free database from MaxMind. If you want location data, you need to get a free MaxMind licence yourself, which is a small step that is easy to miss and that blocks the feature if you do not.
The second is threat information enrichment by indicator of compromise, and the documentation labels it experimental. The supported IoC sources are your own indicators in TXT and STIX 2.x formats, the Tor Project, the Abuse.ch Feodo Tracker and AlienVault OTX. Using OTX requires an API key.
The cost is stated in the same paragraph as the feature, and it is the most useful warning in the README. If there are many IoCs, the processing time of the Lambda function increases, so indicators should be selected carefully. That is the central trade-off: a larger indicator set means more enrichment on every record the function processes, and the function is the ingestion path for everything else.
The project has a page describing this enrichment in more detail, and it is linked from the configuration guide.
The template deploys a t3.medium.search instance and tells you to change it
The most consequential detail in the getting started guide is a warning attached to the deployment itself.
The CloudFormation template deploys OpenSearch Service with a t3.medium.search instance, and the documentation says plainly that this is not the AWS Free Tier. It tells you to change the instance type to something that can deliver higher performance than t3 when using the solution in a production environment, because aggregating many logs requires more processing power, and it points at the AWS Management Console for making the change after deployment.
Two things follow from that. First, the deployment is not a production configuration, and a team treating the template as production infrastructure will find the limit the first time log volume is real. Second, the sizing advice is to change the instance after the fact in the console, which is a manual step, not a parameter in the template.
A second detail is worth attention before deployment rather than after. The getting started walkthrough has you create a publicly accessible SIEM on OpenSearch Service domain. The repository has a page for changing the configuration of the solution, and the advanced deployment guide for a VPC deployment, but the documentation available here does not describe how the domain is authenticated or restricted. For a system holding security logs, that is the first thing to settle.
Control Tower, Security Lake and serverless deployment paths
Three integration paths sit around the core solution, and each has its own document, with architecture diagrams shown for the Control Tower and Security Lake integrations.
The AWS Control Tower integration is aimed at organisations that govern many accounts from a landing zone. The architecture diagram for it is separate from the base one, which tells you the data collection model changes when the accounts are enrolled in a landing zone rather than being listed individually.
The Amazon Security Lake integration is the other direction of the same problem. Security Lake is where a security team standardises on query-ready data, and this integration connects the OpenSearch based SIEM to it, so the same collection effort can feed both.
OpenSearch Serverless is offered as a deployment option in its own guide. That matters because the sizing problem described earlier has a different answer in a serverless deployment, where capacity is not a fixed instance type.
The dashboard is documented separately as well, which is where the visualisation side of the project lives, along with a FAQ page and a changelog. The repository is laid out with the templates under deployment/, the documentation under docs/, the source under source/, and the top-level tox.ini for the Python test tooling, plus a CODE_OF_CONDUCT.md and a CONTRIBUTING.md.
The README is also published in several languages, with separate Japanese and two Chinese files alongside the English one, and the translations are maintained in the repository rather than through a separate system.
A sample with no releases and a recent last commit
The project publishes no GitHub releases, so there is no version to pin and nothing to compare against when a change lands. The repository is not archived, and the last push was on 2026-08-18.
For a sample solution that is a reasonable posture. The intent of the repository is to be deployed, and the deployment is done from a template rather than from a versioned binary, so the changelog file in the repository is where change history lives. Anyone running a deployment should note that the template in the repository may have moved since their deployment, and that re-running it is a diff rather than an upgrade.
The licence is MIT-0, which is the most permissive form of the MIT licence with the attribution clause removed. For an AWS sample that people are expected to adapt, copy into their own account and modify, that is a deliberate and useful choice, since there is no requirement to carry the notice forward in derived work.
What the project does not provide is any statement about operating the SIEM after deployment. The documentation covers collecting, correlating, visualising, enriching and deploying. Retention, cost control, index lifecycle management and access control after the fact are not part of what the documentation describes, and a team taking this into production will have to answer those questions with their own service configuration.
Editorial conclusion
SIEM on Amazon OpenSearch Service suits a security team that wants a working SIEM on AWS without writing an ingestion pipeline, and it does not suit an organisation that needs multi cloud coverage or a production sized cluster out of the box, since the template ships a t3.medium.search instance that the documentation tells you to replace. Before deploying, read the supported log types page to confirm your services are covered, obtain a MaxMind GeoLite2 licence if you want location data, and decide how you will protect the OpenSearch domain, because the getting started walkthrough creates a publicly accessible domain.
Frequently asked questions
What is SIEM on Amazon OpenSearch Service?
It is an AWS sample solution that collects multiple types of logs from multiple AWS accounts, correlates them and visualises them for security investigations. Logs are written to an S3 bucket and a purpose-built Lambda function loads them into SIEM on OpenSearch Service.
How do I deploy SIEM on Amazon OpenSearch Service?
Deployment uses AWS CloudFormation or the AWS CDK and takes about 30 minutes according to the documentation. The getting started guide creates a publicly accessible domain, while a separate advanced deployment guide covers deploying inside an Amazon VPC and other customisations.
Which log sources are supported?
The supported table covers security services such as GuardDuty, Inspector, Security Hub, WAF and Network Firewall, management logs from CloudTrail and AWS Config, networking logs including CloudFront, VPC Flow Logs and load balancer access logs, database and storage logs, and Linux and Windows logs through CloudWatch Logs. The ECS entry via FireLens is listed as framework only.
How are the logs normalized?
Supported logs are normalized in accordance with the Elastic Common Schema, and the supported log types document carries a correspondence table between original and normalized field names. The project marks this support as experimental and warns that field types and normalization may change.
Does the solution add IP geolocation and threat intelligence?
It can add country and latitude and longitude information for IP addresses using the GeoLite2 Free database from MaxMind, which needs a free MaxMind licence, and it can enrich records with threat information by IoC from your own TXT or STIX 2.x lists, the Tor Project, Abuse.ch Feodo Tracker and AlienVault OTX. The IoC enrichment is marked experimental, and many indicators increase the processing time of the Lambda function.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/aws-samples-siem-on-amazon-opensearch-service)Was this useful?