How to Migrate an EFS Filesystem Across AWS Accounts Using Only AWS Services

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.

AWS EFS filesystem through Backup / Datasync

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

Overwhelmed by AWS?

Struggling with infrastructure? We streamline your setup, strengthen security & optimize cloud costs so you can build great products.

Related AWS best practices blogs

Looking for more interesting AWS blog posts?

Amazon Cognito vs. Auth0: Why Cognito is a Nightmare

Choosing between Amazon Cognito and Auth0 for authentication? One is cheap but frustrating, the other is powerful but expensive—so which one actually works?

Read more

Reduce AWS Fargate pull times with SOCI

One of the major drawbacks of AWS Fargate is that the pull times are relatively slow (compared to EC2). This is because EC2 nodes can have a local image cache on the instance. Fargate is serverless co ...

Read more

Get a cheap VPN into your AWS VPC and worldwide performance improvement through Cloudflare tunnels

In this article you can read about cheap VPN for your AWS VPC and better performance through Cloudflare tunnels.

Read more

How to solve 'Inaccessible-encryption-credentials' in AWS RDS

When your KMS key has been deactivated due to your AWS account being locked you might run into the issue that your database won't start, this blog post contains the solution.

Read more

Verifying S3 Gateway Endpoints: Why AWS Should Make It Easier

AWS recommends using traceroute to verify S3 Gateway Endpoints, but isn't there a better way?

Read more

Why Managed AWS Should Be the Default for Growing SaaS Companies

Managed AWS enables SaaS companies to focus on their own product while ensuring scalability, security, and operational efficiency.

Read more

Wiz Alternatives: What’s Next After Google’s Acquisition?

With Wiz now part of Google, multi-cloud security teams are questioning its future neutrality. If you rely on AWS, Azure, and GCP, can you trust that Wiz won't become GCP-first? Let’s break down what ...

Read more