System Prompts in Amazon Bedrock: Write, Test, and Reuse Them

Amazon Bedrock is a managed service that provides access to foundation models from Anthropic, Amazon, Meta, Mistral, and others through a unified AWS API. Each model family has its own instruction format, and Bedrock provides tools for testing and versioning prompts without managing the underlying infrastructure. Tools like fenbs keep the approved prompt versions and lessons from evaluation outside the AWS console, available to every connected assistant.

Check the Amazon Bedrock documentation↗ (opens in a new tab) for current API references, available model IDs, and supported parameters. Model availability and API features change as AWS updates the service.

How system prompts reach the model in Bedrock

Bedrock provides two main APIs for running inference: the older InvokeModel API, which takes a model-specific JSON body, and the newer Converse API, which uses a consistent format across models. For new applications, the Converse API is the recommended path because it handles format differences across model families.

In the Converse API, you pass a system parameter as a list of content blocks alongside the messages array. This puts your system instructions in a consistent place regardless of which model you are calling. The API translates your system parameter into the format each model expects.

import boto3

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

response = client.converse(
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    system=[
        {"text": "You are a technical writing assistant. Respond in plain US English. Keep paragraphs to four sentences or fewer."}
    ],
    messages=[
        {"role": "user", "content": [{"text": "Explain what a context window is."}]}
    ]
)

Model-specific instruction handling

Even with the Converse API abstracting the format, the underlying models handle instructions differently. Claude models (from Anthropic) treat the system prompt as a first-class instruction layer and respond well to structured prompts with XML tags. Amazon Titan models have their own format expectations. Meta's Llama models use special tokens derived from their training.

If you use the InvokeModel API directly, you must format the request body in the model-specific format. For example, calling Claude through InvokeModel requires the Anthropic messages format, including the system field outside the messages array. Mistral models use their own instruction format.

The practical implication: write your system prompt for the specific model family you are using, and test it there. A prompt that works well with Claude may need revision before it works as well with a Titan or Llama model.

The Bedrock Playground

The Amazon Bedrock console includes a Playground for testing prompts interactively. You can choose a model, set a system prompt in the System instructions field, send messages, and see how the model responds. The Playground is the fastest way to iterate on a prompt before building it into an application.

The Playground also lets you compare responses across models: try the same system prompt with Claude, Llama, and Titan to see how each interprets and applies it. This is useful when deciding which model to use for a particular task.

Prompt Management in Bedrock

Bedrock Prompt Management lets you store named prompts with full version history in the AWS console. You can create a prompt, run evaluations, save a version, and use the prompt ARN in your application rather than hardcoding the prompt text. When the prompt changes, you update the version without redeploying code.

Versioning matters when a prompt update changes the behavior of a deployed application. Keeping a record of which version was in production at a given time, and what changed between versions, makes it easier to investigate unexpected output. Note the version ARN and the date of each change alongside the reason for it.

Saving evaluation lessons

Model evaluations in Bedrock, whether through the Model Evaluation feature or manual testing in the Playground, teach you things about how each model handles your instructions. A lesson worth saving: "Llama 3 in Bedrock needs explicit step-by-step instructions to produce numbered lists; it ignores format hints." That kind of finding is easy to forget and expensive to rediscover.

Common issues

• Wrong API for the model: using InvokeModel with a format designed for the Converse API, or vice versa.
• Model-specific parameter gaps: some models in Bedrock do not support all parameters (like max_tokens) the same way. Check the model's documentation.
• Region availability: not all models are available in all AWS regions. Check the Bedrock console for the current list in your region.
• Stale prompt versions: a Prompt Management version that worked six months ago may produce different results after a model update. Re-evaluate after model updates.

How to do this with fenbs

1. Create a free account. Start a personal kanban board for your Bedrock prompt work.
2. Add a task for each system prompt you are developing. In the plan, note the model family, the Converse or InvokeModel API path, and the intended behavior.
3. After testing in the Playground, record the evaluation results in the task. Note which model version, what the prompt achieved, and what edge cases you found.
4. Save approved prompt versions as Skills in fenbs. Link to the Bedrock Prompt Management ARN if you have one, and note the date tested.
5. When you learn something that should change how you approach Bedrock prompts, add a Lesson in fenbs. Check existing Lessons before starting new Bedrock work.

Related: prompt engineering covers the general principles that apply across all models. System prompt examples has patterns worth adapting for Bedrock work.