Streamwake + Amazon CloudWatch.
A source-inspected CloudWatch surface with a proposed Streamwake evaluation model.
Source inspection covers AWS-native metrics and logs through GetMetricData and FilterLogEvents, with sts:AssumeRole named for cross-account access and SNS alarm/log-event parsing. Compatibility for Amazon CloudWatch is not verified yet, and verified setup instructions are unavailable; customer-account connection, broad namespace coverage, telemetry delivery, remediation, and production readiness remain unverified.
Amazon CloudWatch aws-native metrics + logs — getmetricdata + filterlogevents + sts assumerole. The Amazon CloudWatch-owned surfaces are source-inspected; the Streamwake workflow on this page is conceptual and not a demonstrated live integration.
Verification evidence
- Public capability claim
The published Amazon CloudWatch detail page states the capability Streamwake offers alongside Amazon CloudWatch.
- Basis
- The page copy is explicitly presented as a capability claim, separate from implementation and test evidence.
- Scope
- Public capability claim on this integration detail page.
- Reference
- /integrations/cloudwatch
- Source-inspected implementation
The Amazon CloudWatch detail page is backed by a checked-out static integration configuration and page implementation.
- Basis
- The checked-out page and its shared IntegrationPage configuration were inspected for this surface.
- Scope
- Static source implementation represented by the public detail page.
- Reference
- src/app/(custom)/integrations/cloudwatch/page.tsx
What Amazon CloudWatch owns. What Streamwake proposes on top.
The Amazon CloudWatch surfaces below are based on source-inspected research. The proposed Streamwake layer is conceptual; live compatibility, operation, and remediation remain unverified.
Claim status labels: see definitions.
Metrics + Logs + Alarms + Dashboards
Cross-service signal + STS AssumeRole
Proposed viewer-impact correlation and typed classification
Proposed operator-reviewed recovery and postmortem loop
A proposed operating loop
for Amazon CloudWatch signals.
Four conceptual steps from a Amazon CloudWatch signal to an operator-reviewed next action. This is not a controlled test or production demonstration.
- 1
Save a source for evaluation
The authenticated source path stores an AWS region, a metric or log query shape, and a credential posture. This is an evaluation/setup surface; saving configuration does not establish customer compatibility or production readiness.
- 2
Pull metric or log evidence
The source-inspected route signs a `GetMetricData` or `FilterLogEvents` request against an allow-listed region, persists CloudWatch evidence rows, and records the result for an authenticated scope. This verifies implementation shape only, not a live customer run.
- 3
Evaluate cross-signal hypotheses
A proposed evaluation could align captured CloudWatch rows with viewer-impact, CDN, or encoder signals and rank typed hypotheses. The repository does not provide customer evidence that this workflow is live or accurate in production.
- 4
Review recovery and learn
Operator review, recovery approval, postmortem capture, and CloudWatch write-back are conceptual scenarios. No `streamwake.cloudwatch.remediation.applied` path or same-account CloudTrail outcome is evidenced by this integration.
No verified Amazon CloudWatch setup is
published yet.
A verified Amazon CloudWatch connection path, live telemetry ingestion, and setup instructions are not available on this page. The conceptual workflow above must not be read as operational guidance.
Conceptual Amazon CloudWatch scenarios
for investigation, not verified operation.
These scenarios use source-inspected Amazon CloudWatch-owned surfaces to illustrate what a future workflow could evaluate. They are proposed examples, not results from a live account.
Claim status labels: see definitions.
Aws Medialive Active Alerts Drift
Conceptual scenario: a MediaLive alert metric and a viewer-impact signal could be compared in one evaluation window, then labeled as separate evidence and a ranked hypothesis. This does not establish named-namespace customer coverage or a demonstrated classification result.
Cloudwatch Logs Filter Skew
Conceptual scenario: a filter-pattern mismatch could be surfaced as a hypothesis for operator review. The source path supports the `FilterLogEvents` request shape; automatic filter rewriting and a recovery result are unverified.
Cloudfront Cache Miss Latency Fan Out
Conceptual scenario: CloudWatch evidence and viewer-impact evidence could be compared to investigate an edge/origin hypothesis. No customer telemetry delivery, broad CloudFront namespace coverage, or automatic rerouting is evidenced.
Metric-vs-classification Skew
Conceptual scenario: a typed confidence review could compare a metric or log event with observed impact and ask an operator to reassess the hypothesis. Confidence calibration, alarm changes, and write-back remain unverified.
Discuss an evidence-bounded CloudWatch evaluation.
Next to Amazon CloudWatch.
Use the independent stream check for a viewer-side observation, then contact engineering to discuss what a customer-approved CloudWatch evaluation would need to verify. The stream check is not proof of CloudWatch compatibility, telemetry ingestion, remediation, or production readiness.
Claim status labels: see definitions.
What this page supports,
and what it does not.
The public evidence records remain limited to the existing public capability and source-inspected records. Read the evidence status definitions for the meaning of each state.
Verified at source / controlled scope
Verified implementation or repeatable fixture behavior only. This is not customer compatibility or production proof.
- CloudWatch metric and log pull request/response shapes
- Allow-listed AWS regions and the SigV4 request path
- Authenticated, scoped source and evidence routes
- SNS alarm/log-event parsing and synthetic fixture correlation
Conceptual
Proposed evaluation model; no claim that the workflow is live or demonstrated.
- Viewer-impact correlation and typed cross-signal classification
- Ranked hypotheses and an operator-reviewed recovery workflow
- Incident/postmortem loop and any CloudWatch write-back scenario
Unverified
No attributable customer or production evidence is present for these claims.
- Live customer-account compatibility and broad named-namespace coverage
- Customer telemetry delivery and production readiness
- Automatic remediation, `streamwake.cloudwatch.remediation.applied`, and same-account CloudTrail outcomes
A possible CloudWatch evaluation is not a customer incident.
If a configured CloudWatch metric or log event coincided with viewer impact, a future evaluation could place both signals in one incident window for operator review.
The checked-in parser and correlation tests use synthetic fixtures. They show repeatable fixture behavior, not a live AWS account, a customer outcome, a numeric confidence result, or a demonstrated remediation.
This scenario illustrates a proposed evaluation model only. Viewer-impact correlation, ranked hypotheses, operator-approved recovery, and any write-back to CloudWatch remain conceptual or unverified.
Configure a source,
then document the evidence boundary.
The authenticated setup island mounts the pull-side CloudwatchSourceCard and a companion alarm-webhook card. It can help prepare an evaluation by showing the existing source and SNS parsing surfaces. Compatibility for Amazon CloudWatch is unverified, and verified setup instructions are unavailable. It does not prove a live customer connection, telemetry delivery, or production operation.
Wire an SNS topic in your AWS account to publish CloudWatch alarms + log events to the Streamwake endpoint. The alarm-webhook ride-along share the per-source routerToken, so the inbound route resolves your tenant from ?token=<routerToken> first and then verifies the AWS-issued SNS signature (RSA-SHA1 over the canonical LF-joined string) against the pinned sns.<region>.amazonaws.com cert URL.
(empty)(not configured)(empty)(no events yet)routerToken from that row.Recent alarm events
No alarm events received yet. Click Send test alarm above to verify the inbound end-to-end.
An evaluation needs IAM access,
a region in scope, and a defined query.
These are proposed prerequisites for a customer-approved evaluation. The source card, allow-listed regions, and request shapes are source-inspected; access to a customer account and the resulting evidence are unverified.
IAM role + cross-account access (sts:AssumeRole preferred)
A least-privilege IAM role is the proposed posture for an evaluation. The inspected path names sts:AssumeRole and these permissions: cloudwatch:GetMetricData, cloudwatch:ListMetrics, logs:FilterLogEvents, logs:DescribeLogGroups.
The form also accepts a static accessKeyId + secretAccessKey pair. Secrets are write-only in the read shape, but no customer credential or IAM outcome is present in the public evidence.
Regions in scope (8)
The source contract exposes 8 allow-listed AWS regions. Selecting one is necessary for an evaluation, but does not verify that a customer’s resources or namespaces are available there.
The implementation shapes that can be inspected in the source. This table is not a compatibility list and does not claim broad named-namespace coverage.
| Surface | Kind | Evidence boundary |
|---|---|---|
| Configured metric namespace | GetMetricData | Source-level request and response handling for a namespace, metric name, dimensions, and returned datapoints. This is not evidence of broad named-namespace or customer-resource coverage. |
| Configured log group | FilterLogEvents | Source-level request and response handling for a log group, filter pattern, log stream, and message body. Customer log delivery and event coverage remain unverified. |
| Allow-listed AWS region | SigV4 path | Region validation and signed `monitoring` or `logs` endpoint construction in the inspected implementation. This does not verify access to a customer account. |
| Authenticated evidence routes | scoped persistence | Authenticated source save/read and evidence persistence shapes are present in the repository. This is not customer evidence. |
Five steps from a blank source card
to a bounded probe result.
The source-inspected sequence for preparing a customer-approved evaluation: role + trust, region, query shape, credentials, and a SigV4-signed probe. A successful probe would still be scoped evidence, not broad compatibility or production proof.
- 1
Prepare an IAM role + trust policy
For an evaluation, a customer would provide an IAM role and least-privilege policy for the intended account. The source-inspected path names `cloudwatch:GetMetricData`, `cloudwatch:ListMetrics`, `logs:FilterLogEvents`, and `logs:DescribeLogGroups`; the actual customer account and IAM outcome are unverified.
- 2
Choose an allow-listed AWS region
Choose a region from the connector’s allow-list. The source-inspected request path signs `monitoring.<region>.amazonaws.com` or `logs.<region>.amazonaws.com` for that region; resource availability and customer compatibility still require an attributable evaluation.
- 3
Select a metric or log query shape
Configure the surface for an evaluation: a namespace, metric name, and optional dimensions, or a log group and filter pattern. The repository supports these request shapes; it does not establish coverage for a customer’s named namespaces or log groups.
- 4
Supply credentials for an evaluation
The setup surface accepts an IAM role ARN or a static pair, with secrets kept write-only in the read shape. Use customer-owned credentials only for an approved evaluation; no credentials or customer account have been verified here.
- 5
Use Test connection as a bounded probe
`Test connection` can issue one signed `GetMetricData` or `FilterLogEvents` request and report its bounded result. A successful probe would not prove broad compatibility, telemetry delivery, automatic remediation, or production readiness.
The static secretAccessKey is never returned by GET /api/v1/cloudwatch-source — only a hasSecretAccessKey: true|false boolean surfaces so the form can prompt for re-entry. The IAM roleArn is also write-only; only hasRoleArn reflects back. Test connection reports viaRole: true when the call succeeded via sts:AssumeRole, so the credential read shape can be checked without exposing secrets. This does not verify a customer account or the complete workflow.
The CloudWatch surfaces
represented by the inspected implementation.
The rows below describe source-level shapes and repeatable fixture behavior. They do not represent customer telemetry, broad namespace coverage, or a live incident view.
| Signal | Kind | Summary |
|---|---|---|
| Metric response shape | metric | A source-level `GetMetricData` response can be persisted with datapoints and a maximum value. No customer metric, namespace, or result is asserted. |
| Log response shape | log | A source-level `FilterLogEvents` response can be persisted with a log stream name and message body. Customer log delivery and event volume remain unverified. |
| SNS CloudWatch alarm envelope | fixture | The parser recognizes the signed alarm payload shape in the checked-in fixture path. The fixture is synthetic and does not represent a customer alarm. |
| SNS CloudWatch Logs event | fixture | The parser recognizes a CloudWatch Logs subscription event shape and correlates it in the checked-in fixture path. This is repeatable fixture behavior, not customer telemetry evidence. |
What a future evaluation could explore
without implying it is live.
These cards separate conceptual workflow ideas and explicitly unverified outcomes from the source-level pull and parsing behavior above. They are evaluation scenarios, not demonstrated customer capabilities.
Ranked hypotheses
A proposed workflow could join CloudWatch evidence with viewer-impact signals and rank typed hypotheses. No customer result or confidence score is claimed.
Cross-signal investigation view
A proposed incident view could place metric and log evidence beside viewer-impact context. The page does not establish that this customer-facing workflow is live.
Operator-reviewed recovery
Recovery selection, approval, verification, and any CloudWatch write-back are conceptual scenarios. The repository has no demonstrated automatic remediation path.
CloudTrail outcome
Same-account CloudTrail correlation and any resulting audit-trail entry are unverified for this CloudWatch page. Do not infer them from source configuration or fixtures.
Discuss a 20-minute evaluation with the evidence boundary in view.
We're happy to discuss the source-inspected metric/log and SNS paths, the customer evidence needed for a controlled evaluation, and the boundary around compatibility, telemetry, recovery, and production claims. Drop your details below and we'll follow up within 1 business day.