Microsoft Defender for Cloud Now Protects AWS RDS

Originally published on DevToolHub.

Microsoft Defender for Open-Source Relational Databases went generally available for AWS RDS on June 1, 2026, and billing started that same day. If you were running it in preview, nothing breaks — you keep the same protection. If you haven't touched it yet, this is the setup: which engines it covers, the exact portal steps, and the IAM permissions it needs on the AWS side.

This matters specifically if you're running Azure as your primary security posture tool but keeping databases in AWS RDS — which is a more common split than it sounds, especially in shops that grew through acquisition or multi-cloud contracts.

What Changed for Defender for Cloud on AWS RDS

Before June 1, this was a preview feature. Now it's GA, which in Microsoft's terms means billing is active and the feature is fully supported rather than best-effort. If you enabled it before the GA date, you keep receiving database threat protection and sensitive data discovery without doing anything — Microsoft carried preview users forward automatically.

The plan detects and investigates unusual activity in your RDS databases: unexpected query patterns, suspicious login attempts, and access from anomalous locations. It also runs sensitive data discovery against your AWS account and feeds those findings into your broader security posture, a capability shared with Defender Cloud Security Posture Management (CSPM).

Which Database Engines Are Covered

Five RDS instance types are supported:

• Aurora PostgreSQL
• Aurora MySQL
• PostgreSQL
• MySQL
• MariaDB

That's the full list — SQL Server and other proprietary engines on RDS aren't part of this specific plan. If you're running those, you're looking at a different Defender for Databases offering.

Prerequisites Before You Enable It

Four things need to be true before you start:

1. You need an active Azure subscription.
2. Defender for Cloud must already be enabled on that subscription.
3. You need at least one AWS account already connected to Defender for Cloud, with the access and permissions that connection requires.
4. Your RDS instances need to be in a supported region — this plan covers all public AWS regions except Tel Aviv, Milan, Jakarta, Spain, and Bahrain.

If you haven't connected an AWS account to Defender for Cloud at all yet, do that first — it's a separate onboarding step from what's covered here.

Step-by-Step: Enabling Defender for Cloud on AWS RDS

1. Sign in to the Azure portal.
2. Search for and select Microsoft Defender for Cloud.
3. Select Environment settings.
4. Select the relevant AWS account.
5. Find the Databases plan and select Settings.
6. Toggle open-source relational databases to On.
7. Select Configure access.
8. In the deployment method section, select Download.
9. Follow the instructions to update the CloudFormation stack in your AWS account — this creates or updates the template with the permissions Defender needs.
10. Confirm the checkbox that the CloudFormation template was updated in your AWS environment.
11. Select Review and generate.
12. Review the summary and select Update.

Turning the plan on also enables sensitive data discovery for RDS resources automatically — it's a shared feature with Defender CSPM, so you don't configure it separately.

What Defender Changes in Your RDS Parameter Groups

This is the part that catches people off guard: enabling the plan doesn't just add a monitoring agent, it modifies parameter and option group settings on your actual RDS instances so Defender can consume audit logs. You don't set these manually — Defender configures them for you — but you should know what's changing before you flip the toggle.

For PostgreSQL and Aurora PostgreSQL, Defender sets log_connections and log_disconnections to 1. For Aurora MySQL cluster parameter groups, it turns on server_audit_logging and expands server_audit_events to include CONNECT and QUERY.

MySQL and MariaDB use an option group instead, built around MARIADB_AUDIT_PLUGIN. Defender expands SERVER_AUDIT_EVENTS to include CONNECT and adds rdsadmin to the excluded users list so its own service account doesn't get logged as suspicious activity.

⚠️ Important: MARIADB_AUDIT_PLUGIN only works on MariaDB 10.2 and later, MySQL 8.0.25 and later, and all MySQL 5.7 versions. If you're running something older, the plan can't fully instrument that instance. You'll likely also need to reboot affected instances for parameter changes to take effect — plan that maintenance window before you enable this in production, not after.

If you're using the default parameter group, Defender doesn't modify it directly — it creates a new group prefixed defenderfordatabases* and applies it instead.

Required AWS Permissions for Defender for Cloud on RDS

The CloudFormation stack creates a role called DefenderForCloud-DataThreatProtectionDB with a specific, scoped set of RDS permissions — not broad admin access. The role can describe and modify parameter groups, option groups, and DB instances/clusters, tag resources, and download log file portions. It cannot delete databases, modify security groups, or touch IAM itself.

If your security team reviews IAM changes before they land — and they should — this is a reasonable role to point them at. It's purpose-built for exactly what the plan needs: reading and writing audit-related configuration, not general database administration.

For the exact permission list and current pricing, check the official setup guide and the Defender for Cloud pricing page — Microsoft updates both directly rather than through this kind of write-up, so they're the source of truth for anything billing-related.

Frequently Asked Questions

Q: Do I need to do anything if I already had this enabled in preview?
A: No. Preview users carried forward automatically on June 1, 2026, and continue receiving protection without re-enabling anything.

Q: Does this cover Amazon Aurora specifically, or just standard RDS?
A: Both Aurora PostgreSQL and Aurora MySQL are covered, alongside standard PostgreSQL, MySQL, and MariaDB instances.

Q: Will enabling this require downtime on my RDS instances?
A: Possibly. Parameter group changes to static parameters don't take effect until the instance reboots, so plan a maintenance window rather than enabling this against production without notice.

Q: Can I disable it later without losing other Defender CSPM features?
A: Yes. Disabling open-source relational database protection just toggles that specific plan off in Environment settings — it doesn't affect other Defender for Cloud plans on the same AWS account.

Quick Summary:

• Defender for Open-Source Relational Databases on AWS RDS went GA June 1, 2026; preview users carried forward automatically
• Covers Aurora PostgreSQL, Aurora MySQL, PostgreSQL, MySQL, and MariaDB — not SQL Server or other proprietary engines
• Setup is entirely in the Azure portal, but requires updating a CloudFormation stack in your AWS account
• Enabling it modifies RDS parameter/option groups to enable audit logging — some instances need a reboot
• The DefenderForCloud-DataThreatProtectionDB role is scoped to audit configuration, not general database admin

Check your RDS engine version against the MARIADB_AUDIT_PLUGIN compatibility requirements before you enable this — an unsupported engine version means partial coverage without an obvious warning.