Enable RDS Enhanced Monitoring

Amazon RDS ships basic performance metrics from outside the database host at no extra charge. What it doesn't give you by default is visibility into what's happening inside the OS — which process is consuming CPU, whether memory pressure is spilling to swap, or why disk IO is spiking. Enhanced Monitoring fills that gap by running an agent inside the database host and streaming OS-level metrics to CloudWatch Logs. Security Hub flags databases that lack it as a failing control under RDS.6.

The cost of Enhanced Monitoring is a function of one variable you control: the polling interval. A 60-second interval on any instance size is essentially free — the CloudWatch Logs volume is negligible. A 1-second interval on a large, busy database can produce several gigabytes of logs per day at roughly $0.50/GB ingest, which adds up fast across a fleet. The finance question this control surfaces isn't whether to enable it — RDS.6 compliance is non-negotiable for SOC 2 and HIPAA-aligned reviews — it's what interval to set for each tier of database to pass the control at the lowest justified cost.

The right framing is a tiering model: production-critical databases warrant 15-second intervals for genuine diagnostic value, dev and test instances can sit at 60 seconds and satisfy the control for near-zero spend. The cost exposure from Enhanced Monitoring comes almost entirely from high-frequency intervals left running on large fleet databases after an incident closes — that's where the CloudWatch Logs bill surprises happen.

Dana is the finance partner reviewing the security findings before the SOC 2 audit closes. RDS.6 is flagged across fourteen databases — all showing MonitoringInterval=0. Engineering wants to bulk-enable Enhanced Monitoring and move on. Dana's job is to make sure the remediation doesn't create a new CloudWatch Logs cost surprise.

She pulls the current CloudWatch Logs bill alongside the RDS instance list. The fourteen databases span three tiers: four large production databases (r6g.2xlarge or bigger), six medium production instances, and four dev/test databases. Dana works with the database lead to agree on an interval policy before anything gets enabled: 15 seconds for the four large production instances, 30 seconds for the medium-tier production databases, and 60 seconds for dev/test. She models the incremental CloudWatch Logs spend for each tier — the 15-second group is the only one with a material cost; the rest are negligible.

The result is a remediation plan that clears RDS.6 on all fourteen databases and carries a known, pre-approved incremental monthly cost. Dana marks the intervals in the cost tracking sheet and flags: if any database is temporarily dropped to 1-5 second intervals for troubleshooting, it needs to be reverted within 48 hours or approved as a budget change. That one standing rule is what prevents the billing surprises.

Without Enhanced Monitoring, incidents take longer to diagnose. Longer incidents mean more engineering hours at incident rates, more business disruption, and more customer impact. But the most direct finance-visible consequence is what happens after those incidents: teams that can't see OS-level metrics tend to over-provision as a hedge. A database that looks like a CPU problem at the hypervisor layer might simply be running autovacuum on a large table — but without OS metrics you can't know that, so the reflex is to go up a tier. A single unnecessary instance-class upgrade on an r6g.2xlarge is several hundred dollars a month in perpetuity.

On the compliance side, a failing RDS.6 in a SOC 2 or HIPAA-aligned review environment is a written finding with a remediation deadline. That isn't abstract risk — audit remediation cycles consume engineering time, and a recurrent finding can delay certification. RDS.6 is straightforward enough to fix that a sustained failure reflects a governance gap more than a technical one.

The cost risk from Enhanced Monitoring itself is also worth naming. It's entirely driven by interval selection. Sixty-second intervals add virtually nothing to the CloudWatch Logs bill on any fleet. But 1-second intervals on a large database during active troubleshooting can ingest several gigabytes of logs per day per instance. Left running across a fleet, that's a meaningful, visible cost anomaly — and it's the kind of cost that appears without any deliberate decision because someone forgot to revert after an incident closed.

The finance position on this control is: enable it everywhere (non-negotiable for compliance), set intervals by tier (60 seconds for dev/test, 15 seconds for production as the steady-state default), and put an alerting rule or budget line on CloudWatch Logs so that any spike from short-interval troubleshooting is visible and time-bounded.

Default cloud monitoring tells you a database is under stress. It doesn't tell you why. Enhanced Monitoring puts an agent inside each database host so the team can see what is actually consuming resources — and resolve incidents in minutes rather than hours. Security Hub flags databases that lack this as a failing compliance control.

This is a low-cost, high-value operational hygiene item. The charge is usage-based and scales with a single dial: how frequently the agent samples. Leaving it off entirely means the team is flying blind during incidents; setting it carelessly at maximum frequency on a large fleet is where unnecessary spend accumulates. The leadership expectation is simple: every production database has Enhanced Monitoring on at a sensible interval, by policy, so incident response never depends on whether someone remembered to enable it.

At one company, every database incident started the same way: an alert that CPU was high, followed by an hour of guessing. The team had no OS-level visibility — just the hypervisor metrics that confirmed something was wrong without saying what. Enabling Enhanced Monitoring across the production fleet, with a policy-driven interval by database tier, changed that. The first incident after the rollout was diagnosed from the OS metrics in under ten minutes.

The leadership signal that mattered wasn't the speed of the fix. It was that Enhanced Monitoring was now on by default for all production databases, with a one-page interval policy that the finance partner had signed off on. Compliance passed, the CloudWatch Logs cost was a predictable line on the bill, and no one had to remember to enable it before an incident.

Running production databases without Enhanced Monitoring means that when something goes wrong — a slow query, a memory spike, a 3am page — the team's first tool is educated guessing. The hypervisor metrics confirm the problem exists; they don't explain it. That gap directly extends incident duration, and in a customer-facing service, every additional minute of investigation is additional customer impact.

The compliance dimension is direct: RDS.6 is a required passing control for SOC 2 and HIPAA-aligned audits. A finding here doesn't fail an audit on its own, but it generates a written remediation commitment with a deadline, which diverts engineering time and can create scrutiny around broader operational maturity. It's a signal that gets noticed.

The right question for leadership isn't "is it enabled?" — it's "is it governed?" Enabling the feature is the easy part. The management signal is whether the org has an interval policy that distinguishes steady-state from troubleshooting mode, and whether there's a control in place to catch incidents where someone drops to 1-second sampling and never turns it back up. That's what separates a compliance check from an actual capability.