Scaling Regulated AI with Domino on Amazon FSx for NetApp ONTAP

By: Semion Mazor, Senior Product Marketing Manager – NetApp
By: Alon Goldin, FSxN Product Management – NetApp
By: Vaibhav Dhawan, Principal Field Solutions Architect – Domino Data Lab
By: Ben Lin, Senior Solutions Architect – AWS

NetApp

Introduction

As AI scales from pilots to enterprise production, data architecture, not the model, becomes the critical governance layer. Model performance still matters, but reliable AI in regulated environments depends on controlling data location, access, and the state behind each run. Data scientists need timely access to approved datasets. Your platform, security, and risk teams need access controls, data-residency boundaries, and reproducibility evidence. Manual copies and one-off processes deliver neither: work slows and unmanaged datasets multiply.

Regulated organizations face requirements for data access, retention, traceability, and transfer, including electronic-record rules for FDA-regulated clinical investigations and GDPR requirements for personal-data transfers. Identity-based access, controlled data placement, and recoverable point-in-time states support these requirements, but no architecture ensures compliance by itself.

Under the AWS Shared Responsibility Model, AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, including configuring and operating controls for their data and workloads. In this post, we share three principles that turn storage choices into governance and operating decisions:

1. Keep compute close to governed data
2. Preserve reproducible data states
3. Scale workloads without full dataset copies

Domino Data Lab is an AWS Partner that develops the Domino Enterprise AI Platform for building, deploying, and governing AI workloads, available in AWS Marketplace. Amazon FSx for NetApp ONTAP is a fully managed AWS storage service that runs NetApp ONTAP file systems in AWS. In this architecture, Domino uses FSx for ONTAP as its shared storage layer.

Why storage matters to AI operations

Most AI projects start small: local datasets, one team’s infrastructure, informal processes. In production, your teams read shared datasets, create checkpoints, generate model artifacts, and revisit prior work after source data changes, and a design built for one job creates queues, redundant copies, and operational overhead as concurrency grows.

In regulated AI, these storage decisions carry governance weight and are hard to retrofit once workloads are in production. Early decisions let you address governance concerns before they become production constraints. The following three principles can guide your approach.

Three principles for regulated AI data architecture

1. Keep compute close to governed data

A single location for every dataset is often impractical: data-residency requirements can keep your authoritative copy in a particular AWS Region or on premises, and transfer time and network costs limit movement. Full dataset transfers for every experiment add delay and create copies that are harder to govern.

A hybrid architecture inverts that decision: you choose compute based on where your approved data resides, and replication and caching policies define and limit any data movement. FSx for ONTAP supports NetApp SnapMirror replication and FlexCache caching between compatible environments, so your platform team maintains defined data boundaries while workloads use AWS compute when appropriate.

Wherever data resides, you still need governed access: for Server Message Block (SMB) workloads, FSx for ONTAP integrates with Microsoft Active Directory Domain Services to support identity-based file access.

Data locality doesn’t require a single environment. Separate authoritative data from temporary data, then track transfer volume, preparation time, and end-to-end runtime to see whether cloud bursting or replication improves results or merely shifts costs elsewhere.

2. Preserve reproducible data states

A model-training run requires more than its code: you must identify the training data, code version, software environment, configuration, and approvals behind it. If the dataset changes without a recoverable point-in-time state, reproduction becomes difficult, and sometimes impossible.

Domino records the project context associated with a run, and point-in-time storage snapshots preserve the corresponding data state. Together, they support model lineage and audit preparation. You still need retention, validation, and change-management controls for your own regulatory obligations.

3. Scale workloads without full dataset copies

Concurrent experiments usually begin from the same training data, and a full copy for every team increases storage consumption, slows provisioning, and obscures the authoritative source. Space-efficient, writable clones let teams branch from a common point-in-time dataset; each clone shares unchanged blocks with its source and consumes capacity only as data changes.

Multiprotocol access removes another class of copies: supported workloads can reach the same FSx for ONTAP data through file interfaces or through Amazon Simple Storage Service (Amazon S3) Access Points attached to FSx for ONTAP volumes, with no separate S3 copy to maintain for a different interface.

