Making AWS EFS Replication play nice with Terraform for disaster recovery

Question

How do I use EFS block replication for disaster recovery when the replica volume is unknown to terraform? After breaking the replication/mirror I need to import the volume into the plan so it can become the new main with it's own replica.

This seems really cumbersome. Is this really the best way for a DR scenario?

Use case We have a Jenkins using an EFS volume and presently use datasync tasks to migrate data to the DR region. However, datasync tasks are like rsync and sluggish as they walk the tree processing files. Whereas, EFS replication is block based and much faster.

1. terraform creates region A volume + access and replication in region B + access
2. At some point region A goes down
3. We delete the replication from A -> B transforming region B EFS volume to writable and our primary volume
4. We create a replication from this volume back to region A
5. Allow sync
6. Delete replication making region A replica the main volume

Terraform sync issues After step 3 we've got a main volume in region B that terraform would need to know about as terraform should be making the replica in region A

After step 6 we've got the same problem in region A

Questions

• Can someone point to a good example of an automated end of end process?
• Is this a case of "import the infra into tf state" as an automated part of the DR process?

Answer 1

Reading your usecase it seem that the solutions your are looking for is the refresh state of terraform

• https://developer.hashicorp.com/terraform/cli/commands/refresh

Allowing you to refresh your state from the current architecture running without applying any diff