DynamoDB TTL: Free Automatic Item Deletion to Reduce Storage Cost

DynamoDB TTL deletes expired items without consuming write capacity in the Region where expiry occurs. Replicated TTL deletes in Global Tables incur replicated write charges in each replica Region. Storage remains billable until items are removed. Pricing examples below use US East (N. Virginia), checked October 15, 2026, before tax and free-tier allowances unless stated.

TTL also removes expired items from indexes. If deletion reduces average billable Standard storage by 10 GB for an entire month, the storage saving is $2.50 at $0.25/GB-month. Maintaining that reduction for all 12 months saves $30. A table growing by 10 GB each month has a changing baseline and cannot be assigned the same fixed annual saving without modeling retention and timing.

What Exactly Is Free About DynamoDB TTL?

DynamoDB TTL pricing has a simple structure: the deletion operation itself costs nothing. Here is the complete DynamoDB TTL cost breakdown.

Action	WCU/WRU Cost	Storage Cost	Streams Cost	Notes
TTL deletes expired item	$0.00 (free)	Removed after deletion	Stream record created (free for Lambda)	Uses backend capacity, not your provisioned/on-demand
TTL removes item from GSI	$0.00 (free)	Removed after deletion	N/A	All GSIs and LSIs cleaned automatically
Expired item in deletion-delay window	$0.00 (no write)	Still billed until deleted	N/A	Appears in reads, queries, scans
Reading expired (not yet deleted) item	Normal RCU/RRU consumed	Still billed	N/A	Filter expressions needed to exclude
Manual BatchWriteItem delete (alternative)	1 WRU per 1 KB item	Removed after deletion	Stream record created	Consumes your provisioned/on-demand capacity

The key distinction: DynamoDB TTL uses internal backend capacity for deletions, not your table’s provisioned or on-demand throughput. This is why TTL deletions are free. Manual deletions through the API (DeleteItem, BatchWriteItem) consume your WCU/WRU at standard rates.

How Much Does DynamoDB TTL Save on Storage Costs?

The DynamoDB TTL cost savings scale directly with the amount of expired data your tables accumulate. Here is the savings calculation at five different data volumes.

Average billable GB avoided each month	Standard Storage Saved	Standard-IA Storage Saved	Annual Savings (Standard)	Annual PITR savings	Total Annual (Standard + PITR)
1 GB	$0.25	$0.10	$3.00	$2.40	$5.40
10 GB	$2.50	$1.00	$30.00	$24.00	$54.00
50 GB	$12.50	$5.00	$150.00	$120.00	$270.00
100 GB	$25.00	$10.00	$300.00	$240.00	$540.00
500 GB	$125.00	$50.00	$1,500.00	$1,200.00	$2,700.00

The PITR backup savings are the hidden multiplier that most DynamoDB TTL cost guides miss. PITR charges $0.20 per GB-month based on your table’s size. Every GB of expired data that TTL removes also reduces your PITR bill. For a table with PITR enabled, the combined storage + PITR savings from DynamoDB TTL are $0.45 per GB-month ($0.25 storage + $0.20 PITR), almost doubling the effective savings.

A steady 500 GB reduction in billable Standard table storage and PITR size saves $225 per month, or $2,700 over 12 months at that same reduction. This is a steady-state comparison, not the saving from deleting a new 500 GB every month. Include any replica-write, archival and consumer costs separately.

 

Also read: DynamoDB Free Tier: 25 GB + 25 WCU + 25 RCU Always Free

How Does DynamoDB TTL Compare to Manual Deletion Methods?

If you do not use DynamoDB TTL, the alternative is deleting items manually through the API. Here is the cost comparison between TTL and the three manual approaches.

