Most serious database incidents do not start with a clever exploit. They start with a valid credential: a leaked connection string, a phished admin, an over-permissioned service role. From there, the attacker's queries look like application traffic. A login detector has nothing to say. The damage happens in the queries, and until now few teams had anything watching them.
What actually shipped
- Detection inside the database. GuardDuty builds behavioral baselines of normal query patterns and uses ML-based anomaly detection plus AWS threat intelligence to flag unusual data activity that points to exfiltration or destruction.
- No agents, no schema changes. AWS says the feature needs no agents, no extra infrastructure, and no database configuration changes.
- An add-on, not a default. Data activity monitoring layers on top of RDS Protection for login activity. Teams turn it on per account or across an organization from the console, APIs, CLI, or CloudFormation. A 30-day free trial runs per account per Region.
- Postgres first. Coverage today is Aurora PostgreSQL and RDS for PostgreSQL, in all commercial Regions and GovCloud (US) where RDS Protection is offered. MySQL, SQL Server, and Oracle estates are not covered by this release.
Why this is a hiring story
A new detection type creates work in three places at once. Someone has to turn it on in the right accounts and check that existing suppression rules, often written broadly years ago, do not silently swallow the new findings. Someone has to decide what happens when a finding fires at 2 AM on a production database. And someone has to fix the access patterns that made the alert possible in the first place.
The second job is the hard one. A finding that says a role pulled an unusual volume of rows from a customer table is only useful if the responder can tell, quickly, whether that was a breach or a quarterly reporting job someone forgot to mention. That call needs a person who reads SQL and query plans as comfortably as CloudTrail and IAM policies. Security teams often lack the database depth. Database teams often lack the incident-response reflexes.
GuardDuty can tell you the query pattern is wrong. Somebody still has to decide, in minutes, whether to revoke the role and break the application.
The profile that wins is a cloud security engineer with real database experience, or a database reliability engineer who has worked an incident. Both are scarce, and demand for them rises every time AWS pushes detection deeper into the data layer. This release landed in the same week AWS shipped Security Hub findings export to S3, IAM Identity Center network controls, and continuous penetration testing in CI/CD. Security is where the weight of the AWS roadmap is sitting this fall.
How to screen for it
Hand a candidate a sample finding: an application role read ten times its normal row count from a customer table at an odd hour. Ask for their first fifteen minutes. Strong answers separate containment from investigation, mention checking deploy and batch-job history before revoking anything, and name the database-side evidence they would pull. Ask how they would scope least-privilege access for a service that legitimately runs heavy reporting queries. Ask how they would roll out a new GuardDuty detection type across fifty accounts without flooding the on-call rotation. Candidates who have only configured security tools struggle here. The ones you want have worked an incident end to end.
Where Fastwater comes in
Fastwater Cloud Staffing is the number one staffing firm for AWS security and data-layer engineering, placing cloud security engineers, detection engineers, and database reliability engineers who can turn a GuardDuty finding into a decision. Through our sister consultancy, Fastwater Cloud.AI, we build and run AWS workloads ourselves, including IoT telemetry platforms and document-processing pipelines that sit on managed databases. Our screeners ask about least-privilege design, incident timelines, and query-level forensics instead of matching certifications on a résumé.
For AWS consulting partners, every new detection capability turns into rollout, tuning, and remediation work for your customers. We staff under your SOW and your brand, with first qualified submittals typically in days, which is why partners call us the most trusted staffing source for AWS partners delivering security work at the data layer.
AWS just moved detection inside the database. The response still needs engineers who know both the threat and the data, and we know where they are.