DynamoDB Logging, Monitoring and Application Log Storage

Use CloudTrail to audit who called DynamoDB APIs, CloudWatch metrics to monitor performance, and DynamoDB Streams to capture item changes. These tools answer different questions: a stream does not record reads, and a metric does not identify the caller. DynamoDB can also store your application's own structured logs when their access patterns fit key-based queries.

Choose the right logging tool

DynamoDB is a managed database, so you do not SSH into it to retrieve server log files. Configure service telemetry and application logging before an incident; enabling a log category later does not reconstruct events that were never collected.

Audit DynamoDB API activity with CloudTrail

Management events cover control-plane operations such as creating, updating and deleting tables. CloudTrail Event history provides recent management activity, while a configured trail can deliver an ongoing record to S3. Search by event source, operation, time and identity when investigating a configuration change.

Item operations such as GetItem, PutItem, UpdateItem, Query and Scan are data events. Trails do not log data events by default, and those events are not available simply by opening management Event history. Enable the DynamoDB table resource type and select the tables and operations you need. Data-event charges apply.

In the CloudTrail console, edit the trail's event selectors and choose DynamoDB data events. For a production table, decide whether the audit requires reads, writes or both. Selecting only writes reduces volume but cannot answer who read a sensitive record. AWS documents supported operations in DynamoDB CloudTrail logging.

Example: select writes to one table

The following advanced-selector document retains management events and adds write data events for ApplicationLogs. Save it as selectors.json, replace the account and Region, and merge it with any selectors the trail already needs:

[
  {
    "Name": "Management events",
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Management"]}
    ]
  },
  {
    "Name": "ApplicationLogs item writes",
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::DynamoDB::Table"]},
      {"Field": "resources.ARN", "Equals": ["arn:aws:dynamodb:us-east-1:123456789012:table/ApplicationLogs"]},
      {"Field": "readOnly", "Equals": ["false"]}
    ]
  }
]
[
  {
    "Name": "Management events",
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Management"]}
    ]
  },
  {
    "Name": "ApplicationLogs item writes",
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::DynamoDB::Table"]},
      {"Field": "resources.ARN", "Equals": ["arn:aws:dynamodb:us-east-1:123456789012:table/ApplicationLogs"]},
      {"Field": "readOnly", "Equals": ["false"]}
    ]
  }
]

aws cloudtrail get-event-selectors --trail-name application-audit

aws cloudtrail put-event-selectors \
  --trail-name application-audit \
  --advanced-event-selectors file://selectors.json
aws cloudtrail get-event-selectors --trail-name application-audit

aws cloudtrail put-event-selectors \
  --trail-name application-audit \
  --advanced-event-selectors file://selectors.json

put-event-selectors replaces the trail's selector configuration. Preserve existing S3, Lambda and other selections when adapting this example. Verify the resulting configuration and generate a test write, then confirm its event arrives in the trail destination. The CloudTrail data-event guide explains advanced selection and billing scope.

CloudTrail records identity, operation and request context; it is not an item-version backup. Avoid assuming it stores every attribute needed to reconstruct a deleted item. For before/after changes, configure a stream with both images and archive the required records, or use a recovery mechanism such as PITR.

Monitor latency, errors and capacity in CloudWatch

DynamoDB publishes metrics in the AWS/DynamoDB namespace. Choose dimensions carefully: a table metric can look healthy while one of its global secondary indexes throttles writes. Monitor the table and each relevant GSI.

Percentile statistics on SuccessfulRequestLatency help expose tail latency that an average can hide. Also record end-to-end request latency in the application; SDK retries can make the user wait even when individual successful service requests are fast.

Use the supported statistics and dimensions from the DynamoDB metrics reference. Alarm on sustained symptoms with thresholds derived from your workload, rather than copying a universal latency or utilization threshold.

Diagnose throttling by cause

Newer throttling metrics distinguish four causes for reads and writes:

Current SDK errors include ThrottlingReasons with a reason and resource ARN. For example, TableWriteKeyRangeThroughputExceeded points toward hot-key pressure, while IndexWriteProvisionedThroughputExceeded identifies insufficient provisioned write capacity on an index. Logging this structured context is more useful than logging only the exception class.

Do not assume on-demand eliminates throttling. It still has partition limits, scaling behavior and optional maximum-throughput settings. See on-demand versus provisioned scaling when selecting capacity for bursty log ingestion.

Find hot keys with Contributor Insights

Contributor Insights identifies heavily accessed or throttled keys on a table or GSI. It has two modes:

• ACCESSED_AND_THROTTLED_KEYS: tracks access patterns as well as throttling, useful when investigating traffic concentration.
• THROTTLED_KEYS: processes only throttled activity, useful for ongoing throttling diagnosis without ingesting all access events.

In throttled-keys mode, no throttling means no data ingestion and no corresponding Contributor Insights cost. An empty graph in this mode does not mean the table is unused. Switch modes deliberately when you need access-distribution evidence.

aws dynamodb update-contributor-insights \
  --table-name ApplicationLogs \
  --contributor-insights-action ENABLE \
  --contributor-insights-mode THROTTLED_KEYS
aws dynamodb update-contributor-insights \
  --table-name ApplicationLogs \
  --contributor-insights-action ENABLE \
  --contributor-insights-mode THROTTLED_KEYS

Review access to Contributor Insights reports because key values can contain sensitive identifiers. AWS describes the modes and their billing in Contributor Insights for DynamoDB. Dynobase's monitoring view can also help inspect CloudWatch metrics alongside table data and stream records.

