Inspect each task's logging settings for the SOURCE_CAPTURE and SOURCE_UNLOAD components. Update the task's logging configuration to LOGGER_SEVERITY_DEFAULT or higher for both. Re-apply the task settings and verify the source components are writing to CloudWatch. Roll source logging into a shared task template so new tasks ship compliant.

Compliance Medium severity

AWS Security Hub · DMS

DMS.8: DMS source DB tasks should have logging

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub DMS.8 check?

DMS.8 fails when a replication task does not log its source-side components, SOURCE_CAPTURE and SOURCE_UNLOAD, at LOGGER_SEVERITY_DEFAULT or higher. It is the source-side counterpart to DMS.7's target-side check.

Why does DMS.8 matter?

SOURCE_CAPTURE is where DMS records how it is reading change data capture from the origin. Without it, CDC can quietly fall behind during a nightly batch and the lag stays invisible until reconciliation at cutover reveals tens of thousands of missing rows. Source logging at the default severity surfaces that lag in CloudWatch the first night it happens.

How do I fix DMS.8?

Inspect each task's logging settings for the SOURCE_CAPTURE and SOURCE_UNLOAD components.
Update the task's logging configuration to LOGGER_SEVERITY_DEFAULT or higher for both.
Re-apply the task settings and verify the source components are writing to CloudWatch.
Roll source logging into a shared task template so new tasks ship compliant.

Remediation script · bash

# Verify the prerequisite first: API Gateway's account-level CloudWatch role.
# Without it, the logging setting saves but no logs ever flow.
aws apigateway get-account --query 'cloudwatchRoleArn' --output text

# Enable ERROR-level execution logging on every stage of a REST API.
REST_API=a1b2c3d4e5
for STAGE in $(aws apigateway get-stages --rest-api-id $REST_API \
  --query 'item[].stageName' --output text); do
  aws apigateway update-stage --rest-api-id $REST_API --stage-name $STAGE \
    --patch-operations op=replace,path=/*/*/logging/loglevel,value=ERROR
done

# Cap retention on the log group so storage stays bounded (do this every time you enable logging).
aws logs put-retention-policy \
  --log-group-name "API-Gateway-Execution-Logs_${REST_API}/prod" \
  --retention-in-days 90

# Example for a managed database: publish engine logs to CloudWatch (no per-event charge).
aws rds modify-db-instance --db-instance-identifier prod-db \
  --cloudwatch-logs-export-configuration 'EnableLogTypes=["error","audit"]' --apply-immediately

Full walkthrough (console steps, edge cases and verification) in the lesson Enable application and API logging.

Is DMS.8 a false positive?

A task can pass DMS.7 with target logging on yet still fail DMS.8 — the two controls cover opposite ends of the pipeline, so green on one says nothing about the other.

Full lesson Enable application and API logging Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for DMS controls ↗ Check your own account for DMS.8 →

Part of the learning path See what's happening

DMS.1 A DMS replication instance is publicly accessible
DMS.6 DMS instances auto minor version upgrade
DMS.7 DMS target DB tasks should have logging
DMS.9 DMS endpoints should use SSL
DMS.10 DMS Neptune endpoints should have IAM auth
DMS.11 DMS MongoDB endpoints should have auth
DMS.12 DMS Redis endpoints should have TLS
DMS.13 DMS replication instances should be Multi-AZ