Deciding Where AI Data Lives and How Long It Stays

The situation

An Australian education provider runs a study assistant for about forty thousand enrolled students. A student asks a question in plain English, the application retrieves the relevant passages from that unit’s course materials, and an Amazon Bedrock model answers using those passages. Course materials sit in an Amazon S3 bucket, the passages are indexed as embeddings in a vector store, and conversation history is held so a student can pick up where they left off. Everything was deployed into the Sydney Region because somebody sensibly assumed that was the Australian one.

The provider is bidding for a state government contract, and legal has sent three questions with a deadline attached.

1. Where does student data physically sit, and can you show that it stays there?
2. How long do we keep the conversation logs, and who decided that?
3. How would we find out if either of those answers stopped being true?

The team’s first draft of an answer was “Sydney, and we don’t keep logs”. Both halves turned out to be wrong. The Region setting in the SDK client says Sydney. But the application was switched to an Amazon Bedrock cross-Region inference profile in June, to get past throttling during a busy assessment week, and nobody checked what that changed. And while Bedrock model invocation logging was never switched on, the application’s own debug logs write every prompt into an Amazon CloudWatch Logs log group that has been accumulating since launch with no expiry set.

What actually matters

Start with the copies, because a generative AI feature is unusually good at making them. AWS groups this whole area under data governance strategies, and names six things inside it: data lifecycles, logging, residency, monitoring, observation, and retention. The first of those is the frame for the rest. A data lifecycle is the sequence a piece of data moves through, from collection, through processing, into storage, then archival, and finally deletion. Traditional applications move one record along that path. A study assistant makes a new copy at almost every step. The student’s prompt, the chunk of coursework retrieved to answer it, the embedding vector representing that chunk, the model’s completion, the log line recording the exchange. Five or six copies of what a student typed, each landing in a different service, each with its own default lifetime. Answering a governance question about “the data” without first listing the copies produces an answer about one of them.

Then residency, which is where the data physically sits. Choosing the Region is the primary control, and for most workloads it is the only one that matters. A Region’s data centres are in a named country, and data stored in a Region stays there unless something is configured to move it. Two things move it. The first is a cross-Region inference profile, Bedrock’s way of spreading load across several Regions in the same geography so a burst does not hit a throttling limit. Requests routed through an Asia Pacific profile can be served from any Region in that geography, which for an Australian obligation is a material difference from Sydney. The second is the temptation that arrives when a model the team wants is not offered in their Region. Reaching for a Region where it is available is a decision about residency, not a workaround, and it needs the same sign-off as any other place student data would be stored.

Retention is the one that surprises people, because the defaults pull in opposite directions. Nothing in S3 deletes itself: an object stays until something removes it, which suits a bucket of teaching material and does not suit a bucket of conversation transcripts. A CloudWatch Logs log group defaults to Never expire, so debug logging switched on for a fortnight during launch is still holding the prompts from launch two years later. Meanwhile a CloudTrail Event history window covers only ninety days, so the record of who changed a setting evaporates on a schedule nobody chose either. Two of these need shortening and one needs extending, and the only way to know which is which is per copy.

The last thing is how anybody finds out that an answer has gone stale. Monitoring and observation cover different halves of that. Monitoring watches the behaviour of the running system through metrics and alarms: how many invocations, how slow, how often a guardrail intervened, and whether any of those moved in a way that suggests the traffic changed shape. Observation, in the sense the governance list uses it, is watching the configuration rather than the traffic. A rule evaluates whether the log bucket still has a lifecycle policy attached and still has encryption enabled, and reports it non-compliant on the day somebody removes one. The first tells you the system is behaving oddly. The second tells you an assumption you wrote down has quietly become false.

What we’ll filter on

1. Which copy is it? Prompt, retrieved chunk, embedding, completion, invocation log, or audit trail. Every answer is per copy.
2. Where does it physically sit, and does anything (an inference profile, a replication rule, a backup) move it out of that Region?
3. How long does it survive by default, with no configuration at all?
4. What actually deletes it, and is that a rule that runs on its own or a person remembering?
5. Who can read it while it exists?
6. How would we notice if any of the four answers above stopped being true?

The landscape

The stages, and the copy each one leaves

