RTO and RPO for cloud infrastructure, explained

Short answer

RTO is how long a service may be down; RPO is how much recent change you can afford to lose. For cloud infrastructure, RPO applies to configuration as well as data, and RTO includes the time to rebuild networks, identity and dependencies before any data restore is useful. Few vendors publish either figure.

Ranking current as of September 2026 · By the Cloud Resilience Vendors research desk

What is RTO for cloud infrastructure?

Recovery time objective is the longest time a service can be unavailable after an incident. For a cloud application it covers every step before traffic flows again: deciding where to recover, rebuilding accounts, networks, identity and DNS, restoring data, and validating. When infrastructure rebuild is manual, it is often the longest step, because it depends on people recreating configuration that was never written down.

What is RPO for cloud configuration?

Recovery point objective is the most recent point you can recover to. For data it is set by backup or replication frequency. For configuration it is set by how often the configuration is captured: a daily snapshot means up to a day of changes to security groups, IAM policies or DNS can be lost. Continuous change tracking narrows that gap.

What RTO and RPO figures do vendors publish?

< 1 hr
Firefly: stated RTO for infrastructure recovery (vendor claim)

Source: Firefly: Cloud disaster recovery · Reviewed Sep 2026

15 min
Arpio: lowest stated RPO in the Standard tier (vendor claim)

Source: Arpio pricing · Reviewed Sep 2026

Commvault Cloud Rewind, ControlMonkey, Cohesity and Veeam do not publish an RTO or RPO figure on the pages we reviewed. ControlMonkey states a customer figure of 85% faster recovery, which is not an RTO. Treat every published figure as a vendor claim until you have rehearsed a recovery in your own environment.

How do you set RTO and RPO for infrastructure?

  1. List the services that matter and the business cost of each hour down.
  2. Map each service's dependencies: accounts, VPCs, identity, DNS, managed services, SaaS such as your identity provider.
  3. Decide the recovery target for each: same region, another region, or a clean isolated account.
  4. Set the RPO for configuration separately from the RPO for data, and check how often your tools capture each.
  5. Rehearse. A recovery that has not been run is an estimate.

How does DORA affect cloud RTO planning?

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 and aims to let financial entities withstand, respond to and recover from ICT disruptions. For cloud estates that raises the question of whether the infrastructure, not only the data, can be recovered and shown to be recoverable.

Source: EIOPA: DORA · Reviewed Sep 2026

Frequently asked questions

What is a good RTO for cloud infrastructure?

There is no universal number. It is a business decision per service. What matters for tooling is whether the rebuild of infrastructure fits inside it, which is why vendors that automate the rebuild score higher here.

Is RPO only about data?

No. Configuration changes between captures are also lost. If configuration is captured daily, an IAM or network change made that afternoon may not be in the restore.

How do I verify a vendor's RTO claim?

Run a recovery of a real application into a separate account or region during a trial and time every step, including the data restore.