Amazon Bedrock Prompt Management, Flows, and Prompt Caching (AWS Gen AI Series, Part 15)
Prompt caching, Prompt Management, and Bedrock Flows get grouped together and confused constantly. What each one does, what caching actually saves, and which to reach for.
Every call to a Bedrock model re-reads your whole prompt. If your system prompt is 8,000 tokens of instructions and product data, you pay to process those 8,000 tokens again on the next question, and the one after that.
TL;DR: Three separate Bedrock features get named in the same breath and confused constantly. Prompt caching cuts the cost and latency of repeated context, and reads from cache bill at roughly a tenth of the normal input rate. Prompt Management stores prompts as versioned objects so they stop living inside your application code. Bedrock Flows chains prompts, models, and AWS services into a workflow you build on a canvas. You do not need all three, and this part says which to reach for.
Prerequisites: You have called a Bedrock model at least once and know what a token is. If the Converse API is new to you, read Part 11 first, because caching hangs off that API. No prior work with Flows or Prompt Management is assumed.
Three features that keep getting confused
Prompt caching, Prompt Management, and Bedrock Flows share a menu heading in the console and almost nothing else. One is a billing and latency trick. One is a filing cabinet for prompts. One is a workflow engine. I have watched a team turn on all three at once because a slide grouped them, then lose a week debugging a Flow they never needed. Here is what each one actually is, defined before we go deeper.
Prompt caching is an inference option. It tells Bedrock to store a fixed chunk at the front of your prompt so the model does not recompute it on the next call. Prompt Management is a store inside Bedrock where a prompt becomes a named, versioned object with variables and saved model settings, instead of a string buried in your code. Bedrock Flows is a builder, on a canvas and through an API, that links a prompt, a model, a knowledge base, and a Lambda function into one workflow you can version and deploy. You can adopt any one without the others.
Figure 1. The three features solve unrelated problems despite sharing a console menu.
Prompt caching, and the tokens you stop paying for
A cache checkpoint is a marker you place in your prompt. Everything before it, the prefix, gets stored after the first call. On the next call, if that prefix is byte for byte identical, the model reads it from cache instead of processing it again. You are billed for cache reads at roughly a tenth of the normal input rate, which is where the savings come from.
There are rules. The prefix has to clear a minimum token count before anything is cached, and that minimum depends on the model. Claude 3.7 Sonnet caches from 1,024 tokens. The 4.5 generation, Opus 4.5, Sonnet 4.5, and Haiku 4.5, needs 4,096 tokens per checkpoint. You get at most four checkpoints per request. The cache has a time to live: five minutes by default, and every cache hit resets the clock. Opus 4.5, Sonnet 4.5, and Haiku 4.5 also offer a one hour TTL if you ask for it with a ttl field. Amazon Nova caches text prompts automatically, though AWS still recommends opting in explicitly to get the cost benefit and not just the latency one.
Caching works on the Converse and ConverseStream APIs, on InvokeModel, alongside cross region inference, and from within Prompt Management. Cross region inference is worth a flag: it can route your request to a different Region under load, and that can turn what you expected to be a read into a fresh write.
Table 1. Prompt caching limits by model
Model
Min tokens per checkpoint
Max checkpoints
TTL options
Claude Opus 4.5
4,096
4
5 min or 1 hour
Claude Sonnet 4.5
4,096
4
5 min or 1 hour
Claude Haiku 4.5
4,096
4
5 min or 1 hour
Claude 3.7 Sonnet
1,024
4
5 min
Amazon Nova (text)
Automatic, plus explicit
n/a
5 min
Figure 2. Reads are cheap, writes carry a premium. Caching pays only when a prefix is read many times before it expires.
Writes cost more than a plain input token, so caching is not free on the first call. A five minute write runs about 1.25 times the input rate, a one hour write about 2.0 times, and reads run about 0.1 times. The math only works when the same prefix is read many times before it expires. Cache something you touch once and you have paid a premium for nothing.
What does a cache miss actually cost you?
Numbers make this concrete. Take a support chatbot with a 10,000 token static prefix: system instructions plus a product catalog the model needs on every answer. Each user question adds about 200 tokens, and each reply is about 300. Say it handles 1,000 requests an hour, steady enough that the cache stays warm.
Worked example
Without caching, every request processes 10,200 input tokens. Across 1,000 requests that is 10.2 million input tokens an hour. At 3 dollars per million input that is 30.60 dollars, plus 300,000 output tokens at 15 dollars per million, 4.50 dollars. About 35.10 dollars an hour.
With caching, each warm request reads 10,000 tokens from cache at 0.30 dollars per million (0.003 dollars), processes 200 new input tokens (0.0006 dollars), and returns 300 output tokens (0.0045 dollars): about 0.0081 dollars a request, or 8.10 dollars an hour. Add roughly 0.45 dollars an hour as the five minute window refreshes the write. Call it 8.55 dollars against 35.10, a 75 percent cut on this workload. Rates are illustrative Sonnet 4.5 figures; confirm your Region and model before trusting the dollars [VERIFY].
Table 2. Cost per hour, 1,000 requests, 10,000 token prefix
Line item
Without caching
With caching
Standard input tokens
30.60 dollars
0.60 dollars
Cache reads
0
3.00 dollars
Cache writes
0
0.45 dollars
Output tokens
4.50 dollars
4.50 dollars
Total per hour
35.10 dollars
8.55 dollars
Figure 3. Same workload, same output. Caching takes the input line item down by about ninety percent.
The shape holds regardless of the exact rate: when a large prefix repeats, caching takes the biggest line item, input processing, and cuts it by about ninety percent. Output tokens do not change, because caching only touches input. That is why the savings flatten once your prompts get output heavy.
Storing prompts in Prompt Management
A prompt that lives as a Python f-string has no version history, no way to compare two wordings, and no home a non-engineer can open. Prompt Management fixes that. You create a prompt as a named object, drop in variables with double brace syntax like {{input}}, pick a model and its inference settings, and save it. Each save can become a version, and versions are what you point an application at.
Two features earn their keep. You can hold up to three variants of a prompt side by side and compare their outputs against the same input, which beats guessing in a text editor. And Prompt Optimization will rewrite a prompt for a target model and show you the before and after, useful when you move a prompt to a new model and the old phrasing underperforms. Prompts you save here get reused by Bedrock Flows and Bedrock Agents, so the store is not a dead end. You can also switch on prompt caching from inside a managed prompt.
The craft of writing the prompt text itself, few shot examples, output format, temperature, is covered in the vendor neutral GenAI Series, Part 12. Here I stay on the Bedrock plumbing around it.
My take: for a solo project, prompts in your Git repo with a code review are fine and probably better, because they travel with the code that calls them. Prompt Management earns its place the moment a second person edits prompts, or a product manager wants to tweak wording without a deploy. Below that bar it is a console tab you will forget to update.
Wiring a cached call in code
Enough concept. Here is a cached Converse call with boto3. The cachePoint sits at the end of the system block, right after the static prefix and before anything that changes per request.
import boto3
client = boto3.client('bedrock-runtime', region_name='us-east-1')
# SYSTEM_PREFIX must clear the model minimum (4,096 tokens for Sonnet 4.5)
SYSTEM_PREFIX = load_instructions_and_catalog()
resp = client.converse(
modelId='anthropic.claude-sonnet-4-5-20250929-v1:0',
system=[
{'text': SYSTEM_PREFIX},
{'cachePoint': {'type': 'default'}}
],
messages=[
{'role': 'user',
'content': [{'text': 'Which plan covers overseas support?'}]}
]
)
u = resp['usage']
print('new input ', u['inputTokens'])
print('cache read ', u.get('cacheReadInputTokens'))
print('cache write ', u.get('cacheWriteInputTokens'))
Failure mode: if SYSTEM_PREFIX sits below the model minimum, both cache fields stay 0 and nothing is cached. Inference still succeeds, so this fails silently. You keep paying the full input rate and never see an error, which is why you watch cacheWriteInputTokens on the first call to confirm the write landed.
On the first call the prefix is written, so cacheWriteInputTokens shows the prefix size and cacheReadInputTokens is zero. On the second call within the TTL, the two swap. Note that inputTokens counts only the new, uncached tokens; to get the true total you add all three fields together.
Bedrock Flows, when a workflow needs a diagram
Flows is the odd one of the three, because it is not about a single model call at all. It is a workflow engine. You drop nodes on a canvas: an input node, a prompt node, a model, a knowledge base, a Lambda function, a condition, an output. You connect the output of one to the input of the next, and Bedrock runs the graph.
The lifecycle matters more than the canvas. You edit a working draft, test it with sample inputs, then publish a version. Versions are immutable, a frozen snapshot. To use one in an application you create an alias that points at a version, and your app calls InvokeFlow against the alias. Need to ship a change? Publish a new version and repoint the alias. Pricing is indirect: a Flow costs whatever the nodes inside it cost, so a prompt node calling a model bills as that model call.
Figure 4. A flow chains nodes and runs the graph; you deploy a version through an alias.
Gotcha
Because versions are immutable, there is no editing a live Flow in place. Every change is a new version and an alias repoint, which is good for auditing and annoying during a hotfix. And a Flow is only as reliable as its weakest node. One Lambda that times out fails the whole run, so error handling belongs inside the nodes, not bolted on after.
When not to use Flows: a single prompt and a single model call. Wrapping that in a Flow buys you latency and moving parts for no benefit, so call Converse directly. Flows pays off when the work is genuinely several steps, when you want a deployable artifact a non engineer can read, or when you are chaining a knowledge base and a Lambda around the model.
Where these three trip you in production
Caching first. The prefix has to be identical, and identical means byte for byte. A timestamp, a reordered JSON key, a trailing space, any one of them turns a read into a full recompute and your savings vanish. Dynamic content must sit after the checkpoint, never before it. And keep an eye on cross region inference: when it reroutes under load, the new Region may not have your cache warm, so writes climb during exactly the traffic spikes you cached to survive.
Prompt Management has a smaller footprint but two real limits. Variants cap at three, so wide tests need a different tool. And Prompt Optimization rewrites meaning, not just wording, so run the optimized prompt through an evaluation before you trust it; I have watched an optimizer quietly drop a constraint that mattered.
Flows fail the way any orchestration fails. Immutable versions mean alias discipline, and a stray alias pointing at an old version is a confusing bug at 2am. Watch node timeouts, and remember that debugging a visual graph is harder than reading a stack trace, so log generously inside every Lambda node.
Using caching inside a managed prompt and a flow
The three features are not rivals, and the better setups combine them. Caching is orthogonal to the other two, so a prompt you store in Prompt Management can have caching switched on, and any Flow that calls that managed prompt inherits the cached prefix without extra wiring. That is the pattern I default to: author the prompt once, cache its static half, and let Flows or Agents reuse it.
Order of adoption is the practical question. Start with caching on your heaviest single call, because it pays back immediately and touches nothing else. Move prompts into Prompt Management next, but only the ones more than one person edits. Add a Flow last, and only when a real second step appears, a knowledge base lookup or a Lambda side effect that a single Converse call cannot cover. Adopt them in that order and each step earns its complexity before you take on the next.
One caution when you combine them: caching still needs a stable prefix, so a Flow that rebuilds its prompt on every run, injecting a fresh timestamp or a reordered context, will never see a cache hit no matter how the managed prompt is set. Keep the variable parts of a flow prompt at the tail.
Which of the three earns a place in your stack?
Different answers for each. Prompt caching: turn it on almost any time you reuse context. It is close to free to adopt, the read discount is large, and the only real cost is the discipline to keep your prefix stable. There is no good reason to leave it off on a chatbot or a RAG endpoint.
Prompt Management: adopt it when more than one person touches prompts, or when you need to compare wordings and roll back. Skip it when prompts live happily in your repo and ship through CI. It is governance, not performance, so buy it when you need the governance.
Flows: reach for it last. It shines for multi step workflows you want to deploy and hand to people who do not write code. For a single call it is overhead you will regret. The next part moves from reusing prompts to changing the model itself, with fine tuning on Bedrock, where the spend and the payoff both get bigger.
If you do one thing this week, put a cache checkpoint at the end of your largest static system prompt and watch the cacheReadInputTokens field on the second call. That single number tells you whether the rest of this is worth your time.
Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.
Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.
DrJha