GuardDuty now detects data exfiltration and destruction in Aurora and RDS PostgreSQL
On October 8, 2026, AWS extended GuardDuty RDS Protection beyond login anomalies to detect data exfiltration and destruction in Aurora PostgreSQL and RDS for PostgreSQL, using agentless behavioral baselines. Turn on the 30-day free trial if you run PostgreSQL — but know that MySQL remains outside the scope.
October 8, 2026. AWS extends GuardDuty RDS Protection beyond login anomalies. PostgreSQL. Only Aurora PostgreSQL and RDS for PostgreSQL are covered by the new detection. 30 days. The length of the free trial, per account and per region. Why it matters: database exfiltration is the classic blind spot of cloud defense — it looks like legitimate application traffic — and AWS is finally addressing that signal, but only for one database engine.
What the new layer detects
Until now, GuardDuty RDS Protection was limited to login anomalies: brute-force attempts, sign-ins from unusual locations, suspicious authentication behavior. The addition, called RDS Protection for data activity, brings detection of data exfiltration and data destruction. In practice, GuardDuty continuously monitors query patterns and flags read or delete activity that diverges from normal.
The mechanism is machine learning-based anomaly detection combined with integrated threat intelligence. GuardDuty builds a behavioral baseline of each database’s normal queries, then alerts when activity departs from it. That is what makes the signal actionable: rather than hunting a static signature, the detection compares observed behavior against what the database usually does.
The target scenario is precise. AWS describes it this way: attackers obtain valid credentials through phishing, social engineering or misconfiguration, and their malicious activity “can appear indistinguishable from legitimate application behavior.” A mass read launched by a compromised account looks, on paper, like a legitimate overnight report. The behavioral baseline exists precisely to catch the deviation that signature-based tools miss.
PostgreSQL only, and agentless
Two operational properties matter. First, there is no agent: the detection activates “without requiring any agents, additional infrastructure, or database configuration changes.” It follows the rest of GuardDuty’s model — telemetry is collected service-side, not injected into the database. For a team that does not want to touch a production database, that is the decisive argument.
Second, activation is organizational. The service is an add-on to existing RDS Protection, enabled for the entire organization with a single click in the console, or via API, SDK, CLI or CloudFormation. The 30-day free trial applies per account and per region, letting you measure the false-positive rate before paying.
But the scope limit is blunt: only Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL are covered. MySQL, MariaDB, SQL Server, Oracle and the rest remain out of scope. If your database estate is heterogeneous — the norm in mature accounts — this detection covers only part of the surface. It is a deliberate choice by AWS, likely tied to the difficulty of instrumenting query-level telemetry on every engine, but it must be factored into the math: the protection only applies to your PostgreSQL instances.
What the findings look like
The concrete output is a GuardDuty finding, in the same shape as a suspicious-login finding, but about data activity. Each finding identifies the affected RDS instance, the type of activity detected — abnormal read suggestive of exfiltration, or a destructive operation suggestive of data destruction — and an associated severity. Triage follows the same path as the rest of GuardDuty: EventBridge, Security Hub or S3 for export, then your existing automations.
The split between the two signal families has a practical consequence. Destruction findings — mass drops, table deletions, queries that empty data — are unambiguous and justify an immediate response, often quarantining the affected credentials. Exfiltration findings are more ambiguous: a large read could be a legitimate backup dump. That is where the baseline earns its keep, comparing the query against the instance’s history rather than an absolute threshold.
You should also calibrate the false-positive rate during the free trial. Anomaly detection on database queries will, by construction, alert on legitimate spikes — a migration, a warehouse reload, an end-of-month report. Measuring that noise before rolling out activation broadly is exactly what the 30-day window is for.
The market context sharpens the value of the announcement. Ransomware and extortion attacks against cloud databases multiplied through 2026, and exfiltration usually precedes encryption — attackers steal first, then destroy. A native detection wired into the existing findings flow avoids adding a third-party database activity monitoring (DSPM) tool for this one scenario. On the other hand, if you need per-query traceability for compliance, Aurora’s Database Activity Streams remain the dedicated tool: GuardDuty detects, it does not archive the query itself.
Where the feature fits in your stack is a judgment call. RDS Protection for data activity is best treated as a detection layer on top of the controls that should already exist: least-privilege database roles, encryption at rest and in transit, and application-side query logging. It closes a specific gap — the attacker who already holds valid credentials — rather than replacing the baseline hygiene that stops credentials from leaking in the first place. Teams that bolt it on without those controls will be alarmed faster, but no better protected. And because the capability is PostgreSQL-only, multi-engine estates should not let a green checkmark in the console create a false sense of coverage: track which instances are actually enrolled, and treat everything else as unmonitored by this feature.
Rolling it out is a measured move, not a big-bang one: enable it on a subset of non-production instances first, watch the findings for a week or two, and only then widen to production. That sequencing keeps false-positive noise from drowning your response queue before the baseline has settled.
The learning window is your blind spot
The least discussed and most important point for real-world use is the learning period. Behavioral baseline detection is only reliable once the baseline exists — that is, after GuardDuty has observed enough normal traffic. During that initial phase, the baseline is still forming, and a slow exfiltration can slip under the radar because there is no established “normal” to compare against.
The consequence is twofold. On one hand, do not enable the detection and consider the problem solved the same day: the value accrues over several weeks of observation. On the other, exfiltration detection is inherently harder than intrusion detection — an attacker holding valid credentials is, by definition, indistinguishable from a legitimate user, and only the statistical deviation betrays them. A patient actor who exfiltrates slowly, below the anomaly threshold, will remain hard to catch regardless of the tool.
That does not make the feature useless — quite the opposite. Data destruction (mass drops, table deletions, database ransomware) is a much more obvious signal, and covering that scenario has immediate value. It is on slow exfiltration that expectations need calibration: the baseline helps, but it does not replace encryption, credential rotation and application-side query logging.
Verdict
Turn on RDS Protection for data activity without delay if you run Aurora PostgreSQL or RDS for PostgreSQL: the entry cost is a 30-day free trial, activation is agentless and organization-wide, and data destruction detection delivers immediate value. If your estate is MySQL-heavy or multi-engine, first measure the share that is actually covered before making it a pillar of your defense — the detection only covers PostgreSQL. Either way, do not treat activation as closure: the value of a behavioral baseline builds over weeks of observation, and slow exfiltration will remain your residual blind spot, to be filled by encryption and application-side logging.