Heads up: I'm based in Japan, so this is written from a Japanese perspective — availability and examples may differ in your region.
New models come out so fast...
New models are released way too fast, aren't they?
If you build AI features into a product, you end up chasing models and updating your integration. But the newest model is not always available in your country, and honestly, I am not always chasing the latest one anyway.
So what do I actually look at when choosing a model? Performance, price, all of that — but this time, the topic is data retention. Your prompts and the model's responses: does Bedrock store them or not?
I had heard "Bedrock doesn't store your data," and I assumed that was the end of the story. Then I ran into a setting called a data retention mode, went "??", and decided to dig in. These are my notes.
TL;DR
The conclusion first:
- "Bedrock doesn't store data" is half right and half incomplete. Whether data is stored is decided by your account's data retention mode × the model's own conditions.
- If you don't want data retained, set the mode to
none. That is ZDR (Zero Data Retention). - But there are exceptions per model. Some models retain only classifier-flagged inputs/outputs for up to 30 days; a few retain everything for up to 30 days.
-
noneis not a magic fix either: models that require retention simply become unusable undernone. - And regardless of the mode, logs you enabled yourself keep being stored by you.
Wait, doesn't Bedrock not store data?
My original understanding was: "Bedrock doesn't store prompts or outputs, and doesn't use them for training." That is broadly correct.
The catch is that three different things tend to get mixed up:
- Whether data is stored (whether inference inputs/outputs are kept in storage)
- Whether data is shared with the model provider
- Whether data is used to train models
These are separate. "Not used for training" does not automatically mean "never stored at all" — and that gap is exactly what this article is about.
What decides storage is the combination of the data retention mode set on your account (or project) and the conditions defined for each model. Looking at only one side doesn't settle it.
What is a data retention mode?
A data retention mode is a setting that controls how Bedrock treats your inputs and outputs. There are five modes:
| Mode | Is data retained? | Notes |
|---|---|---|
none |
No | ZDR. Nothing is shared with the provider either. Models that require retention become unusable. |
default |
Depends on the model | Models that were already ZDR stay ZDR. However, AWS may retain data for safety checks and abuse detection. |
aws_review |
Yes, inside AWS | AWS may review data manually. Required by some models. Nothing is passed to the provider. |
provider_data_share |
Effectively same as aws_review
|
Legacy. Data is no longer actually shared with providers. For new settings, use aws_review. |
inherit |
Doesn't decide by itself | Defers to the parent setting or the model's default. This is the initial value for new accounts and projects. |
The modes form an allowance order: none < default < aws_review < provider_data_share. Each model has a minimum — "you need at least this permissive a mode to use me." If your setting doesn't reach a model's minimum, calling it fails with an error, or the model shows up as unavailable in the model list.
Two things make this confusing:
-
The setting is per Region. Setting
nonein one Region does not propagate to others. Regions you never touched stay oninheritand follow the model's default. -
It also works the other way. Even if your account is set permissively, if a model's conditions include
none, that model's data is not retained. Your setting is a ceiling — "I allow up to this much" — not an instruction that makes models start retaining data.
The effective mode is resolved in the order project → account → model default, taking the first value that isn't inherit.
It depends on the model
This is where the title pays off. The answer to "I thought it didn't store anything?" differs by model:
| Model group | How data is retained |
|---|---|
| Most models (e.g., Claude models released before Claude Fable 5) | Not retained. none is available. |
| OpenAI models (except some of the gpt-oss family) | Only inputs/outputs flagged by a classifier are retained, for abuse detection, for up to 30 days. Eligible customers can request full ZDR per account and per model via their AWS account team. |
| Claude Fable 5 / 5.1 | All inputs/outputs are retained inside AWS for up to 30 days, and AWS may review them manually. Requires aws_review (or the legacy provider_data_share); cannot be used with none or default. |
"Another model retains everything" sounds alarming, but for now this is limited to the Fable 5 family, and the data stays inside AWS — it does not go to the model provider. Worth keeping those two things separate.
One more exception to the exceptions: if content is flagged by CSAM (child sexual abuse material) detection, data may be stored and reviewed regardless of your mode.1
none, for when you don't want data retained
If you don't want to allow retention, set the mode to none.
We switched our own account to none as well. For ZDR-capable models, that puts you in a state where data is not retained.
Here is where I initially had it wrong. I thought: "Once I set none, I can switch to any model and still have nothing retained." Not true.
none means: "If using this model would retain data, don't let me use that model."
- Models that are fine with
none(most models) → they keep working, and nothing is retained. - Models that reject
none(GPT-6 Luna, Claude Fable 5, etc.) → your data is never silently retained. Instead, you simply can't call them (you get an error, or they show as unavailable).
The second point is the important one. Bedrock never goes "we'll just keep your data and let you use it anyway." If you don't want retention, it stops you. If you want the model, you change the mode yourself — and only from that point does data get retained, under that model's conditions.
So none is not a magic all-models switch. It is a switch that trades away some models in exchange for nothing being retained.
Trying GPT-6 Luna got me an error
In practice, when I tried the new GPT-6 Luna model, I couldn't use it at first — I got an AccessDeniedException saying the model is not available for this account.
To be precise: the error message itself doesn't mention retention at all. But digging into it, Luna turned out to be a model that doesn't accept none. It is one of the models where only classifier-flagged inputs/outputs are retained, for up to 30 days.
So even when all you want is "let me try the new model," you end up stopping to think about retention settings. Model selection is not just a performance comparison — that was my biggest takeaway this time.
Checking whether a model accepts none
You can check, per model, whether none is available — but how depends on how you call Bedrock.
On Mantle
On the Mantle side, each model exposes its data retention info. The model details include data_retention, with the currently effective mode (mode) and the list of modes the model allows (allowed_modes).
If allowed_modes contains none, the model can be used with ZDR. If it doesn't, you need a more permissive mode to use that model.
On the Runtime side
The Runtime (traditional invocation) side has no per-model retention signal. You set the mode at the account level on the control plane and invoke under that setting.
So the split is: use Mantle when you want to verify per model in advance; use the Runtime-side setting when you want to decide policy for the whole account.
By the way, calls like the embedding model (Titan Text Embeddings V2) and reranking (Rerank 1.0) used by Knowledge Bases are also inference calls in the end. The account mode applies to those behind-the-scenes calls too, not just your chat model — worth knowing before you relax after setting none only for chat.
Checking and changing the mode with the AWS CLI
Because the setting is per Region, don't forget --region:
# Check the current mode
aws bedrock get-account-data-retention --region us-east-1
# Change the mode (example: default, so models like Luna become usable)
aws bedrock put-account-data-retention --region us-east-1 --mode default
# Back to ZDR
aws bedrock put-account-data-retention --region us-east-1 --mode none
For the Fable 5 family you would need --mode aws_review. Note that project-level settings are not available via the CLI; those are Mantle API only.
Further reading
- Data retention - Amazon Bedrock — the official documentation
- get-account-data-retention / put-account-data-retention — the CLI reference for checking and changing the current mode
-
Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies — an AWS blog post on enforcing
noneacross an organization with SCPs
The logs you keep yourself
Here is the easy-to-miss part.
Even with the mode set to none, logs you configured yourself do not stop.
If you enabled model invocation logging that delivers inputs/outputs somewhere, data keeps landing in that destination (S3, CloudWatch Logs) regardless of the data retention mode. "Bedrock keeps nothing, but my own bucket had everything" is a very possible outcome.
Retention periods in CloudWatch, and whether your application logs include prompts, are all on your side of the fence. When you switch to none, reviewing your log destinations and retention periods at the same time is the safer move.
One more quiet pitfall: the store parameter of the Responses API. Under the default mode it leans toward true, and setting store=false does not by itself guarantee ZDR. If you want the guarantee, the official answer is to set the mode to none.
To use newer models well, know how your data is retained
Even if you want to adopt a new model, it is hard to switch when you don't know the conditions around where data is processed and stored.
But lumping everything together as "inference happens abroad, so my data is stored abroad too" narrows your model choices more than necessary. The questions worth separating are:
- Is processing abroad acceptable, or must processing itself stay in-country?
- Even if processing is fine, do you want to avoid storage?
- Does the model you want include
nonein itsallowed_modes? - The logs you enabled: where do they go, and how long do they stay?
- Is the mode set in every Region you actually use?
Separating "processing" from "storage" widens the range of models you can pick from — more than I expected. The opposite, stopping everything at "sounds scary," means new models stay out of reach forever.
So the answer to "I thought Bedrock didn't store our data?" was: "Basically, it doesn't. But there are exceptions depending on the mode and the model — which is why the setting, and checking it, matter." Unglamorous, but knowing this much already makes model selection a lot less confusing.
Sources
- Data retention - Amazon Bedrock: https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html
- Amazon Bedrock abuse detection: https://docs.aws.amazon.com/bedrock/latest/userguide/abuse-detection.html
- Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies: https://aws.amazon.com/blogs/security/enforce-zero-data-retention-on-amazon-bedrock-with-bedrock-projects-and-service-control-policies/
-
Amazon Bedrock's abuse detection documentation states that inputs/outputs classified as potential CSAM may be stored and reviewed to confirm and to report to the relevant authorities. ↩
Top comments (0)