AgentCore Memory Pricing and TTL: A UK FinOps and UK GDPR Playbook for Agent Memory

What changed

Two Amazon Bedrock AgentCore Memory changes landed in October 2026, and they belong in the same conversation.

1. Consumption-based pricing for short-term memory (announced 12 October 2026). Short-term memory (STM) is no longer a flat rate per event. It is billed on three dimensions:

Long-term memory (LTM) pricing is unchanged. The change applies automatically in every Region where AgentCore Memory is offered, with no configuration needed.

2. Time-to-live for long-term memory records. You can now set how long extracted LTM records are retained before they expire, using recordExpirySpecification. Configuring or removing a TTL needs a new IAM permission: bedrock-agentcore:UpdateMemoryRecordExpirySpecification.

One is a cost lever, the other is a retention lever. For UK teams, retention is also a legal requirement.

Why this matters in the UK

UK GDPR's storage limitation principle says personal data should be kept no longer than necessary for its purpose. Agent memory is full of personal data: names in support chats, account details, preferences extracted into long-term records. Until now, LTM retention in AgentCore needed your own clean-up job. A native TTL makes it something you can declare, review and evidence.

On the cost side, consumption billing rewards some designs and penalises others. You need to re-cost before your next forecast, not after the first bill.

Re-costing STM: a worked example

The arithmetic below uses only the published rates and rounds 1 GB to 1,000,000 KB. It is illustrative, not a quote; check the AgentCore pricing page for your Region.

A support agent writes 1,000,000 STM events a month, each about 2 KB, and each event is read back about three times.

• Ingestion: every 2 KB event bills at the 12 KB minimum, so about 12 GB, or $12.00.
• Retrieval: 3,000,000 reads at 12 KB is about 36 GB, or $7.20.
• Storage: actual size, about 2 GB held for a month, or $0.20.

That is roughly $19.40 a month, and the striking part is that the 12 KB minimum, not the real payload, drives almost all of it.

Now group three turns into one event of about 6 KB. You write about 333,000 events, still billed at 12 KB each, so ingestion drops to about 4 GB, or $4.00, with retrieval falling in step.

What the billing shape tells you

• Tiny events are the expensive pattern. Below 12 KB you pay for space you do not use. Consider writing per exchange rather than per token stream or per tool callback, where it does not harm recall.
• Very large events are capped. Ingestion and retrieval stop at 64 KB billable per event, while storage still bills actual size. Do not treat that as a reason to dump whole documents into STM; it still costs storage and hurts retrieval quality.
• Retrieval is cheap per GB but multiplies. An agent that re-reads the whole session on every turn can make retrieval the biggest line. Read the last few events, not the history.
• TTL controls storage. AWS's own guidance is to manage storage cost with a shorter TTL on memory resources.

The playbook

Step 1: Measure before you redesign

For each agent, pull a week of event counts, average event size and reads per event. Tag memory resources by agent and environment so Cost Explorer can split the bill.

Step 2: Set event-size guardrails

Add a lint or runtime check that flags agents whose median STM event is well under 12 KB, and agents that write more than one event per user turn. Review those first.

Step 3: Write a retention schedule per memory type

The right numbers are a decision for your data protection officer and records policy. The point is to write them down and enforce them with TTL, not leave them implicit.

Step 4: Lock down who can change retention

Because bedrock-agentcore:UpdateMemoryRecordExpirySpecification controls both setting and removing a TTL, treat it like a data-retention admin right.

• Grant it to the platform pipeline role, not to agent execution roles.
• Alert on any call that removes or extends a TTL in production.
• Require a change record for retention changes, the same as a backup policy change.

Step 5: Prove expiry works

In a lower environment, set a short TTL, write test records, and confirm they stop being returned after expiry. Keep the evidence; it answers the auditor's question of how you know.

Step 6: Handle erasure requests separately

TTL is for routine retention. A right-to-erasure request still needs an on-demand delete path for a specific user's records. Make sure that path exists and is tested.

Thirty-day checklist

• STM cost re-forecast per agent using event counts, sizes and reads.
• Event-size guardrail in CI or at runtime.
• Written retention schedule per memory type, signed off by the DPO.
• TTL applied to production LTM, with the update permission restricted and alerted.
• Expiry and erasure both tested, with evidence kept.

Cost and retention used to be separate tickets. With this release they are the same design decision.