DEV Community: Yoshiki Fujiwara(藤原善基)@AWS Community Builder

Building an Agentic Access-Aware RAG System with Amazon FSx for NetApp ONTAP, S3 Vectors, and S3 Access Points— Where AI Respects File Permissions

Yoshiki Fujiwara(藤原善基)@AWS Community Builder — Sun, 05 Apr 2026 17:15:03 +0000

Introduction

Enterprise data lives on file servers. And on those file servers, not everyone can see everything — NTFS ACLs, UNIX permissions, and group policies control who accesses what. But when you plug that data into a Retrieval-Augmented Generation (RAG) system, those permission boundaries tend to disappear. Suddenly, anyone can ask the AI about another team's, division's, or board member's confidential information.

But there's a flip side to this problem that's equally important: without permission awareness, the AI can't fully help the people it should be helping.

Think about it. An engineer has years of design docs, project specs, and team-internal notes in their department's shared folder. A sales lead has pipeline data, customer contracts, and regional forecasts in theirs. When you strip away permissions and dump everything into one vector store, the AI doesn't just leak confidential data — it also drowns each user's results in irrelevant noise from every other team. The engineer gets sales forecasts mixed into their search results. The sales lead gets CI/CD pipeline docs they'll never need.

Permission-aware/Access-aware RAG flips this around. Because the system knows exactly which files each user can access, it delivers personalized, noise-free AI assistance grounded in the data each person actually works with day to day. Your personal folder, your team's shared drive, the cross-functional project space you're part of — the AI sees what you see, nothing more, nothing less.

I built Agentic Access-Aware RAG to make this real. It's an open-source system that lets AI agents autonomously search, analyze, and respond to enterprise data stored on Amazon FSx for NetApp ONTAP — while respecting per-user file-level access permissions. The same question yields different answers depending on who's asking: an admin gets the full financial report, a project member gets their project's restricted docs, and a general user gets public information only. Each user gets an AI assistant that's effectively customized to their role and responsibilities — without any manual configuration.

The entire stack deploys with a single npx cdk deploy --all command.

👉 GitHub: Yoshiki0705/FSx-for-ONTAP-Agentic-Access-Aware-RAG

Architecture at a Glance

Browser → AWS WAF → CloudFront (OAC+Geo) → Lambda Web Adapter (Next.js 15)
                                                    │
              ┌─────────────┬───────────────────────┼──────────────────┐
              ▼             ▼                       ▼                  ▼
        Cognito       Bedrock KB              DynamoDB            DynamoDB
       User Pool    + S3 Vectors /          user-access          perm-cache
                    OpenSearch SL           (SID Data)         (Perm Cache)
                         │
                         ▼
                  FSx for ONTAP
                  (SVM + Volume)
                + S3 Access Point

The system is organized into 7 CDK stacks: WAF, Networking, Security (Cognito), Storage (FSx for ONTAP + DynamoDB), AI (Bedrock KB + vector store), WebApp (Lambda + CloudFront), and an optional Embedding stack.

The Core Idea: Permission-aware/Access-aware RAG

Traditional RAG retrieves documents based on semantic similarity alone. This system adds a second dimension: SID-based permission filtering.

Here's the flow:

User sends a question via the chat UI
The app retrieves the user's SID list (personal SID + group SIDs) from DynamoDB
Bedrock KB Retrieve API performs vector search — each result carries allowed_group_sids metadata
The app matches each document's SIDs against the user's SIDs
Only permitted documents are passed to the Converse API for answer generation
The user sees a filtered response with citation badges showing access levels

■ Admin user: SIDs = [...-512 (Domain Admins), S-1-1-0 (Everyone)]
  public/          → S-1-1-0 match  → ✅ Permitted
  confidential/    → ...-512 match  → ✅ Permitted
  engineering/     → No match       → ❌ Filtered out (no noise from other teams)

