Reduce DynamoDB Storage Costs with Infrequent Access Table Class (2026)

DynamoDB’s Infrequent Access (IA) table class isn’t just a cheaper storage tier; it’s a fundamental shift in how you think about data access patterns, allowing you to save significant money by actively not reading data you rarely need.

Let’s see this in action. Imagine a logging application. We’ve got our primary Logs table with standard provisioned capacity, where we’re writing and reading recent logs frequently.

{
  "TableName": "Logs",
  "KeySchema": [
    {"AttributeName": "log_id", "KeyType": "HASH"},
    {"AttributeName": "timestamp", "KeyType": "RANGE"}
  ],
  "AttributeDefinitions": [
    {"AttributeName": "log_id", "AttributeType": "S"},
    {"AttributeName": "timestamp", "AttributeType": "N"}
  ],
  "ProvisionedThroughput": {
    "ReadCapacityUnits": 10,
    "WriteCapacityUnits": 5
  },
  "BillingMode": "PROVISIONED",
  "TableClassSummary": {
    "TableClass": "STANDARD"
  }
}

Now, we want to archive older logs. Instead of keeping them in the STANDARD class where every read, even infrequent ones, incurs the higher per-GB cost and potentially read capacity costs, we’ll move them to an IA table.

Here’s how you’d create a new table for archived logs using the IA class:

aws dynamodb create-table \
    --table-name ArchivedLogs \
    --attribute-definitions \
        AttributeName=log_id,AttributeType=S \
        AttributeName=timestamp,AttributeType=N \
    --key-schema \
        AttributeName=log_id,KeyType=HASH \
        AttributeName=timestamp,KeyType=RANGE \
    --billing-mode PAY_PER_REQUEST \
    --table-class INFREQUENT_ACCESS

Notice PAY_PER_REQUEST and INFREQUENT_ACCESS. This means you only pay for reads and writes that actually happen, and the storage cost per GB is significantly lower than STANDARD (around 60% less). The key is that you’re designating this table for data that will be accessed less than once a month.

How does this work internally? DynamoDB is smart. For STANDARD tables, it optimizes for low-latency access, keeping data readily available. For INFREQUENT_ACCESS tables, it uses a different storage optimization strategy that’s cheaper per GB but might have a slightly higher access latency (though still within milliseconds, it’s not quite the same as STANDARD). The critical point is that DynamoDB knows you’re using IA and adjusts its internal storage and retrieval mechanisms accordingly, passing the savings on to you.

The mental model to build is one of tiered data. Your hot, frequently accessed data lives in STANDARD tables where performance is paramount and cost is secondary. Your warm or cold data, accessed perhaps for compliance, historical analysis, or rare debugging, moves to INFREQUENT_ACCESS tables where storage cost is the primary concern, and a small potential increase in access latency is acceptable.

Think about a user profile table. You might have a UserProfiles table in STANDARD for active users where you’re constantly fetching their details. But what about inactive users, or historical user data you need to retain for GDPR compliance? That’s a perfect candidate for INFREQUENT_ACCESS. You can set up a nightly process that scans your UserProfiles table, identifies users inactive for 30+ days, and copies their data to a new InactiveUserProfilesIA table, then deletes it from the STANDARD table.

The primary levers you control are:

1. Table Class Selection: Explicitly choose STANDARD or INFREQUENT_ACCESS when creating or updating a table.
2. Data Lifecycle Management: Implement processes to move data between classes based on access patterns and business rules. This is often done with AWS Lambda functions triggered by CloudWatch Events or Step Functions orchestrating DynamoDB scans and writes.
3. Access Pattern Awareness: Understand your application’s read/write patterns. If a table’s data is accessed less than once per month on average, it’s a prime candidate for IA.

A common misconception is that the IA table class is only for archival after data is deleted from a hot table. While that’s a valid strategy, you can also convert an existing STANDARD table to INFREQUENT_ACCESS if its access pattern changes. This is done via the UpdateTable API call. For example:

aws dynamodb update-table \
    --table-name MyOldLogs \
    --table-class INFREQUENT_ACCESS

This operation is asynchronous and can take some time depending on the table size. DynamoDB will gradually transition the data, and you’ll start seeing the storage cost savings once the transition is complete. Your application’s reads and writes will continue to function seamlessly during this process, though you might observe a slight, temporary increase in latency for operations touching data being transitioned.

When you move data to the INFREQUENT_ACCESS table class, DynamoDB doesn’t just apply a different pricing scheme; it re-optimizes the physical storage of that data. Instead of keeping it in highly available, low-latency SSDs optimized for immediate retrieval, it moves it to a more cost-effective storage medium and employs different caching strategies. This is why the storage cost is lower, but it also means that the first read request for a piece of data that hasn’t been accessed in a while might incur a slightly higher latency as DynamoDB retrieves it from its optimized storage. Subsequent reads within a short window will be fast, but the system is designed for infrequent access, not constant, low-latency retrieval of every item.

The next step after optimizing storage costs is to consider optimizing read/write capacity costs with DynamoDB Streams and Lambda.