S3 Burst on ONTAP Files — Collect via S3 API, Consume via FlexCache NFS/SMB

Introduction

You have an S3 ingestion pipeline. But the consumers only see an NFS mount. Sound familiar?

You want to deliver driving logs to a HiL test bench, stage design jobs for an EDA toolchain, push rendering assets to production nodes, or feed genomic sequencer output to an HPC cluster. In each case the writer speaks S3 API in the cloud while the reader speaks NFS/SMB on physical hardware. Without a way to connect these directly, you end up adding a sync job in between — and with it comes latency, cost, and one more thing to monitor.

This structure spans industries: automotive, semiconductor, media/VFX, oil and gas, life sciences, manufacturing, remote work, and IoT (see the full table in When This Pattern Fits below).

This post introduces a pattern that removes that sync job. Write to an Amazon FSx for NetApp ONTAP (hereafter FSx for ONTAP) S3 Access Point, and the data appears on a FlexCache NFS mount. No separate copy job and no scheduled replication between the two. FlexCache pulls the data that gets read from the origin and holds it on the cache side, so what this removes is the sync job you would otherwise own — not the data transfer itself. I measured all four directions to see how fast the visibility propagates.

Here's the conclusion up front:

• S3 PutObject → FlexCache NFS read visibility: p50 8 ms. No separate copy or replication job; the data that gets read is pulled into the cache on demand
• FlexCache overhead is +5 ms (vs. reading origin directly) — nearly transparent for same-region VPC peering
• Reverse direction (NFS write → S3 AP read) is p50 44 ms, dominated by S3 API overhead. Not the main path in this design
• FlexCache duality (NAS bucket S3 reads on FlexCache volumes) works, but only after -is-s3-enabled true is set on the cache volume in advanced privilege. My first attempt returned AccessDenied because that step was missing

Repository: Yoshiki0705/s3-burst-on-ontap-files

The Architecture

[S3 Client] --PutObject--> [S3 Access Point] --> [Origin Volume]
                                                       |
                                                  FlexCache
                                                       |
                                                [NFS/SMB Client]

Layer	What	Protocol
Collect (write)	S3 Access Point on FSx for ONTAP	S3 API
Source of truth	Origin volume	—
Distribution	FlexCache	Cluster/SVM peering
Consume (read)	Cache volumes	NFS/SMB only

The S3 Access Point attaches to the origin only. Cache volumes serve NFS/SMB. This single decision simplifies the design considerably:

• One write path. The origin is authoritative; writes always go through the S3 AP
• No S3 implementation differences pushed to the edge
• Cache side requires only FlexCache + NFS/SMB — fewer platform constraints to hit

Test Environment

Item	Value
Date	2026-08-09
ONTAP version	9.18.1P3D1 (both clusters)
Configuration	SINGLE_AZ_1, 128 MBps × 2 clusters
Connectivity	VPC peering (same region, same account)
Mount	NFSv3, actimeo=0 (client cache disabled)
Object size	64 bytes
Concurrency	1
Method	boto3 persistent session, same host, 30 iterations

Why NFS First

The initial measurements used NFS. Three reasons:

1. Client cache control. NFS actimeo=0 fully disables kernel attribute caching, isolating storage-side visibility latency. SMB oplocks/leases let the client cache independently, making it harder to measure the same thing at the same granularity.
2. Matching the identity to the security style. An access point authorizes every request as one file system identity, and AWS says to use a UNIX identity for UNIX security-style volumes and a Windows identity for NTFS ones (managing data access). NTFS volumes are supported too — this is not a UNIX-only feature, which corrects how an earlier version of this post put it. UNIX plus NFS was chosen here because it was the shortest path to a measurement, not because the other side is unavailable.
3. Primary use-case distribution. HiL test benches, rendering farms, and IoT analysis appliances are predominantly Linux + NFS. When the read side is SMB-dominant (Windows workstations in a production studio), the origin security style changes to NTFS — a different design path (see First Decisions).

SMB Shows Identical Results

I ran a separate verification with SMB (mount -t cifs, cache=none) on the same architecture:

