[erikdarlingdata]

What

pg_plan_capture and pg_deadlocks both failed on an entire Aurora fleet today because the monitoring host's IAM role had zero RDS permissions — and this requirement was documented nowhere except the collectors' own runtime error messages. Adding it to docs/postgres-first-target-runbook.md so the next person (or the next fleet) doesn't have to re-derive it from source under time pressure.

Changes

• New subsection under step 1 (IAM, for the two collectors that read the server log): explains why this is a different identity axis from the DB-level pg_monitor grant, gives the exact IAM policy statement (rds:DescribeDBClusters, rds:DescribeDBLogFiles, rds:DownloadDBLogFilePortion), and clarifies self-managed Postgres doesn't need it at all (verified directly against DarlingWorker's dispatch table — both collectors correctly fall back to the SQL-side pg_read_file() path for non-Aurora/non-RDS targets).
• New row in the step 10 failure-modes table for the specific denied-IAM-action error shape, matching the existing table's format.

Docs-only change, no code touched.

🤖 Generated with Claude Code

[claude]

Reviewed. This is a docs-only change (no code touched), so the correctness/security/performance/parity checklist mostly doesn't apply — but I verified the factual claims against the actual Darling source since a runbook with a wrong IAM policy is worse than no runbook:

• IAM actions match code: RdsLogSource.cs calls exactly DescribeDBClustersAsync (to resolve the Aurora writer), DescribeDBLogFilesAsync, and DownloadDBLogFilePortionAsync — matching the three actions in the new policy JSON.
• Dispatch/fallback claim verified: DarlingWorker.cs's collector dispatch table routes pg_plan_capture and pg_deadlocks through the RDS log API only when Target.IsAurora || Target.IsAwsRds; everything else (including self-managed Postgres) falls through to the pg_read_file() route. Confirms the doc's claim that self-managed doesn't need this IAM grant.
• Error-shape claim verified: RdsLogUnavailableException.IsAuthorizationRefusal matches AWS's "is not authorized to perform: rds:..." / "no identity-based policy allows" / AccessDenied message shapes, and the catch in DarlingWorker.cs (~line 4643) logs status PERMISSIONS with the raw AWS message (which names the action and the IAM role ARN) prefixed onto an explanation. Matches the new step 10 table row.
• Lite/Darling parity: not applicable — Lite is SQL-Server-only and has no PostgreSQL/RDS code path, so there's no counterpart to keep in sync.

No issues found. The doc's IAM policy example uses wildcard resource ARNs (cluster:*, db:*) rather than a specific instance/cluster ARN — reasonable for a generic runbook example, not a correctness problem.