Skip to main content
Let’s walkthrough a live demo in an editor (I’m using Visual Studio Code, but any editor will work). This lesson uses two Python scripts that show two approaches to calling Amazon Bedrock via the runtime API: Both scripts use the Bedrock runtime client via Boto3.

invoke_model.py

This script demonstrates a direct model invocation that includes model-specific control tokens in the prompt. These tokens come from the model’s required input format and must be provided exactly as specified by that model.
What this script does:
  • Instantiates a Bedrock runtime client with Boto3: boto3.client("bedrock-runtime", region_name="us-east-1").
  • Builds a JSON payload that includes a prompt with model-specific control tokens.
  • Calls invoke_model with the chosen modelId.
  • Reads and parses the response stream and prints the generated text.
Sample terminal output after running invoke_model.py:
Model-specific control tokens (for example, "<|begin_of_text|>") are required by some providers/models to frame the input correctly. These tokens vary by model—consult the model’s documentation for the exact input format before sending requests.

converse.py (unified messages format)

This script demonstrates a vendor-agnostic approach using a messages array. The unified messages structure is easier to reuse across different models and providers because it removes model-specific control tokens from your application logic.
Why use the unified messages format?
  • Vendor-agnostic: keeps your app code consistent when switching models/providers.
  • Reusable: the same messages payload can be re-used across different model IDs.
  • Inspectable: because response schemas vary by model, it’s useful to print and inspect the returned JSON to determine how to extract the generated text.
Sample terminal output after running converse.py (trimmed for readability):
Response schemas vary across models and providers. Do not rely on a single fixed response field—inspect the returned JSON and map the fields your application needs (for example, generation, content, or provider-specific properties).
A "Results" slide with four numbered dark-blue cards (01–04), each containing an icon and brief text. The cards list benefits: standardized integration with Bedrock services, faster application development, reduced complexity when interacting with models, and consistent architecture across AWS services.
There are over 200 AWS services. The common integration pattern is the same across services: instantiate a service client with Boto3 and call the appropriate API methods. For Bedrock:
  • Use the control plane APIs (via the SDK or console) to configure model resources and manage the service.
  • Use the runtime API (e.g., bedrock-runtime via Boto3) for inference/invocations.
A presentation slide titled "Key Takeaway" with text explaining that Amazon Bedrock uses control plane APIs to manage resources and runtime APIs to perform model inference, typically accessed through AWS SDKs. The slide has a dark blue left panel and light background for the text.
This concludes the demonstration. For hands-on experience, run the scripts locally and experiment with different modelId values and payload options such as temperature, top_p, and max_gen_len.

Quick comparison: direct prompt vs unified messages

A hands-on lab is recommended to practice accessing Bedrock with Boto3 and testing both model-specific prompts and the unified messages format.

Watch Video

Practice Lab