Protocol	Mount method	p50	p90	max	n
SMB	mount -t cifs, cache=none	7 ms	8 ms	9 ms	30
NFS	mount -t nfs, actimeo=0	7 ms	8 ms	15 ms	30

With persistent mounts, SMB and NFS have identical visibility latency. No protocol difference.

Note: smbclient (establishing a new session per request) showed p50 43 ms. This is SMB session setup overhead — the same structural problem as the AWS CLI cold-start that inflated our first NFS→S3 measurement to 873 ms. Production environments with persistent connections won't see this.

SMB Considerations

FlexCache serves both NFS and SMB. This architecture doesn't exclude SMB — but note:

• With a UNIX security-style origin, SMB clients receive UNIX permission-based access control, not NTFS ACLs
• For SMB-primary workloads, NTFS security style is the natural choice, and an access point works there with a Windows identity. The trade-off is not availability but the identity you fix on the access point, which cannot be changed after creation
• mixed security style is available in the API but officially not recommended by AWS — it's labeled "advanced users only." Permission type is determined by the last client that wrote, making troubleshooting difficult. This architecture doesn't use it
• SMB needs a CIFS server on the SVM. An Active Directory join is not required: where a domain is not available, AWS documents setting up an SMB server in a workgroup (NTLM only, no Kerberos, and no GPO, VSS or SMB3 CA shares). If you do join AD, every data operation through the access point then needs a reachable domain controller, and HeadBucket succeeds even when it is not — so it cannot be used to check that

What I used here: a UNIX security-style origin with a UNIX identity, because the read side was NFS. For an SMB-primary workload the equivalent choice is an NTFS origin with a Windows identity. Decide it before the origin volume exists — whether the cache inherits the security style from the origin is unconfirmed on the on-premises path, and if it does, changing it later means rebuilding the serve layer.

actimeo=0 measures the minimum visibility latency by disabling client-side caching. Production deployments should use appropriate actimeo values for their workload — the default (~60 s) means subsequent reads hit kernel cache at ~0.05 ms, but changes aren't visible during that window.

Results — All Four Directions

#	Direction	p50	p90	p99	max
1	S3 AP PutObject → FlexCache NFS read	8 ms	9 ms	19 ms	19 ms
2	S3 AP PutObject → Origin NFS read (direct)	3 ms	5 ms	8 ms	8 ms
3	NFS write (Origin) → FlexCache NFS read	6 ms	7 ms	25 ms	25 ms
4	NFS write (Origin) → S3 AP GetObject	44 ms	49 ms	328 ms	328 ms

What the Numbers Say

Direction 1 is the main path. S3 write, FlexCache NFS read: p50 8 ms.

The +5 ms gap between directions 1 and 2 is FlexCache overhead. For same-region VPC peering, FlexCache is nearly transparent.

Direction 3 is faster than 1 (6 ms < 8 ms). NFS writes commit directly to the origin — no S3 API overhead — and FlexCache propagation alone is faster than the full S3-to-cache path.

Direction 4 (reverse) is slowest at 44 ms. S3 read-side processing dominates. This design keeps reads on NFS/SMB, so direction 4 isn't the main path.

NFS Client Cache Effect

Condition	p50
actimeo=0 (cache disabled)	7 ms
actimeo=60 (subsequent access)	0.05 ms (kernel cache hit)

With defaults, reads within 60 seconds of the last attribute check hit the kernel cache. The tradeoff: you won't see changes during that window. Tune per workload.

FlexCache Duality — It Works (With One Extra Step)

S3 access to NAS FlexCache volumes — "duality" — arrives in ONTAP 9.18.1, not 9.14.1 as an earlier version of this post said. I tested it on FSx for ONTAP 9.18.1P3D1.

Result: Works After Enabling -is-s3-enabled true

My initial test returned AccessDenied and I concluded it didn't work. After additional investigation, I found missing configuration step: S3 access must be explicitly enabled on the FlexCache volume:

set -privilege advanced
flexcache config modify -vserver <svm> -volume <fcache_vol> -is-s3-enabled true

