Optimizing AWS DynamoDB Costs - 7 Proven Strategies

AWS DynamoDB is a preferred database for serverless applications due to its scalability and performance. However, costs can quickly add up if not properly managed. Our Scale to Zero AWS kit heavily uses DynamoDB to store data while keeping costs minimal. In this comprehensive guide, we'll explore 7 proven strategies to optimize your DynamoDB costs.

Before diving into optimization techniques, let's understand how DynamoDB pricing works to better target our cost-saving efforts.

Understanding DynamoDB Pricing

DynamoDB write and read requests are charged with increments, which is crucial to understand for cost optimization:

Read and write request pricing

Write operations are measured in 1KB increments. Read operations are measured in 4KB increments.

For example:

• Writing an item with 400 bytes: You pay for 1KB
• Writing an item with 1.1KB: You pay for 2KB
• Reading an item with 2KB: You pay for 1 read request unit (4KB)
• Reading an item with 6KB: You pay for 2 read request units (8KB)

note

Write requests are approximately 5x more expensive than read requests in the On-Demand Throughput model.

Operation Type	On-Demand Pricing
Write Request Units (WRU)	$1.525 per million write request units
Read Request Units (RRU)	$0.305 per million read request units

This pricing model makes optimizing your total item size a top priority for cost reduction.

Strategy 1: Use Compression for Large Data

If you store large data objects in DynamoDB, compressing them before storage can significantly reduce your costs. Since you pay for item size on both reads and writes, compression can provide substantial savings.

Implementation example:

import { brotliCompress, brotliDecompress } from 'zlib';

export const compressDataBrotli = async (data: string) => {
  const compressBrotli = promisify(brotliCompress);
  const buffer = Buffer.from(data);
  const compressedData = await compressBrotli(buffer);
  return compressedData;
};

export const decompressDataBrotli = async (data: Uint8Array) => {
  const decompressBrotli = promisify(brotliDecompress);
  const decompressedData = await decompressBrotli(data);
  const urfString = decompressedData.toString('utf8');
  return JSON.parse(urfString);
};

Real-world compression rates can reach up to 70-80% for JSON data, meaning you could potentially reduce a 10KB item to just 2-3KB, cutting your write costs by up to 80%.

tip

For binary data like images or PDFs, consider storing them in S3 instead and keeping only the reference in DynamoDB.

Strategy 2: Optimize GSI (Global Secondary Indexes) Projections

Global Secondary Indexes are powerful but can double your storage costs if not properly configured. By default, GSIs store copies of all attributes from the base table.

Projection types:

• ALL - Copies all attributes (highest cost)
• KEYS_ONLY - Only copies index and primary keys (lowest cost)
• INCLUDE - Only copies specified attributes (balanced approach)

In our AWS Serverless kit, we use GSI for querying users by email. Instead of projecting all attributes, we only project what we need:

mainTable.addGlobalSecondaryIndex({
  indexName: 'GSI1',
  partitionKey: {
    name: 'GSI1PK',
    type: aws_dynamodb.AttributeType.STRING,
  },
  sortKey: {
    name: 'GSI1SK',
    type: aws_dynamodb.AttributeType.STRING,
  },
  projectionType: aws_dynamodb.ProjectionType.INCLUDE,
  nonKeyAttributes: ['PN', 'PL'], // PN = Provider Name, PL = Plan
});

warning

Be careful with KEYS_ONLY projection. If you later need additional attributes, you'll need to recreate the GSI since projection types can't be modified after creation.

By projecting only necessary attributes to GSIs, a typical application can save 30-50% on GSI storage costs.

Strategy 3: Use Short Attribute Names

DynamoDB charges for both attribute values AND attribute names. Using shorter attribute names directly reduces your storage and transfer costs.

Before optimization:

{
  "partitionKey": "user#12345",
  "sortKey": "profile",
  "firstName": "John",
  "lastName": "Doe",
  "emailAddress": "john.doe@example.com",
  "userSignupDate": "2023-01-15T08:00:00Z"
}

After optimization:

{
  "PK": "user#12345",
  "SK": "profile",
  "FN": "John",
  "LN": "Doe",
  "EM": "john.doe@example.com",
  "SD": 1673769600000
}

Notice how we:

• Used abbreviated attribute names (PK, SK, FN, LN, etc.)
• Used epoch time (milliseconds since 1970) instead of ISO date string

This technique can save approximately 5-15% on storage costs depending on your data model, which adds up significantly at scale.

Strategy 4: Use Provisioned Capacity for Predictable Workloads

DynamoDB offers two capacity modes:

• On-Demand: Pay per request (higher per-unit cost)
• Provisioned: Pre-allocated capacity with optional auto-scaling (lower per-unit cost)

