DynamoDB

If you’ve been using Amazon DynamoDB for a while, you’ve probably noticed something: not all your data gets the same attention. Some of it is “hot” — frequently accessed, constantly updated. But a lot of it is “cold” — just sitting there, costing you money every month.

What if you could store that cold data somewhere cheaper without changing your code or losing availability?

That’s exactly what DynamoDB Standard-IA (Infrequent Access) is for. In this post, we’ll break down what it is, how it works, how it can save you money, and when it might not be the best idea.

Recap on previous post:

• AWS: DynamoDB & DAX Cost Factors
• AWS: DynamoDB Basics

DynamoDB Table Classes

DynamoDB offers different table classes to optimize costs based on your access patterns:

1. Standard – For data you access frequently.
   • Designed for low-latency access any time.
   • Best for your main, active application data.
   • The default table class when you create a new DynamoDB table.
   • Suitable for most workloads. Provides high availability and durability.
2. Standard-IA (Infrequent Access) – For data you rarely read or write.
   • Designed for data that is not accessed often but needs to be available when needed.
   • Offers lower storage costs compared to Standard.
   • Higher retrieval costs, so it’s best for data that you access less than once a month.

Both table classes work exactly the same way from a developer’s point of view:

• Same APIs
• Same queries
• Same AWS Console experience

The only difference? How AWS stores it behind the scenes and how much you pay.

What is Standard-IA?

Standard-IA is a table class designed for data that you access infrequently. It’s like a storage locker for your cold data — it’s still there when you need it, but it costs less to keep it around.

Think of it like moving your old books to a basement shelf:

• They’re still yours.
• You can still get them any time.
• But they’re not taking up expensive prime shelf space.

How can it save you money?

The main savings come from storage pricing:

That’s about 60% cheaper for storage.

Example: If you have 100 GB of archived order history:

• Standard = ~$25/month
• Standard-IA = ~$10/month

💡 That’s $15/month saved — or $180/year — just for one table.

The Catch

But it’s not all sunshine and rainbows. There are some important trade-offs to consider:

• Retrieval Costs – Around $0.01 per GB each time you read data from IA.
• Minimum 30-Day Storage Billing – You pay for at least 30 days even if you delete earlier.
• Not for Hot Data – If accessed often, retrieval fees can eat up savings.
• Whole-Table Setting – You can’t mix Standard and IA in one table.

Best Practice before Switching

• Check Access Patterns — Use CloudWatch metrics to see how often the table is read.
• Move Predictable Cold Data — Avoid sudden spikes in retrieval.
• Test on a Smaller Table First — See if retrieval costs are low enough to justify the switch.
• Combine With TTL — Automatically delete expired data to save more.

DynamoDB Standard-IA is like a budget-friendly storage locker for data you still need but rarely touch. It can cut storage costs by more than half — but only if you choose the right workloads.

Rule of thumb: If it’s predictable, cold, and still worth keeping — IA is your friend.

We discussed about DynamoDB in previous post, but let’s dive deeper into the cost factors associated with DynamoDB and its accelerator, DAX (DynamoDB Accelerator).

Recap

• Amazon DynamoDB (DDB) is AWS’s fully managed NoSQL database service, designed for applications that require consistent performance at any scale.

• Amazon DynamoDB Accelerator (DAX) is an in-memory caching service for DynamoDB. Think of it as a turbocharger — it reduces read latency from milliseconds to microseconds by storing frequently accessed data in memory.

Together, DDB and DAX can significantly improve application performance — but they also come with different cost models you’ll want to understand before adopting.

When to Use DAX?

DAX is particularly useful when:

• Your workload has high read traffic with repeated queries for the same items.
• You want microsecond read latency for real-time user experience.
• You aim to offload read traffic from DynamoDB to reduce provisioned read capacity usage.

Example: A database for AI model training, where the same training data is accessed repeatedly.

Skip DAX when:

• Your workload is write-heavy with low read repetition.
• Your queries are strongly consistent (DAX only supports eventually consistent reads).
• Your access patterns are highly dynamic and unpredictable — the cache hit rate might be low.

Understanding DynamoDB Costs

DynamoDB costs come from three main areas:

• Reading Data
  • Imagine a reading allowance — every time you check a page from a book, it uses part of your allowance.
  • You can either pay per read (On-Demand) or buy a monthly “reading subscription” (Provisioned) if you know your usual usage.
• Writing Data
  • Adding or updating books also uses an allowance — think of it as your “writing subscription” or “per-write” payment.
• Storing Data
  • This is your bookshelf space.
  • Regular storage (Standard) is always ready but costs more.
  • Cheaper storage (Standard-IA) is for books you rarely read, but you’ll pay a small fee each time you take one.

Extras You Might Pay For:

• Backups — like taking daily photos of your bookshelf.
• Copies in other regions — like having the same library in multiple cities.

Understanding DAX Costs

5. DAX Costs DAX pricing is per node-hour, depending on node type:

• Smallest node (dax.t3.small) is the cheapest, suitable for dev/test.
• Larger nodes (dax.r5.large, etc.) cost more but handle higher throughput.
• DAX clusters require at least 3 nodes for fault tolerance in production.