Deletion Method	WCU/WRU Cost (10M items, 1 KB)	Engineering Effort	Deletion Timing	Best For
DynamoDB TTL	$0.00 (free)	One-time setup (minutes)	Typically within a few days; no guaranteed deadline	All time-based expiration
BatchWriteItem (on-demand)	$6.25 (10M × $0.625/M)	Custom script + scheduling	Immediate	Immediate deletion required
BatchWriteItem (provisioned)	$1.90 for 4 WCUs × 730 hours × $0.00065/WCU-hour	Custom script + capacity planning	Spread evenly over the modeled month	Controlled throughput deletion
Lambda + Scan + Delete	Scan RCU + Delete WCU + Lambda	Lambda function + CloudWatch Events	Scheduled (hourly/daily)	Complex expiration logic
Export + Reimport (skip expired)	$0.25/GB round-trip	S3 pipeline + table swap	Hours (migration window)	One-time massive cleanup

For 10 million deletes of items up to 1 KB, Standard on-demand write charges are $6.25. An illustrative continuously provisioned four-WCU cleanup allocation costs $1.898 per 730-hour month and can process up to 10.512 million one-WCU deletes if evenly utilized. Bursts, scans, indexes, other writes and capacity headroom change that result. TTL avoids the originating deletion write charge; Global Table replica charges still apply.

Corrected deletion-cost comparison: originating TTL deletes $0; 10 million on-demand one-WRU deletes $6.25; illustrative four-WCU monthly allocation $1.90. Other charges and assumptions are described above.

What Is the Deletion-Delay Deletion Window and Why Does It Cost You Money?

DynamoDB TTL does not delete items instantly at the expiration timestamp. The TTL background process runs continuously but deletion typically occurs within a few days, without a guaranteed deadline of the item’s expiration time. During this window, expired items remain in your table and continue to incur costs.

Storage Cost During the Window

Expired items remain billable while awaiting deletion. A persistent average backlog of 10 GB costs $2.50 per month at the Standard storage rate. If those 10 GB exist for only two days in a 30-day month, their prorated storage charge is about $0.17. Measure the average backlog; AWS does not guarantee a two-day cleanup deadline.

Read Cost During the Window

Expired items appear in Query and Scan results until they are actually deleted. If your application reads these items without filtering, you consume RCU/RRU for data your application does not need. If a scan evaluates 50 GB of active data plus 5 GB of expired data, it evaluates 55 GB total. Read-unit billing also depends on item sizes and consistency; filtering after the read does not avoid those read charges.

The Filter Expression Solution

Add a filter expression to every Query and Scan that excludes items where the TTL attribute is less than or equal to the current Unix epoch timestamp. This prevents expired items from appearing in results. However, filter expressions are applied after DynamoDB reads the data, so you still pay for the RCU consumed to read the expired items before filtering. The filter reduces the result set size (saving network transfer and application processing) but not the RCU consumed.

An index does not automatically remove entries when a timestamp expires. A sparse-index design requires application-maintained membership and may add write charges. Do not assume it eliminates expired-item read cost without implementing and measuring that behavior.

How Do DynamoDB TTL Stream Deletions Affect Downstream Costs?

When DynamoDB TTL deletes an item, the deletion generates a stream record in DynamoDB Streams. This DynamoDB TTL stream record is marked with a special identifier: userIdentity.type = “Service” and userIdentity.principalId = “dynamodb.amazonaws.com”. This distinguishes TTL deletions from application-initiated deletions.

The DynamoDB TTL stream cost impact depends on your consumer architecture:

Lambda Consumers

Standard Lambda-trigger reads from DynamoDB Streams have no Streams read charge; Lambda Managed Instances are an exception. In a modeled month with 5 million records, batches of 100 produce 50,000 invocations. At 128 MB, 50 ms per invocation and first-tier x86 rates, request cost is $0.01 and duration cost is about $0.00521, totaling about $0.01521 before free-tier allowances, retries, logs and other services. Real batches and durations must be measured.

If your Lambda consumer only cares about application writes (not TTL deletions), add a filter expression to the event source mapping: {“eventName”: [“INSERT”, “MODIFY”]}. This prevents TTL DELETE events from invoking your function at all, eliminating the Lambda execution cost for TTL deletions.