After applying this setting:

Operation	Before (missing setting)	After (-is-s3-enabled true)
HeadBucket	✅	✅
ListObjectsV2	❌ AccessDenied	✅ KeyCount=1
GetObject	❌ AccessDenied	✅ Content verified

The fsxadmin role on FSx for ONTAP has access to advanced privilege commands including flexcache config modify. Documented at NetApp: Enable FlexCache duality.

Design Implication

FlexCache duality works, which means S3 reads from the cache side are possible. However, this architecture still recommends NFS/SMB on the cache side because:

• ONTAP native S3 (NAS buckets) and AWS-managed S3 Access Points are different mechanisms
• NAS buckets are read-only (no PutObject)
• Requires additional configuration (advanced privilege + S3 user management)
• No IAM integration or access point policy governance like S3 AP provides

FlexCache duality becomes an option when "S3 reads at the cache site" is a hard requirement. For AWS service integration (Lambda, Bedrock, etc.), the origin-side S3 AP remains the better fit. These are separate mechanisms, and the support status of one is not evidence for the other.

When This Pattern Fits

"Collect via S3 API in the cloud, consume via NFS/SMB at the edge" — this structure exists across industries.

Industry	Collect side	Consume side	Example
Automotive (AV/ADAS)	Driving logs and sensor data ingested to S3	HiL test benches replay via NFS	AWS + NetApp: Hybrid Cloud HiL
Semiconductor (EDA)	Design job I/O staged via S3	Toolchains (Synopsys, Cadence) run on NFS	EDA Scale with FSx for ONTAP
Media and VFX	Rendering assets collected to S3	Artist workstations mount SMB/NFS	FlexCache: distributed product development
Oil and Gas	Seismic survey data uploaded to S3	Interpretation workstations mount NFS	VDI for Subsurface O&G
Life Sciences	Genome sequencer output stored in S3	Bioinformatics HPC processes via NFS	Sequencer → S3 → NFS pipeline
Manufacturing / QA	Inspection camera images collected to S3	Line-side inspection software reads via NFS	Image → judgment → archive flow
Remote Work	Central design data updated via S3	Remote-site WorkSpaces access FlexCache NFS/SMB	FlexCache in AWS WorkSpaces
IoT / Edge	Sensor data streamed to S3	On-site analysis appliances read via NFS	Factory gateway → cloud → shopfloor

Common structure: Few write sites (often one), multiple read sites. Writes are bursty; reads touch only what's needed.

When It Doesn't Fit

• Need full S3 semantics (versioning, event notifications, lifecycle): Use S3 natively
• Object names aren't NAS-friendly (flat namespace, millions of keys with no directory separators): Performance degrades as root directory grows
• Consumers need S3 reads at the cache site: possible from ONTAP 9.18.1 with duality (see above), but this architecture keeps the cache on NFS/SMB — the NAS bucket is a read-only view, needs advanced privilege, and has no IAM or access point policy governance
• Need write-back from the cache: This pattern keeps cache read-centric
• Need conditional writes (If-None-Match): Returns 501 NotImplemented. Handle exclusion at the application layer

S3 Access Point Design Notes

A few things to know when using the S3 AP as the collect layer.

S3 AP ≠ Amazon S3

The FSx for ONTAP S3 AP supports a subset of S3 operations. GetObject, PutObject, ListObjectsV2, HeadObject, DeleteObject, and MultipartUpload work. The following do not:

• S3 Event Notifications (poll, or read the ONTAP native audit log. FPolicy + EventBridge is not a substitute — see the next section)
• Lifecycle rules (use FabricPool)
• Versioning (use ONTAP Snapshots)
• Conditional writes If-None-Match (returns 501)
• S3 Select, SSE-S3/KMS, Cross-AP Copy

Monitoring Coverage — FPolicy Does Not See This Path

An earlier version of this post offered FPolicy as the substitute for S3 Event Notifications.
I measured it, and it does not work. Correcting that here.