■ Engineer (Engineering group member): SIDs = [...-1100 (Engineering), S-1-1-0 (Everyone)]
  public/          → S-1-1-0 match  → ✅ Permitted
  confidential/    → No match       → ❌ Denied
  engineering/     → ...-1100 match → ✅ Their team's docs, front and center

■ Sales user: SIDs = [...-1200 (Sales), S-1-1-0 (Everyone)]
  public/          → S-1-1-0 match  → ✅ Permitted
  confidential/    → No match       → ❌ Denied
  engineering/     → No match       → ❌ No engineering noise in their results

The engineer asking "What's the status of Project X?" gets answers from their team's internal docs — not from sales forecasts or HR policies. The sales lead asking "What are our Q3 targets?" gets their regional data without wading through engineering specs. Each user's AI experience is naturally scoped to the data they work with every day.

S3 Access Points: The Bridge Between FSx for ONTAP and Bedrock KB

One of the most impactful recent additions is S3 Access Point integration with FSx for ONTAP. This creates a clean, single-path data ingestion architecture:

FSx for ONTAP Volume (/data)
  ├── public/company-overview.md
  ├── public/company-overview.md.metadata.json
  ├── confidential/financial-report.md
  ├── confidential/financial-report.md.metadata.json
      │
      │  S3 Access Point
      ▼
  Bedrock KB Data Source (S3 AP alias)
      │  Ingestion Job (chunking + Titan Embed v2)
      ▼
  Vector Store (S3 Vectors or OpenSearch Serverless)

Before S3 Access Points, getting data from FSx for ONTAP into Bedrock KB required either a custom Embedding server with CIFS mounts or manual S3 uploads. Now, Bedrock KB reads documents directly from the FSx for ONTAP volume through the S3 Access Point — no intermediate copies, no sync scripts.

The S3 AP user type is automatically selected based on your AD configuration:

AD Configuration	Volume Style	S3 AP User Type	Behavior
AD configured	NTFS	WINDOWS (`Admin`)	NTFS ACLs automatically applied
No AD	NTFS/UNIX	UNIX (`root`)	All files accessible; permission control via `.metadata.json`

One gotcha I discovered: the S3 AP WindowsUser must not include the domain prefix. DEMO\Admin works for CLI operations but causes AccessDenied on data plane APIs (ListObjects, GetObject). Always specify just Admin.

S3 Vectors: Low-Cost Vector Storage

The default vector store is Amazon S3 Vectors — a relatively new service that brings vector search costs down to a few dollars per month, compared to ~$700/month for OpenSearch Serverless.

Configuration	Cost	Latency	Best For
S3 Vectors (default)	~$2-5/month	Sub-second to 100ms	Demo, dev, cost optimization
OpenSearch Serverless	~$700/month	~10ms	High-performance production

S3 Vectors does have a 2KB filterable metadata limit per vector. Since Bedrock KB's internal metadata already consumes ~1KB, custom metadata is effectively limited to ~1KB. The system handles this by setting all metadata keys (including allowed_group_sids) as non-filterable and performing SID matching on the application side after retrieval.

If you start with S3 Vectors and later need higher performance, you can export on-demand to OpenSearch Serverless using the included export-to-opensearch.sh script.

Embedding Design: `.metadata.json` and the Ingestion Pipeline

Permission metadata follows the standard Bedrock KB metadata file specification. Each document has a companion .metadata.json file:

product-catalog.md                    ← Document body
product-catalog.md.metadata.json      ← Permission metadata

The metadata format:

{
  "metadataAttributes": {
    "allowed_group_sids": "[\"S-1-1-0\"]",
    "access_level": "public",
    "doc_type": "catalog"
  }
}

The allowed_group_sids field is a JSON array string of Windows SIDs that are allowed to access the document. S-1-1-0 is the well-known "Everyone" SID.

Bedrock KB Ingestion Jobs automatically read these .metadata.json files alongside documents, chunk the content, vectorize with Amazon Titan Text Embeddings v2 (1024 dimensions), and store everything in the vector store. No custom ETL pipeline needed.

