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 them. 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. It was all 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 was “Sydney, and we don’t keep logs”. Both halves turned out to be wrong. The SDK client’s Region setting does say 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. Bedrock model invocation logging was never switched on, but the application’s own debug logs write every prompt into an Amazon CloudWatch Logs log group that has accumulated since launch with no expiry set.

What actually matters

Start with the copies. A generative AI feature makes a lot of them. AWS groups this area under data governance strategies, and names six things inside it: data lifecycles, logging, residency, monitoring, observation, and retention. The first frames the rest. A data lifecycle is the sequence a piece of data moves through: collection, processing, storage, archival, deletion. A conventional application moves 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 representing that chunk, the model’s completion, the log line recording the exchange. Five or six copies of what a student typed, each 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, where the data physically sits. Choosing the Region is the primary control, and for most workloads the only one that matters. A Region’s data centres are in a named country, and data stored there stays there unless something is configured to move it. Two things move it: a cross-Region inference profile that routes the model call elsewhere, and a model the team wants that their own Region does not offer, since calling it where it exists sends prompts there. Both look like ordinary configuration, and neither changes a storage setting.

Retention surprises people, because the defaults pull in opposite directions. Most of these stores keep everything until told otherwise, one keeps nothing until somebody switches it on, and the audit trail expires on a schedule nobody chose. Some need shortening and some need 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 it. Monitoring watches the running system through metrics and alarms: how many invocations, how slow, how often a guardrail intervened. Observation, in the sense the governance list uses, watches the configuration rather than the traffic. A rule evaluates whether the log bucket still has a lifecycle policy attached and 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 stopped being true.

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 an inference profile, a replication rule or a backup move it out of that Region?
3. How long does it survive 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 lifecycle stages and the copies fall out on their own. Collection is the student typing the question. Processing is retrieval pulling two or three passages of coursework from the vector store into the request, and the model call that produces the completion. Storage is everything written down afterwards: conversation history so the student can scroll back, and any log of the exchange. Archival moves the older parts of that somewhere cheaper. Deletion happens only if somebody configures it.

Two copies are less obvious than the rest. The embedding is a numeric representation of a chunk of coursework, and it sits in the vector index until an ingestion run removes it. Deleting the source document from S3 does not remove its vectors by itself; a knowledge base drops them on the next sync of that data source, so a takedown request that only touches the bucket leaves the content retrievable until then. And the retrieved chunk gets a second life inside the prompt, so 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 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, and it comes in two shapes. A geographic profile, carrying a us, eu or apac prefix, routes a request to a Region inside that geography and keeps processing within it. A global profile routes to any commercial Region, worldwide, at about ten per cent off the standard price. Both spread load across more compute than one Region has, and both carry their own cross-Region request and token quotas rather than removing the limit. With no residency obligation, either is an easy improvement. For student data under a state contract, both change the answer to legal’s first question, and this team’s change arrived through a switch that looked like a performance fix.

Two details make that change hard to see. Stored data stays in the source Region either way, so the buckets and the index do not move; the prompts and completions in flight are what leave. And CloudTrail records every cross-Region inference request in the source Region with an additionalEventData.inferenceRegion field naming the Region that processed it, which answers question one with evidence rather than assumption.

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

One service-side copy belongs on the list. Bedrock runs a zero-operator-access, zero-data-retention model by default: operators of the service cannot read model input or output, and inputs and outputs are not stored. Some newer models are the exception. Certain Anthropic Claude and OpenAI GPT models on Bedrock retain traffic for up to thirty days for automated abuse detection, and under cross-Region inference that copy is stored in the Region that processed the request. Retained content stays inside AWS and is not passed to the model provider. An account or project sets its own policy through a data retention mode; a model needing more retention than the mode allows is reported unavailable rather than invoked.

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, tag or size, then applies actions on an age schedule: transition to a cheaper storage class after so many days, expire after so many more. The archival classes are the Amazon S3 Glacier family, which trade retrieval speed for storage cost, so transcripts older than a quarter can move to S3 Glacier Flexible Retrieval and stay readable if an incident review needs them. Expiration ends the lifecycle: after the configured age, S3 deletes the object without anyone doing anything. The rule covers objects already in the bucket, not only new ones. A rule that 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 store log data indefinitely. Setting it to a number of days is one API call, and it applies to events already stored rather than only new ones, though CloudWatch can take up to 72 hours to delete what has expired. This setting most often turns a log group into the longest-lived copy of the prompts, because debug logging is added early, written to a group nobody configured, and forgotten. Any log group that has carried prompt text needs an explicit retention value chosen against the same policy as everything else.

Neither the vector index nor the conversation history is covered by either setting; each is deleted by the sync or the application code that owns it.

The only record of what was said