Measured 2026-08-26, ap-northeast-1, ONTAP 9.18.1P3D1, with the same result for both a UNIX-identity
and a WINDOWS-identity access point.

Mechanism	Operations through the S3 AP	Detail
FPolicy	Not notified	Zero notifications in a 90-second idle window, zero across nine S3 AP data-plane calls, while a file-protocol control on the same volume in the same session did fire. The protocols an FPolicy event accepts are cifs, nfsv3 and nfsv4 only — there is no value for the S3 path
FPolicy mandatory	Not blocked	With a synchronous engine and mandatory=true, an NFSv3 write returned Permission denied while PUT, GET, LIST and DELETE through the S3 AP on the same volume all succeeded
ONTAP native audit log	Recorded	As Source=HTTP for object operations and Source=S3 for LIST. But SubjectUserName and SubjectDomainName are Not Present and SubjectIP is an AWS service-side address, so the requester is not recorded. HeadObject produced nothing across six calls. An audit ACE (SACL) is required
ARP	Detected	ARP 5.0. 150 high-entropy files written through the access point were recorded as suspect under High Entropy, with attack_probability at moderate

Two things follow for the design. First, detection, DLP and blocking that start from an FPolicy
notification do not reach this path — including the guarantee mandatory is chosen for, that an
unreachable engine stops the operation. Second, the audit log records the operation but not the
requester, so answering "who touched this file" from the audit trail alone is not possible; it needs
correlation with AWS CloudTrail.

ARP does detect, but attack_probability changes more than ten minutes after the write. Reading
none from a short observation window and concluding nothing was detected is a false negative. ARP
blocking is unmeasured.

Whether FPolicy, auditing or ARP fire on the cache side is unverified. Writes in this architecture
land on the origin, so the cache side remains a separate question.

Throughput is shared with NFS/SMB

S3 AP, NFS, and SMB all consume the same FSx for ONTAP provisioned throughput. In this architecture, origin and cache are separate clusters so this rarely matters — but if NFS clients also access the origin directly, account for the shared bandwidth. I have not measured concurrency, so I will not hand you a number: the ceiling follows from provisioned throughput divided by the bandwidth one request consumes, and that second term depends on your object size and request duration. Raise concurrency while watching the SlowDown (503) rate and p99, and stop below what you can absorb.

Directory design matters

S3 PutObject keys map directly to directory structure. What sets the ceiling is the volume's maxdir-size: reach it and the client gets ENOSPC and can no longer create files. It is a per-volume setting, and raising it could affect performance. Check the value on your own volume and partition by date, tenant, or hash prefix so the entries in one directory stay well short of it. Response time for readdir and ListObjectsV2 grows with entry count too, though I have not measured where that starts to hurt.

This directly affects NFS usability. If you flat-dump millions of objects without hierarchy, FlexCache NFS clients will struggle with ls and find. Design your S3 keys with "how does this look when I ls on NFS?" in mind.

Key recommendations:

• Date-based partitioning (year=YYYY/month=MM/day=DD/) so the entries in one directory stay well short of maxdir-size
• Separate ingest volumes from consumption volumes; apply FlexCache only to consumption
• On the NFS side, use manifest files or path generation instead of directory traversal (find)

For full details, see the S3 AP Design Guide in the repository.

What It Costs — Egress First, Requests Second

I framed this section around S3 request pricing when I first wrote it. That was the wrong axis, and the modelling I did afterwards says so plainly. Corrected below.

The cost that hurts when your readers sit outside AWS is data transfer. Egress is charged on bytes leaving the Region, so reading the same file ten times moves ten times the bytes and pays ten times over. A cache removes the multiplier: it carries the working set once and every later read is served locally over NFS or SMB, never becoming an S3 request at all.

A worked case — 20 TiB dataset, 2 TiB monthly working set, 4 MiB objects, each file read 30 times, internet egress from ap-northeast-1:

Option	Monthly
Read S3 directly from on premises	$6,211 — egress alone is $5,693 (92%)
Copy the whole dataset down with DataSync	$2,847
FSx for ONTAP + FlexCache	$1,333

Storage and requests are rounding errors next to transfer here.