Walk one student question through the data lifecycles the feature runs, and the copies fall out on their own. Collection is the student typing the question, which becomes the prompt. Processing is the retrieval step, which pulls two or three passages of coursework out of the vector store and pastes them into the request alongside the question. The model call follows and produces the completion. Storage is everything written down afterwards: conversation history so the student can scroll back, and any log of the exchange. Archival is moving the older parts of that storage somewhere cheaper because it is rarely read but has to be kept. Deletion is the stage that only happens if somebody configures it.

Two copies in that list are less obvious than the rest. The embedding is a numeric representation of a chunk of coursework, and it lives in the vector index for as long as the index does. Deleting the source document from S3 does not remove its embeddings, so a takedown request that only touches the bucket leaves the content retrievable. And the retrieved chunk gets a second life inside the prompt, which means anything sensitive in the corpus travels into every log line that records a request. This is the sharp end of grounding a model in your own documents: the corpus becomes part of the prompt every time one is built.

Where it physically sits

Residency is settled by Region selection, and the Sydney Region is in Australia in the ordinary sense: the buildings are here, and objects written to an S3 bucket there stay there. That is the default and it holds unless something is configured to move data, so the work is finding the things that move it.

Cross-Region inference is the one that catches generative AI workloads specifically. A cross-Region inference profile lets Bedrock serve a request from any Region within a geography, which raises the throughput available during a burst without asking for a quota increase. The geography, not the Region, is the boundary that applies, so an Asia Pacific profile can serve a Sydney application’s request from another Region in Asia Pacific. For a workload with no residency obligation that is a free improvement. For student data under a state contract it is a change of answer to question one, and it happened through a configuration switch that looked like a performance fix.

The other residency trap is model availability. Not every foundation model is offered in every Region, and when the model a team wants is missing from theirs, calling it in a Region where it exists is one line of configuration away. That is not a technical workaround, it is a decision to send prompts to another country, and it needs checking against the obligation before it is made rather than after. Where the obligation is firm, the options are picking a model available locally or getting the obligation changed. Region availability belongs in the model-selection criteria for exactly this reason.

Worth stating plainly, because a reader new to this usually assumes the opposite: Amazon Bedrock does not use your prompts or completions to train the base foundation models, and does not share them with the model provider. The residency work is about the copies you create and store, not about a hidden copy the service takes.

What keeps it, and what deletes it

Retention on Amazon S3 is configured through a lifecycle rule attached to the bucket. A rule matches objects by prefix or tag, then applies actions on an age schedule: transition an object to a cheaper storage class after so many days, and expire it after so many more. The archival classes are the Amazon S3 Glacier family, which trade retrieval speed for storage cost. Transcripts older than a quarter can move to Glacier and cost a fraction of what they did, while staying available if an incident review needs them. Expiration is the action that ends the lifecycle: after the configured age, S3 deletes the object without anyone doing anything. A rule that only transitions and never expires builds a cheaper archive that grows forever.

Retention on Amazon CloudWatch Logs is a single setting on the log group, and its default is to never expire. Setting it to a number of days is one API call and it applies to existing log events, not just new ones. This is the setting that most often turns a log group into the longest-lived copy of the prompts in the whole architecture, because application debug logging is added early, written to a group nobody configured, and forgotten. Any log group that has ever carried prompt text needs an explicit retention value chosen against the same policy as everything else.

The vector index and the conversation history each need their own answer, and neither gets one from the two settings above. Deleting a document from the corpus means deleting it from the bucket and removing or re-indexing its embeddings. Conversation history stored in a database is deleted by whatever that database offers, on a schedule the application owns.

The only record of what was said

Logging in a Bedrock workload has two layers, and confusing them produces an audit trail that cannot answer the question asked of it. AWS CloudTrail records API calls: who invoked a model, from which identity, at what time, and whether it succeeded. It does not record the text. Amazon Bedrock model invocation logging is the feature that records the text, capturing the request and the response for each invocation. It is opt-in: nothing is written until it is switched on for the account in that Region. The destination is a bucket or a log group you own, which puts the transcript inside your own retention and encryption regime rather than the service’s.

