Streamwake + Amazon CloudTrail.
Don't replace Amazon CloudTrail — we pull its change events as incident candidate root causes, correlate them with CloudWatch evidence on the same AWS account, and rank them by typed confidence.
Don't replace Amazon CloudTrail — CloudTrail records who changed what and when across a streaming account; we pull CloudTrail `LookupEvents` for that account, correlate each change event against the AWS MediaLive + Amazon CloudFront pair the +CloudWatch page already names, score each candidate against a small typed heuristic (iam_change_as_root_cause vs config_change_as_root_cause vs media_live_change_as_root_cause vs aligned_with_cloudwatch_evidence_within_30s), and surface the ranked list in the InvestigationCorrelationsPanel under the existing HypothesisList on /app/incidents/[id] — same AWS account, same timeline, ONE operational picture on top of CloudWatch + CloudTrail.
Amazon CloudTrail aws-native audit log + change events — lookupevents + sts:assumerole. Streamwake doesn't replace Amazon CloudTrail— we correlate its signals and drive remediation on the anomalies it already surfaces.
What Amazon CloudTrail owns. What Streamwake runs on top.
Honest framing of the surface the vendor owns and the surface Streamwake runs on top of it. Both layers run together in production — same signal bus, different obligations.
Audit log + change-event bus
AWS cross-service signal + STS AssumeRole
Detect → Classify → Pull change evidence + bi-directional sync
InvestigationCorrelationsPanel on the incident detail
An incident closed
before your viewers notice.
Four steps from a Amazon CloudTrailanomaly to a closed incident with a typed postmortem. Read top to bottom — the loop is closed end to end.
- 1
Save the CloudTrail source
Per-user CloudtrailSource row holds the AWS Region, an optional list of `LookupAttribute` narrows to bias the LookUp to high-signal eventNames (defaults to none — capture everything in the time window), and the credentials posture — a static accessKeyId + secretAccessKey pair (the minimum IAM setup) OR an IAM roleArn the SigV4 helper assumes via sts:AssumeRole. The recommended posture is the role + no static secret on disk.
- 2
Pull change events during an incident
The InvestigationCorrelationsPanel on /app/incidents/[id] calls `/api/v1/cloudtrail-events/collect` with the active incidentId; the route signs one `LookupEvents` call against `cloudtrail.<region>.amazonaws.com` using the shared SigV4 helper, persists the matching CloudtrailEvent rows (deduped by eventId), and runs the correlation pass on the same call so the panel surfaces the ranked candidate list the moment the operator lands on the incident detail. A periodic `cloudtrail-poll` cron also ticks every 5 minutes so the underlying event store stays current even when no incident is in flight.
- 3
Score + cross-correlate with CloudWatch evidence
The correlator joins the captured CloudtrailEvent rows against the CloudwatchEvidence rows ALREADY tagged to the same incidentId and scores each candidate by small typed heuristics: iam change set (+30), config / Put / Update / Create / Delete / Attach / Detach (+20), media-live change prefix (+15), within ±30s of first CloudWatch evidence row (+20), IAMUser with non-empty actor (+10), region-aligned with the CloudwatchSource region (+10). Persisted as typed `CloudtrailIncidentCandidate` rows the panel reads — not raw event noise.
- 4
Surface ranked candidate roots in the investigation view
The InvestigationCorrelationsPanel under the existing HypothesisList on /app/incidents/[id] renders CloudWatch metrics / logs AND CloudTrail change events in ONE timeline — each row carries a vendor chip ('CloudWatch' or 'CloudTrail'), CloudTrail rows add the actor ARN + actorName + actorType + a typed score badge + the typed reason chain (iam_change_as_root_cause / config_change_as_root_cause / media_live_change_as_root_cause / aligned_with_cloudwatch_evidence_within_30s / region_matches_incident_region). The same dashboard panel the agent read is also the panel the agent updated.
Four failure modes Amazon CloudTrail alerts alone miss.
Each one is something the Amazon CloudTrailsignal exposes but the agent loop names and acts on — so a chart becomes a closed incident rather than a triage queue.
Iam Principal Change As Root Cause
An `iam:AttachUserPolicy` or `iam:CreateRole` or `iam:CreateAccessKey` event timed within ±30s of the first CloudWatch evidence row for the incident — Surface noise looks chart-shaped alone but the root cause is up the AWS-side control plane. CloudTrail records the change; Streamwake joins it against the CloudWatch row in the same window and surfaces a typed iam_change_as_root_cause with the actor ARN surfaced as a chip — never collapsed into a CloudWatch-side metric regression.
Config Mutation Cluster As Root Cause
A `Put*` / `Update*` / `Create*` / `Delete*` / `Attach*` / `Detach*` cluster on the AWS-side config side (typically a CloudFront origin-shield retune, a MediaPackage packaging change, or an Elastic Load Balancer attribute flip) — the same window shows CloudWatch-side ViewerImpact regression on the chart side, but the root cause is upstream in the AWS control plane, not on the chart. CloudTrail records the cluster; Streamwake joins it against the CloudWatch row in the same window and surfaces a typed config_change_as_root_cause with the eventName + actor surfaced as a chip.
Media Live Change As Root Cause
A `medialive:*` / `mediapackage:*` / `mediatailor:*` / `mediaconnect:*` / `mediastore:*` event in the same window as the first CloudWatch row for the incident — paired with an `eventName` chip + the regional AWS region surfaced so a chart that flipped on the encoder side is never collapsed with a chart that flipped on the chart side. Streamwake catches the media-live side deliberate in the AWS control plane on the same signal bus and pins the typed classification to media_live_change_as_root_cause.
Metric-vs-classification Skew
The operator pages on a chart that has not yet broken or stays silent on one that has — CloudTrail scores too high and the CloudWatch dashboard widget reads green; too low and the same chart trips a different CloudWatch Alarm the operator has silenced. Streamwake catches the confidence-vs-real-skew on the same signal and re-anchors the heuristic scoring curve to the current CloudWatch-vs-CloudTrail burn-rate so the next candidate lands in lockstep with the Alarm the operator already wired.
Monitor your CloudTrail account change feed free.
Next to Amazon CloudTrail.
Paste your CloudTrail playback URL or AWS MediaLive output URL — /stream-check runs the same five checks (manifest, segments, bitrate ladder, CDN response, playback errors) in under a minute. No login. Pair it with the Book-a-demo block below for a guided walkthrough of the CloudTrail + CloudWatch change-event correlation probe lane on the same AWS account.
AWS/MediaLive channel-state flip + matching CloudTrail `iam:AttachUserPolicy`.
aws.medialive.active_alerts drifted to 14 vs 0 baseline on iad-cmh paired against CloudTrail recording an iam:AttachUserPolicy event 38 seconds earlier on the same account, actor ops-bridge-prod (IAMUser).
The agent joined the AWS/MediaLive ActiveAlerts drift + the same-account CloudTrail iam:AttachUserPolicy event + the matching CloudFront cache_miss_latency_p95_ms and classified the joint signal as a single iam_change_as_root_cause hypothesis at 88% confidence, emitted a paired AWS MediaLive channel retune + a CloudFront PoP reroute, and emitted the remediation back into the same account as streamwake.cloudtrail.remediation.applied on the CloudTrail event id so the same panel that flagged the ActiveAlerts drift re-renders the loop-closure metric the moment the fix lands.
Direct mapping to the Streamwake detect → classify → fix loop on the CloudTrail + CloudWatch signal bus — the same AWS/MediaLive ActiveAlerts drift AND the matching CloudFront cache-miss latency fan-out (both on the +CloudWatch page) AND the CloudTrail `iam:AttachUserPolicy` change event that landed 38 seconds earlier on the same account (this page) are the signals that get surfaced in the InvestigationCorrelationsPanel under the ranked hypothesis list on /app/incidents/[id] — one timeline, one typed classification, one typed remediation.
Book a 20-minute walkthrough on your AWS CloudTrail account.
We're happy to walk through how the AWS/MediaLive ActiveAlerts drift, CloudFront cache-miss latency fan-out, CloudWatch Logs FilterLogEvents, CloudTrail LookupEvents (iam_change + config + media_live typed heuristics), and sts:AssumeRolecredential posture map onto your existing AWS account. Drop your details below and we'll follow up within 1 business day.