Note: DAX charges are separate from DynamoDB — even if your reads come from the cache.

Cost Comparison

If your cache hit rate is low, DAX might increase costs without much benefit.

Final Thoughts

• Use DAX if you have heavy, repeated reads and need lightning-fast results.
• Use Standard-IA storage for rarely accessed data — but don’t forget the retrieval cost.
• Always measure first: monitor read/write usage and cache hit rates before committing.

Datastore is always a crucial part of any application, and choosing the right database can significantly impact your application’s performance, scalability, and maintainability. In this post, we’ll explore AWS DynamoDB.

Database Types

There are two main types of databases:

• Relational Databases (RDBMS): These databases use structured query language (SQL) and are designed to handle structured data with predefined schemas. Examples include MySQL, PostgreSQL, and Oracle.
• NoSQL Databases: These databases are designed to handle unstructured or semi-structured data. They provide flexibility in data modeling and can scale horizontally. Examples include MongoDB, Cassandra, and DynamoDB.

If you’re coming from MySQL or PostgreSQL, imagine removing JOINs and replacing rows with JSON-like documents stored under a single key.

Key Features of DynamoDB

• Fully Managed: DynamoDB is a fully managed service, meaning AWS handles the operational aspects such as hardware provisioning, setup, configuration, and scaling.
• Performance at Scale: It automatically scales up and down to adjust for capacity and maintain performance.
• Flexible Data Model: Supports key-value and document data structures, allowing for a variety of use cases.
• Built-in Security: Offers encryption at rest and in transit, along with fine-grained access control.

So, what is DynamoDB? DynamoDB is a fully managed NoSQL database service provided by AWS that offers fast and predictable performance with seamless scalability. It is designed to handle large amounts of data and high request rates, making it ideal for applications that require low-latency data access.

Key Concepts

• Tables: The primary structure in DynamoDB, similar to tables in relational databases. Each table has a primary key that uniquely identifies each item.
• Items: Individual records in a table, similar to rows in a relational database.
• Attributes: The data fields in an item, similar to columns in a relational database.
• Primary Key: Uniquely identifies each item in a table. It can be a simple primary key (partition key) or a composite primary key (partition key and sort key).
• Indexes: Allow for efficient querying of data. DynamoDB supports both global secondary indexes (GSI) and local secondary indexes (LSI).

A simple item in a DynamoDB table might look like this:

{
  "UserId": "12345", # Unique identifier for the user. Primary key.
  "Name": "Hazriq",
  "Email": "hazriq@example.com"
}

Benefits of Using DynamoDB

• Scalability: Automatically scales to handle large amounts of data and high request rates without manual intervention.
• Performance: Provides low-latency data access, making it suitable for real-time applications.
• Flexibility: Supports various data models, allowing developers to choose the best fit for their application.
• Cost-Effective: Pay-as-you-go pricing model, where you only pay for the resources you use, making it cost-effective for applications with variable workloads.
• Integration with AWS Services: Seamlessly integrates with other AWS services like Lambda, API Gateway, and CloudWatch for monitoring and logging.
• TTL (Time to Live): Automatically deletes expired items, helping manage storage costs and data lifecycle.

Performance Considerations

• Provisioned Throughput: You can specify the read and write capacity units for your table, which determines how many reads and writes per second your table can handle.
• On-Demand Capacity: Automatically scales to accommodate workload changes, making it suitable for unpredictable workloads.
• Caching: Use DynamoDB Accelerator (DAX) for in-memory caching to improve read performance for read-heavy workloads.
• Batch Operations: Use batch operations for efficient processing of multiple items in a single request, reducing the number of round trips to the database.

Without DAX

• Reads and writes are directly from the DynamoDB table.
• Each read or write operation incurs a latency based on the network and DynamoDB’s processing time.

With DAX

• DAX acts as an in-memory cache, reducing the latency for read operations.
• DAX handles cache misses by fetching data from DynamoDB and storing it in memory for subsequent requests.
• This significantly speeds up read operations, especially for frequently accessed data.

When not to Use DynamoDB

While DynamoDB is a powerful tool, it may not be the best fit for every use case. Here are some scenarios where you might consider alternatives:

• Complex Queries: If your application requires complex queries with multiple joins or aggregations, a relational database might be more suitable.
• Transactional Support: If your application requires complex transactions involving multiple items or tables, consider using a relational database or a database that supports multi-item transactions.
• Large Binary Objects: If your application needs to store large binary objects (BLOBs), such as images or videos, consider using Amazon S3 for storage and DynamoDB for metadata.
• High Write Throughput: If your application requires extremely high write throughput, consider using Amazon S3 or a distributed database like Apache Cassandra.

DynamoDB shines when you need a fast, scalable, and fully managed database that just works — whether you’re powering a real-time leaderboard, handling millions of API requests, or storing user sessions with minimal latency. By understanding its core concepts and performance features like DAX, you can unlock a powerful tool that fits right into modern, serverless-first architectures.

Of course, like any tool, it’s not a one-size-fits-all solution. Knowing when and how to use DynamoDB effectively is key — and that journey starts with grasping its strengths.