An AI agent memory cost comparison can understate the budget when it treats an event, a stored record, and a model call as the same unit. Use this workload worksheet to count each separately, then multiply by rates from a dated official source.
Compare the same conversations, retention windows, and retrieval demand before comparing prices. The worksheet below includes a blank-rate CSV and a worked usage example. Amazon Bedrock AgentCore supplies the documented billing example; its units do not describe every memory provider. Keep extraction inference and supporting infrastructure visible alongside the memory-service subtotal.
Figure 1. AgentCore applies a billing-size clamp to each event written or read. Event storage follows actual bytes. The cap describes billing, not an API payload limit. Source: AWS pricing, checked 18 October 2026.
| Input | Record once | Why it changes the comparison |
|---|---|---|
| InputConversation workload | Record onceEvents written; payload-size distribution; sessions | Why it changes the comparisonAn average payload can hide a per-event billing minimum. |
| InputRaw-event retention | Record onceOpening inventory and hours stored within the estimating month | Why it changes the comparisonA new deployment and an established store have different inventories. |
| InputRetrieval demand | Record onceEvents returned on reads; long-term retrieval requests | Why it changes the comparisonReading a session can return many events. |
| InputExtraction and records | Record onceStrategy; record inventory over time; model usage if separate | Why it changes the comparisonRecord count is an output to measure, not a synonym for event count. |
| InputRate provenance | Record onceRegion, currency, rate date, unit denominator and official URL | Why it changes the comparisonA per-1,000 rate cannot be multiplied by an unscaled count. |
Compare architecture boundaries before rate cards
Choose configurations that satisfy the same recall requirement, then compare their accounting lines. An events-only store cannot replace extracted cross-session facts merely because its bill is lower.
AgentCore's memory guide distinguishes raw conversation events from extracted long-term records. With no strategy, the service stores short-term events only. Built-in strategies extract information such as preferences, facts, summaries, or episodes. Built-in overrides let you supply prompts and select a model that AgentCore invokes in your account.
| Configuration | Count in the budget | Failure mode and prevention |
|---|---|---|
| ConfigurationEvents only | Count in the budgetEvent writes, byte-time storage and event reads | Failure mode and preventionMissing required cross-session recall: define the recall task before treating this as an alternative. |
| ConfigurationBuilt-in strategy | Count in the budgetEvent meters plus stored records and record retrieval | Failure mode and preventionDouble-counted extraction: built-in automatic processing is included; do not invent an extra extraction token bill. |
| ConfigurationBuilt-in with overrides | Count in the budgetMemory meters plus separately charged model usage | Failure mode and preventionOmitted inference: measure extraction and consolidation input/output usage in the account. |
| ConfigurationSelf-managed strategy | Count in the budgetStored records, retrieval and the custom extraction pipeline; event meters where used | Failure mode and preventionMissing pipeline costs: include the model, compute, delivery, temporary storage and retries actually used. |
Figure 2. Processing responsibility changes the budget boundary. The pricing table groups override and self-managed record storage together, but their extraction paths differ.
The self-managed guide describes a custom extraction and consolidation pipeline that writes records through batch APIs. Its documented event-triggered pattern uses S3 payload delivery and SNS notifications. Include those resources when you use that pattern; direct batch-written records should follow their actual ingestion path.
Do not carry a single inferred “records per event” ratio across strategies. Replaying the same input with each selected strategy establishes the record inventory and retrieval behavior you need to budget.
Copy the memory cost worksheet
Fill the quantities first. Keep the rate and cost cells empty until the billing unit, region, and effective date match your selected configuration.
Download the blank-rate memory cost worksheet (CSV). Open it in a spreadsheet and make a copy per configuration. It is an input template; the formulas and worked example below explain the calculation. It contains no live prices or automatic totals.
| Meter | Quantity to calculate | Rate unit to copy |
|---|---|---|
| MeterEvent ingestion | Quantity to calculateSum the billable size of each written event, in GB | Rate unit to copyPer GB ingested |
| MeterEvent retrieval | Quantity to calculateSum the billable size of every returned event, including rereads, in GB | Rate unit to copyPer GB retrieved |
| MeterEvent storage | Quantity to calculateSum actual event GB multiplied by in-period stored hours, then divide by estimating-month hours | Rate unit to copyPer GB-month |
| MeterLong-term record storage | Quantity to calculateSum record-hours, divide by estimating-month hours, then by 1,000 | Rate unit to copyPer 1,000 records/month; select built-in or override/self-managed row |
| MeterLong-term retrieval | Quantity to calculateRetrieve-memory requests divided by 1,000 | Rate unit to copyPer 1,000 retrievals |
| MeterSeparate extraction model | Quantity to calculateMeasured input and output usage for each extraction/consolidation model | Rate unit to copyFrom the selected model rate card; keep token units explicit |
| MeterSupporting resources | Quantity to calculateActual pipeline compute, delivery, temporary storage and retry work | Rate unit to copyEach resource has its own rate card |
These are the units on the AgentCore pricing page, checked 18 October 2026. Event ingestion and retrieval have a 12 KB minimum and 64 KB maximum billable size per event; storage uses actual size and hourly proration. The page lists long-term storage per 1,000 records/month with hourly billing, and retrieval per 1,000 requests. Its short-term rows identify the current consumption units as effective 6 October 2026. Match the effective period if you are reconciling an older bill.
Work a shared workload through the units
Calculate each meter using its own quantity and denominator. For a hypothetical uniform-size cohort, define N as events written, S as actual KB per event, r as complete rereads per event, h as hours each event stays in this estimating month, and H as the hours in that month. Use decimal KB/GB here, as in AWS's published pricing-example arithmetic.
- Billable KB per event:
B = min(max(S, 12), 64). - Ingestion GB:
I = N × B / 1,000,000. - Event retrieval GB:
R = N × r × B / 1,000,000. - Event storage GB-month:
G = N × S × h / (1,000,000 × H). - Record-storage units:
L = total record-hours / (H × 1,000). - Record-retrieval units:
Q = retrieve-memory requests / 1,000.
Hypothetical inputs: 40,000 events of 4 KB each, two complete rereads, and 168 hours stored within a chosen 720-hour estimating month. Separately assume a constant 2,000 long-term records throughout that month and 6,000 record-retrieval requests. These assumptions demonstrate arithmetic; they are not traffic measurements, provider performance, or a recommended retention setting.
| Meter | Substitution | Quantity for the rate row |
|---|---|---|
| MeterIngestion | Substitution40,000 × 12 / 1,000,000 | Quantity for the rate row0.48 GB |
| MeterEvent retrieval | Substitution40,000 × 2 × 12 / 1,000,000 | Quantity for the rate row0.96 GB |
| MeterEvent storage | Substitution40,000 × 4 × 168 / (1,000,000 × 720) | Quantity for the rate row0.037333 GB-month (rounded) |
| MeterRecord storage | Substitution(2,000 × 720) / (720 × 1,000) | Quantity for the rate row2 units of 1,000 records/month |
| MeterRecord retrieval | Substitution6,000 / 1,000 | Quantity for the rate row6 units of 1,000 retrievals |
If pI, pR, pG, pL and pQ are rates in the corresponding units above, the memory-service subtotal is:
C = 0.48 × pI + 0.96 × pR + 0.037333 × pG + 2 × pL + 6 × pQ.
Add separately billed extraction and supporting resources to that subtotal, counting each resource once. Leave the total pending while any applicable rate is unknown. A blank rate means unresolved, not zero cost.
For mixed payload sizes, apply the clamp to each event before summing. For staggered arrivals, count each cohort's hours inside the billing period and include opening inventory. The 720-hour denominator is an estimating assumption; reconcile it against the provider's actual invoice convention. Multiplying all new events by their full TTL can incorrectly assign future-month storage to this month.
Keep event expiry separate from record retention
Track two inventories: raw events and extracted records. Event expiry does not define long-term record retention. Extraction runs asynchronously, so a user read need not happen before record generation.
Figure 3. Both branches can contribute storage in the same period. Rereading an event is separate from retrieving an extracted record.
The create-memory guide allows raw-event retention up to 365 days. It applies event expiry at write time; changing that setting affects future events rather than extending existing ones.
The record TTL guide says long-term records do not expire by default. Strategy-level retention and request-level retention for batch-written records have their own configuration rules. Record the policy used by your actual write path, and measure the inventory it leaves behind. Do not subtract a deletion credit or assume an exact billing cutoff without confirming those terms.
Add the costs outside persistent memory
A usable budget includes separately billed extraction, pipeline operation, and the resources that call the memory service. Keep runtime RAM, observability telemetry, and the agent's answer-generation model in distinct lines, so a memory subtotal can still be compared across configurations.
Record successful work and reprocessing separately; then reconcile them to the bill without counting retries twice. For a self-managed pipeline, check temporary payload retention, notification delivery, compute, and the engineering work needed to monitor and repair extraction. No fixed percentage covers those costs.
The agent observability cost worksheet covers the adjacent telemetry budget. For the distinction between context windows and persistent recall, open A Longer Window Is Not a Memory. That talk record supplies context, not the rates or calculations above. More related records sit under agentic AI.
Method and sources
Updated 18 October 2026. This worksheet maps the current public AWS pricing units to a shared hypothetical workload. The equations are dimensional arithmetic, with explicit estimating assumptions; they do not establish equivalent recall quality or a cheapest provider. The downloadable CSV contains blank inputs and rates.
Official sources checked on that date: AgentCore pricing, memory types, create a memory, built-in strategies, built-in overrides, self-managed strategies, and long-term record TTL.
Open the official rate card while filling the CSV, and retain its date, region and unit beside each rate. Use the page's citation control to reference this method; report a correction if an official source changes. OnlineSummit's methodology explains how source records support the editorial pages.