Design Decisions and Trade-offs

At scale (thousands of documents), managing individual .metadata.json files becomes a maintenance burden. The system supports three approaches:

Approach	Status	Pros	Cons
`.metadata.json` (current default)	✅ Production	Bedrock KB native, no extra infra	Doubles file count, manual management
ONTAP REST API auto-generation	✅ Partially implemented	File server ACLs as source of truth	Requires Embedding server
DynamoDB permission master	🔜 Recommended for scale	DB-driven, easy auditing	Requires pre-Ingestion generation pipeline

The recommended direction for large-scale environments:

ONTAP REST API (ACL retrieval)
  → DynamoDB document-permissions table
  → Auto-generate .metadata.json before Ingestion Job
  → Ingest via S3 AP into Bedrock KB

Multiple Authentication Modes

The system supports 5 authentication configurations, all driven by cdk.context.json parameters:

Mode	Authentication	Permission Source	Configuration
A: Email/Password	Cognito native	Manual DynamoDB SID registration	Default (no extra config)
B: SAML AD Federation	Cognito + SAML IdP	AD Sync Lambda → auto SID retrieval	`enableAdFederation=true`
C: OIDC + LDAP	Cognito + OIDC IdP	LDAP query → auto UID/GID retrieval	`oidcProviderConfig` + `ldapConfig`
D: OIDC Claims Only	Cognito + OIDC IdP	OIDC token claims → group mapping	`oidcProviderConfig` + `groupClaimName`
E: SAML + OIDC Hybrid	Both IdPs simultaneously	Combined SID + UID/GID	Both configs + `permissionMappingStrategy=hybrid`

The OIDC/LDAP federation (added in v3.4.0) enables zero-touch user provisioning: when a user signs in via the OIDC IdP for the first time, the Identity Sync Lambda automatically queries LDAP for their UID/GID/groups and stores them in DynamoDB. No admin intervention required.

For environments with FSx for ONTAP UNIX volumes, the system also supports ONTAP name-mapping — automatically resolving UNIX usernames to Windows users via the ONTAP REST API.

Agentic AI: Beyond Document Search

The system isn't just a search engine. Toggle between two modes with one click:

KB Mode: Permission-aware/Access-aware document search and Q&A
Agent Mode: Permission-aware/Access-aware autonomous multi-step reasoning and task execution via Bedrock Agents

Agent mode includes an Agent Directory — a catalog-style management screen where you can create, edit, share, and schedule Bedrock Agents from templates. 14 workflow cards cover research tasks (market analysis, competitive research, etc.) and output tasks (presentations, approval documents, meeting minutes).

Permission filtering works in both modes. Even when an Agent autonomously searches and reasons across multiple documents, only documents the user is authorized to see are included.

AgentCore Memory (v3.3.0)

With enableAgentCoreMemory=true, the system integrates Amazon Bedrock AgentCore Memory for conversation context maintenance:

Short-term memory: In-session conversation history (TTL: 3 days)
Long-term memory: Cross-session user preferences and summaries (semantic + summary strategies)

Additional Features

Smart Routing (v3.1.0)

Automatic model selection based on query complexity. Short factual queries route to Claude Haiku (fast, cheap); complex analytical queries route to Claude Sonnet (powerful). Toggle ON/OFF in the sidebar.

Image Analysis RAG (v3.1.0)

Drag-and-drop image upload in the chat input. Images are analyzed with Bedrock Vision API (Claude Haiku 4.5) and the analysis is integrated into KB search context.

6-Layer Security

Layer	Technology	Purpose
L1	CloudFront Geo Restriction	Geographic access control
L2	AWS WAF (6 rules)	Attack pattern detection
L3	CloudFront OAC (SigV4)	Origin authentication
L4	Lambda Function URL IAM Auth	API-level access control
L5	Cognito JWT / SAML / OIDC	User authentication
L6	SID / UID+GID Filtering	Document-level authorization

8-Language i18n — Why It Matters

