Inspect each task's logging settings to confirm TARGET_APPLY and TARGET_LOAD severity. Update the task's logging configuration to set both to LOGGER_SEVERITY_DEFAULT or higher. Re-apply the corrected task settings and confirm logs flow to CloudWatch. Standardise on a logging template so copied task settings do not reintroduce the gap.

Compliance Medium severity

AWS Security Hub · DMS

DMS.7: DMS target DB tasks should have logging

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub DMS.7 check?

DMS.7 fails when a replication task does not have logging enabled at LOGGER_SEVERITY_DEFAULT or higher for its target-side components, TARGET_APPLY and TARGET_LOAD. The control inspects the task's logging settings for those two components specifically.

Why does DMS.7 matter?

The target-side components are where DMS writes rows into the destination and reports type-mapping problems. With their logging off, a silent failure — a truncated decimal column, a dropped row — leaves no trace, and the corruption only surfaces weeks later when business data does not add up. Target logging turns those silent failures into CloudWatch warnings you can catch on day one.

How do I fix DMS.7?

Inspect each task's logging settings to confirm TARGET_APPLY and TARGET_LOAD severity.
Update the task's logging configuration to set both to LOGGER_SEVERITY_DEFAULT or higher.
Re-apply the corrected task settings and confirm logs flow to CloudWatch.
Standardise on a logging template so copied task settings do not reintroduce the gap.

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.7 a false positive?

A custom task settings file copied from an old project often carries logging in a default-off state — the task can look healthy and report a successful load while DMS.7 stays FAILED.

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.7 →

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.8 DMS source 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