01
Discover
Read-only production discovery captures the agreed AWS scope and dependencies.
Dockfield DRaaS
Continuous recovery assurance for AWS.
Dockfield DRaaS combines live discovery, recovery-state management, quarantine, security validation, isolated testing, recovery orchestration and evidence into one controlled operating model.
The DRaaS lifecycle
Every recovery state has a gate.
The newest snapshot is not automatically the safest snapshot. Dockfield separates collection, trust, validation, approval and traffic promotion.
02
Blueprint
Resources are classified by recovery strategy and mapped to the target account and Region.
03
Tier 0 trust
Provenance, integrity, Terraform validation, Checkov, Trivy, secret exposure and policy checks run before recovery.
04
Quarantine
Failed, suspicious or destructive changes are held outside the promotable recovery path.
05
Isolated recovery
Approved recovery is built or restored inside the DR trust zone without serving production traffic.
06
Tier 1–3 validation
Infrastructure/security, smoke tests, application behaviour and data are validated in sequence.
07
Promotion approval
Traffic remains locked until evidence passes and an authorised decision opens the gate.
08
ARC / traffic control
When configured, ARC routing controls or an approved routing mechanism move traffic only after promotion approval.
09
Evidence & repeat
Manifests, test results and approvals are retained, and the cycle repeats as production changes.
Seven recovery strategy families
Use the AWS-native mechanism that fits the resource.
SHARED CONTROL PLANE
Keep resilient control services shared where architecture and blast-radius analysis support it.
NATIVE CONTINUOUS REPLICATION
Use AWS-native continuous replication for services designed to replicate state across Regions or accounts.
EVENT-DRIVEN MIRROR
Mirror recovery-relevant configuration changes through governed events rather than waiting for a full rebuild.
DECLARATIVE REBUILD
Recreate recoverable infrastructure from a continuously refreshed blueprint in the DR trust zone.
NATIVE BACKUP / PITR
Recover data from governed backups, logs or point-in-time recovery boundaries appropriate to the service.
REISSUE / RECREATE
Reissue certificates, secrets or trust material that should not be copied blindly across security boundaries.
ORG CENTRAL CONFIG
Reuse centrally governed organisation-level configuration where that is the safer recovery model.
Security, scanners and recovery proof
Trust is earned before traffic moves.
Artifact trust
Terraform validation plus policy and security scanners such as Checkov and Trivy. Provenance, integrity, secrets, encryption, privilege, public exposure and destructive-change signals are assessed.
Infrastructure & security
The recovered foundation is checked for expected networks, routes, controls, identity, encryption, logging and service prerequisites.
Isolated smoke tests
The DR environment runs without serving production traffic. Health, reachability, service discovery and critical dependency checks must pass.
Application & data
Business-facing application behaviour and data readiness are validated before promotion becomes eligible.
Hold and investigate
Anything that fails policy, introduces destructive risk or needs human review stays quarantined and cannot be promoted.
Record the decision
Dockfield retains the recovery manifest, validation status, approvals and exercise outcome so the recovery path is explainable after the event.
Service operating model
From one-off recovery engineering to continuous assurance.
| Capability | DRaaS | DR-as-Code |
|---|---|---|
| Live AWS discovery | Continuous / scheduled | Project snapshot and agreed refresh workflow |
| Recovery blueprint | Continuously refreshed | Generated and handed over |
| Quarantine & validation | Operational lifecycle | Implemented pipeline and runbook |
| Recovery exercises | Recurring service activity | Handover test / optional follow-on |
| ARC / traffic promotion | Controlled operational path where configured | Architecture and automation delivered to the client |
| Evidence | Continuous recovery evidence | Project evidence pack and code ownership |
What we will and will not claim
Recovery objectives need evidence.
Target, then prove
Sub-hour recovery can be a design target for a bounded scope. It becomes credible only after repeated timed tests support it.
Owned by the data path
Infrastructure capture cadence does not create zero data loss. Replication, logs, consistency and the incident boundary determine the recoverable point.
Service-specific
Not every AWS service uses the same mechanism. Dockfield classifies each resource and records gaps rather than pretending one executor can recover everything.
Separate trust zones
Production discovery is read-only. Recovery writes are constrained to the DR trust zone and approved native replication paths.
Never implicit
A healthy DR environment can be promotion-eligible without serving traffic. Traffic movement remains an explicit operational decision.
Representative slice
The public demo proves the lifecycle on a scoped ECS recovery slice; it is not a claim that the demo rebuilds an arbitrary enterprise estate unchanged.
Free initial consultation
Turn recovery evidence into an operating discipline.
Discuss the AWS scope, recovery objectives and a practical DRaaS onboarding path.