AWS Bedrock AI Observability installation

Let AI instrument your LLM calls for you

Skip the manual setup — run this in your project and the wizard installs the SDK and wires up AI Observability for you.

Install dependencies

Required

Install the OpenTelemetry SDK, OTLP exporter, and the AWS SDK instrumentation for your language.

pip install boto3 opentelemetry-instrumentation-botocore opentelemetry-sdk "posthog[otel]"
npm install @aws-sdk/client-bedrock-runtime @opentelemetry/instrumentation-aws-sdk @opentelemetry/sdk-node @opentelemetry/resources @posthog/ai
There are no Go instrumentation libraries for the AWS SDK yet. Register PostHog's span processor and set the `gen_ai.*` attributes on a span around each Bedrock call, as shown in the Go tab of the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry).

Set up the OpenTelemetry exporter

Required

Configure the OpenTelemetry SDK to export traces to PostHog's OTLP ingestion endpoint. PostHog converts gen_ai.* spans into $ai_generation events automatically.

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.resources import Resource, SERVICE_NAME
from posthog.ai.otel import PostHogSpanProcessor
from opentelemetry.instrumentation.botocore import BotocoreInstrumentor

resource = Resource(attributes={
    SERVICE_NAME: "my-ai-app",
})

provider = TracerProvider(resource=resource)
provider.add_span_processor(
    PostHogSpanProcessor(
        api_key="<ph_project_token>",
        host="https://us.i.posthog.com",
    )
)
trace.set_tracer_provider(provider)

BotocoreInstrumentor().instrument()
import { NodeSDK } from '@opentelemetry/sdk-node'
import { resourceFromAttributes } from '@opentelemetry/resources'
import { PostHogSpanProcessor } from '@posthog/ai/otel'
import { AwsInstrumentation } from '@opentelemetry/instrumentation-aws-sdk'

const sdk = new NodeSDK({
  resource: resourceFromAttributes({
    'service.name': 'my-ai-app',
  }),
  spanProcessors: [
    new PostHogSpanProcessor({
      projectToken: '<ph_project_token>',
      host: 'https://us.i.posthog.com',
    }),
  ],
  instrumentations: [new AwsInstrumentation()],
})
sdk.start()

Call Bedrock

Required

Make Bedrock API calls as normal. The instrumentation automatically captures gen_ai.* spans for Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream operations.

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

response = client.converse(
    modelId="openai.gpt-oss-20b-1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Tell me a fun fact about hedgehogs."}],
        }
    ],
)

for block in response["output"]["message"]["content"]:
    if "text" in block:
        print(block["text"])
        break
// The AWS SDK must be imported after sdk.start() so the
// instrumentation can patch it.
const {
  BedrockRuntimeClient,
  ConverseCommand,
} = await import('@aws-sdk/client-bedrock-runtime')

const client = new BedrockRuntimeClient({ region: 'us-east-1' })

const response = await client.send(
  new ConverseCommand({
    modelId: 'openai.gpt-oss-20b-1:0',
    messages: [
      {
        role: 'user',
        content: [{ text: 'Tell me a fun fact about hedgehogs.' }],
      },
    ],
  })
)

const textBlock = response.output?.message?.content?.find((b) => 'text' in b)
console.log(textBlock?.text)

await sdk.shutdown()

Supported models

The instrumentation emits gen_ai.* spans for Amazon Titan, Amazon Nova, and Anthropic Claude models. Tool call instrumentation is available for Amazon Nova and Anthropic Claude 3+.

Note: To capture LLM events anonymously, omit the posthog.distinct_id resource attribute and don't set a distinct ID in the PostHog context. See our docs on anonymous vs identified events to learn more.

You can expect captured $ai_generation events to have the following properties:

Property	Description
`$ai_model`	The specific model, like `gpt-5-mini` or `claude-4-sonnet`
`$ai_latency`	The latency of the LLM call in seconds
`$ai_time_to_first_token`	Time to first token in seconds (streaming only)
`$ai_tools`	Tools and functions available to the LLM
`$ai_input`	List of messages sent to the LLM
`$ai_input_tokens`	The number of tokens in the input (often found in response.usage)
`$ai_output_choices`	List of response choices from the LLM
`$ai_output_tokens`	The number of tokens in the output (often found in `response.usage`)
`$ai_total_cost_usd`	The total cost in USD (input + output)
[...]	See full list of properties

Users and sessions

Recommended

A server usually handles requests for many users, so a resource attribute can't say who each trace belongs to. Wrap each request in a PostHog context instead. The PostHog span processor adds the context's distinct ID and properties to every AI span started inside it. Other span processors and exporters on the same provider don't see them.

Set $ai_session_id if your product has multi-turn conversations, so the Sessions tab can group their traces. Workloads that finish in a single trace, like batch jobs or one-shot generation, don't need it.

# Requires posthog 7.70.0 or later
import posthog

with posthog.new_context():
    posthog.identify_context(user_id)
    posthog.tag("$ai_session_id", conversation_id)
    posthog.tag("plan", "pro")  # custom properties work too

    reply = handle_turn(user_message)
// Requires @posthog/ai 8.14.0 and posthog-node 5.15.0 or later
import { PostHog } from 'posthog-node'

const posthog = new PostHog('<ph_project_token>', { host: 'https://us.i.posthog.com' })

const sdk = new NodeSDK({
  // ...the rest of your setup from the earlier step
  spanProcessors: [
    new PostHogSpanProcessor({
      projectToken: '<ph_project_token>',
      host: 'https://us.i.posthog.com',
      client: posthog,
    }),
  ],
})

const reply = await posthog.withContext(
  {
    distinctId: userId,
    properties: {
      $ai_session_id: conversationId,
      plan: 'pro', // custom properties work too
    },
  },
  () => handleTurn(userMessage)
)

On Node, install posthog-node and pass the client as the client option of your PostHogSpanProcessor. Without it, the processor doesn't read the context.

A distinct ID set this way takes priority over a posthog.distinct_id resource attribute, so you can keep the resource attribute as the fallback for work outside a request. If your instrumentation already sets the gen_ai.conversation.id attribute, PostHog uses it as the session ID, and an explicit $ai_session_id takes priority over it.

Verify traces and generations
Recommended
Confirm LLM events are being sent to PostHog
Let's make sure LLM events are being captured and sent to PostHog. Under AI Observability, you should see rows of data appear in the Traces and Generations tabs.

Check for LLM events in PostHog

Next steps

Recommended

Now that you're capturing AI conversations, continue with the resources below to learn what else AI Observability enables within the PostHog platform.

Resource	Description
Basics	Learn the basics of how LLM calls become events in PostHog.
Generations	Read about the `$ai_generation` event and its properties.
Traces	Explore the trace hierarchy and how to use it to debug LLM calls.
Spans	Review spans and their role in representing individual operations.
Anaylze LLM performance	Learn how to create dashboards to analyze LLM performance.

AWS Bedrock AI Observability installation

Contents

Install dependencies

Set up the OpenTelemetry exporter

Call Bedrock

Users and sessions

Verify traces and generations

Next steps

Still have questions?

Was this page useful?