The UI and all documentation (README, guides, setup instructions) are available in 8 languages: Japanese, English, Korean, Simplified Chinese, Traditional Chinese, French, German, and Spanish.

This isn't just a nice-to-have. Enterprise file servers are inherently multi-regional — a global company's FSx for ONTAP volumes serve teams across Tokyo, Seoul, Shanghai, Frankfurt, and New York. If the RAG interface only speaks English, you've created a barrier for the very users who need it most. Non-English-speaking knowledge workers shouldn't need to context-switch languages just to search their own documents.

From a Community Builder perspective, localization also lowers the barrier to adoption. When a solutions architect in São Paulo or a storage admin in Taipei can read the deployment guide in their own language, they're far more likely to actually try it, fork it, and adapt it to their environment. Open-source projects that only document in one language inadvertently limit their community to one language group.

The implementation uses Next.js next-intl with per-locale message files (src/messages/{locale}.json). Every UI string — from card labels to sign-in buttons to error messages — goes through useTranslations(). The sign-in page even detects the browser's preferred language and auto-redirects to the matching locale.

Localization doesn't stop at the UI chrome. The AI's chat responses also match the user's language. The system prompt instructs the model to "respond in the same language as the question" — so a Korean user asking in Korean gets a Korean answer with Korean citation labels ("참조 문서", "전체 접근 가능"), and a German user gets "Referenzierte Dokumente" and "Allgemein zugänglich". This end-to-end language consistency — from sign-in screen to card labels to AI-generated answers to citation metadata — means users never hit a jarring language switch mid-workflow.

Here's what the card grid and sign-in screens look like across all 8 languages:

🇯🇵 日本語	🇺🇸 English	🇰🇷 한국어	🇨🇳 简体中文

🇹🇼 繁體中文	🇫🇷 Français	🇩🇪 Deutsch	🇪🇸 Español

Sign-in pages are also fully localized:

🇯🇵	🇺🇸	🇫🇷	🇩🇪

Tips for Builders

A few things I learned the hard way that might save you time.

OpenLDAP `memberOf` Overlay

If you're testing with OpenLDAP, the LDAP Connector reads the memberOf attribute from user entries. Basic OpenLDAP doesn't populate this automatically — you need to add moduleload memberof and overlay memberof to slapd.conf, and create groupOfNames entries (not just posixGroup). posixGroup and groupOfNames are different structural classes and can't coexist in the same entry — use a separate OU.

The repo includes setup-openldap.sh that handles all of this automatically.

Geo Restriction Default

The WAF configuration defaults to Japan-only access (allowedCountries: ["JP"]). If you're deploying outside Japan, update this before deploying:

{ "allowedCountries": ["JP", "US", "DE", "SG"] }

Set to [] for worldwide access.

Multiple Volumes, One Deployment

If your FSx file system has multiple volumes, specify one as the primary during CDK deployment. Additional volumes can be added as Bedrock KB data sources after deployment — each gets its own S3 Access Point and can be independently synced.

Built with Kiro

I used Kiro throughout the entire development lifecycle — specs for requirements-to-code traceability, hooks for automated validation on file saves, and steering files for project-specific rules that persist across sessions. The 8-language documentation, 130+ unit tests, 52 property-based tests, and the LDAP/ONTAP live environment verification were all developed with Kiro's assistance. As a solo developer, this level of tooling makes enterprise-quality projects feasible.

Getting Started

git clone https://github.com/Yoshiki0705/FSx-for-ONTAP-Agentic-Access-Aware-RAG.git
cd FSx-for-ONTAP-Agentic-Access-Aware-RAG && npm install

npx cdk bootstrap aws://$(aws sts get-caller-identity --query Account --output text)/ap-northeast-1
npx cdk bootstrap aws://$(aws sts get-caller-identity --query Account --output text)/us-east-1

bash demo-data/scripts/pre-deploy-setup.sh
npx cdk deploy --all --require-approval never
bash demo-data/scripts/post-deploy-setup.sh