The read count decides it

Reads per file per month	Direct	This architecture	Ratio
1	$746	$1,333	0.6x
5	$1,680	$1,333	1.3x
10	$2,593	$1,333	1.9x
30	$6,211	$1,333	4.7x
100	$18,451	$1,333	13.8x

At one read per file the direct path wins — the same bytes move either way and there is no reason to carry a file system's fixed cost. The crossover is between five and ten. Where it falls is a property of your workload, not of the products.

Requests matter too, but only below a certain object size

I had assumed S3 GET charges were a co-equal problem. At 4 MiB objects they are not: the entire 5.2 million reads in the ten-read case cost $1.94, about a thousandth of the transfer bill. Through an access point it is $0.31, and through FlexCache $0.16 — the reads are NFS and SMB, so they generate no S3 requests, and only the origin-side capacity pool fetch on cache fill remains.

Where the assumption does hold is small objects. Holding bytes read constant and varying object size:

Object size	Reads/month	GET charges	Share of that option's transfer bill
8 KiB	2.68 B	$993	48%
64 KiB	336 M	$124	6%
256 KiB	84 M	$31	1.5%
4 MiB	5.2 M	$1.94	0.1%

So both charges need designing for, and they respond to opposite remedies:

• Transfer falls by carrying fewer bytes — cache the working set, move the readers into AWS, or drop the unit rate with Direct Connect ($0.041/GB against $0.114 for the first 10 TB of internet egress). Making objects bigger does not help; the byte count is unchanged.
• Requests fall by making fewer calls — batch at collection time so files are larger, and serve reads over a file protocol so they never become S3 calls. Negotiating transfer rates does not help when the money is on the request side.

Batch too far and you hit the collection side: a single PutObject caps at 5 GiB and a whole object at 50 GiB, and the 50 GiB check happens at CompleteMultipartUpload — after the entire payload has been transferred and paid for. Both figures being binary (5,368,709,120 and 53,687,091,200 bytes) is confirmed by the vendor, but the public documentation still reads "5 GB" and "50 GB" and is being corrected. The increase from 5 GiB to 50 GiB was also never announced through any channel. An unannounced tenfold change leaves every downstream document that quotes the old value wrong, with no signal to re-check. Batching past the consumer's read unit also sends bytes nobody reads. The repository's design guide sets the consumer's read unit as the reference for how far to go, with the measurement and monitoring steps.

If the readers can move, move them

Worth stating because it outweighs every storage choice. In-Region transfer is free, so putting the consumers in AWS deletes the entire egress line — $2,079 at ten reads on this workload. Reading S3 directly from EC2 comes to $514/month; S3 Files costs $515, ninety-four cents more, because 4 MiB objects sit above its size threshold and never reach its high-performance storage; FSx for ONTAP in the same Region is $1,053, twice the direct path, since the transfer gap that justified it is gone.

S3 Files cannot serve this architecture's consumers. It speaks NFSv4.1 and NFSv4.2 only — no NFSv3, no SMB — so an appliance pinned to v3 and any Windows stage are out, and the documented compute targets are EC2, Lambda, EKS and ECS. It belongs in the picture as the option you get after migrating the readers, not as a substitute for a cache.

This architecture is for the cases where the readers cannot move: equipment on site, proximity to whatever is being measured, capital already spent on it.

On the distribution side

A FlexCache cache volume cannot be tiered — an origin with FabricPool tiering can be cached, but the cache itself never tiers, so it sits entirely on SSD. That is affordable because it is sparse: NetApp's guidance is at least 10% of origin, which is also the create default. At 10% the distribution side runs 2.7x to 6.1x below a full second copy, with the copy given its capacity pool discount. Size it like a copy and it inverts — at 100% it costs more than the copy, precisely because it cannot tier.

Cache volumes are writable, which I understated earlier. Write-around is the default and withholds the client acknowledgement until the origin has committed; write-back, from ONTAP 9.15.1, commits at the cache and propagates asynchronously. The default being synchronous with respect to the origin matters for freshness: there is no window where a cache-side write is missing from the canonical copy.