Custom Consumers

For ordinary paid Streams reads, the US East (N. Virginia) rate is $0.02 per 100,000 GetRecords calls after applicable allowances. A call can return multiple records, so TTL record count alone does not establish the bill. Use metered calls and verify the consumer-specific pricing.

Also read: DynamoDB Contributor Insights Pricing

How Should You Configure DynamoDB TTL for Maximum Cost Savings?

Step 1: Choose the Right TTL Attribute

The TTL attribute must be a top-level attribute of type Number containing a Unix epoch timestamp in seconds (not milliseconds). Common choices: ‘expiresAt’, ‘ttl’, ‘expiration’. If your items already have a timestamp attribute in a different format (ISO 8601, milliseconds), you need to add a separate epoch-seconds attribute for TTL. DynamoDB ignores items where the TTL attribute does not exist, is not a Number type, or contains a timestamp more than 5 years in the past.

Step 2: Enable TTL on the Table

Navigate to the DynamoDB console, select your table, go to Additional settings, and enable Time to Live. Specify the TTL attribute name. Alternatively, use the AWS CLI: aws dynamodb update-time-to-live –table-name YourTable –time-to-live-specification “Enabled=true, AttributeName=expiresAt”. Enabling TTL is asynchronous; confirm the table status and monitor actual deletion progress. Expiry does not guarantee immediate deletion.

Step 3: Set TTL Values on Items

When writing items, compute the expiration timestamp and include it in the TTL attribute. For a session that should expire in 24 hours: expiresAt = current_epoch_seconds + 86400. For a cache entry expiring in 1 hour: expiresAt = current_epoch_seconds + 3600. For items that should never expire, either omit the TTL attribute entirely or set it to a far-future timestamp (e.g., epoch for year 2099).

Step 4: Add Filter Expressions to Reads

Update all Query and Scan operations to include a filter expression: FilterExpression = ‘#ttl > :now’ with ExpressionAttributeNames = {‘#ttl’: ‘expiresAt’} and ExpressionAttributeValues = {‘:now’: current_epoch_seconds}. This prevents expired-but-not-yet-deleted items from appearing in your results.

Step 5: Configure Streams Filters (If Using Lambda)

If your Lambda consumer should not process TTL deletions, add an event source mapping filter: FilterCriteria = {“Filters”: [{“Pattern”: “{\”eventName\”: [\”INSERT\”, \”MODIFY\”]}”}]}. This excludes all DELETE events, including both TTL and application-initiated deletes. If you need application deletes but not TTL deletes, filter on the userIdentity field instead.

What Are the Best Use Cases for DynamoDB TTL Cost Savings?

Session Stores

Session data is a useful TTL candidate, but compare average retained storage over the same period. At $0.25/GB-month, reducing billable average storage from 60 GB to 4 GB saves $14/month. It saves $168 over a year only if that 56 GB difference holds for all 12 months; a growing no-TTL baseline needs a separate month-by-month calculation.

Event Logs and Audit Trails

For a modeled 15 GB/month ingest rate, a six-month no-TTL snapshot contains 90 GB. Comparing it with a measured 16 GB retained footprint gives (90 − 16) × $0.25 = $18.50 in storage savings for that month. Multiplying by 12 gives a constant-footprint annual scenario, not the actual first-year saving while the baseline grows.

Cache Tables

DynamoDB is sometimes used as a durable cache layer. Cache entries with a 1-hour TTL are naturally high-volume and short-lived. TTL keeps the table small by automatically removing stale cache entries, preventing unbounded table growth that would increase both storage and PITR backup costs.

Temporary Tokens and One-Time Codes

Temporary tokens can be removed after application expiry. For example, avoiding a sustained 1.4 GB of billable Standard storage saves $0.35/month before allowances. Estimate the retained footprint from actual item sizes, per-item overhead, retention and measured deletion backlog; a one-hour TTL does not guarantee a one-hour storage lifetime.

