{"id":852,"date":"2024-09-30T17:53:00","date_gmt":"2024-09-30T17:53:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=852"},"modified":"2024-09-30T17:53:00","modified_gmt":"2024-09-30T17:53:00","slug":"transfer-efs-data-datasync","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=852","title":{"rendered":"Transfer EFS data between AWS Accounts Using AWS DataSync"},"content":{"rendered":"

In this blog, you will learn how to migrate EFS data from one AWS Account to another using AWS Datasync.<\/p>

I have given step by step instructions along with screenshots for this guide.<\/p>

EFS to EFS DataSync Workflow<\/h2>

The following image shows the high level workflow of EFS to EFS data transfer using Datasync.<\/p>

\"EFS<\/figure>

Here is how it works.<\/p>

  1. DataSync Agent EC2 instance will be created in the source account within the same region and subnet.<\/li>
  2. The DataSync Agent can access the source EFS via its mount point.<\/li>
  3. A VPC<\/a> Peering connection (cross account) from the source to the destination secures private communication between networks.<\/li>
  4. A VPC Endpoint<\/a> will be created in the destination account for the AWS DataSync Service, enabling secure communication.<\/li>
  5. The DataSync Agent instance in the source account writes data to the destination EFS account through the VPC Endpoint using ENIs.<\/li>
  6. AWS DataSync encrypts the data during transfer and allows scheduling and filtering it during migration.<\/li><\/ol>

    EFS to EFS DataSync Transfer Steps<\/h2>

    Follow the steps given below to setup Datasync for EFS to EFS data transfer.<\/p>

    Step 1: Source Account Elastic File System (EFS)<\/h3>

    I already have an Elastic File System with data in the source account.<\/p>

    \"source<\/figure>

    We can mount this to a server to check the available data in the file system.<\/p>

    I am mounting this EFS to an EC2 instance. For that, we need the EFS DNS name<\/strong> and other details.<\/p>

    \"source<\/figure>

    The following window will give the mount command with the File System DNS name.<\/p>

    \"source<\/figure>

    Create an EC2 instanc<\/a>e with Amazon Linux AMI, and use the following command to add the Network File System client.<\/p>

    sudo yum install -y amazon-efs-utils<\/code><\/pre>
    Create a directory to mount the File System<\/p>
    mkdir efs<\/code><\/pre>
    Paste the mount command from the above screenshot.<\/p>
    sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <EFS_DNS_NAME>:\/ efs<\/code><\/pre>
    After mounting the file system, we can view the available data in the efs<\/strong> directory.<\/p>
    \"source<\/figure>
    Now, we will migrate this data to another EFS situated on another AWS account.<\/p>
    Ensure the EFS has mount points; otherwise, it cannot connect with other services.<\/p>
    \"source<\/figure>
    Step 2: Create VPCs in Both Accounts<\/h3>
    First, we need to create a VPC<\/a> in both accounts, and the CIDR values of both VPCs should be different.<\/p>
    Source AWS Account<\/h5>
    Here, the source account VPC CIDR is 172.16.0.0\/16, <\/strong>and the region I have chosen is us-west-2<\/strong>.<\/p>
    \"source<\/figure>
    Destination AWS Account<\/h5>
    For the destination account, I have chosen the 10.0.0.0\/16<\/strong> CIDR VPC, and the region is us-east-1<\/strong><\/p>
    \"destination<\/figure>
    Step 3: VPC Peering<\/h3>
    We use the Peering connection method to establish private communication between two different networks.<\/p>
    Source Account<\/h5>
    First, we must establish the peering connection request from the source VPC.<\/p>
    \"establish<\/figure>
    On the next page, provide the required information.<\/p>
    \"aws<\/figure>
    After creating the peering connection, the request goes to the destination account, so we need to accept the request from the destination account.<\/p>
    Destination Account<\/h5>
    The peering connection won’t be established until the request is accepted.<\/p>
    \"destination<\/figure>
    Step 4: Update Route Table<\/h3>
    We need to modify both VPC route tables to route the traffic between the two networks via the peering connection.<\/p>
    Source Account<\/h5>
    First, we updated the source account’s VPC Route Table Rules.<\/p>
    \"source<\/figure>
    Edit routes to add new routes. For the new route, the Destination<\/strong> is the destination VPC CIDR 10.0.0.0\/16<\/code> , and the Target<\/strong> is the Peering Connection.<\/p>
    \"source<\/figure>
    Destination Account<\/h5>
    We update the destination account’s route table with the source VPC details.<\/p>
    \"destination<\/figure>
    Step 5: Install Datasync Agent Instance<\/h3>
    We need to create a Datasync AWS EC2 Agent instance in the source account.<\/p>
    The DataSync Agent instance should be in the same region and network as the source EFS to effectively read the data and reduce latency.<\/p>
    Source Account<\/h5>
    To transfer data between EFS systems, we need a data transfer agent so that the agent can get the data from the source and store it in the destination file system.<\/p>
    To get the AMI of the DataSync Agent, use the following command.<\/p>
    You can use the cloud shell to run this command.<\/p>
    aws ssm get-parameter --name \/aws\/service\/datasync\/ami --region us-west-2<\/code><\/pre>
    From the output, we can get the DataSync Agent AMI ID.<\/p>
    \"get<\/figure>
    Create an EC2 instance using this AMI ID.<\/p>
    \"Datasync<\/figure>
    The AMI will be available in the community AMI’s section.<\/p>
    \"filter<\/figure>
    Note: The DataSync Agent should be created in the same network as the Source EFS to ensure it can access the EFS.<\/blockquote>
    \"dayasync<\/figure>
    Step 6: Create a VPC Endpoint in the Destination Account<\/h3>
    We need a private VPC endpoint<\/strong> in the destination account to transfer data securely to an AWS service.<\/p>
    Destination Account<\/h5>
    Navigate to the VPC dashboard and select the “Endpoints<\/strong>” tab.<\/p>
    \"creation<\/figure>
    In the next window, we need to choose the Service category<\/strong> as “AWS Service<\/strong>” because we are using this for internal service communication.<\/p>
    \"selecting<\/figure>
    In the following section, select the AWS Service, destination VPC, Subnets, and Security group<\/strong> to attach to the VPC endpoint.<\/p>
    \"choosing<\/figure>
    \"select<\/figure>
    Step 7: Setup DataSync in Destination<\/h3>
    In the destination account, we need to set up the DataSync Agent<\/strong> with the VPC Endpoint<\/strong> and create source and destination locations<\/strong> with that Agent to perform the data sync between accounts.<\/p>
    Prerequisite<\/h5>
    We need the IP address<\/strong> of the source account DataSync Agent instances<\/strong> for AWS DataSync activation.<\/p>
    Source Account<\/h5>
    If your browser can access the Private IP of the Source DataSync Instance, you can use it to activate it. Otherwise, you use the public IP of the instance for the activation.<\/p>
    \"aws<\/figure>
    Note: <\/strong>If you haven’t establised a VPN connection, you cannot use the Private IP for DataSync Agent activation.<\/blockquote>
    Refer to this blog to learn how to set up the AWS Client VPN<\/a>.<\/p>
    Destination Account<\/h5>
    Open the AWS DataSync<\/strong> Service from the destination account.<\/p>
    \"creation<\/figure>
    In the next window, choose the ‘Deploy agent<\/strong> as Amazon EC2<\/strong>‘, because our agent runs in the source as an EC2 instance.<\/p>
    In the ‘Service endpoint<\/strong>‘ section, select the VPC Endpoint we created in the previous steps.<\/p>
    The endpoint type should be VPC endpoints using AWS PrivateLink. <\/strong>We also need to select the VPC, Subnet, and security group.<\/strong><\/p>
    \"setup<\/figure>
    In the Activation key<\/strong> section, provide the Public IP of the source DataSync Agent instance.<\/p>
    \"selecting<\/figure>
    If you successfully activate the Agent, you will see the following output.<\/p>
    \"datasync<\/figure>
    Now, we can create the Agent.<\/p>
    \"setting<\/figure>
    Step 8: Create Destination Elastic File System (EFS)<\/h3>
    We must create a destination EFS<\/strong> to migrate data from the source EFS.<\/p>
    \"creation<\/figure>
    Provide the destination VPC and Security Group in the settings to create the EFS.<\/p>
    \"destination<\/figure>
    Step 9: Create DataSync Locations<\/h3>
    Before creating the locations, we need one of the Mount Point IPs<\/strong> of the source EFS.<\/p>
    Source Account<\/h5>
    \"copying<\/figure>
    Destination Account<\/h5>
    Now, create a location for the source and destination.<\/p>
    \"create<\/figure>\n\nFirst, we need to create a location for the source account. The location<\/strong><\/span> type<\/strong> should be NFS because the source EFS is in another account<\/span>\n\n
    \"setting<\/figure>
    Now, we need to create a location for the destination EFS.<\/p>
    \"setting<\/figure>
    Step 10: Setup DataSync Task<\/h3>
    Now, we can set up the DataSync task to perform the migration.<\/p>
    \"setting<\/figure>
    First, we need to configure the source location.<\/p>
    \"provide<\/figure>
    Then, configure the destination location<\/p>
    \"provide<\/figure>
    Both locations are now configured, and the other configuration settings are performed.<\/p>
    Provide a name for the task. In the ‘Source Data Option’ Section, choose between Everything and Specific files, objects, and folders.<\/strong><\/p>
    I need to transfer all data from the source account to the Destination account, so I am choosing Everything. However, you can exclude specific files, objects, or folders if required.<\/p>
    In the Transfer Options <\/strong>section, various configurations are available.<\/p>
    Transfer Mode<\/strong><\/h4>\n\n
      \n
    1. Transfer all data: <\/strong>This will not compare the source and destination files; instead, it will directly proceed with copying<\/span>.<\/li>\n\n\n
    2. Transfer only changed data:<\/strong> This option will compare the source and destination data before copying them. If any data is changed in the source or the destination doesn’t have that data, only the copy will happen.<\/li>\n<\/ol>\n\n
      Verification<\/h4>
      1. Verify all data:<\/strong> After transferring the data, verify all the source and destination data and ensure that the source and destination are properly synced.<\/li>
      2. Verify only transferred data.<\/strong><\/li>
      3. Don’t verify data after transferred<\/strong><\/li><\/ol>
        Bandwidth Limit<\/h4>
        1. By default, DataSync will use a maximum bandwidth limit to transfer the data, but we can limit the bandwidth if required.<\/li>
        2. We can always keep the files in the destination location even if it is deleted from the source location.<\/li>
        3. Overwrite the data when the source data has any changes.<\/li><\/ol>
          Additional Settings<\/h4>
          1. Copy Ownership: User and Group ID<\/li>
          2. Copy Permissions from the source<\/li>
          3. Copy Timestamps from the source<\/li>
          4. Queueing<\/li><\/ol>
            Note: Depends on the configuration, the on premises to AWS data transfer bandwidth can go upto 10 Gbps.<\/blockquote>
            \"configuration<\/figure>
            In the Scheduling<\/strong> section, we can manually trigger the sync or configure it to occur periodically.<\/p>
            In the Task Repot<\/strong> section, we can create a standard<\/strong> or summary only<\/strong> report about the sync and can be stored in an S3 Bucket.<\/p>
            If choosing the Standard Report, you will get more customization options such as success and errors <\/strong>or errors only<\/strong> reports for (Transferred, Verified, Deleted, or Skipped)<\/p>
            In the Logging<\/strong> section, we can send the logs to AWS Cloudwatch.<\/p>
            \"datasync<\/figure>
            The task is ready to perform the sync. We have to start the task.<\/p>
            \"aws<\/figure>
            Note: Each AWS DataSync task creates four Elastice Network Interfaces (ENIs) will be created. This will optimize the performance and helps for the fault tolerance.<\/blockquote>
            Step 11: Verify the DataSync<\/h3>
            We can check the Task history<\/strong> to verify that the data is properly migrated from the source to the destination account.<\/strong><\/p>
            \"aws<\/figure>
            In the history, you can see the execution details such as Execution ID, Start Time, Duration, Status, Transfer Speed, Size, etc.<\/strong>; if we want more information, we can click the execution ID.<\/p>
            \"describe<\/figure>
            You can also manually check if all the files have been synced by mounting the destination EFS to an EC2 instance.<\/p>
            \"mount<\/figure>
            Conclusion<\/h2>
            I hope this blog will give you an idea of the AWS DayaSync Workflow and how we can migrate or sync EFS data from one account to another in different regions.<\/p>
            With DayaSync, you can do more configuration and implementation. When you implement it, make sure that the security groups provide only the required network and ports to route the traffic.<\/p>\n
            Ngu\u1ed3n:<\/strong> Transfer EFS data between AWS Accounts Using AWS DataSync \u2014 DevOpsCube<\/a><\/p>","protected":false},"excerpt":{"rendered":"
            Source: https:\/\/devopscube.com\/transfer-efs-data-datasync\/<\/p>\n","protected":false},"author":1,"featured_media":853,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-852","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/852","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=852"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/852\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/853"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=852"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=852"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=852"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}