One assumption drives more of these numbers than any other, so treat it carefully. Background storage efficiency does not run on data once it has been tiered — only savings applied while the block was on SSD are preserved, and a block tiered before efficiency ran keeps none (AWS, NetApp). Expecting better than 40% on a tiering-enabled volume is optimistic. The model takes the SSD rate from AWS's published per-workload figures, assumes the pool tier retains half of it, and carries a sensitivity table — because the assumption only ever flatters this architecture: ONTAP deduplication does not reduce an S3 storage bill.

Full breakdown, every rate with its effective date, the workload models and the cross-layer pitfalls: FinOps cost structure and the S3 AP Design Guide (Japanese). Cost tables are generated from a model in the repository, so a price change moves one declaration rather than fifty typed totals.

A verification copy that costs no capacity — FlexClone and the S3 Access Point

Everything above is about distribution, so I measured duplication as well.

I checked whether FlexClone works on a volume with an access point attached (2026-08-26, ap-northeast-1, ONTAP 9.18.1P3D1). NetApp records FlexClone as unsupported for ONTAP S3, so I expected the same restriction might appear on this path, but it did not appear as a restriction.

FlexClone has two granularities, and they behave quite differently.

	File granularity	Volume granularity
Where it lands	The same volume. It appears as a new key on the same access point	A separate volume
Authorization boundary	Same as the parent	Its own access point, its own policy, its own identity
Time before it is usable	None	A volume created through the ONTAP API took 599 to 1,177 s to appear on the AWS side, then the junction path has to be set before attaching
Visible over S3	Yes. StorageClass=FSX_ONTAP, sha256 matches the source	Yes. LIST / GET / PUT through the clone's own access point

At either granularity the clone shares data blocks with its parent. Cloning a 256 MiB file four times gives these figures:

Point	Logical	Physical
Just after one 256 MiB PUT	—	253,534,208 B
After four file-granularity clones	1,350,942,720 B	277,200,896 B

Logical grew to five copies, but physical grew by only about 23 MB.

FinOps — no capacity to provision per duplicate

FSx for ONTAP bills provisioned SSD capacity. If a duplicate shares blocks with its parent, there is no capacity to provision for it. Doing the same on S3 requires CopyObject, every duplicate carries full storage charges, and the copy requests are billed on top. That difference is structural, so a unit rate does not close it.

The saving does reach the invoice only as capacity you did not have to provision, though. Where headroom is already generous, the figure does not move.

Two notes on what the space figures assume. NetApp states that copies consume no storage except what is required for metadata until changes are written to the copy (FlexClone volumes, files, and LUNs), so changes written to the clone are not shared and consume new blocks for whatever was written. And deleting data on the parent does not return capacity while a clone or a snapshot still references it.

The operation that ends the sharing is a split (volume clone split start). I did not measure it, so this is the documentation: from ONTAP 9.4, on AFF systems where the volume guarantee is none, the split shares the physical blocks rather than copying the data, and space efficiency is preserved. After the split, however, both the parent and the clone require the full space allocation set by their volume guarantees. The space needed can be checked beforehand with volume clone show -estimate (splitting procedure).

Operational Excellence — no AWS-side work per duplicate

What helps operationally is that making a duplicate adds no AWS-side resource. A file-granularity clone appears as a new key under the existing access point, so there is nothing to attach and nothing to wait for. A verification dataset can be produced from the production bytes and handed to the S3 consumers already in place, such as Amazon Bedrock, AWS Glue and Amazon Athena, without a staging copy job.

Where separation is needed, volume granularity is the one to use. Attaching a separate access point to the clone keeps its identity and policy apart from the parent's, and a write to the clone did not appear on the parent. That gives a way to separate the authorization boundary without duplicating the bytes. The cost is the 10-to-20-minute wait noted above.

There are two operational cautions as well.