How Does DynamoDB TTL Interact with the Archival Pattern (TTL + Streams + S3)?

For data that must be deleted from DynamoDB for cost reasons but retained for compliance, the DynamoDB TTL stream archival pattern captures expired items before they disappear.

How the Pattern Works

1. Enable DynamoDB TTL on the table with the appropriate expiration timestamp. 2. Enable DynamoDB Streams with NEW_AND_OLD_IMAGES view type (to capture the full item before deletion). 3. Create a Lambda function triggered by the stream that filters for TTL DELETE events (userIdentity.type = Service). 4. The Lambda function writes the expired item data to an S3 bucket (or S3 Glacier for long-term archival). 5. The expired item is automatically deleted from DynamoDB by the TTL process.

Archival Pattern Cost

Estimate the complete pipeline: Lambda requests and duration, S3 PUT or transition requests, stored bytes and object overhead, minimum storage duration, retrieval, transfer, encryption and monitoring. Batch small records into larger objects where appropriate. One S3 object per item can make request and minimum-size charges dominate.

As a storage-only illustration, 10 GB of sufficiently large S3 Glacier Instant Retrieval objects costs $0.04 per month at $0.004/GB-month, before the 128 KB minimum billable object size and 90-day minimum storage duration. This is not a $0.04 total archival bill. Avoiding the same 10 GB of Standard DynamoDB storage plus PITR saves $4.50/month before allowances, so net savings are $4.50 minus the complete archival cost.

For a steady 500 GB, the storage-only difference is $125 DynamoDB Standard minus $2 Glacier Instant Retrieval = $123/month. The $1,476 annual figure assumes the same footprint for 12 months and excludes all pipeline, request, retrieval and retention effects. It must not be presented as verified net savings. See AWS S3 pricing.

How Does DynamoDB TTL Fit into the Broader DynamoDB Cost Optimization Strategy?

DynamoDB TTL is a table-level cost optimization that reduces storage and backup costs. It works independently of the capacity mode and reserved capacity decisions, making it a complementary optimization that stacks on top of throughput savings.

Here is where DynamoDB TTL fits in the cost optimization hierarchy:

1. Capacity mode selection: compare actual request usage with paid provisioned hours. 2. Reserved capacity (for provisioned mode): up to 54% for one year or 77% for three years on eligible provisioned capacity, depending on the quote and utilization. 3. Item size optimization: 1-3x cost multiplier on reads/writes.
2. DynamoDB TTL: Direct storage cost reduction ($0.25-0.45/GB-month including PITR). 5. Table class selection (Standard vs Standard-IA): Up to 60% storage savings for remaining data. 6. Eventually consistent reads: 50% read cost reduction.

DynamoDB TTL is the highest-impact storage optimization because it eliminates data entirely rather than just storing it more cheaply. Standard-IA reduces the rate you pay per GB; TTL removes the GB completely.

After DynamoDB TTL reduces your table size and your traffic patterns stabilize, the provisioned capacity and reserved capacity decisions become the primary cost levers. Usage.ai Flex Reserved Instances automate the reserved capacity purchasing for DynamoDB, analyzing your read and write consumption patterns (on the now-smaller, TTL-optimized table) and purchasing reserved capacity blocks where utilization justifies the commitment.

The platform refreshes analysis every 24 hours versus AWS Cost Explorer’s 72+ hour cycle. If a reservation becomes underutilized, Usage.ai provides cashback and credits on the unused portion. The fee is a percentage of realized savings only.

See how much you can save on DynamoDB with Usage.ai

How Do DynamoDB TTL and Standard-IA Table Class Work Together?

DynamoDB TTL and Standard-IA table class are complementary storage optimizations. TTL removes expired data entirely. Standard-IA reduces the cost of storing the data that remains. Combining both produces the maximum storage cost reduction.

