Aurora PostgreSQL: "process took" in ZDP event for reader instances reports massively inflated time compared to actual wall-clock duration

Based on the available documentation about Aurora PostgreSQL zero-downtime patching (ZDP), the "process took" metric in ZDP events is intended to report the actual duration of the upgrade operation. The documentation shows examples where this metric accurately reflects the time between the "Attempting" and "finished" events, such as "The process took 3485 ms, 378 connections preserved, 0 connections dropped."

However, the specific behavior you're observing—where reader instances report dramatically inflated "process took" values (30x to 270x larger than wall-clock time) while writer instances report accurate values—is not explicitly documented or explained in the available AWS documentation about Aurora PostgreSQL upgrades or ZDP operations.

The documentation does note that during minor version upgrades of Multi-AZ DB cluster deployments, Amazon RDS upgrades reader DB instances one at a time, then switches one reader to become the new writer, and finally upgrades the old writer instance. This sequencing could potentially involve internal timing mechanisms that differ between writer and reader upgrades, but there's no documented explanation for why the reported metric would be so significantly different from actual elapsed time.

Given that this discrepancy appears consistent across your 14 clusters and the magnitude of the difference is substantial, this could represent either an undocumented behavior in how the timing is calculated for reader instances, or potentially a reporting issue. I would recommend opening a support case with AWS to get clarification on whether this is expected behavior and what the "process took" metric actually measures for reader instances during automatic minor version upgrades.
Sources
Use ZDP for Aurora PostgreSQL DB cluster upgrades | AWS re:Post
Upgrades of the RDS for PostgreSQL DB engine - Amazon Relational Database Service

That is exactly why I posted my analysis here — I expect this might be a calculation bug, and I hope this discrepancy will be brought to AWS's attention.