AWS DynamoDB Best Practices

~ Last updated on : ~ jayendrapatil
Table of Contents hide
AWS DynamoDB Best Practices
Primary Key Design
Secondary Indexes
Large Items and Attributes
Querying and Scanning Data
Time Series Data
Capacity and Throughput Management
Cost Optimization Best Practices
Security Best Practices
Global Tables Best Practices
Zero-ETL Integrations
Other Best Practices
AWS Certification Exam Tips
Reference

AWS DynamoDB Best Practices

Primary Key Design

  • Primary key uniquely identifies each item in a DynamoDB table and can be simple (a partition key only) or composite (a partition key combined with a sort key).
  • Partition key portion of a table’s primary key determines the logical partitions in which a table’s data is stored, which in turn affects the underlying physical partitions.
  • Partition key should have many unique values.
  • Distribute reads / writes uniformly across partitions to avoid hot partitions
  • Store hot and cold data in separate tables
  • Consider all possible query patterns to eliminate the use of scans and filters.
  • Choose a sort key depending on the application’s needs.
  • Avoid hot keys and hot partitions – a partition key design that doesn’t distribute I/O requests evenly can create “hot” partitions that result in throttling and use the provisioned I/O capacity inefficiently.
  • Use composite keys for access patterns – compose partition and sort keys by concatenating multiple attributes (e.g., {Type}#{ID}) to enable efficient queries without scans, especially in single-table designs.
  • Write sharding for high-volume keys – for items with high write volumes on the same partition key, add a random suffix or calculated suffix to distribute writes across multiple partitions.

Secondary Indexes

  • Use indexes based on the application’s query patterns.
  • Local Secondary Indexes – LSIs
    • Use primary key or LSIs when strong consistency is desired
    • Watch for expanding item collections (10 GB size limit!)
  • Global Secondary Indexes – GSIs
    • Use GSIs for finer control over throughput or when your application needs to query using a different partition key.
    • Can be used for eventually consistent read replicas – set up a global secondary index that has the same key schema as the parent table, with some or all of the non-key attributes projected into it.
    • Overloaded GSIs – use a single GSI with generic attribute names (e.g., GSI1PK, GSI1SK) to support multiple access patterns in single-table designs, reducing the total number of indexes needed.
  • Project fewer attributes – As secondary indexes consume storage and provisioned throughput, keep the index size as small as possible by projecting only required attributes as it would provide greater performance
  • Keep the number of indexes to a minimum – don’t create secondary indexes on attributes that aren’t queried often. Indexes that are seldom used contribute to increased storage and I/O costs without improving application performance.
  • Sparse indexes – DynamoDB indexes are Sparse and it writes a corresponding index entry only if the index sort key value is present in the item. If the sort key doesn’t appear in every table item, the index will not contain the item.

Large Items and Attributes

  • DynamoDB currently limits the size of each item (400 KB) that is stored in a table, which includes both attribute names and values binary length.
  • Use shorter (yet intuitive!) attribute names
  • Keep item size small.
  • Use compression (GZIP or LZO).
  • Split large attributes across multiple items (vertical partitioning).
  • Store metadata in DynamoDB and large BLOBs or attributes in S3.
  • Vertical partitioning – split items into multiple items using a sort key to distinguish parts, allowing you to exceed the 400 KB limit while maintaining efficient access to individual attribute groups.

Querying and Scanning Data

  • Avoid scans and filters – Scan operations are less efficient than other operations in DynamoDB. A Scan operation always scans the entire table or secondary index. It then filters out values to provide the result, essentially adding the extra step of removing data from the result set.
  • Use eventual consistency for reads.
  • Use parallel scans cautiously – parallel scans can improve throughput for large tables but consume significant read capacity. Use them only for infrequent, large-scale data processing tasks.

Time Series Data

  • Use a table per day, week, month, etc for storing time series data – create one table per period, provisioned with the required read and write capacity and the required indexes.
  • Before the end of each period, prebuild the table for the next period. Just as the current period ends, direct event traffic to the new table. Assign names to the tables that specify the periods they have recorded.
  • As soon as a table is no longer being written to, reduce its provisioned write capacity to a lower value (for example, 1 WCU), and provision whatever read capacity is appropriate. Reduce the provisioned read capacity of earlier tables as they age.
  • Archive or drop the tables whose contents are rarely or never needed.
  • Dropping tables is the fastest, simplest and cost-effective method if all the items are to be deleted from the table, without spending time in scanning and deleting each item.
  • Use TTL for automatic expiry – leverage Time to Live (TTL) to automatically delete expired items without consuming write throughput, ideal for session data, temporary records, and event logs.
  • Use DynamoDB Standard-IA table class – for older time series tables with infrequent access, switch to the Standard-Infrequent Access table class to save up to 60% on storage costs.

Capacity and Throughput Management

  • On-demand mode (recommended default) – on-demand mode is the default and recommended throughput option that eliminates capacity planning. DynamoDB instantly accommodates workloads as they ramp up or down. With the November 2024 pricing reduction (50% off), on-demand is now significantly more cost-effective.
  • Configurable maximum throughput – for on-demand tables, optionally set maximum read/write throughput limits to control costs and protect downstream services from accidental traffic surges (launched May 2024).
  • Warm throughput – provides visibility into the read and write operations your table can immediately support. Pre-warm tables proactively to meet anticipated traffic demands without throttling during sudden spikes (launched November 2024).
  • Burst Capacity reserves a portion of unused capacity (5 mins.) for later bursts of throughput to handle usage spikes.
  • Adaptive capacity helps run imbalanced workloads indefinitely. It minimizes throttling due to throughput exceptions and reduces cost by enabling you to provision only the needed throughput capacity.
  • Provisioned mode with Auto Scaling – for predictable workloads, provisioned mode with auto scaling can be more cost-effective than on-demand. Use scheduled scaling for known traffic patterns.
  • Reserved capacity – for steady-state workloads on provisioned tables, purchase 1-year or 3-year reserved capacity for significant savings. AWS Cost Explorer now provides purchase recommendations for DynamoDB reserved capacity.

Cost Optimization Best Practices

  • Choose the right capacity mode – on-demand mode pricing was reduced by 50% (November 2024). Evaluate whether on-demand or provisioned with auto scaling better suits your workload pattern.
  • DynamoDB Standard-IA table class – use for tables where storage cost exceeds 50% of throughput cost. Saves up to 60% on storage while keeping the same performance. Ideal for infrequently accessed data, logs, and historical records.
  • Use TTL to expire data – TTL deletes expired items without consuming write capacity, reducing both storage costs and manual cleanup effort.
  • Monitor with AWS Compute Optimizer – AWS Compute Optimizer now identifies idle DynamoDB provisioned tables (launched June 2026), helping detect unused resources and potential cost savings.
  • Global tables pricing – global table replicated write costs were reduced by up to 67% (November 2024). Evaluate global tables for multi-Region active-active architectures.

Security Best Practices

  • Resource-based policies (launched March 2024) – attach policies directly to DynamoDB tables, indexes, and streams to simplify cross-account access control. Integrates with IAM Access Analyzer and Block Public Access capabilities.
  • Attribute-Based Access Control (ABAC) – use tag-based conditions in IAM policies to grant access based on tags attached to users, roles, and DynamoDB resources (GA November 2024). ABAC automatically applies permissions as organizations grow without rewriting policies.
  • AWS PrivateLink (launched March 2024) – connect to DynamoDB over a private network without public IP addresses, eliminating the need for internet gateways or firewall rules.
  • Encryption at rest – all DynamoDB tables are encrypted at rest using AWS owned keys by default. Use AWS KMS customer managed keys (CMK) for additional control.
  • Deletion protection can keep the tables from being accidentally deleted.
  • FIPS 140-3 endpoints – FIPS-compliant interface VPC and Streams endpoints available in US, Canada, and GovCloud Regions (launched December 2024).

Global Tables Best Practices

  • Multi-Region strong consistency (GA June 2025) – global tables now support multi-Region strong consistency (MRSC), enabling zero RPO and ensuring applications can read the latest data from any Region. Ideal for user profiles, inventory tracking, and financial transactions.
  • Choose the right consistency mode – MRSC provides strongly consistent reads across Regions with slightly higher write latencies. Choose between MRSC and multi-Region eventually consistent (MREC) based on application needs.
  • Test with AWS FIS – use the AWS Fault Injection Service (FIS) action to pause global table replication and test application resilience during Regional interruptions (launched April 2024).
  • Pricing optimization – global table replicated write costs reduced by up to 67% for on-demand and 33% for provisioned (November 2024).

Zero-ETL Integrations

  • Amazon Redshift integration (GA October 2024) – zero-ETL integration with Amazon Redshift enables high-performance analytics on DynamoDB data without impacting production workloads or building ETL pipelines. Data becomes immediately available in Redshift as it is written to DynamoDB.
  • Amazon SageMaker Lakehouse integration (December 2024) – automates data synchronization between DynamoDB and SageMaker Lakehouse using Apache Iceberg format. Enables analytics and ML workloads with ACID transaction support.
  • Use zero-ETL for analytics – instead of running complex Scan operations for reporting, leverage zero-ETL integrations to offload analytics workloads to purpose-built analytics services.

Other Best Practices

  • Single-table design – for applications with multiple entity types and well-defined access patterns, consider single-table design with composite keys and overloaded GSIs to reduce costs and improve performance.
  • Multi-table design – for applications with simple access patterns or when teams need independent management of entities, multi-table design offers simpler maintenance and clearer data boundaries.
  • DynamoDB Accelerator (DAX) – use DAX for read-heavy workloads requiring microsecond response times. DAX provides up to 10x performance improvement for eventually consistent reads.
  • DynamoDB Streams – use streams for event-driven architectures, cross-Region replication, and real-time data processing. Now supported as a source in Amazon Managed Service for Apache Flink (November 2024).
  • Import from S3 – bulk import supports up to 50,000 S3 objects in a single import operation (increased March 2024), simplifying initial data loading.

AWS Certification Exam Tips

  • Understand partition key design and how to avoid hot partitions – a fundamental topic across all AWS certification exams.
  • Know the difference between on-demand and provisioned capacity modes and when to use each.
  • Understand global tables multi-Region strong consistency vs. eventual consistency trade-offs.
  • Know resource-based policies vs. identity-based policies for cross-account DynamoDB access.
  • Understand TTL for cost optimization and data lifecycle management.
  • Know DynamoDB Standard vs. Standard-IA table class selection criteria.
  • Understand zero-ETL integrations as the recommended approach for analytics on DynamoDB data.
  • Know warm throughput and configurable maximum throughput for performance management.

Reference