Moving specialist data onto AWS without breaking the workflow

A specialist application can depend on much more than the contents of a folder. Project files reference other files. Background jobs expect stable paths. Shared directories carry ownership and permissions that determine who can finish a piece of work. Moving the bytes onto AWS addresses only part of that dependency.

In a 2025 implementation for an oil and gas company, the engineering contribution included DataSync agent deployment, encryption configuration, operational documentation and a network workaround for a shared-VPC limitation. A temporary endpoint VPC, discovered endpoint addresses and a cross-account deployment handoff allowed endpoint ownership to be handled separately from FSx storage in shared networking. Storage and agent provisioning also became independent deployment decisions.

That combination matters to a workload owner: retaining familiar file access requires decisions about service compatibility, network ownership and application acceptance alongside the copy itself.

Start with the workflow people need to finish

Choose a representative project and follow it from opening the first file to saving and handing over the result. Record the application version, protocol, mount path, user identity and linked directories. Include scheduled jobs and service accounts; an interactive user’s successful test can miss a dependency that runs overnight.

Define acceptance around opening, saving and handing over that project, including linked files, locking and restricted access. Test from the intended application location: bulk-copy throughput cannot tell you how quickly a user opens hundreds of small files.

Choose the managed service around those requirements

Amazon FSx for NetApp ONTAP is the relevant service here. It provides managed shared storage with NFS and SMB access. A storage virtual machine, or SVM, presents the file-service endpoints and hosts volumes. This can support a move that retains file-based application behaviour while AWS operates the underlying service. AWS’s FSx for ONTAP overview and SVM responsibilities.

Confirm application support, availability, capacity, throughput and the working set that needs fast access. The storage team still owns volume layout, access policy, recovery objectives and restore testing.

Keep protocol changes separate from the initial migration where possible. For an NFS workload, preserve the Unix identity and permissions model. For SMB, plan directory integration and Windows permissions. A mixed environment needs an explicit mapping between those models.

Resolve endpoint ownership without moving the destination

A shared VPC separates network ownership from workload deployment. AWS Resource Access Manager can share a subnet with a workload account, but that account does not acquire ownership of the subnet’s network infrastructure.

In 2025, two constraints met at the DataSync control connection. Participants could not create or manage interface endpoints in shared subnets, and DataSync did not support using the VPC owner’s centrally managed endpoint for the participant’s agent. An otherwise suitable shared-storage design therefore needed a separate solution for private service connectivity. AWS documented a comparable placeholder-VPC workaround.

The solution was a small, temporary VPC owned by the workload account. It provided subnets and a private DataSync service endpoint under the required ownership. A central Transit Gateway, shared with that account, connected the endpoint VPC into the wider network. The destination FSx service remained in shared networking. The workaround addressed the service-control boundary without relocating the managed storage.

Zoom outZoom inReset100%Close

The temporary VPC handles endpoint ownership while storage stays in shared networking. Discovered endpoint addresses guide control routing; task interfaces carry the separate transfer path.

This creates separate operating responsibilities. The workload deployment manages its endpoint resources; the network deployment manages central connectivity. Agent VM placement remains a separate choice based on source access and supported connectivity. Owning the endpoint VPC does not require placing the appliance there. The DataSync endpoint guide distinguishes endpoint subnets, activation choices and appliance placement.

Discover the endpoint addresses and hand them to the network owner

An endpoint ID is useful for identifying a resource, but routing needs its addresses. A CloudFormation custom resource queried the endpoint’s network-interface IDs and then their private IPv4 addresses. The stack exposed those addresses and its Transit Gateway attachment ID as outputs.

Azure DevOps then read the outputs using workload-account credentials, published named task output variables and supplied them to a later routing deployment using central-network credentials. This made the handoff explicit: the first deployment produced endpoint destinations; the second applied the routes under the network owner’s authority.

The following original task fragment uses fictional service connections and resource names. Place both tasks in the same job’s steps. It assumes a completed endpoint stack with the two named outputs, the AWS Toolkit extension, and an agent with Bash, the AWS CLI and jq.

- task: AWSShellScript@1
  name: ReadEndpointOutputs
  inputs:
    awsCredentials: atlas-workload-reader
    regionName: ap-southeast-2
    scriptType: inline
    inlineScript: |
      set -euo pipefail
      outputs=$(aws cloudformation describe-stacks \
        --stack-name atlas-endpoint-access \
        --query 'Stacks[0].Outputs' --output json)
      output_value() {
        jq -er --arg key "$1" \
          '.[] | select(.OutputKey == $key) | .OutputValue | strings | select(test("\\S"))' <<<"$outputs"
      }
      addresses=$(output_value EndpointPrivateAddresses)
      attachment=$(output_value EndpointAttachmentId)
      printf '##vso[task.setvariable variable=Addresses;isOutput=true]%s\n' "$addresses"
      printf '##vso[task.setvariable variable=Attachment;isOutput=true]%s\n' "$attachment"
 