Prerequisites: Node.js 22+, Docker, AWS CLI configured with AdministratorAccess. Total deployment time is about 30-40 minutes (FSx for ONTAP creation takes 20-30 minutes).

The post-deploy-setup.sh script handles everything after CDK deployment: S3 Access Point creation, demo data upload, Bedrock KB data source registration + sync, DynamoDB SID data, and Cognito demo users.

What's Next

The project is at v3.4.0 and actively evolving. Some directions I'm exploring:

DynamoDB-driven permission master for large-scale environments (eliminating per-file .metadata.json management)
Multi-volume embedding across multiple FSx for ONTAP volumes with independent S3 Access Points
Bedrock KB Custom Data Source integration as an alternative to S3 AP

I'm looking for feedback on:

Permission models: Are SID/UID-GID/hybrid strategies sufficient for your use cases?
Authentication patterns: What IdP combinations do you need?
Document types: Beyond markdown, what formats need Permission-aware/Access-aware handling?

If you try it out, I'd love to hear about your experience — especially edge cases I haven't considered. PRs and issues are welcome.

👉 GitHub Repository and README.md you can switch language from 8 as well as Applicatiton UI

Yoshiki Fujiwara

Taking a look at Tiering of AWS ever-evolving File Storage services!

Yoshiki Fujiwara(藤原善基)@AWS Community Builder — Tue, 31 Dec 2024 13:42:48 +0000

Disclaimer

Opinions are my own.
Cover image is for Amazon S3 Intelligent-Tiering storage class Automatic Access tiers, but main topic is AWS File Storage Tiering.
If you have any questions or concerns after reading this article, please let us know.
Based on the features and contents as of December 31, 2024. If there are any discrepancies, please check the latest AWS official information at the time you read the article.

Why it's a good time to take a look at AWS File Storage Tiering now?
File storage services on AWS
What is Tiering?
Tierings of AWS file storage services
Conclusion

Why it's a good time to take a look at AWS File Storage Tiering now?

In conclusion, "AWS file storage services and features are so diversified that it is difficult to understand them as a whole". In such a situation, Tiering is an effective function for optimizing the file storage environment. But, it's difficult to understand because there are no materials for cross-sectional understanding.
I would like to understand it from a bird's-eye view rather than comparing services. If I could not find such materials, I'll write it myself.

The direct trigger of this blog post was the update during AWS re:Invent 2024, which introduced the new FSx storage class Amazon FSx Intelligent-Tiering. You can check the AWS release note titled "Announcing Amazon FSx Intelligent-Tiering, a new storage class for FSx"

This is a announcement related storage during AWS re:Invent 2024 and is an exciting update that is attracting attention.

It was also covered at Storage-JAWS#6, the re:Cap community based webinar of AWS re:Invent 2024 of "Storage-JAWS", a storage specialized branch of the Japanese AWS User Group, or JAWS-UG.

You can check the YouTube video linked above for details. (Since this is a local event in Japan, the introduction was in Japanese)

If you haven't seen the Storage-JAWS video above, please check it out as the speakers summarize the updates in an easy-to-understand manner, and there are great sessions and LTs that are explained with live demos and screenshots of management console. Please feel free to fill out the survey after watching (this is a guide for me as a Storage-JAWS management member).

...But,
Contrary to the title and content of the release notes above, "FSx Intelligent-Tiering," the reality is that this is a feature only available for Amazon FSx for OpenZFS, and is not available for the entire Amazon FSx series. Other services that follow are not available at the time of writing this blog.

Personally, I felt that this notation was confusing, so I decided to take this opportunity to clarify "What is File Storage Tiering on AWS and how it works?"

Below are some excerpts from the AWS release note. I think there are some expressions that can lead to misunderstandings as to whether this is about the FSx series or FSx for OpenZFS feature. I will try to write this blog in a way that avoids any misunderstandings.