Logging here has two layers, and confusing them produces an audit trail that answers the wrong thing. 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 records the text, capturing the request and response bodies for each invocation, inline up to 100 KB and as a separate S3 object above that. It is opt-in: nothing is written until it is switched on for the account in that Region. The destination is a bucket or log group you own, in the same account and Region, 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. With it, every prompt and completion is written down in a store that holds them forever unless a lifecycle rule says otherwise. The switch and the retention decision belong in the same conversation; 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 Invocations, InvocationLatency, input and output token counts, and separate counts for client errors, server errors and throttles. Guardrails publishes InvocationsIntervened, the number of requests a guardrail acted on. An alarm catching a tenfold jump in invocations overnight, or a sudden cluster of interventions, is how a change in what students are sending reaches somebody before it reaches the transcript archive. Latency alarms do operational rather than governance work, and they matter here for a different reason: latency is what pushed this team toward the cross-Region inference profile.

Observation of the configuration is AWS Config. A Config rule evaluates a resource against a condition, marks it compliant or non-compliant, and records the result with a timestamp. Managed rules cover the assumptions this workload rests on: s3-lifecycle-policy-check, s3-bucket-server-side-encryption-enabled, cw-loggroup-retention-period-check and cloudtrail-enabled. Each turns a written policy into something that fails visibly when it drifts, and the dated record is what 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 objects in an S3 bucket and reports findings when it detects personal data, 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)	The source Region, or a profile’s destination Region	The role that invokes the model	Not stored, except up to 30 days for abuse detection on models that require it	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	A sync after the source object is deleted; deleting the object alone does not
The completion	Returned to the student, and into conversation history	The student, plus anyone with database access	For as long as that store keeps it	The application’s deletion schedule
The Bedrock invocation log	An S3 bucket or CloudWatch log group you own, same account and Region	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 of management events 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 for ninety days whether that suits anybody or not, one barely at all until somebody opts in, and one for as long as application code says. There is no single retention control for “the AI data” because there is no single place the AI data lives.

The last column matters more in 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. The embeddings and the conversation history are not: a student exercising a deletion right is served by code somebody has to have written, and the way to find out whether it was written is to try it rather than 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 destination Regions the profile can reach satisfy the obligation. There is no third option where it is left switched on and unexamined. If the model the team most wants is unavailable in Sydney, that is a model-selection constraint to resolve at selection time. Then check the one copy the team does not create: whether the model in use retains traffic for abuse detection, and where that copy sits once a profile is routing requests.

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 transitioning to S3 Glacier at ninety days and expiring at the end of the retention period. The debug log group gets an explicit retention in days, today, because it is the longest-lived copy of the prompts and was never a decision. The CloudTrail trail’s bucket gets a longer expiry than everything else, since it records who changed the other settings and is useless if it expires first.

How anyone would notice. One AWS Config rule per assumption: a lifecycle configuration on the transcript bucket, server-side encryption on it, a minimum retention on the log group, CloudTrail enabled. Each goes non-compliant the day somebody removes the thing it watches, and the compliance history is dated evidence rather than a screenshot. On the monitoring side, CloudWatch alarms on invocation count and on guardrail interventions make a change in what students are sending 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 generalises past this workload. A residency claim needs a Config rule; a retention claim needs a lifecycle rule plus a Config rule checking it is still attached; a claim about behaviour needs an alarm. A governance document with none of those behind it describes what the team intended in the month it was written.

Worked example

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

The prompt travels to Bedrock in Sydney, unless the cross-Region inference profile is still switched on, in which case it may be processed elsewhere and question one is already answered wrongly. Retrieval pulls three passages from the week nine reading, held as embeddings 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 at 8.59pm. Conversation history holds the question and the answer. The invocation log, if switched on, holds the full request: 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, and with the Region that processed it. The embeddings and the corpus were read but not changed.

Run the clock forward. At ninety days, the lifecycle rule transitions that log object to S3 Glacier, where it stays readable for an incident review at a lower storage rate. At the end of the academic year, the application’s deletion job removes the conversation history. At the end of the retention period, the expiration action deletes the log object, and that copy is gone without anybody filing a ticket. The CloudTrail record 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’s timestamp is both the alert and, later, the evidence that the gap was found and closed.

What’s worth remembering

1. A generative AI feature leaves a copy at every lifecycle stage (prompt, retrieved chunk, embedding, completion, log line), so every governance answer is per copy rather than for “the data”.
2. Region selection is the primary residency control, and three things move data out of it: a geographic inference profile routing within its geography, a global profile routing anywhere, and a team reaching for a Region where the model they want is available.
3. S3 keeps objects until a lifecycle rule transitions and expires them, and a CloudWatch Logs log group stores data indefinitely by default, which makes an unconfigured debug log group the longest-lived copy of the prompts.
4. Bedrock model invocation logging is opt-in and writes to a bucket or log group you own in the same account and Region; it is the only record of what was asked and answered, so switching it on and setting its retention are one decision.
5. Monitoring is CloudWatch alarms on Invocations, latency and InvocationsIntervened; observation is AWS Config rules that go non-compliant when a bucket’s lifecycle or encryption drifts.
6. Bedrock stores no model inputs or outputs by default and does not pass content to the model provider, but some models retain traffic for up to thirty days for abuse detection, in the Region that processed the request.