Skip to main content
In this lesson we cover how to connect your application to Amazon Bedrock so it can expose generative AI capabilities. We’ll explain the problem, the two Bedrock APIs, a recommended SDK workflow, and provide short examples you can reuse. We’ll cover:
  • The problem: how to connect your app to Bedrock
  • The solution: Bedrock API and Bedrock Runtime API
  • A simpler workflow using the AWS SDK
  • A short demonstration and expected results
  • A summary and a hands-on lab
A slide titled "Lecture Flow" showing a sequence of rounded blue boxes connected by arrows. The boxes read Problem (How to connect your app to Bedrock), Solution (Bedrock API), Workflow (AWS SDK Bedrock Client), Demonstration, Results (Faster application development), and Key Takeaway (Control and Runtime API).

​
The problem: How do we connect our application to Amazon Bedrock?

If your application needs to provide generative AI features, it must interact programmatically with Bedrock. Typical responsibilities include:
  • Sending prompts to models to perform inference.
  • Managing available models, guardrails, and configuration (control plane).
These are distinct operation types and therefore map to different APIs: one for configuration/setup (control plane) and one for model invocation (inference/runtime).
A presentation slide titled "Problem: How To Connect Your App to Bedrock" showing four numbered panels describing developer challenges. The panels note problems like programmatic interaction, separate model/prompt management, the need for a consistent interface, and the complexity of raw APIs.
If you call HTTP endpoints directly you must handle:
  • SigV4 request signing
  • Retries and exponential backoff
  • Serialization and deserialization of JSON payloads
  • Error handling and status parsing
That burden is why most developers use an SDK to avoid reinventing those features.

​
The solution: Bedrock API vs Bedrock Runtime API

There are two APIs to know: Both are REST-over-HTTPS, require IAM authentication using SigV4, and return JSON responses.
A diagram titled "Solution: Bedrock and Bedrock Runtime API" showing two API types: Setup/Configuration (Bedrock API — control plane operations like creating knowledge bases and managing guardrails) and Execution/Inference (Bedrock Runtime API — invoking models and generating responses). It also notes common characteristics such as REST over HTTPS, IAM authentication, and JSON responses.

​
Direct REST (manual) — what it looks like

If you choose to call the runtime endpoint manually, you perform an HTTPS POST with a SigV4 Authorization header and a JSON body. Example (pseudocode):
And you receive a JSON response with the model output. When you do this manually you must implement signing, retries, and error handling yourself. The AWS SDKs (e.g., Boto3 for Python, AWS SDK for JavaScript/TypeScript, AWS SDK for Java, .NET, PHP) provide a higher-level interface that:
  • Performs SigV4 signing automatically
  • Serializes requests and deserializes JSON responses
  • Handles retries, timeouts, and credential resolution
  • Exposes simple method calls for runtime and control-plane actions
Install the SDK for your language (pip, npm, Maven/Gradle, NuGet, etc.) and create separate clients for bedrock and bedrock-runtime to keep configuration and inference operations distinct.
A diagram titled "Workflow: Software Developer Kit (SDK)" showing Python code connected to the AWS SDK for Python. Arrows indicate the SDK calling APIs for Amazon Bedrock, Amazon S3, and AWS EC2, with labels like "Dependency" and "Simple method calls like invoke-model()".

​
Example: creating a Bedrock Runtime client in Python (Boto3)

Notes before the example:
  • The Python SDK is called Boto3.
  • Use the service name bedrock-runtime for inference calls and bedrock for control-plane calls.
  • Configure credentials and region (shared credentials file, environment variables, or IAM role).
  • Ensure the Bedrock service is available in the chosen region.
Example code:
A few practical tips:
  • Name your clients clearly (inference_client, config_client) to avoid confusion.
  • Verify the service is available in your AWS Region: consult the official AWS Regional Services List.
  • The SDK handles SigV4 signing; you do not need to implement signing logic manually.
Use separate SDK clients for runtime (bedrock-runtime) and control-plane (bedrock) operations. The SDK handles signing, retries, and serialization, which simplifies development and reduces errors.

​
Short demonstration and expected results

Typical demo flow:
  1. Use the control-plane client (bedrock) to list available models or configure a knowledge base.
  2. Use the runtime client (bedrock-runtime) to invoke a model with a text prompt.
  3. Receive a JSON response containing the generated text (or streamed tokens if using streaming APIs).
  4. Handle errors (throttling, validation errors) by relying on the SDK’s retry/backoff behavior and inspecting exception details.
Expected outcomes:
  • Faster development: no manual signing or JSON plumbing.
  • Cleaner code: method calls instead of raw HTTP requests.
  • More robust apps: built-in retries and credential management.

​
Summary and next steps

  • Problem: Applications need programmatic access to models and configuration.
  • Solution: Two APIs — control-plane (bedrock) and runtime (bedrock-runtime) — each mapped to separate API endpoints and SDK clients.
  • Recommendation: Use the AWS SDK for your language (Boto3 shown for Python) to handle signing, retries, and serialization.
  • Next: Follow a hands-on lab to list models, invoke a model, and inspect outputs. For production, integrate error handling, rate-limit awareness, and logging.

Watch Video