For workloads with predictable traffic patterns, Provisioned capacity can save up to 50% compared to On-Demand.

Consider these scenarios:

Scenario	Recommendation
New application with unknown traffic	Start with On-Demand
Stable application with consistent traffic	Switch to Provisioned with auto-scaling
Seasonal/cyclical traffic patterns	Use Provisioned with scheduled capacity

For example, an e-commerce site might increase capacity during Black Friday and reduce it during slower periods.

Strategy 5: Use Item Collections for Related Data

Instead of creating separate items for related data, consider using item collections (items with the same partition key but different sort keys). This approach:

1. Reduces the number of requests by enabling batch gets and transactions
2. Makes more efficient use of read capacity units through query operations

// Instead of separate items:
// Item 1
{
  "PK": "USER#123",
  "SK": "PROFILE",
  "name": "John Doe"
}

// Item 2
{
  "PK": "ORDER#456",
  "SK": "ORDER",
  "userId": "123",
  "amount": 99.99
}

// Use item collections:
{
  "PK": "USER#123",
  "SK": "PROFILE",
  "name": "John Doe"
},
{
  "PK": "USER#123",
  "SK": "ORDER#456",
  "amount": 99.99
}

This pattern allows retrieving all user data with a single Query operation instead of multiple GetItem operations.

Strategy 6: Use TTL for Temporary Data

DynamoDB's Time to Live (TTL) feature automatically deletes items at no additional cost. Use TTL for:

• Session data
• Temporary tokens
• Log entries
• Event records that lose value over time

// Set TTL for a session item
const ONE_HOUR = 60 * 60; // seconds
const expiryTime = Math.floor(Date.now() / 1000) + ONE_HOUR;

const sessionItem = {
  PK: 'SESSION#abc123',
  SK: 'SESSION',
  // UD = User Data
  UD: {
    /* session data */
  },
  TTL: expiryTime,
};

This approach not only reduces storage costs but also eliminates the need for cleanup logic in your application code.

Strategy 7: Use DynamoDB Streams Efficiently

When using DynamoDB Streams to react to data changes:

1. Filter events: Only process the events you need
2. Batch processing: Handle multiple events in a single Lambda execution
3. Use compression for large items in the stream

Real-World Cost Savings Example

One of our clients was experiencing high DynamoDB costs for their user profile system. By implementing these strategies, we achieved:

Optimization	Cost Reduction
Compressing profile data	35% reduction in write costs
Optimizing GSI projections	40% reduction in GSI costs
Using shorter attribute names	8% reduction in storage costs
Switching to provisioned capacity	30% reduction in overall costs
Total savings	Over 45% reduction in monthly bill

The monthly DynamoDB bill decreased from $450 to approximately $245 after implementing these optimizations.

Implementing These Strategies with Scale to Zero AWS Kit

Our Scale to Zero AWS Kit incorporates these best practices out-of-the-box:

• Pre-configured DynamoDB tables with optimized key structures
• Helper functions for data compression and decompression
• Properly configured GSIs with minimal attribute projection
• Flexible capacity mode configuration

If you're building serverless applications on AWS, check out our kit to save both development time and infrastructure costs.

Frequently Asked Questions

How do I choose between On-Demand and Provisioned capacity?

Start with On-Demand for new applications, then analyze usage patterns for at least 2 weeks. If your traffic is predictable with less than 30% variance, switch to Provisioned with auto-scaling to save costs.

Will compression affect my application's performance?

Modern compression algorithms like Brotli have minimal CPU impact. For most applications, the network savings outweigh the slight CPU increase. Our testing shows < 5ms additional latency for items under 100KB.

How many GSIs should I create for optimal cost efficiency?

Limit GSIs to only what's necessary for your access patterns. Each GSI essentially doubles the storage costs for projected attributes. Consider using sparse indexes (where not all items appear) when possible.

How can I monitor my DynamoDB costs effectively?

Use AWS Cost Explorer with resource tags to track costs by table. Additionally, set up CloudWatch alarms for consumed capacity metrics to get notified before costs spike.

Is it better to store large objects in DynamoDB or S3?

Items larger than 100KB are typically more cost-effective to store in S3, keeping only a reference key in DynamoDB. This hybrid approach gives you the benefits of DynamoDB's query capabilities while leveraging S3's lower storage costs.

---

For more on AWS cost optimization, check out our other guides:

• DynamoDB Data Modeling
• UUIDv7 in DynamoDB
• AWS Lambda Misconceptions

Ready to optimize your AWS infrastructure costs? Get our Scale to Zero AWS Kit today and start saving on your serverless applications.