Interpret disaster-recovery test evidence and prepare recovery reports

What the source reports

In an AWS article coauthored by Nubank staff, the bank describes One Step Execution for controlled disaster-recovery exercises. Argo orchestrates synthetic traffic and fault injection; AWS FIS bounds the experiment and ends faults. An internal service supplies the AWS DevOps Agent with the scenario, time window and recovery conditions. Through internal MCP servers, the agent correlates metrics, logs and alerts and generates a report for engineers. Three scenarios cover unavailable zones, unavailable clusters and simulated data destruction. The article reports platform-level results across nine tests in 2026; it does not isolate the agent’s contribution.

Reported technology: AWS DevOps Agent, AWS FIS, Argo Workflows and K6. Scope and outcomes are source-reported.

What the enterprise environment would need

The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.

Proposed enterprise environment

Use a disposable service replica with synthetic transactions, pinned recovery objectives, bounded fault scenarios and read-only evidence access. Keep fault permissions separate from the report-writing agent.

Proposed practice project

Prepare a recovery report from a fixed experiment window, attach each conclusion to telemetry, identify conflicting signals and hand unresolved recovery claims to the responsible engineer.

People and agent responsibilities

In this proposed practice, the agent drafts evidence-linked findings. Engineers approve the experiment boundaries and independently accept or reject recovery claims; a risk owner reviews the final evidence package.

A proposed simulation

An illustrative practice design derived from this work, not an executed assessment.

Proposed: produce an evidence-linked recovery report that exposes uncertainty before operational acceptance.

Review gate: A reviewer can reproduce every recovery conclusion from the supplied evidence and identify every unresolved objective.

Challenge the result: Provide healthy infrastructure metrics alongside failed synthetic customer transactions; the report must withhold a successful-recovery conclusion.

What needs checking

• Proposed: an independent checker compares each reported recovery assertion against fixed synthetic transaction outcomes and recovery-objective measurements.
• Proposed: verify that evidence outside the approved test window cannot silently influence the recovery conclusion.
• Proposed: confirm that stopping a fault does not automatically count as successful service recovery.

Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.

Shape this around your enterprise

Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.

Sources and limitations

Curation review: 31 October 2026. This is the date this source example was reviewed, separate from source publication dates.

• The source is an AWS and customer account, not an independent audit.
• The article does not provide the full test evidence, report-error rate or independent confirmation of regulatory acceptance.
• Published platform gains cannot be attributed solely to the agent; future scheduling and reporting plans are not current delivered scope.
• Proposed practice and checks are illustrative designs, not an executed Nuvepro demonstration.

1. AWS and Nubank: How Nubank automated disaster recovery with the AWS DevOps AgentSource publication: 2026-10-28