Enterprise SIEM on AWS — $50 a month, not $14,000

The mandate came from AWS, which changed how the decision could be made. It is worth being precise about who required this, because it determined the shape of the entire project. This was not an internally proposed security improvement competing for budget against feature work, where the honest answer to a $14,000 monthly quote is to defer it for a quarter and revisit. AWS had audited the integration and made a SIEM a condition of continued access to an API the product could not function without. That removes the option of doing nothing, and it also removes the option of doing something token — the implementation had to genuinely satisfy an external reviewer, not merely exist. What it did not remove was discretion over how the requirement was met. The requirement specified an outcome, and the market's assumption that the outcome costs five figures a month was an assumption about the market, not about this environment.

Self-hosting was ruled out on ownership, not on licence cost. The obvious escape from enterprise pricing is to self-manage an open-source stack, and on a spreadsheet it wins immediately. It was excluded at the outset anyway, at the client's direction, and the reasoning holds up better than the spreadsheet does. A self-hosted SIEM is not a piece of software you install; it is a security platform you now operate. It needs patching, and the patching is not optional because the thing being patched is the system that watches for compromise. It needs version upgrades that break index mappings and detection rules. It needs someone to tune it as the environment changes, or it degrades quietly into a log archive nobody reads. And it needs infrastructure underneath it — storage that grows monotonically, compute sized for query load — billed every month whether the platform is healthy or not. The client was clear they would not carry that indefinitely, and a security control that depends on sustained attention nobody has committed to is worse than an honest gap, because it produces the appearance of coverage. So the evaluation was confined to managed offerings, and the question became which pricing model fit rather than which licence was cheapest.

Four platforms were priced against the real workload, not a feature matrix. I took the actual AWS environment and its real event profile into technical and pricing discussions with the Wazuh, Splunk, and Google teams, so that what came back were quotes for this workload rather than list prices for a generic one. The spread was extraordinary. Google Security Operations quoted approximately $14,000 a month for the proposed package and ingestion profile — around $168,000 a year. Splunk Enterprise Security came in at approximately $1,200 a month for the required security configuration, roughly $14,400 a year. Wazuh Cloud's managed proposal sat in a four-figure monthly range, broadly comparable with Splunk once the cost of operating the platform was included, and the exact figure is no longer retained. Datadog Cloud SIEM was priced differently in kind rather than in degree: $5 per million analyzed events on an annual contract, which at the observed volume worked out to roughly $600 a year. Against the quotes received, that is approximately a 96% reduction versus Splunk and more than 99% versus Google Security Operations. The conclusion people tend to draw from those numbers is the wrong one. Datadog is not simply the cheap option — at high event volumes, per-event pricing is precisely the model that becomes expensive, and a committed-capacity contract is what starts to look sensible. It won here because its pricing unit was the only one that tracked the size of this environment. The transferable lesson is that vendor selection at small scale is usually a question about pricing units rather than feature depth, and that the platform with the deepest capability set is a bad answer if its commercial model assumes an organization ten times larger.

The AWS audit trail was established before any of it reached Datadog. A SIEM is a function of the telemetry it receives, so the implementation started at the source rather than at the tool. I enabled AWS audit logging to capture account and API activity — administrative actions, changes to cloud resources, and the identity behind each of them. CloudTrail forms the core audit record, answering which principal performed an action, against which service, when, and from where. Alongside it I enabled the relevant service access logs so the SIEM could see how the parts of the platform handling sensitive data were actually being used. Those two streams do different jobs, and the distinction is what makes an investigation tractable: CloudTrail can show that a resource policy was modified, while an access log shows what happened to the resource afterwards. Either one alone leaves you narrating half an incident.

Ingestion was deliberately selective, because per-event pricing makes noise expensive. I connected the AWS environment to Datadog and built a dedicated ingestion job for the selected security sources, collecting audit and access events from their AWS destinations and forwarding them in to be parsed, enriched, tagged, and made available to Cloud SIEM. The important decision was what not to send. On a per-analyzed-event contract, indiscriminately routing every log the platform produces into security analysis converts the cost advantage straight back into the bill it was chosen to avoid — and it does so while making detections worse, because high-volume operational noise dilutes the signal the rules are looking for. So SIEM analysis was scoped to the streams that genuinely serve the security and audit requirement. Events were then tagged with their AWS account, environment, service, and log source, which is what makes a signal actionable rather than merely true: an alert arrives already attached to the specific resource and environment it came from, instead of starting an investigation with the question of where this happened.

Managed detections provided the floor; custom rules covered what was actually at risk. With data flowing reliably, I enabled Cloud SIEM's managed detection content and then adapted the alerting layer to this environment. The managed rules are the right foundation precisely because they are maintained by someone else — detection content decays as attack techniques change, and a rule set maintained in-house is another long-term commitment the client had already declined to make. On top of that floor, custom rules and thresholds targeted the risks specific to this platform and its AWS security model, covering suspicious authentication activity, changes to IAM identities and permissions, unexpected administrative actions, changes affecting audit-log collection itself, sensitive service and data access, network and resource exposure changes, and unusual activity spanning accounts or environments. Being able to set alert conditions rather than accept a fixed vendor policy is what keeps a SIEM useful over time. A platform that fires constantly at low-value activity does not get tuned; it gets ignored, and then it is a monthly invoice for a dashboard nobody opens.

The whole path was validated, from an AWS action to an investigable signal. The implementation was not treated as finished when logs first appeared in a dashboard, which is the point at which a surprising number of SIEM projects are declared complete. I validated the full chain end to end: an auditable or access-related action occurs in AWS, AWS records it in the appropriate log, the ingestion job forwards it, the pipeline parses and enriches it, Cloud SIEM evaluates it against the configured detections, matching activity produces a security signal, and that signal carries enough AWS context to identify the affected account, service, resource, and action without further digging. Every one of those steps is a place where the chain can break silently — a log group not subscribed, a parser that fails on an unexpected shape, a detection scoped to a tag that is not being applied — and each failure looks identical from the dashboard, which is to say it looks like nothing happening. Testing the path proves the difference between retaining logs and operating a SIEM, and it is the evidence you want in hand when the party that mandated the control asks how you know it works.