That makes invocation logging the copy with the strongest case both for existing and for being short-lived. Without it, nobody can say what the assistant told a student in a disputed exchange, which is a hard position for an education provider. With it, every prompt and completion is written down in a store that will hold them forever unless a lifecycle rule says otherwise. The switch and the retention decision belong in the same conversation, and reaching one without the other is how a service that logged nothing becomes a service that logs everything permanently. The same care applies to the prompts themselves, which are worth versioning and protecting in their own right.

Noticing when an answer stops being true

Monitoring is Amazon CloudWatch metrics with alarms on them. Bedrock publishes invocation counts, latency, token counts and error rates; Bedrock Guardrails publishes how often a guardrail intervened on a request. An alarm on invocation count catching a tenfold jump overnight, or on guardrail interventions catching a sudden cluster of them, is how a change in what students are sending reaches somebody before it reaches the transcript archive. Latency alarms do operational work rather than governance work, and they matter here for a different reason: a latency problem is what pushed this team toward the cross-Region inference profile in the first place.

Observation of the configuration is AWS Config. A Config rule evaluates a resource against a condition and marks it compliant or non-compliant, continuously, and records the result with a timestamp. There are managed rules for exactly the assumptions this workload rests on: that a bucket has a lifecycle configuration, that a bucket has server-side encryption enabled, that a CloudWatch log group’s retention period is at least a set number of days, that CloudTrail is enabled. Each turns a written policy into something that fails visibly when it drifts. The dated record it leaves is the material an assessor wants, which is the difference between a service that watches and one that produces evidence. Amazon Macie sits alongside as the observation of content rather than configuration. It samples a bucket and reports whether personal data is in there, which checks whether the log bucket holds what the team believes it holds.

Evaluation

Side by side

The copy	Where it lives	Who can read it	Kept by default	What deletes it
The prompt (in flight)	Sent to Bedrock in the chosen Region, or the profile’s geography	The application role that invokes the model	Not stored by Bedrock	Nothing to delete unless it is logged
The retrieval corpus	An S3 bucket in the chosen Region	Whoever the bucket policy and IAM allow	Forever	An S3 lifecycle expiration rule, or a manual delete
The embeddings	The vector index, in the chosen Region	The retrieval service role	For the life of the index	Re-indexing or deleting the vectors; deleting the source object does not
The completion	Returned to the student, and into conversation history	The student, plus anyone with database access	For as long as the history store keeps it	The application’s own deletion schedule
The Bedrock invocation log	An S3 bucket or CloudWatch log group you own	Whoever can read that bucket or log group	Nothing at all until logging is switched on; then forever	An S3 lifecycle rule, or a CloudWatch Logs retention setting
The CloudTrail record	Event history, or a trail delivering to S3	Whoever can read the trail’s bucket	90 days in Event history; forever in a trail’s bucket	The 90-day window, or an S3 lifecycle rule on the trail bucket

Read the “kept by default” column down and the shape of the work appears. Three of the six are kept forever. One is kept for ninety days whether that suits anybody or not, one is not kept at all until somebody opts in, and one is governed by application code rather than any AWS setting. There is no single retention control for “the AI data” because there is no single place the AI data lives.

The last column is the more useful one for a governance review, because it separates the copies deleted by a rule that runs on its own from the copies deleted by a person remembering. S3 lifecycle expiration and CloudWatch Logs retention are automatic: configure once and they keep applying. The embeddings and the conversation history are not. A student exercising a deletion right is served by application code somebody has to have written, and the way to find out whether it was written is to try it rather than to read the policy.

The solution

Take the three questions in order, and answer each per copy.

Where it sits. Pin every store to the Sydney Region and write that down as a decision rather than a default, then deal with the inference profile. Either drop back to a single-Region model call and solve the assessment-week throttling with a quota increase, or confirm in writing that the geography the profile covers satisfies the obligation before keeping it. There is no third option where it is left switched on and unexamined, because it changes the answer to legal’s first question. If the model the team most wants is unavailable in Sydney, that is a model-selection constraint to resolve at selection time. Alongside this, note the thing that is already true and does not need building: Bedrock is not training base models on these prompts and is not passing them to the model provider, so the residency work is entirely about the copies the team creates.