Today, AWS announces the general availability of Amazon FSx Intelligent-Tiering, a new storage class for Amazon FSx that costs up to 85% less than the FSx SSD storage class and up to 20% less than traditional HDD-based NAS storage on premises, and that brings full elasticity and intelligent tiering to network-attached storage (NAS). The new storage class is available today on Amazon FSx for OpenZFS.

Using Amazon FSx, customers can launch and run fully managed cloud file systems that have familiar NAS capabilities such as point-in-time snapshots, data clones, and user quotas. Before today, customers have been moving NAS data sets for mission-critical and performance-intensive workloads to FSx for OpenZFS, using the existing SSD storage class for predictable high performance. With the new FSx Intelligent-Tiering storage class, customers can now bring to FSx for OpenZFS a broad range of general-purpose data sets, including those with a large proportion of infrequently accessed data stored on low-cost HDD on premises. FSx Intelligent-Tiering delivers low-cost storage and costs up to 85% less than the FSx SSD storage class and up to 20% less than traditional HDD-based NAS storage on premises...

Now, let's get into the details.

File storage services on AWS

Items in this chapter

Storage services on AWS
File Storage services on AWS

Storage services on AWS

First, let's take a look at storage services on AWS.
As far as we can see from the following AWS Webpage "Cloud Storage on AWS", there are 11 "categories" as shown in the figure below, and each category is further divided into services and features.

Quote: Cloud Storage on AWS

File Storage services on AWS

There are three types of file storage in the diagram above: Amazon Elastic File System (EFS), Amazon FSx, and Amazon File Cache. In this article, we will take a look at the EFS and FSx series other than Amazon File Cache, which is a cache service that does not have a tiering feature.
The characteristics of File Storage and how to choose one are summarized in an easy-to-understand manner on the AWS blog "How to choose an AWS file storage service".
It's written in Japanese, but you can easy to understand the contents of it. Or you can check AWS re:Invent sessions of AWS Files Storage Team like AWS re:Invent 2024 - Network-attached storage in the cloud with Amazon FSx (STG202)

For example, in the AWS blog mentioned above, in the "Storage Types" section below, it confirmed the understanding of the three types of "block storage", "object storage", and "file storage" that will be explained this time,

In the "File Storage Protocols" section below, it discusses the two protocols NFS (Network File System) and SMB (Server Message Block), and in the "AWS File Storage Service" section, it explains Amazon FSx for Luster's unique protocol. Let's check the three protocols including.

In addition, in the "Comparison of AWS File Storage Services" section, the figure below shows a list of services excluding FSx for Luster at the time of writing, and points to consider when making a selection. In "Protocols supported by each service," Amazon FSx for NetApp ONTAP is characterized by being multi-protocol, not only supporting both NFS and SMB protocols, but also supporting iSCSI. It also touches on some unique aspects.

Next, in the section "How to choose an AWS file storage service", the part "Consider what you are looking for" touches on Tiering, the main theme of this blog, and the EFS lifecycle policy. In this blog, I will update and supplement the above table based on the AWS re:Invent 2024 Update.

What is Tiering?

What do you think of when you hear the word "Tiering"?
Let's take a look at Amazon S3, AWS's representative storage. In the feature description of "Amazon S3 Intelligent-Tiering storage class" whose name includes Tiering, This feature is introduced from the perspective of cost optimization as follows.

The Amazon S3 Intelligent-Tiering storage class is designed to optimize storage costs by automatically moving data to the most cost-effective access tier when access patterns change.

However, I guess that the scope of implementation and use cases are gradually expanding now.
For example, on an AWS blog, "Optimizing your AWS Infrastructure for Sustainability, Part II: Storage", the section "Analyze data access patterns and use storage tiers", with the following two explanations, it suggests to make S3 lifecycle management sustainable by using automated tiering.

Choosing the right storage tier after analyzing data access patterns gives you more sustainable storage options in the cloud.
For data with unknown or changing access patterns, use Amazon S3 Intelligent-Tiering to monitor access patterns and move objects among tiers automatically.

