> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Bedrock API Part 1
> Explains connecting applications to Amazon Bedrock, compares control plane and runtime APIs, recommends using AWS SDKs, and provides examples for model invocation and configuration.
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
## 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).
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:
| API | Purpose | Typical operations |
| - | - | - |
| `bedrock` (control plane) | Setup and configuration | Create knowledge bases, manage guardrails, register models |
| `bedrock-runtime` (runtime/inference) | Model execution and response generation | Invoke models, stream outputs, handle inference responses |
Both are REST-over-HTTPS, require IAM authentication using SigV4, and return 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):
```http theme={null}
POST /model/invoke HTTP/1.1
Host: bedrock.us-east-1.amazonaws.com
Authorization: AWS4-HMAC-SHA256 Credential=AKIA..., SignedHeaders=host;x-amz-date, Signature=...
Content-Type: application/json
{
"prompt": "Explain Amazon Bedrock and how to call it programmatically."
}
```
And you receive a JSON response with the model output. When you do this manually you must implement signing, retries, and error handling yourself.
## Recommended workflow: Use the AWS SDK
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.
### 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:
```python theme={null}
import boto3
# Runtime client for model invocation (inference)
inference_client = boto3.client(
"bedrock-runtime",
region_name="us-east-1"
)
# Control plane client for management/configuration
config_client = boto3.client(
"bedrock",
region_name="us-east-1"
)
```
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.
## Links and References
* Amazon Bedrock documentation: [https://docs.aws.amazon.com/bedrock/](https://docs.aws.amazon.com/bedrock/)
* AWS SDKs: [https://aws.amazon.com/tools/](https://aws.amazon.com/tools/)
* Boto3 documentation: [https://boto3.amazonaws.com/v1/documentation/api/latest/index.html](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html)
* Signature Version 4 signing process: [https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.