RPO and RTO tiers for an insurer's claims platform

First, check separability. If the brokers' rows live in the same 1.4 TB database as every other customer, no feature can give them a different RPO - replication, failover and backup are per database. The first design decision is to move those customers into their own database, which is a data-migration project and must be scheduled as such.

For that database: Business Critical (local SSD, includes a readable secondary), zone-redundant, with an auto-failover group to the secondary region. The failover group gives a stable read-write listener endpoint, so the brokers' connection strings do not change on failover, and automatic failover with a grace period avoids a manual decision at 03:00.

Be honest about the guarantees:

• Geo-replication is asynchronous. Five seconds is typical, not guaranteed; a sustained write burst on a saturated primary can exceed it. Do not sign a contract that treats it as a hard limit without saying so.
• The 2-minute RTO covers failover plus DNS TTL plus application reconnect. Test it with a planned failover and measure end-to-end, not the portal's "failover completed" timestamp.
• A truly guaranteed 5-second RPO needs synchronous commit, which means the application acknowledging writes - that is an application and contract discussion, not an infrastructure setting.

Adopt it, but for the right reason, and do not substitute it for the failover group.

• Zone redundancy keeps replicas across availability zones within West Europe. A cooling failure that takes out one datacenter becomes a failover to another zone, typically with no data loss and an outage measured in minutes rather than the 3 hours observed. It requires explicit selection (general purpose zone redundancy is not offered in every region) and adds cost for the extra replicas.
• It does nothing for a region-wide event and provides no geo-secondary. A regional outage still needs the failover group or a geo-secondary.

So the two answer different questions: zone redundancy covers the incident you actually had; the failover group covers the incident the auditors care about.

Order of work: enable zone redundancy on the General Purpose database and the Managed Instance first, since that is the demonstrated risk and the cheapest fix per unit of downtime avoided; then build the failover groups. Verify the tier/region supports zone redundancy before promising a date, and confirm the application retries connections - a fast platform failover is still visible as a dropped connection to the app.

You cannot. Three hours forty minutes leaves about twenty minutes of margin against a four-hour commitment, and a real failover at peak load would be slower - plus initiating the restore and repointing the application are manual, untested steps.

Use a warm secondary instead of restore. Put the portal database in a failover group (or active geo-replication) to the secondary region. The data is continuously copied, so recovery becomes a metadata operation that repoints the listener - comfortably inside four hours - and the RPO improves from "up to an hour" to seconds, which also satisfies the auditors' 15-minute requirement for the Managed Instance once an instance failover group is configured.

The trade-off is real: a secondary is compute you pay for continuously. Address it by sizing the secondary to the capacity you actually need on day one of a disaster and scaling up after failover - verify tier and size compatibility for the pair before committing, and rehearse a planned failover quarterly with recorded timings.

Keep geo-restore and long-term retention for what they are good at: recovering from logical corruption or a bad deployment (point-in-time restore) and answering "restore last March" audit requests.