Amazon Bedrock AgentCore Memory Pricing Moves to Per-GB

Your agent's memory bill stopped counting events and started counting bytes. AgentCore Memory pricing for short-term memory is now consumption-based. AWS announced the change on October 12, 2026, and the pricing page lists the new per-GB rates as of October 6. Long-term memory pricing is unchanged.

What changed in AgentCore Memory pricing

Short-term memory (the raw events an agent writes during a session) now has three meters instead of one flat per-event rate:

• Ingestion: $1.00 per GB. It was $0.25 per 1,000 new events through October 5.
• Retrieval: $0.20 per GB.
• Storage: $0.10 per GB-month, prorated hourly over each event's time to live (TTL).

Ingestion and retrieval bill every event at a minimum of 12 KB and a maximum of 64 KB, whatever its real size. Storage uses the actual size. The change applies automatically in every Region where AgentCore Memory is offered.

Who saves money: small payloads

The old ingestion rate works out to $0.00025 per event. At the 12 KB floor, the new rate is $0.000012 per event, and at the 64 KB cap it is $0.000064. So ingestion is cheaper at every billable size. This is my arithmetic from the published rates.

AWS's own example uses 100,000 events of 3 KB, one retrieval each, and a 30-day TTL. That comes to $1.20 ingestion, $0.24 retrieval and $0.03 storage, or $1.47. The old rate on ingestion alone would have been $25.00. The docs don't say what the old model charged for retrieval and storage, so compare against your September invoice, not my math.

Here is a small estimator that reproduces AWS's example:

def stm_monthly_cost(events, avg_kb, reads_per_event, ttl_days):
    # Each event is billed at 12 KB minimum and 64 KB maximum for ingest and retrieval
    billable_gb = events * min(max(avg_kb, 12), 64) / 1_000_000
    ingest = billable_gb * 1.00
    retrieve = billable_gb * reads_per_event * 0.20
    # Storage uses actual size, prorated over the TTL
    storage = events * avg_kb / 1_000_000 * 0.10 * (ttl_days / 30)
    return round(ingest + retrieve + storage, 2)

print(stm_monthly_cost(100_000, 3, 1, 30))  # 1.47

This clamps the average size, while AWS clamps each event, so feed it per-size buckets if your payloads vary a lot.

Where the new model can still surprise you

Retrieval is metered per event returned. An agent that reloads the last 30 turns on every message pays for 30 events each time.

Large tool outputs, such as log dumps and ticket attachments, push events toward the 64 KB cap, more than five times the floor.

Storage scales with TTL. AWS says a shorter TTL on the memory resource is the lever, and for short-term events that is eventExpiryDuration, in days, which the UpdateMemory API accepts:

aws bedrock-agentcore-control update-memory \
  --memory-id "<memory-id>" \
  --event-expiry-duration 30

This sets events to expire after 30 days. The docs don't say whether the change reaches events already stored, so test it on a non-production memory first.

Set a TTL on long-term memory records

The same release adds a TTL for long-term records through recordExpirySpecification, set per strategy. The AWS documentation gives these rules:

• recordExpiryDurationDays has a minimum of 31.
• The TTL is applied when a record is generated, so changes affect only new records.
• Deletion can take a few days, and expired records can still be returned meanwhile. Use DeleteMemoryRecord if you need one gone now.

Configuring or removing a TTL needs the new bedrock-agentcore:UpdateMemoryRecordExpirySpecification permission, on top of the base action. Without it you get AccessDeniedException even if UpdateMemory is allowed. The reason is sensible: anyone who can set a short TTL can delete data without holding a delete permission.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageMemoryAndRetention",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:CreateMemory",
        "bedrock-agentcore:UpdateMemory",
        "bedrock-agentcore:UpdateMemoryRecordExpirySpecification"
      ],
      "Resource": "arn:aws:bedrock-agentcore:<region>:<account-id>:memory/*"
    }
  ]
}

Then set the TTL on an existing strategy:

aws bedrock-agentcore-control update-memory \
  --memory-id "<memory-id>" \
  --memory-strategies '{"modifyMemoryStrategies":[{"memoryStrategyId":"<strategy-id>","recordExpirySpecification":{"recordExpiryDurationDays":90}}]}'

Semantic and user-preference strategies in the same memory must share one value, and so must summary and episodic strategies.

What a service-desk agent team should check on Monday

1. Split last month's short-term memory charges into ingestion, retrieval and storage, and compare them with September.
2. Measure real event sizes. Anything over 64 KB is billed at the cap, so trim bulky tool output before it is written.
3. Count how many past events each turn reloads. That number drives retrieval spend.
4. Set eventExpiryDuration to how long a ticket realistically stays open for follow-up, not the number from the demo.
5. Set recordExpiryDurationDays to your retention policy, and give the new permission only to the pipeline role that manages memory, not the agent's runtime role.

Memory cost now follows how much your agent writes and re-reads, so payload size, TTL and retention permissions are production settings that deserve a review instead of staying at their demo defaults.