Use the same components on both sides. In this illustrative snapshot, the no-TTL table has 500 GB and the TTL table has 150 GB. Assume Standard throughput costs $10/month and the same request mix costs $12.50/month on Standard-IA; these throughput amounts are scenario inputs, not a universal premium. Free allowances are excluded.

Scenario	Storage	PITR	Throughput	Total/month	Saving vs baseline
500 GB Standard, no TTL	$125.00	$100.00	$10.00	$235.00	—
150 GB Standard, TTL	$37.50	$30.00	$10.00	$77.50	$157.50 (67.0%)
150 GB Standard-IA, TTL	$15.00	$30.00	$12.50	$57.50	$177.50 (75.5%)

In this model, adding Standard-IA after TTL saves another $20/month. Use actual regional read/write rates and request mix before choosing a table class.

The marginal benefit of adding Standard-IA on top of TTL depends on how much data remains after TTL cleanup. For tables where TTL reduces storage to under 25 GB, the Standard class free tier (25 GB free) is more valuable than Standard-IA pricing. For tables that remain above 100 GB after TTL, Standard-IA adds meaningful additional savings.

What Is the DynamoDB TTL Cost Savings Operational Checklist?

Use this checklist when evaluating and implementing DynamoDB TTL across your account.

Discovery Phase

Identify all DynamoDB tables with time-series or temporary data by reviewing table names and schemas for timestamp attributes. Check each table’s TableSizeBytes metric in CloudWatch to quantify the storage cost baseline. Calculate the percentage of each table’s data that is older than the desired retention period by sampling items with a Scan limited to a date range. Estimate monthly savings: (expired data GB) x $0.25 (Standard) or $0.10 (Standard-IA) plus (expired data GB) x $0.20 if PITR is enabled.

Implementation Phase

Add the TTL attribute (Unix epoch seconds, Number type) to new items in your application code. Backfill the TTL attribute on existing items using a BatchWriteItem script or DynamoDB import-from-S3 approach if the table is large. Enable TTL on the table through the console or CLI. Add filter expressions to all Query and Scan operations that should exclude expired items. Configure Lambda event source mapping filters if DynamoDB Streams consumers should ignore TTL deletions.

Monitoring Phase

Monitor TableSizeBytes and ItemCount in CloudWatch weekly for the first 30 days after enabling TTL. Compare actual storage reduction against your estimated savings. Check the /aws-dynamodb/imports log group in CloudWatch for any TTL-related errors (rare, but possible for malformed timestamps). Verify that your Streams consumers are not processing an unexpected volume of TTL deletion events. Review your DynamoDB bill in Cost Explorer after the first full billing cycle to confirm the storage cost reduction.

Ongoing Maintenance

TTL requires zero ongoing maintenance after implementation. The only maintenance scenario: if your application changes the TTL attribute name, you must update the table’s TTL configuration to match. Periodically audit tables where TTL was enabled to confirm that the TTL attribute is still being set correctly on new items. Tables where developers stopped populating the TTL attribute will accumulate data indefinitely despite having TTL enabled.

What Are the Common DynamoDB TTL Pitfalls That Increase Costs?

Pitfall 1: TTL Attribute in Milliseconds Instead of Seconds

DynamoDB TTL requires Unix epoch timestamps in seconds. If your application writes milliseconds (e.g., 1714000000000 instead of 1714000000), DynamoDB interprets the value as a timestamp thousands of years in the future and never deletes the item. Your table grows indefinitely with items that should have expired. This is the single most common DynamoDB TTL implementation error.

Pitfall 2: Forgetting to Filter Expired Items in Reads

Expired items remain readable for an unspecified deletion delay. If your application does not add filter expressions to queries, users may see stale or expired data. Worse, every read of an expired item consumes RCU that your application does not need.

Pitfall 3: Not Monitoring TTL Deletion Backlog

