AWS CloudWatch Logs for DBAs and Developers / Lesson 2 of 10

Enable Database and Application Logs

Identify what the engine and application emit, enable supported exports, and choose logging carefully so incident evidence does not create unnecessary load or expose sensitive data.

1. Find supported log types

In the AWS console, open the RDS database or Aurora cluster, review its engine/version, and inspect the available log exports. Enable the engine logs needed for the use case (for example, PostgreSQL engine logs). Export names and supported behavior differ between RDS engines, Aurora versions, and deployment types; verify the current AWS documentation for the exact resource before changing it.

  1. Record the resource identifier, account, Region, engine/version, and current settings.
  2. Check the change window and impact with the service owner.
  3. Enable the selected CloudWatch log exports using the approved change process.
  4. Review the resulting log-group name and confirm that fresh events arrive.

2. Configure database logging deliberately

For PostgreSQL, parameter-group settings can add useful context. Confirm whether a parameter is dynamic or requires a restart for your engine/version, assess log volume, and test before rollout.

# PostgreSQL parameter examples (parameter group values):
log_line_prefix = '%m [%p] %q%u@%d '
log_lock_waits = 1
deadlock_timeout = '1s'
log_min_duration_statement = '1000'

This example logs completed statements that meet the configured duration threshold; a threshold of 1000 milliseconds is only an example, not a universal recommendation. Use a workload-appropriate value. Very verbose statement logging can add volume and expose SQL literals. Avoid logging passwords, tokens, and sensitive bind values; follow your organization's privacy and retention policy.

3. Add application-side context

Developers should log a stable request/trace ID, service and version, operation name, database target alias, start/end time, outcome, and duration. Use structured JSON fields where possible. Do not log secrets, full connection strings, or unrestricted user input. Make sure retries and pool-wait time are distinguishable from database execution time.

4. Verify the pipeline

Generate a safe test event in a non-production environment, confirm the correct log group and stream receive it, verify the event timestamp and permissions, and check the export's health. If logs are missing, verify resource-level export settings, engine support, parameter-group application, Region/account selection, delivery delay, and IAM access.

CloudWatch logging configuration is not a substitute for database activity monitoring or application tracing. A query still running may not yet have a completion-duration log line; use the database activity view or approved monitoring for live query state.

Progress stays in this browser.