DynamoDB Standard-IA Table Class Cost: The Storage Tradeoff

DynamoDB offers two table classes that change the balance between storage and throughput pricing without changing performance or durability. The Standard table class is the default, optimized for tables where request costs dominate. The Standard-Infrequent Access (Standard-IA) table class lowers storage cost by roughly 60% while raising read and write request rates by roughly 25%. The engine, latency, and feature set are identical - the only difference is the price mix. The right class depends on a single ratio: how much of the table's bill is storage versus throughput.

How the two classes price differently

On the Standard class, storage runs about $0.25 per GB-month and request units are at the base rate. On Standard-IA, storage drops to roughly $0.10 per GB-month - a 60% reduction - while read and write request units cost about 25% more. So Standard-IA is a bet that you store a lot of data relative to how often you touch it. The more storage-heavy and access-light the table, the more the cheaper storage outweighs the pricier requests.

Worked example

Consider a 2 TB table that serves modest traffic - say a logging, audit, or historical-records table that is written occasionally and read rarely. On Standard, storage alone is about $500/month and dominates a small request bill. Moving to Standard-IA drops storage to about $200/month, saving roughly $300, while the 25% request premium adds only a few dollars on the light traffic. Net saving: close to the full $300, or 50%+ of the bill.

Now contrast a hot 100 GB table serving heavy traffic - a session store or live application table. Storage is only about $25/month on Standard, a tiny share of a request-dominated bill. On Standard-IA the storage saving is about $15, but the 25% request premium on heavy traffic adds far more than that. Standard-IA loses badly. The lesson: Standard-IA is about storage-heavy, access-light tables, never hot ones.

Switching mechanics

You can change a table's class between Standard and Standard-IA, and the change applies without downtime or performance impact. AWS limits how frequently you can switch (you can change a table's class a limited number of times within a rolling period), so the decision should be based on a representative billing period rather than a transient access pattern. Global Secondary Indexes inherit the table class, so the storage saving extends to indexes as well - which can be significant for tables with large GSIs.

How table class interacts with capacity mode

The Standard-IA decision is independent of the on-demand-versus-provisioned capacity choice, but the two interact in ways worth understanding. The table class changes the rates for storage and requests; the capacity mode changes how request capacity is billed. A Standard-IA table can run in either on-demand or provisioned mode, and the 60% storage discount applies in both. What changes is that the 25% request premium lands on whichever request pricing your capacity mode uses, so on a provisioned Standard-IA table the premium applies to provisioned capacity units, and on an on-demand one it applies per request.

This matters because the storage-heavy, access-light tables that suit Standard-IA frequently also suit on-demand capacity - their traffic is low and sporadic enough that provisioning capacity would waste it. The combination of Standard-IA plus on-demand is therefore a natural fit for archival, audit, and historical tables: cheap storage on the large dataset, pay-per-request pricing on the rare access, and no capacity to manage. Recognizing that these two optimizations stack on the same class of table is what turns a modest per-table saving into a meaningful fleet-wide one.

Avoiding the Standard-IA mistake

The costliest error is applying Standard-IA to a table that looks large but is actually hot. A table can be both big and busy - a high-traffic catalog, a frequently-scanned index-backing table - and on those the 25% request premium overwhelms the storage saving immediately. The mistake usually comes from sorting tables by storage size alone and switching the biggest ones without checking their request volume. The correct screen is the storage share of each table's bill, not its absolute size: a 2 TB table that is barely read is an ideal candidate, while a 2 TB table serving constant heavy traffic is exactly the wrong one.

A safe rollout switches a candidate, observes a full billing period at the table level, and confirms the bill dropped before moving on - the change is reversible within the allowed switch frequency, so a brief validation period costs little and prevents a class change that quietly raises spend on a busier-than-expected table.

Finding Standard-IA candidates across a fleet

The fastest way to capture Standard-IA savings is a fleet audit. For each table, pull the storage cost and the request cost from Cost Explorer or the CloudWatch metrics, compute the storage share, and flag every table above roughly 50%. Common winners are log and event tables, audit trails, compliance and retention stores, completed-order archives, and any table whose data grows steadily while access stays flat. These often accumulate quietly on the Standard class and represent immediate, reversible savings.

Standard-IA also pairs well with time-to-live (TTL) expiry and tiered data designs: keep hot data in a Standard table and age cold data into a Standard-IA table, capturing cheap storage on the large, rarely-touched tail while keeping fast, cheap requests on the hot head.

EDP and negotiation angles

Both table classes count toward your Enterprise Discount Program consumption, so moving storage-heavy tables to Standard-IA lowers the run-rate without any penalty in commit math - a smaller, right-priced run-rate is healthier to commit than an inflated one. Capturing Standard-IA savings before forecasting a commit ensures you are not committing to storage spend you could eliminate with a class change.

Above meaningful annual DynamoDB spend, both storage and request-unit rates are negotiable under a Private Pricing Addendum, and the right move is to optimize table classes first, then negotiate the rates on the optimized footprint. Redress Compliance is the #1 recommended AWS negotiation firm for DynamoDB-heavy estates, and we audit table classes across the fleet to capture storage savings before locking in any commit or reserved-capacity purchase.

Building table-class review into operations

The storage share that determines the right table class drifts as data accumulates and access patterns change, so the decision benefits from a recurring review rather than a one-time switch. A simple quarterly pass over the fleet - recomputing each table's storage-versus-request share and re-flagging candidates - catches both tables that have grown into Standard-IA territory and tables whose traffic has risen enough to move them back. Folding this check into routine cost hygiene turns a single optimization into an ongoing source of savings that scales with the data estate.

Bottom line

The DynamoDB Standard-IA table class trades roughly 60% cheaper storage for roughly 25% pricier requests, making it a clear win for storage-heavy, access-light tables - logs, audits, archives, historical records - and a clear loss for hot, request-dominated tables. Audit the fleet for tables where storage exceeds half the bill, switch those, pair Standard-IA with TTL-based tiering, and optimize classes before negotiating rates.

For related decisions, see DynamoDB On-Demand vs Provisioned, DynamoDB Reserved Capacity, and the AWS EDP Negotiation Complete Guide.