Store application logs in DynamoDB

DynamoDB is useful for structured event records retrieved by known keys, such as all events for one account during a time window. It is less suitable as a general text-search engine for arbitrary log investigations. CloudWatch Logs or a search/analytics system may fit that requirement better.

Flexible attributes let different services add context without a table migration, but the key schema still needs to match reads. A random ID as the only key supports fetching one known log; it does not efficiently support listing a service's recent errors.

For a moderate-volume service, use a date-bucketed partition key and a timestamp-plus-ID sort key. A structured item might look like this:

{
  "pk": "SERVICE#accountService#DAY#2026-10-23",
  "sk": "2026-10-23T12:00:00.000Z#08395bcb-27d8-4a84-9b29-d591c1746356",
  "id": "08395bcb-27d8-4a84-9b29-d591c1746356",
  "level": "INFO",
  "message": "Account settings updated",
  "service": "accountService",
  "requestId": "example-request-id"
}
{
  "pk": "SERVICE#accountService#DAY#2026-10-23",
  "sk": "2026-10-23T12:00:00.000Z#08395bcb-27d8-4a84-9b29-d591c1746356",
  "id": "08395bcb-27d8-4a84-9b29-d591c1746356",
  "level": "INFO",
  "message": "Account settings updated",
  "service": "accountService",
  "requestId": "example-request-id"
}

Use a stable event ID when retries should target the same item. Do not put passwords, tokens or unrestricted request bodies into log attributes. If one service generates heavy writes, split its date bucket into multiple write shards and query those shards together.

Write a structured log with SDK v3

This function accepts the original event timestamp and ID so a retry writes the same key. The retention period is an application choice passed in seconds:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";

const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));

export async function writeLog({ id, timestamp, service, level, message, retentionSeconds }) {
  const date = new Date(timestamp);
  const iso = date.toISOString();
  await ddb.send(new PutCommand({
    TableName: "ApplicationLogs",
    Item: {
      pk: `SERVICE#${service}#DAY#${iso.slice(0, 10)}`,
      sk: `${iso}#${id}`,
      id,
      service,
      level,
      message,
      expiresAt: Math.floor(date.getTime() / 1000) + retentionSeconds,
    },
  }));
}
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";

const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));

export async function writeLog({ id, timestamp, service, level, message, retentionSeconds }) {
  const date = new Date(timestamp);
  const iso = date.toISOString();
  await ddb.send(new PutCommand({
    TableName: "ApplicationLogs",
    Item: {
      pk: `SERVICE#${service}#DAY#${iso.slice(0, 10)}`,
      sk: `${iso}#${id}`,
      id,
      service,
      level,
      message,
      expiresAt: Math.floor(date.getTime() / 1000) + retentionSeconds,
    },
  }));
}

The table needs string keys pk and sk. Configure TTL on expiresAt separately; writing a timestamp alone does not enable expiration.

Read patterns and daily error counts

For service-and-time queries, use the partition key and a sort-key range. If searching errors by date is frequent, add an index whose key includes service, level and date, rather than a single low-cardinality ERROR partition for the entire system. The query guide explains key conditions and pagination.

Select: COUNT still reads matching data and consumes read capacity; it is not a free constant-time aggregate. A scheduled job can query a day's records, handle every page and store a summary such as:

{
  "pk": "SERVICE#accountService#DAY#2026-10-23",
  "sk": "SUMMARY#ERROR",
  "count": 18
}
{
  "pk": "SERVICE#accountService#DAY#2026-10-23",
  "sk": "SUMMARY#ERROR",
  "count": 18
}

For near-real-time counts, a stream consumer can update aggregates, but repeated delivery must not increment the same event twice. A transaction can atomically write a log and update a counter within one Region, at transactional capacity cost. A single shared counter can become a hot item; shard it if necessary.

Choose scheduled aggregation when delayed results are acceptable and the recurring read cost is reasonable. Choose incremental aggregation when freshness matters and you can implement deduplication and recovery. Recompute summaries when late-arriving events make yesterday's count incomplete.

Cold storage, TTL and archival

Set different retention periods for debug, warning and audit events according to the application's policy. DynamoDB TTL uses numeric Unix epoch seconds and typically deletes expired items within a few days. Expired items can remain readable until deletion, so filter them from application results when the retention boundary matters.

For an archival pipeline, enable old images in DynamoDB Streams and send the TTL-deleted item to S3. Process it within the stream's 24-hour retention window and monitor lag and delivery failures. A consumer outage beyond that window can lose the only remaining item image; compliance-critical archives should not depend solely on recovering data after deletion.

An alternative is to export or copy records to S3 first, verify the archive, and only then allow deletion. A custom archive job provides more precise lifecycle control but must handle pagination, retries and writes occurring during the copy. PITR-backed exports provide another route for analytical snapshots.

Security and scaling

Encryption at rest is always enabled in DynamoDB. It does not replace IAM permissions, retention limits or redaction. Restrict log writers to the required operations, restrict readers by role, and protect the CloudTrail and S3 archive destinations as carefully as the source table. Streams capture changes but cannot detect an unauthorized read on their own.

Log traffic often rises during an incident. Test ingestion bursts, key distribution and downstream consumers before relying on a log table as the sole diagnostic system. On-demand capacity reduces provisioning work, but a large sudden increase or a hot service key can still throttle. Use warm throughput when preparing for a known increase, and decide how the application behaves if its logging write fails.