How a Bedrock Request Moves Through AWS

A typical Bedrock app has five layers: application UI/API, orchestration logic, model invocation, safety checks, and telemetry. Understanding this flow is the difference between a demo and a production system.

1. Ingress - user input reaches your backend (Lambda, ECS/Fargate, EC2, or App Runner) through API Gateway or an ALB.
2. Orchestration - your code assembles the request: system prompt, conversation history, retrieved context, tool definitions.
3. Invocation - the backend calls the Bedrock Runtime API (Converse or InvokeModel) with a model ID and messages.
4. Safety - Guardrails evaluate the prompt before the model sees it and the response before the user sees it.
5. Telemetry - token usage, latency, stop reason, and guardrail verdicts flow to CloudWatch/CloudTrail and your tracing store.

Two APIs, Two Jobs

Bedrock splits its surface into a control plane and a data plane - the same pattern as most AWS services:

This matters for IAM too: an application role usually needs only bedrock:InvokeModel-class data-plane actions, while a platform/admin role manages the control plane.

A Minimal Python Invocation

import boto3

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

response = client.converse(
    modelId="amazon.nova-lite-v1:0",
    messages=[{"role": "user", "content": [{"text": "Explain S3 lifecycle rules in 3 bullets"}]}],
    inferenceConfig={"maxTokens": 512, "temperature": 0.2},
)

print(response["output"]["message"]["content"][0]["text"])
print(response["usage"])   # inputTokens / outputTokens -> cost telemetry