How long it stays. One retention decision per row of the table, each recorded with a reason. Course materials in S3 stay for the life of the unit plus the appeals period. Conversation history stays for the academic year, then goes. Bedrock model invocation logging gets switched on, because a provider that cannot say what its assistant told a student is in a worse position than one holding transcripts. Its destination bucket gets a lifecycle rule that transitions to S3 Glacier at ninety days and expires at the end of the retention period. The application’s debug log group gets an explicit retention in days, today, because it is currently the longest-lived copy of the prompts and it was never a decision. The CloudTrail trail’s bucket gets a longer expiry than everything else, since it is the record of who changed the other settings and is useless if it expires first.

How anyone would notice. One AWS Config rule per assumption, so each written statement has a check behind it. A rule that the transcript bucket has a lifecycle configuration. A rule that it has server-side encryption enabled. A rule that log group retention is set to at least the required number of days. A rule that CloudTrail is enabled. Each of those is non-compliant the day somebody removes the thing it watches, and the compliance history it leaves is dated evidence rather than a screenshot. On the monitoring side, CloudWatch alarms on Bedrock invocation count and on guardrail interventions, so a change in what students are sending is visible in hours. Then a Macie scan on the transcript bucket every quarter to confirm the contents match what the team told legal was in there.

The pattern is worth naming, because it generalises past this workload: a residency claim needs a Config rule; a retention claim needs a lifecycle rule, plus a Config rule checking that the lifecycle rule is still attached; a claim about behaviour needs an alarm. A governance document with none of those behind it is a description of what the team intended in the month it was written.

Worked example

A student asks the assistant to explain a concept from week nine, at 9pm on a Tuesday.

The prompt is collected and travels to Bedrock in Sydney, unless the cross-Region inference profile is still switched on, in which case it may be served elsewhere in Asia Pacific and question one is already answered wrongly. Processing retrieves three passages from the week nine reading, which are embeddings the vector index has held since the unit was published, and pastes their source text into the request. The model returns a completion.

Now count what exists that did not exist at 8.59pm. The conversation history holds the question and the answer. The invocation log, if it has been switched on, holds the full request, which includes the three passages of coursework as well as the student’s own words. CloudTrail holds a record that the application role invoked that model at that time, with no text. The embeddings and the corpus were read but not changed.

Run the clock forward. At ninety days, the lifecycle rule on the transcript bucket transitions that log object to S3 Glacier, where it stays readable for an incident review and costs a fraction of what it did. At the end of the academic year, the application’s own deletion job removes the conversation history. At the end of the retention period, the lifecycle rule’s expiration action deletes the log object, and that copy is gone without anybody filing a ticket. The CloudTrail record of the invocation outlives all of it, on purpose, because it names the identity rather than the student.

Now break something. In March, an engineer removes the lifecycle rule from the transcript bucket while debugging a permissions problem and does not put it back. Nothing fails. Transcripts keep arriving and stop expiring, and the first person to notice would otherwise be whoever reads the storage bill eighteen months later. With the Config rule in place, the bucket goes non-compliant that afternoon and the finding carries a timestamp, which is both the alert and, later, the evidence that the gap was found and closed rather than never noticed.

What’s worth remembering

1. A generative AI feature leaves a copy of the data at every stage of its lifecycle (the prompt, the retrieved chunk, the embedding, the completion, and the log line), so every governance answer is per copy rather than for “the data”.
2. Region selection is the primary residency control, and the two things that move data out of it are a cross-Region inference profile serving a request from elsewhere in its geography, and a team reaching for a Region where the model they want is available.
3. Amazon S3 keeps objects forever until a lifecycle rule transitions them to an S3 Glacier class and expires them, while a CloudWatch Logs log group defaults to never expire, which makes an unconfigured debug log group the longest-lived copy of the prompts.
4. Amazon Bedrock model invocation logging is opt-in and writes to a bucket or log group you own, and it is the only record of what was actually asked and answered; switching it on and setting its retention are one decision, not two.
5. Monitoring is CloudWatch metrics and alarms on invocation counts, latency and guardrail interventions; observation is AWS Config rules that go non-compliant when a bucket’s lifecycle or encryption configuration drifts, and a governance claim without one of those behind it has nothing checking it.
6. Amazon Bedrock does not use your prompts or completions to train the base foundation models and does not share them with the model provider, so the residency and retention work is about the copies you create and store.