Best practice for onboarding Amazon Aurora clusters in Database Performance Analyzer (DPA)

8/5/2026 4:54 PM

8/5/2026 4:54 PM

When DPA is registered only to an Aurora cluster or writer endpoint, queries that execute exclusively on reader instances may not appear in DPA, even though they are visible in AWS Performance Insights.

This article explains the expected behavior and the recommended way to onboard Aurora clusters so that both writer and reader instances are monitored in DPA.

Database Performance Analyzer

Cause

DPA monitors one database instance per registration; it does not currently treat an Aurora cluster endpoint as the entire cluster.

 

• If you register only the writer/cluster endpoint in DPA, DPA collects waits and SQL for that writer instance only.
• Queries that run solely on a reader node do not appear in the writer’s DPA data; they are still visible in AWS Performance Insights because AWS instruments each Aurora instance independently.

 

Resolution

1. Align expectations for Aurora cluster monitoring in DPA

   • DPA requires a separate registration for each Aurora writer or reader instance you want to monitor; registering the cluster or writer endpoint alone does not automatically include reader instances.
   • A query that runs only on a reader node will not be captured in DPA unless that reader is registered as its own monitored database in DPA.

2. Best practice for onboarding an Aurora cluster with DPA

   Configure DPA so that both writer and any workload-bearing readers are individually monitored:

   1. Register the writer instance

      • Register the Aurora writer instance using its writer/instance endpoint as a standard DPA database registration.

   2. Register each reader instance that carries workload

      • For every reader instance that runs application or reporting queries, register it as its own database in DPA rather than relying on the cluster endpoint alone.

3. Registering read-only Aurora/MySQL endpoints

   For Aurora or MySQL read-only endpoints that cannot be registered directly through the normal DPA wizard, follow the supported pattern:

   1. Register the corresponding non-read-only (read/write) MySQL/Aurora instance in DPA using the standard registration wizard.
   2. In the Advanced Options for Performance Schema, select Leave MySQL as it is (MYSQL_OR_MARIADB_PERFORMANCE_SCHEMA) so that DPA does not change the existing Performance Schema configuration.
   3. After registration succeeds, use Update Connection Info in DPA to point that registration to the read-only endpoint and resume monitoring from there.

   This pattern is the documented approach for monitoring read-only MySQL/Aurora endpoints with DPA and is consistent with existing guidance for Amazon RDS and Aurora environments.

4. Correcting an existing deployment that only uses the cluster/writer endpoint

   If DPA is currently registered only to the Aurora cluster or writer endpoint and is missing queries that run on readers:

   1. Identify all Aurora reader instances that handle production or reporting workload.
   2. For each such reader:
      • Either register it directly as its own database in DPA (if it is not strictly read-only), or
      • Use the read-only registration pattern described above to monitor that reader endpoint.
   3. Once the readers are registered, verify that DPA now shows wait time and SQL for queries that previously appeared only in AWS Performance Insights.