AWS Backup: The Foundation of Your Cross Account EFS Migration
AWS Backup has matured into a robust service capable of managing cross-account backups with minimal setup. Before jumping into backup policies and copy jobs, the very first thing you need to do is enable the cross-account backup feature at the AWS Backup settings level. You’ll find it under Backup Settings in the console—toggle the option to allow cross-account backups.
Without this setting enabled, everything else fails silently. It’s the AWS way: they let you configure the rest of the pipeline, but block actual execution unless this is toggled.
Next up, enable automatic backups on your EFS filesystem. If you're starting from an unprotected filesystem, go to your EFS settings and enable the daily backup feature. This will register the EFS with AWS Backup and create recovery points in the default backup vault.
Wait for the first backup to complete. After it appears in the “Default” backup vault, we need to override a security default that AWS sneakily applies—by default, cross-account copy actions are blocked. You’ll need to edit the backup vault’s access policy.
Replace XXXX
below with the source account ID (yes, the one that owns the EFS):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::XXXX:root" }, "Action": [ "backup:DeleteBackupVault", "backup:DeleteBackupVaultAccessPolicy", "backup:DeleteRecoveryPoint", "backup:StartCopyJob", "backup:StartRestoreJob", "backup:UpdateRecoveryPointLifecycle" ], "Resource": "*" } ] }
This policy is key—it allows the source account to initiate the cross-account copy. Without it, your copy job will throw opaque “Access Denied” errors.
Configuring the Destination Vault for Cross-Account Access
Switch over to the destination AWS account where you want the filesystem to land. Here, create a new backup vault. It doesn’t matter what name you use, but you’ll want to make sure it has a compatible access policy.
Replace XXX
in the policy below with the source account ID:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::XXX:root" }, "Action": "backup:CopyIntoBackupVault", "Resource": "*" } ] }
This allows the source account to push recovery points into this new vault.
Performing the Cross Account Copy
Now head back to the source account, find the EFS backup recovery point in the AWS Backup interface, and select Copy. Choose “Copy to another account” and enter the destination account ID and the vault name you just created. You can use the default AWSBackupDefaultServiceRole unless you have custom roles set up.
Once the copy job begins, it’ll show up in the AWS Backup console. Track the progress—these copy jobs can take a while depending on EFS size, but they're resilient and retry automatically in case of issues.
Restoring the Backup in the Destination Account
After the copy finishes, go to the destination account, open AWS Backup, and find the recovery point in the new vault. Hit Restore, and AWS will create a brand-new EFS filesystem.
Here’s the limitation: you can’t restore into an existing filesystem. The restoration always spins up a fresh EFS instance. That’s not a bug, it’s a constraint of how cross-account backup restores are handled.
Once the restore is complete, you now have a live EFS filesystem in the destination account—one that’s an exact snapshot of the original.
Transferring Contents to an Existing Filesystem (Optional)
Maybe you need the data in an existing EFS—perhaps it’s wired into IAM permissions or attached to a workload you don’t want to disrupt. In that case, you’ll need to copy contents from the new restored filesystem to your existing one.
Before doing that, we strongly recommend you set the throughput mode to Elastic on the destination filesystem. This allows for higher bandwidth during the copy job, which can drastically reduce the migration time.
Then use AWS DataSync to transfer the files. Create a DataSync task between the restored filesystem (source) and the existing filesystem (destination). This will copy the contents into a subdirectory on the destination, so after the transfer is done, you’ll need to SSH into an EC2 instance with mount points to both filesystems and move the contents into the root directory as needed.
Once you're satisfied with the data placement, feel free to switch the EFS back to bursting mode to optimize cost.
Clean, Auditable, and All-Native
What makes this process so powerful is that it’s entirely based on AWS-native tools. No third-party backups, no complex replication pipelines, no vendor lock-in. You get full auditability via CloudTrail, IAM policies control access at every step, and backup copies are encrypted and lifecycle-managed by default.
Cross account EFS migration doesn’t have to be a devops nightmare. If anything, it’s now easier than ever to execute securely with AWS Backup and DataSync—just be aware of the permissions and access policies, and you’re set.

Migrating AWS EFS cross-account might seem like a daunting task