DynamoDB does not provide a direct CloudWatch metric for TTL deletion backlog. The closest proxy is comparing your table’s ItemCount (from DescribeTable) against your expected active item count. If the gap grows over time, your TTL deletion process may be falling behind, possibly due to extremely high table activity that consumes the backend capacity used for TTL deletions.

Pitfall 4: Enabling TTL Without Updating Downstream Consumers

If your Lambda function processes DynamoDB Streams and you enable TTL without adding a filter for TTL deletions, every expired item triggers a Lambda invocation. For tables with high expiration rates, this can double or triple your Lambda invocation count, increasing both Lambda costs and downstream processing load.

Pitfall 5: Using TTL for Immediate Deletion Requirements

DynamoDB TTL is best-effort with a deletion-delay window. If your application requires that items be unavailable immediately after expiration (for example, GDPR right-to-erasure), TTL alone is not sufficient. You need either a synchronous DeleteItem call (which consumes WCU) or a combination of TTL plus client-side filtering to ensure expired items are never returned in responses.

 

 

Frequently Asked Questions

1. Is DynamoDB TTL free?

Yes, the deletion operation itself is completely free. DynamoDB TTL does not consume any provisioned or on-demand write capacity units when deleting expired items. You save both the deletion cost and the ongoing storage cost of the removed data. Replicated Global Table TTL deletes incur replicated write charges. Other costs include expired items consuming storage during the deletion delay and Streams records triggering downstream consumers.

 

2. What does TTL mean in DynamoDB?

TTL (Time to Live) is a per-item expiration mechanism. You designate a Number attribute containing a Unix epoch timestamp in seconds. When the current time passes that timestamp, DynamoDB automatically deletes the item within a few days (typically a few days). TTL is enabled at the table level and applies to all items that have the designated TTL attribute.

 

3. Does DynamoDB have TTL?

Yes. DynamoDB TTL is a built-in feature available on all DynamoDB tables at no additional cost. You enable it through the console, CLI, or SDK by specifying a TTL attribute name. TTL works with both capacity modes and table classes; Global Table replica deletes are billed.

 

4. How long does DynamoDB TTL take to delete items?

DynamoDB TTL typically deletes expired items within a few days, without a guaranteed deadline of the expiration timestamp. The exact timing depends on table size and activity level. Items are not deleted instantly at the expiration time. During the deletion window, expired items still appear in reads, queries, and scans and still consume storage costs. Always filter expired items client-side.

 

5. Do TTL deletions appear in DynamoDB Streams?

Yes. Every DynamoDB TTL stream deletion creates a stream record marked with userIdentity.type = Service and principalId = dynamodb.amazonaws.com. Lambda consumers read these for free. Non-Lambda consumers pay $0.02/100K reads. Use event source mapping filters to exclude TTL deletions from Lambda consumers that do not need them.

 

6. Can you set different TTL values for different items?

Yes. DynamoDB TTL is per-item, not per-table. Each item can have a different expiration timestamp in the TTL attribute. A session item might expire in 1 hour (current_time + 3600) while an order history item in the same table might expire in 90 days (current_time + 7776000). Items without the TTL attribute are never expired by TTL.

 

7. Does DynamoDB TTL work with Global Tables?

Yes. TTL works with Global Tables, but with a nuance: the TTL deletion is replicated to all replica regions. If an item expires and is deleted in the primary region, that deletion replicates to all other regions and incurs replicated write capacity or request charges there. DynamoDB TTL stream records for TTL deletions are only identifiable in the region where the deletion originated, not in regions where it was replicated.

 

8. What happens if I update an item’s TTL attribute after it expires?

You can still update expired items that have not yet been deleted by the TTL background process. If you update the TTL attribute to a future timestamp, the item will no longer be eligible for TTL deletion. Use a condition expression when updating expired items to ensure the item has not been deleted between expiration and your update attempt.

Pricing and cost assumptions reviewed October 15, 2026. Sources: AWS TTL behavior and replica billing, DynamoDB pricing, and Lambda pricing.