AWS Bridges the Hybrid Observability Gap with CloudWatch Database Insights for EC2 PostgreSQL
AWS has extended Amazon CloudWatch Database Insights to support self-managed databases, launching initial support for PostgreSQL running on Amazon EC2. The integration leverages the host-level Amazon CloudWatch Agent to capture performance telemetry directly from PostgreSQL's core administrative views. The agent samples pg_stat_activity at one-second intervals to compute average active session (AAS) metrics and wait-event distributions, while polling pg_stat_statements every sixty seconds to track Top SQL queries, latency metrics, and execution plans alongside OS-level hardware counters. Telemetry is retained for fifteen months and surfaced directly within the CloudWatch console's Fleet View with a distinct "Self-Managed" tag.
Enterprise database fleets rarely exist purely in fully managed environments. Many mission-critical systems remain on EC2 due to unsupported PostgreSQL extensions, custom OS kernel tuning, legacy replication topographies, or gradual cloud migration schedules. Previously, database administrators had to maintain separate observability stacks—such as self-hosted Prometheus scrapers, OpenTelemetry pipelines, or expensive third-party APM agents—to monitor self-hosted nodes, while using native AWS tooling for RDS and Aurora. Consolidating both under CloudWatch Database Insights establishes a single pane of glass, eliminating operational fragmentation and standardizing triage workflows across heterogeneous fleets.
This release aligns with the broader cloud infrastructure pattern of closing feature parity between managed platform services and raw IaaS infrastructure. As enterprises face budget tightening and tool consolidation mandates, cloud providers are integrating legacy and unmanaged footprints into their primary governance and observability planes. Furthermore, providing seamless diagnostic continuity serves as an operational bridge for modernization: teams can establish baseline performance profiling on EC2 before executing cutovers to managed services like Aurora PostgreSQL or Aurora DSQL without needing to rewrite runbooks or metric dashboards.
For DevOps and SRE teams, rolling out this capability requires installing or updating the CloudWatch Agent and granting appropriate read-only access to PostgreSQL performance schemas via infrastructure-as-code automation. However, practitioners should note key limitations: self-managed nodes currently lack automated Lock Analysis and Performance Analysis Reports available in managed RDS tiers, and they are omitted from Fleet View when cross-account/cross-Region aggregation modes are engaged. Teams should evaluate standard CloudWatch metric ingestion charges against existing third-party APM licensing costs before transitioning their entire unmanaged EC2 database footprint.
Read original source