The first is that a file-granularity clone gives no observable failure. POST /api/storage/file/clone returns 202 and a job UUID, but the UUID resolved to 404 entry doesn't exist and appeared in no job listing. The same fsxadmin retrieves volume-create and volume-clone jobs as state=success, so this is not a permissions problem. A call naming a destination directory that does not exist also returned 202 and created nothing. Judge the outcome by inspecting the destination file.

The second is that teardown gains an ordering constraint. Delete the clone before the parent. While the deleted clone sits in ONTAP's volume recovery queue, the parent keeps clone.has_flexclone at true, and the AWS-side delete-volume returned DELETING and then silently went back to CREATED. Purging the recovery queue clears the flag and the same call works. That queue appears in neither the console nor the FSx for ONTAP API, so watching only the AWS side leaves you stuck here.

What I did not measure is LUN-granularity cloning: creating a LUN needs an iSCSI configuration, which is not on this architecture's path. The procedure and the controls are in the repository's interoperability page, and the cost structure in FinOps cost structure.

Deploy

CloudFormation and Terraform templates:

• GitHub: Yoshiki0705/s3-burst-on-ontap-files

Conclusion

"Collect via S3, consume via NFS" — one volume, no separate copy or replication job. FSx for ONTAP S3 Access Point + FlexCache. Main path p50 8 ms. FlexCache adds ~5 ms for same-region — nearly transparent. Transfer still happens for whatever gets read; what is absent is the sync job.

This verification was done entirely on AWS (FSx for ONTAP to FSx for ONTAP over VPC peering), but the cache side isn't limited to AWS. AWS documents exactly three FlexCache configurations, and with FSx for ONTAP as the origin the cache is either on-premises ONTAP or FSx for ONTAP (replicating with FlexCache). Cloud Volumes ONTAP, ONTAP Select, Azure NetApp Files and Google Cloud NetApp Volumes are absent from that table, so I record them as unconfirmed rather than assuming they work because they are ONTAP-based — and unconfirmed is not the same as unsupported. The repository's Portability and Support Matrix pages track what's confirmed and what's next. Cross-platform verification is on the roadmap.

The reverse direction is outside that table too, and the verdict splits two ways. Another
cloud's file storage as the origin with FSx for ONTAP as the cache is unconfirmed for Google Cloud
NetApp Volumes and Azure NetApp Files — something that looking could still resolve. For Google Cloud
Filestore, Azure Managed Lustre, Azure Blob NFS and OCI File Storage it is out of scope as a
mechanism, because they are not ONTAP and the cluster and SVM peering FlexCache requires cannot
exist. Network reachability does not change the second group. I do not write the two with the same
word.

I wrote up the network underneath it separately. AWS Interconnect – multicloud is GA, but its
published Region pairs are eight for Google Cloud and one for OCI (us-east-1 to us-ashburn-1), and
neither includes a Japanese Region. Azure is stated as planned, which is neither GA nor Preview.
Starting from Japan therefore means joining Direct Connect to the other cloud's circuit inside an
interconnection provider's fabric, and whether that is possible is decided not by the Region-pair
table but by whether Direct Connect locations, the other cloud's connection locations and the
provider's footprint overlap. Taking the partner route does not add Regions to the managed
service — it switches to a different construction.

The arrows in the figure stop at the AWS VPC. Not drawing the next hop as a solid edge is what the figure is for.

Encryption also sits at two layers worth keeping apart. MACsec on the physical link and cluster
peering encryption over FlexCache traffic (ONTAP 9.6 or later, TLS 1.2 AES-256 GCM) are different
things, and the first does not remove the need for the second. Whether ONTAP itself offers MACsec
on an intercluster LIF is something I could find no statement for. The options and the Region
coverage are in cross-cloud connectivity.

FlexCache duality (S3 reads on the cache side) does work, once S3 access is enabled on the cache volume itself with -is-s3-enabled true in advanced privilege. The earlier AccessDenied was a missing setting, not a platform limitation. The architecture still keeps cache-side access to NFS/SMB, because ONTAP native S3 and the AWS-managed access point are separate mechanisms and the NAS bucket is a read-only view without IAM integration.

---

All test resources torn down. Numbers are from a specific test environment and vary by workload and configuration.