Finally, as datasets, checkpoints, and artifacts accumulate, ONTAP deduplication, compression, compaction, and tiering reduce the solid-state drive (SSD) capacity you need. Results vary with data type and access pattern, so measure representative workloads instead of assuming a fixed savings percentage.

How Domino applies the principles on AWS

Domino’s platform design reflects these principles. FSx for ONTAP is the default storage for Domino Cloud, and Domino offers Domino Volumes for NetApp ONTAP for self-hosted deployments. In this architecture, Domino provides project context and workload management, while FSx for ONTAP provides shared storage and ONTAP data-management capabilities. Your platform team configures data placement, access, retention, and automation to your requirements.

In practice, your data scientists access approved data through self-service workflows while your platform team retains governance control: workloads run near approved data, run context pairs with point-in-time states, and concurrent projects get writable, space-efficient clones.

The results are measurable. Domino reports that running Domino Cloud on FSx for ONTAP improved write speeds by 417 percent and read speeds by 94 percent, reducing data-loading times and training delays, and delivered roughly twice the performance of previous configurations. Novartis and Merck (MSD), two regulated life sciences customers, are migrating clinical workflows to FSx for ONTAP with deployments spanning hundreds of volumes across multiple file systems.

Reference architecture and operations

Figure 1 shows a Domino deployment inside an Amazon Virtual Private Cloud (Amazon VPC). User traffic reaches Domino through Elastic Load Balancing, Domino runs on Amazon Elastic Kubernetes Service (Amazon EKS), and Amazon FSx for NetApp ONTAP provides the shared storage layer.

Figure 1 – Domino on Amazon EKS with with Amazon FSx for NetApp ONTAP

The diagram also shows an optional control loop: a customer-defined monitor tracks file-system capacity with Amazon CloudWatch metrics and invokes an AWS Lambda function that adjusts capacity. This automation is not built into Domino or FSx for ONTAP, so your operations team owns thresholds, change management, and failure handling.

Measure outcomes at the workload level

How do you know it’s working? Service-level numbers such as peak throughput and storage capacity won’t tell you whether teams finish work faster, use compute more effectively, or spend less on data movement. Compare the same workload under comparable conditions before and after the change, using these workload-level metrics:

• Time to provision an approved dataset for a new project: Shows how quickly teams can begin work without bypassing governance controls.
• Storage consumed by full copies, snapshots, and writable clones: Reveals the capacity and cost of each provisioning approach.
• Job startup time, end-to-end runtime, and GPU utilization: Indicates whether data access keeps your compute resources productive and shortens completion time.
• Time to identify and restore the data state behind a prior run: Captures the effort spent supporting reproducibility and audit requests.
• Data transferred between environments and the resulting network cost: Reveals the performance and cost effects of hybrid placement, replication, and caching.

Define the workload, baseline, and measurement period upfront so you can connect infrastructure decisions to delivery speed, cost, utilization, and governance effort.

Conclusion and next steps

As regulated AI expands, storage becomes a core part of your governance system: the layer that determines whether production AI stays controlled, reproducible, and efficient. With Domino lifecycle context, ONTAP data management, and managed AWS infrastructure, you can apply these principles across your production environments today. To get started:

• Review Amazon FSx for NetApp ONTAP.
• Explore the Domino Data Lab and NetApp integration.
• Review the Guidance for Deploying Enterprise Apps with NetApp BlueXP Workload Factory and Amazon FSx for NetApp ONTAP

NetApp – AWS Partner Spotlight

NetApp is an AWS Advanced Tier Partner with the AWS Storage Competency. Amazon FSx for NetApp ONTAP, the fully managed AWS storage
service that runs NetApp ONTAP file systems in AWS, is the shared storage layer in this architecture.

Contact NetApp | Partner Overview | AWS Marketplace

Domino Data Lab – AWS Partner Spotlight

Domino Data Lab provides an Enterprise AI Platform for building, deploying, and governing AI workloads, available in AWS Marketplace.
Domino is a founding member of the AWS Machine Learning Competency Partners, validated since 2017.

Contact Domino Data Lab | Partner Overview | AWS Marketplace

This post was co-authored with NetApp and Domino Data Lab. The content and opinions are those of the third-party authors. AWS is not responsible for the content or accuracy of this post.