- task: CloudFormationCreateOrUpdateStack@1
  condition: succeeded()
  inputs:
    awsCredentials: atlas-network-deployer
    regionName: ap-southeast-2
    stackName: atlas-endpoint-routing
    templateSource: file
    templateFile: infrastructure/endpoint-routing.yaml
    templateParametersSource: inline
    templateParameters: |
      - ParameterKey: EndpointAddresses
        ParameterValue: '$(ReadEndpointOutputs.Addresses)'
      - ParameterKey: EndpointAttachment
        ParameterValue: '$(ReadEndpointOutputs.Attachment)'
    capabilityIAM: true
    capabilityNamedIAM: false

jq -e rejects missing, empty or blank outputs, and the shell stops before publishing either variable if a required value is absent. The later task consumes named task outputs within the same job. Passing those values does not grant network permissions: its separate service connection needs authority to deploy the routing stack. Microsoft’s same-job output syntax, AWS’s shell task and CloudFormation task inputs.

The surrounding route template remains a prerequisite. It must accept the two parameters, validate the comma-separated addresses and attachment, and configure prefix-list reconciliation and central route references. Its network configuration, IAM permissions and capabilities need their own review.

Maintain one destination set for the control routes

The routing design progressed from individual host routes to a customer-managed prefix list. Each discovered endpoint address became an IPv4 /32 entry. Transit Gateway route tables referenced the list and the endpoint VPC attachment, allowing the network owner to maintain one destination set across the relevant tables. AWS’s Transit Gateway prefix-list guidance describes how each list entry becomes a route.

During infrastructure deployment, reconciliation compared the supplied addresses with the list, added missing entries and removed obsolete entries using the list’s current version. Endpoint replacement therefore needs refreshed discovery and another routing deployment. This is a deployment-driven mechanism, not a continuous watcher of endpoint changes.

The /32 entries select individual control destinations. They do not restrict ports, authorise file access or establish the complete transfer path. Check effective routes in both directions, security groups and required ports alongside the separate source and destination connections. Give the temporary VPC a retirement condition tied to accepted migration work and remaining agent dependencies.

For a new design: AWS announced native DataSync shared-VPC support on 29 September 2026. Agents can now use RAM-shared subnets and an endpoint managed by the VPC owner. Assess that supported path first before adding a temporary endpoint VPC. Participants still cannot manage interface endpoints in subnets shared with them; the endpoint ownership restriction remains.

Give provisioning and transfer separate release decisions

Storage provisioning should create and maintain the destination without requiring a data copy. Agent provisioning should establish the transfer appliance and its connectivity without changing application mounts. Transfer configuration should identify exactly which source and destination paths it will use.

Keep these as independently maintainable jobs, with a later readiness check that requires both sides. Declare dependencies where the next operation needs an output or an accepted result. Microsoft’s guidance on job dependencies.

An agent’s lifecycle also extends beyond creating its virtual machine. Track the selected image, activation, service connection and source access. Replacing an appliance must include checking which transfer locations depend on it. The next copy should start only after those checks pass.

Check the source, service and user connections separately

Zoom outZoom inReset100%Close

Three connections need independent checks: reading the source, transferring to AWS and using the destination. A private service endpoint covers only part of the path.

A DataSync VPC endpoint provides private service connectivity. The agent still needs to resolve and reach the source server, mount the agreed export and read its contents. For the native FSx for ONTAP destination below, DataSync creates task network interfaces in the file system’s subnet. Those transfer interfaces are separate from the endpoint interfaces discovered for the control routes. Application clients have their own DNS, routing and file-access requirements. AWS’s task-interface placement guidance and DataSync network requirements.

Test DNS and access from the agent and intended clients. Limit source access to the transfer scope; a source-only NFS location needs read and traversal permissions. Check metadata compatibility too: DataSync does not copy NFSv4 ACLs. AWS’s NFS location guidance.

File access and infrastructure administration are different permissions. For its ONTAP NFS location, DataSync uses NFSv3 with AUTH_SYS and UID/GID zero. Scope the destination export policy to the transfer interfaces and required metadata operations. Preserve and test the application users’ identities separately. AWS recommends matching source and destination protocols and using Unix security style for an NFS migration. DataSync access to FSx for ONTAP.

