Transforming Bedrock Guardrails events into OCSF with CloudWatch

What it is

A reference pipeline from AWS that converts AWS Bedrock Guardrails intervention events (blocked prompt injections, PII redactions, content-policy hits) into OCSF Detection Finding records (class_uid 2004), landing them in the CloudWatch unified data store (launched December 2025) so they're queryable alongside CloudTrail and VPC Flow Logs.

How it works

Bedrock model invocation logging captures guardrail trace data as JSON embedded in invocation logs, in a Bedrock-specific shape. CloudWatch's native OCSF converter, ParseToOCSF, only supports five log sources (CloudTrail, Route 53 Resolver, VPC Flow Logs, EKS audit logs, WAF) — Bedrock Guardrails isn't one of them, so a custom Lambda transform is required. A CloudWatch Logs subscription filter matches only entries where guardrail action is INTERVENED, triggering the Lambda, which expands each guardrail assessment within a single log entry into its own OCSF record (one invocation can contain multiple assessments, e.g. a content-policy hit and a PII match together) and assigns severity: High for prompt injection, Medium for content/topic/sensitive-info interventions. Failed transforms route to an SQS dead-letter queue with error metadata for redrive. Output lands in a dedicated log group associated with AWS S3 Tables, stored as an Iceberg table — but since Bedrock Guardrails is a custom source (not one of the five vended ones), records land as OCSF JSON inside a single cwl__message column rather than typed columns, requiring json_extract_scalar in Athena queries.

flowchart LR
    A[Bedrock invocation + guardrail] --> B[Model invocation log]
    B --> C{Subscription filter:\naction == INTERVENED?}
    C -->|no| X[Dropped, no cost]
    C -->|yes| D[Lambda: OCSF transform]
    D -->|success| E[Destination log group → S3 Tables/Iceberg]
    D -->|failure| F[SQS dead-letter queue]
    E --> G[Athena/Logs Insights: correlate with CloudTrail, VPC Flow Logs]

Preconditions / Affected

Requires an existing Bedrock guardrail, model invocation logging enabled with textDataDeliveryEnabled (captures guardrail trace text), and a Region supporting the CloudWatch unified data store + S3 Tables integration. Logging must be enabled per-account before deploying (the CDK stacks don't manage it). Analytics access requires a separate one-time step per Region: enabling S3 Tables analytics integration and granting Lake Formation Select/Describe permissions to analyst IAM roles — without this grant, Athena returns access-denied even if IAM policy allows it.

What to do

Clone the reference repo and deploy two CDK stacks, TransformPipelineStack (Lambda, subscription filter, dead-letter queue) and MonitoringStack (dashboard + alarms: error rate >5%, DLQ depth >0, p99 Lambda duration >10s, notified via SNS). Tag the destination log group with cw:datasource:name (e.g. bedrock_guardrails) and cw:datasource:type (e.g. ocsf) — the resulting table name joins them with a double underscore (bedrock_guardrails__ocsf), queryable at path "s3tablescatalog/aws-cloudwatch"."logs"."bedrock_guardrails__ocsf". For orgs with multiple accounts: deploy the transform pipeline per workload account and use CloudWatch Logs centralization to replicate only the sanitized OCSF output to one central account (rather than centralizing raw invocation logs first), since raw logs may contain prompt/response text. For recurring correlation queries, materialize extracted fields into a typed table via CREATE TABLE AS SELECT to avoid repeated json_extract_scalar calls.

Caveats

Records contain structural metadata only (no prompt/response content), per the page. The custom-source JSON storage means every Athena query against this table needs json_extract_scalar rather than plain columns unless you materialize a CTAS table yourself. This complements, not replaces, GuardDuty AI Protection's managed findings (direct prompt injection, anomalous invocation) — the two are described as working side by side, not as alternatives.