Two mechanisms, one vCPU floor: why db.t3.micro cannot meet a 1-second RPO on RDS

A writeup on dev.to takes an AWS exam-style requirement set and actually builds it: a financial application on RDS for PostgreSQL with a 1-second RPO, a 60-second RTO, and database credentials rotated every 30 days without taking the application offline [s1c1]. The author's framing is that this is two independent problems with two independent solutions [s1c15], and the interesting part is not the architecture, which is predictable, but the preconditions that must hold before terraform apply does anything useful [s1c15].

Take the recovery side first. A single-instance RDS deployment fails both numbers: there is no automatic failover, and restoring from backup takes far longer than 60 seconds [s1c5]. Multi-AZ fixes the data loss half by keeping a synchronous standby in a second Availability Zone, with every write committed to the standby before the transaction is acknowledged, which the writeup puts at typically under 1 second of RPO for PostgreSQL [s1c6]. On failure, RDS promotes the standby and updates the endpoint DNS record, usually inside 60 seconds [s1c7].

That is where the paper answer diverges from the operational one. During the DNS change, existing connections are dropped, and a connection pool spends real time re-establishing them and waiting for propagation, which under load surfaces as errors [s1c8]. RDS Proxy holds a warm pool in front of the database, detects the new primary and reroutes internally while the application's connection to the Proxy stays up [s1c9]. Without it, according to the writeup, Multi-AZ may meet the 60-second RTO on paper while still producing application-level errors [s1c10].

The rotation half is Secrets Manager plus the AWS-provided rotation Lambda for RDS PostgreSQL, which generates a password, sets it in RDS, updates the secret and verifies it works [s1c11]. The staging-label sequence matters: the new password is set in the database before it becomes AWSCURRENT, so old and new credentials are both valid during the transition window [s1c12]. At a 30-day cadence that is roughly 12 transition windows a year ^[1], each one a chance for a stale connection to fail if nothing is mediating.

Here is the coupling the "two independent solutions" framing understates. The Proxy is also the component that reads credentials from Secrets Manager, so the application never handles them and picks up rotated passwords on the Proxy's next refresh [s1c13]. One component is therefore load-bearing for both requirements, which is why the instance-type precondition is not a sizing footnote: RDS Proxy requires at least 2 vCPUs, db.t3.micro is unsupported, and db.t3.medium and above work [s1c2]. Choose the cheapest instance and you do not lose a nice-to-have, you lose the mechanism both the RTO and the rotation story depend on.

The rest of the checklist is the usual quiet failure surface. The Proxy runs in your VPC and needs at least two private subnets in different AZs, and the rotation Lambda also runs in-VPC so it can reach the instance during the credential update [s1c4]. The Terraform principal needs 17 actions across five services, spanning instance and proxy creation, target group registration, IAM role creation and PassRole, secret creation and rotation, Lambda creation, and security group and subnet group setup [s1c3]^[2]. AdministratorAccess covers it, and the author's advice is to lock it down afterwards [s1c3].

Three things to check before trusting this. The list as printed puts CreateDBSubnetGroup under an ec2: prefix [s1c3], worth verifying against your provider's actual API surface. The Proxy's credential refresh interval is described only as "next refresh cycle", with no number attached [s1c13]. And the module layout stops at outputs in the published text [s1c14], so the failover behaviour under load is still something you test yourself.