In this way, we can see that storage tiering is important not only from a cost optimization perspective but also from a sustainability perspective.

I often use not only S3 but also the EFS and FSx series of file storage services from the perspective of optimizing cost and performance, and provide design support. I will take a deep dive into file storage, which has a wide variety of types and features.

Tierings of AWS file storage services

Items in this chapter

Tierings of AWS file storage services
Relevant information

Tierings of AWS file storage services

Description/Service	EFS	FSx for OpenZFS	FSx for ONTAP	FSx for Lustre	FSx for Windows
Tiering	Available	Available	Available	N/A	N/A
Tiering granularity	File Level	Data Block Level	Data Block Level	N/A	N/A
Tiering configuration unit	File System	File System	Volume	N/A	N/A
Tiering Class/Pool	1.Standard 2.Infrequent Access (IA) 3.Archive	1.Frequent Access 2.Infrequent Access 3.Archive	1.Primary Storage(SSD) 2.Capacity Pool (HDD)	N/A	N/A

I purposely included "Tiering granularity". This is because it's one of pitfalls of tiering. Let's say S3 and EFS implement file/object level tiering, so when the file/object is read, it is determined that it has been accessed and the tiering is applied even if the data blocks in the file have hardly been read and tiering won't be triggered the rest of data block has never been accessed.

On the other hand, FSx for OpenZFS and FSx for ONTAP have data block level tiering, so the data blocks that can potentially be optimized for cost/performance through tiering may be wider.

As an example, if you open this blog and leave after just seeing the title, EFS and S3 will not be subject to Tiering who this file/object, but FSx for OpenZFS and FSx for ONTAP will execute Tiering for unread data blocks other than the title. As described in the ONTAP Knowledge Base and Technical Report, FSx for ONTAP judges data blocks in 4K units and performs tiering in 4M units. Regarding FSx for OpenZFS, I have not yet been able to find any documentation that shows the specific behavior of Tiering at the data block level, so if anyone knows about it, I would appreciate it if you could let me know.

Cautions and TIPs:

The FSx Intelligent-Tiering storage class of FSx for OpenZFS can only be used in multi-AZ configurations on a file system basis.
- Screenshot of AWS Management Console for creating FSx for OpenZFS file system. When you choose Intelligent-Tiering (elastic) Storage class, you cannot choose Single-AZ 2 (HA) nor Single-AZ 2 (non-HA).
Tiering in FSx for ONTAP allows you to change and tune the Tiering Policy even after the file system and volume are created. Both single-AZ and multi-AZ configurations are possible.
- Screenshots of AWS Management Console for creating FSx for ONTAP file system and Updating volume.
If you want to run EFS Tiering when creating a file system, select "Customize" and set it in "Lifecycle Management".

Relevant information

EFS Tiering：

Amazon EFS Pricing: > Amazon EFS offers three storage classes: EFS Standard, SSD-based storage which delivers sub-millisecond latencies for actively-used data; EFS Infrequent Access (EFS IA), cost-optimized storage which delivers milliseconds latencies for data accessed only a few times a quarter; and EFS Archive, cost-optimized storage which delivers milliseconds latencies for long-lived data accessed a few times a year or less.
Amazon EFS Infrequent Access：「Amazon EFS will automatically and transparently move your files to the lower cost regional EFS IA storage class based on the last time they were accessed. 」
Amazon EFS Archive：「Amazon EFS will automatically and transparently move your files to the lower cost EFS IA and Archive storage classes based on the last time they were accessed.」

FSx for OpenZFS Tiering：

Amazon FSx for OpenZFS Features > Cost optimization>Intelligent-Tiering(Need to open to see following description):

Intelligent-Tiering delivers automatic storage cost savings when data access patterns change, without performance impact or operational overhead. The Amazon FSx for OpenZFS Intelligent-Tiering storage class is designed to optimize storage costs using elasticity to automatically move data to the most cost-effective access tier when access patterns change. Amazon FSx Intelligent-Tiering is up to 85% lower cost than the FSx SSD storage class, and up to 20% lower cost compared to traditional on-premises HDD deployments.

