Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · Transfer

Transfer.3: Transfer connectors should have logging

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub Transfer.3 check?

Transfer.3 fails when an AWS Transfer Family connector has no CloudWatch logging role attached, so its transfer activity is never recorded.

Why does Transfer.3 matter?

A connector with no logging role still does its job, it just leaves no audit trail. When a partner disputes whether files were sent or received, there is no CloudWatch record on the AWS side to settle it, turning a one-line log query into a multi-week argument and a manual file replay. The control fails because the connector works fine while being unauditable.

How do I fix Transfer.3?

  1. List connectors and check whether each has a logging role configured.
  2. Create an IAM logging role with the right trust policy and CloudWatch Logs permissions.
  3. Attach the logging role to each connector so transfer events flow to a log group.
  4. Default new connectors to a logging role via a naming convention or IaC so Transfer.3 stays green.

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

The control fails purely on the absence of a CloudWatch logging role on the connector, so it flags a connector that is non-production by design: a throwaway connector built to validate a new partner endpoint, or one in a sandbox account you have deliberately left without logging because its transfers carry no auditable business value. The connector works correctly; you have simply chosen not to pay for and retain logs for activity that doesn't need an audit trail. If a connector is genuinely transient or scoped to a non-audited environment, suppress the Transfer.3 finding for it with a note recording that decision, rather than attaching a logging role whose log group no one will ever read.

Full lesson Enable application and API logging Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for Transfer controls ↗ Check your own account for Transfer.3 →
Part of the learning path See what's happening

More Transfer controls