Native replication
Use a service’s replication path for supported state. Examples: new ECR pushes, S3 object replication or an approved database replica.
See the pattern →Recovery strategies
Explore how images, certificates, network controls, secrets, data and infrastructure fit together. These diagrams describe the Dockfield recovery design; each customer implementation is scoped and tested separately.
Select by service and recovery objective
A workload can combine several families. A container service needs its image, network, identity, secrets and data ready together. Configuration recovery and application data recovery have separate evidence and timing.
Use a service’s replication path for supported state. Examples: new ECR pushes, S3 object replication or an approved database replica.
See the pattern →Capture change events, inspect current configuration and reconcile mapped equivalents in DR. SGs and NACLs need a custom reconciler.
See the pattern →Reconstruct supported infrastructure from the recovery blueprint, in dependency order. Examples: VPC, load balancers, ECS and EKS.
See the pattern →Recover state from an approved restore point using service-native backup paths. Examples: RDS, Aurora and supported AWS Backup resources.
See the pattern →Create a valid destination resource and map its new identity. Example: ACM certificates for the target account and Region.
See the pattern →Keep routing decisions coordinated across the protected environments. ARC routing controls act on Route 53 health checks.
See the pattern →Manage applicable controls centrally, using delegated administration and service-specific regional settings.
See the pattern →Images · backfill + ongoing native replication
Existing images and future pushes follow different paths. The destination image must be available before ECS or EKS tries to start the recovered workload.
Configure native replication rules and destination registry permissions. Existing content needs its own copy path; check the destination digest and approved release.
Encryption, tag immutability, permissions and lifecycle rules need target configuration or suitable creation templates. Native image replication does not propagate source deletion.
AWS references: ECR replication
Certificates · reissue / reimport
Capture certificate intent: names, type, validation method and workload attachment. Request or import a certificate in the destination account and Region, then map its ARN into the recovered listener.
A source ACM ARN is not a destination certificate. Prepare issuance and DNS validation ahead of a recovery exercise; check the destination listener binding.
Discovery does not need private keys. Any import uses an approved secure key path. CloudFront certificates use us-east-1 even when the application is elsewhere.
AWS references: ACM Regions and usage · Import certificates
Network controls · reconcile + hold risky changes
These services do not provide native cross-account SG/NACL replication. A Dockfield reconciler uses change events as signals, reads the current configuration, maps references and applies approved target rules. Periodic reconciliation covers missed or delayed events.
| Control | Security Group | Network ACL |
|---|---|---|
| Placement | Resource / network interface | Subnet association |
| Traffic behavior | Stateful; allowed responses are tracked | Stateless; allow the required return path |
| Rule model | Allow rules; map referenced SG IDs | Ordered allow / deny rules; preserve rule numbers |
| Destination mapping | Target VPC, SG references and approved CIDRs | Target subnet associations, CIDRs and inbound / outbound rules |
Use supported CloudTrail write events and an enabled trail. Re-read authoritative configuration, handle retries idempotently and track reconciliation evidence.
Policy review covers changed access and associations as well as whole-resource deletion. Holding a change requires reviewer attention; retained access is a conscious temporary decision.
AWS references: EventBridge via CloudTrail · Network ACL behavior
Sensitive state · separate from discovery
Discovery inventories secret metadata and dependencies without calling GetSecretValue. Operational secret protection is a separate authorised path that handles encrypted values, KMS permissions, rotation and target endpoints.
Native regional replicas propagate secret updates and rotation. Use an appropriate target-region KMS key and verify that connection settings resolve to the intended recovered service.
Native regional replication is not cross-account replication. Choose a controlled synchronisation path or authorised shared access; shared access alone does not create an isolated copy. Cross-account access needs resource, identity and customer-managed KMS permissions.
AWS references: Regional replicas · Cross-account access
Stateful recovery · replica / backup / PITR
Select the data path separately from the infrastructure blueprint. RDS and Aurora use service-appropriate restore or replication patterns; DynamoDB, EBS, EFS and FSx require their own supported protection paths. Recovery-point selection, destination access and retention are tested explicitly.
The infrastructure capture interval is not the application data RPO. Restore duration, replication lag, retained restore points and the tested workload define the actual recovery evidence.
S3 existing objects can require Batch Replication separately from new-object replication. EFS, FSx and volume snapshots use the mechanisms supported for the chosen service, account and Region.
AWS references: RDS point-in-time restore · S3 replication scope
Declarative recovery · dependency order
The blueprint describes supported configuration and target mappings. Native state protection provides images and data; infrastructure automation reconstructs the surrounding service in dependency order.
Source account IDs, Regions, certificate ARNs, KMS keys, image locations and endpoint references require target mappings.
For Kubernetes, recover workload specifications and persistent data rather than transient pod IDs. The service needs real application checks beyond a healthy control plane.
Dockfield design pattern: supported service coverage and dependency mappings are defined during assessment.
Traffic · readiness → approval → routing action
Routing controls influence Route 53 health checks and DNS traffic. Dockfield’s human approval and validation gate is an application control; configured ARC safety rules complement it. The recovery engine builds the workload before a routing action is eligible.
An approved UI state does not demonstrate that routing controls changed. Record the control action and confirm the recovered service and DNS behavior.
Configure suitable safety rules, rehearse the approved transition and rollback, and account for DNS caching and client behavior.
AWS references: ARC routing control · ARC safety rules
Organisation controls · central configuration
Control Tower, AWS Config, Security Hub and GuardDuty have different organisation and regional configuration models. Use the applicable central administration pattern, then verify coverage, aggregation and permissions in every DR account and Region. IAM trust and KMS access remain explicit dependencies.
A central administrator does not automatically mean every destination is covered. Record the required enabled Regions, member accounts and evidence sources.
For each resource, record the strategy, destination mapping, owner, approval rule, protection evidence and last successful recovery test.
Free initial consultation
Start with one critical workload, its dependencies and a measurable recovery objective.