A regional utilities consortium tightened RPO for SCADA historian data replicated to AWS. The current design uses infrequent cross-Region snapshot copy that can lose many hours of telemetry. Which reliability change best matches the new RPO?
Select an answer to reveal the explanation.
Short Explanation
If the new RPO says “minutes,” a weekly suitcase of snapshots will not cut it. Pick a replication rhythm that actually matches how much telemetry the consortium can afford to lose.
Full Explanation
A regional utilities consortium that tightened RPO for SCADA historian data replicated to AWS cannot keep infrequent cross-Region snapshot copy that may lose many hours of telemetry. Revisiting replication methods—more frequent cross-AZ or continuous cross-Region replication appropriate to the data store—so recovery points meet the tightened utilities RPO is the reliability change required. That change works because RPO is a maximum tolerable data-loss window; snapshot cadence must be at least as frequent as that window, or continuous replication used. Keeping weekly snapshot copy and accepting multi-day data loss fails the new RPO by definition. Stopping all replication to reduce transfer costs while claiming RPO zero fails conceptually and factually. Storing historian data only in instance store volumes for write speed fails durability and recovery for SCADA telemetry. Exam caveat: continuous replication has cost and conflict-handling implications; pick mechanisms native to the historian store (database replication, AWS Backup frequency, etc.) rather than a generic slogan. Operational check: calculate current snapshot-copy data-loss window, select a replication mode that meets the new RPO, run a restore/failover drill measuring actual loss, and update the utilities continuity evidence pack.