Treat encryption as several responsibilities too. FSx encrypts file systems and backups at rest using AWS KMS. An EC2-hosted agent’s encrypted EBS volumes have their own key-access requirements. Keep key administration distinct from the permissions needed to provision and operate those resources; plan key retention alongside data retention. FSx encryption at rest and EBS encryption permissions.

DataSync encrypts its transfer connection, while the source and destination file-protocol connections need separate assessment. The NFSv3 example below does not establish encryption across every connection. If policy requires that, validate a supported protection mechanism for each leg before using it; a private route alone does not supply encryption. How DataSync protects connections in transit.

Make the first copy narrow and non-destructive

Start with an isolated pilot export and a new destination volume. The following original CloudFormation fragments describe a fictional NFS workflow. They belong under Resources in a larger template and do not start a transfer.

The prerequisites are an existing FSx for ONTAP file system and SVM, an activated Basic mode agent, source DNS and an approved transfer security group. SvmId and SvmArn must identify the same SVM; the other unresolved references are deployment parameters. Networking, export policies, key configuration, backups and reporting require surrounding configuration.

First, give the pilot its own Unix-style volume. The retention attributes protect it from automatic deletion during stack deletion or replacement; they do not replace backups. CloudFormation’s FSx volume configuration and retention policies.

AtlasPilotVolume:
  Type: AWS::FSx::Volume
  DeletionPolicy: Retain
  UpdateReplacePolicy: Retain
  Properties:
    Name: atlas_pilot
    VolumeType: ONTAP
    OntapConfiguration:
      StorageVirtualMachineId: !Ref SvmId
      JunctionPath: /atlas-pilot
      SecurityStyle: UNIX
      SizeInMegabytes: "65536"
      StorageEfficiencyEnabled: "true"

Next, bind the source export to that volume’s junction path. The explicit dependency matters because repeating a path string does not create a CloudFormation resource dependency. DataSync’s ONTAP location resource and CloudFormation dependency rules.

PilotSource:
  Type: AWS::DataSync::LocationNFS
  Properties:
    ServerHostname: !Ref SourceServerDns
    Subdirectory: /exports/atlas-pilot
    OnPremConfig:
      AgentArns: [!Ref SourceAgentArn]
    MountOptions: {Version: NFS3}
 
PilotDestination:
  Type: AWS::DataSync::LocationFSxONTAP
  DependsOn: AtlasPilotVolume
  Properties:
    StorageVirtualMachineArn: !Ref SvmArn
    Subdirectory: /atlas-pilot
    SecurityGroupArns: [!Ref TransferSecurityGroupArn]
    Protocol:
      NFS:
        MountOptions: {Version: NFS3}

Finally, define a first-pass task that keeps destination-only files and refuses to overwrite existing destination data. It copies new data, so it is not a dry run. DataSync’s transfer options.

PilotFirstPass:
  Type: AWS::DataSync::Task
  Properties:
    Name: atlas-first-pass
    TaskMode: BASIC
    SourceLocationArn: !Ref PilotSource
    DestinationLocationArn: !Ref PilotDestination
    Options:
      TransferMode: CHANGED
      OverwriteMode: NEVER
      PreserveDeletedFiles: PRESERVE
      VerifyMode: ONLY_FILES_TRANSFERRED
      Uid: INT_VALUE
      Gid: INT_VALUE
      PosixPermissions: PRESERVE

These settings deliberately leave an existing destination file unchanged even when the source changes. Repeating this task therefore does not establish convergence. A later reconciliation needs an agreed source of truth and explicit overwrite rules.

ONLY_FILES_TRANSFERRED checks the data transferred in that execution; it does not certify the entire destination. Review skipped files and errors as well as successful transfers. Application acceptance remains a separate exercise. DataSync verification scope and task reports.

Accept the workflow before changing the source of truth

Agree the following decisions before scheduling cutover. Each needs a named owner who can accept the result or stop the move.

Bulk copying can happen while the source remains in use, but final acceptance needs a controlled consistency point. Quiesce application writes using an application-appropriate procedure, run the agreed final delta and verify the selected scope before switching clients. A verification option cannot make an actively changing application dataset consistent by itself.

Keep the previous source protected for the agreed rollback window. Once users write to the new destination, rollback also needs a plan for those new changes; redirecting clients to an older copy can lose work. Retire transfer access and temporary resources only after acceptance and the retention decision.

The AWS Workload Foundations Assessment applies these questions to one workload: its file dependencies, access boundaries, operating responsibilities and delivery sequence. It provides a target pattern and a proceed, remediate or reshape recommendation before a larger migration commitment.