AWS News blog: Announcing Amazon FSx Intelligent-Tiering, a new storage class for FSx for OpenZFS

FSx for ONTAP：

Amazon FSx for NetApp ONTAP Features > Cost optimization > Elastic capacity pool tiering(Need to open to see following description)：

Each Amazon FSx for NetApp ONTAP file system has two storage tiers: primary storage and capacity pool storage. Primary storage is provisioned, scalable, high-performance SSD storage that’s purpose-built for the active portion of your data set. Capacity pool storage is a fully elastic storage tier that can scale to petabytes in size and is cost-optimized for infrequently-accessed data. Amazon FSx for NetApp ONTAP automatically tiers data from SSD storage to capacity pool storage based on your access patterns, allowing you to achieve SSD levels of performance for your workload while only paying for SSD storage for a small fraction of your data. Capacity pool storage automatically grows and shrinks as you tier data to it, providing elastic storage for the portion of your data set that grows over time without the need to plan or provision capacity for this data.

ONTAP Tiering logic: Technical Report FabricPool best practices ONTAP 9.14.1

Data movement > Tiering data to an object store
After a block has been identified as cold, it is marked for tiering. During this time, a background tiering scan looks for cold blocks. When enough 4KB blocks from the same volume have been collected, they are concatenated into a 4MB object and moved to the cloud tier based on the volume tiering policy.

Conclusion

What do you think of this summary of AWS file storage Tiering?
When selecting a file system, you will most likely choose one that you are familiar with. However, from the perspective of cost/performance optimization, data integration, application configuration, security, etc., why not consider equally the features and benefits of other services?

Among the options discussed this time, there are differences in the tiering methods for EFS, FSx for OpenZFS, and FSx for ONTAP, and you will need to make a choice based on usage and user experience.
Regarding prices, the actual amount and validity vary greatly depending on the method of use and purpose, and it often changes with the release of new features, so I intentionally did not include it in the list this time so as not to make the comparison stand alone.

I am sure that Amazon FSx Intelligent-Tiering will become even more powerful in the future. Let's keep an eye on AWS file storage and Tiering, which will continue to evolve!!
I hope this blog will be helpful to someone.

Bye now!!

Socials:

DEV Community: Yoshiki Fujiwara(藤原 善基)@AWS Community Builder

Building an Agentic Access-Aware RAG System with Amazon FSx for NetApp ONTAP, S3 Vectors, and S3 Access Points— Where AI Respects File Permissions

Introduction

Architecture at a Glance

The Core Idea: Permission-aware/Access-aware RAG

S3 Access Points: The Bridge Between FSx for ONTAP and Bedrock KB

S3 Vectors: Low-Cost Vector Storage

Embedding Design: .metadata.json and the Ingestion Pipeline

Design Decisions and Trade-offs

Multiple Authentication Modes

Agentic AI: Beyond Document Search

AgentCore Memory (v3.3.0)

Additional Features

Smart Routing (v3.1.0)

Image Analysis RAG (v3.1.0)

6-Layer Security

8-Language i18n — Why It Matters

Tips for Builders

OpenLDAP memberOf Overlay

Geo Restriction Default

Multiple Volumes, One Deployment

Built with Kiro

Getting Started

What's Next

Taking a look at Tiering of AWS ever-evolving File Storage services!

Disclaimer

Table of contents

Why it's a good time to take a look at AWS File Storage Tiering now?

File storage services on AWS

Storage services on AWS

File Storage services on AWS

What is Tiering?

Tierings of AWS file storage services

Tierings of AWS file storage services

Relevant information

Conclusion

DEV Community: Yoshiki Fujiwara(藤原善基)@AWS Community Builder

Embedding Design: `.metadata.json` and the Ingestion Pipeline

OpenLDAP `memberOf` Overlay