RTO/RPO Planning

Turn AISIX's scenario-by-scenario recovery behavior into the Recovery Time Objective and Recovery Point Objective figures your own SLA needs, without a blanket number AISIX does not publish.

Disaster Recovery is explicit that AISIX does not publish one blanket Recovery Time Objective (RTO) or Recovery Point Objective (RPO) covering every deployment and failure mode — there is no single number to plug into a customer-facing SLA. What it does publish, scenario by scenario, is the concrete recovery characteristic of each failure mode: what is lost, what keeps running, and what has to be restored. This page walks through turning those characteristics into the RTO/RPO figures your own SLA needs, scenario by scenario, rather than asserting numbers AISIX itself does not commit to.

This page assumes you have already read Disaster Recovery for the full scenario descriptions. It restates only what each scenario implies for RTO and RPO, then shows how to translate that into a commitment.

Why There Is No Single Number

RTO and RPO are properties of your deployment choices — whether you run High Availability's active-active pattern, whether snapshot_cache_enabled is turned on, how often you back up your database, whether your external Postgres is itself replicated — not properties AISIX imposes uniformly. Two organizations running the same AISIX version can have materially different RTO/RPO for the same failure mode purely based on those choices. A blanket number would either overstate what an unprepared deployment can actually achieve, or understate what a well-prepared one does achieve — neither is useful in a contract.

Translate Each Scenario Into Your Own Numbers

For each scenario, Disaster Recovery states the mechanism; the table below states what to measure in your own environment to turn that mechanism into a number.

Scenario	RTO driver	RPO driver	What to measure in your deployment
Region or AZ loss, with active-active HA	Time for your global load balancer to detect the loss and stop routing to it — not an AISIX-side recovery step at all	Near zero for the traffic path; gateways hold no state of their own	Your load balancer's own health-check interval and failover time.
Region or AZ loss, single deployment	Time to redeploy gateway instances elsewhere and have them reconnect and pull configuration	Near zero if the control plane survives — a redeployed gateway pulls current configuration with nothing to reconstruct	Your own infrastructure-as-code or runbook time to stand up a replacement gateway deployment.
Control-plane connectivity loss	Not applicable while disconnected — gateways keep serving their last accepted configuration	Usage telemetry generated during the outage is dropped, not delayed, once it exceeds the batch buffer; budget decisions reuse the last cached decision for up to `AISIX_DP_BUDGET_STALE_MAX_SECONDS` (default 600 seconds) before falling back to the configured failure mode	Whether you have changed `AISIX_DP_BUDGET_STALE_MAX_SECONDS` from its default, and whether that default is acceptable for your budget-enforcement SLA.
Control-plane loss, HA pattern	Self-heals: a failed replica is replaced automatically	Whatever your HA Postgres endpoint's own RPO is	Your Postgres HA topology's own documented failover and replication lag.
Control-plane loss, single instance	Time to restart the instance, plus a full database restore if the database was also affected	Bounded by your backup cadence — data since the last backup is at risk	How often you actually run the recommended daily backup, and how long your last restore drill took.
Gateway fleet loss	Time to redeploy instances and have them re-authenticate over mTLS and pull configuration	Near zero — gateways hold no state beyond a certificate bundle and, if enabled, a snapshot cache	Your redeploy automation's own time; whether `snapshot_cache_enabled` and its backing volume are part of your fleet template.
Database loss, bundled Postgres	Full restore only — no failover exists for a single-host bundled database	Bounded by your backup cadence	Same as the single-instance control-plane row above; this is the same restore procedure.
Database loss, replicated external Postgres	Whatever your Postgres cluster's own failover takes	Whatever your Postgres cluster's own replication lag is	Your DBA team's documented HA Postgres RTO/RPO — AISIX has no scenario-specific procedure here beyond what your database layer already provides.

Build Your SLA Clause From These Rows

A defensible RTO/RPO clause names the scenario and the deployment choice it depends on, rather than a single blended number:

Pick the scenarios your SLA needs to cover — typically region loss, control-plane loss, and database loss, since those are the ones a customer's own risk assessment usually asks about.
State the deployment choice each row assumes. An RTO/RPO claim for region loss is only valid if you actually run the active-active HA pattern; state that assumption in the clause, or the SLA is describing a deployment you do not run.
State the measured number, not the mechanism. "Gateway fleet loss recovers in under N minutes" is a testable SLA line; "gateways are stateless" is the mechanism behind it, not a number a customer can hold you to.
Re-measure after any topology change. Changing your backup cadence, enabling snapshot_cache_enabled, or moving from a single-instance to an HA control plane changes the numbers in the table above — treat an SLA clause as tied to a specific topology, not to AISIX in the abstract.

Validate the Numbers With a Drill

A number derived from reading this table is a hypothesis until you have run the scenario. Disaster Recovery already describes how to run one: pick a scenario, simulate it for real in a non-production environment, and record the actual time to recovery and what was lost. Use that measured result as your SLA number, not the theoretical one from this page — a drill's result is the only figure you can defend if the scenario actually happens.

Next Steps

Disaster Recovery — the full scenario descriptions this page's table summarizes.
High Availability — the active-active deployment pattern several rows above assume.
Backup and Restore — the backup cadence and restore procedure that bounds RPO for database-loss scenarios.