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

FSx for ONTAP S3 Access Points as a Serverless Automation Boundary — AI Data Pipelines, Volume-Level SnapMirror DR, and Capacity Guardrails

Yoshiki Fujiwara(藤原善基)@AWS Community Builder — Fri, 01 May 2026 23:44:20 +0000

TL;DR: FSx for ONTAP S3 Access Points let you treat NAS data as an S3-facing automation boundary — without moving data — making serverless AI pipelines and ops workflows practical.

This is a continuation of Building an Agentic Access-Aware RAG System with Amazon FSx for NetApp ONTAP. While the previous article focused on the RAG application itself, this one covers the operational automation layer built around FSx for ONTAP S3 Access Points.

The Shift: S3 Access Points Make Serverless NAS Automation Practical

Enterprise file data lives on FSx for NetApp ONTAP — accessed via SMB/NFS by users and applications every day. Automating operations around that data has traditionally meant mounting NFS from compute instances, managing file system connections, and dealing with the cold-start and connection-limit penalties that come with VPC-mounted Lambda functions.

FSx for ONTAP S3 Access Points change this equation. They expose ONTAP file data through supported S3 object APIs — GetObject, PutObject, ListObjectsV2, and others — while keeping the data in FSx and preserving concurrent SMB/NFS access. The practical shift is that Lambda no longer needs mounted NAS access for the data path. S3 Access Points provide the supported object-facing operations, and ONTAP REST API supplies the storage-system metadata that S3 cannot expose.

This is the architectural pivot that makes the automation suite in this article possible:

Serverless file inventory without NFS/SMB mounts from Lambda
AI / RAG preprocessing directly against ONTAP file data through supported S3 object APIs
Metadata sidecar generation by combining S3-listed objects with ONTAP ACL, export policy, and security-style metadata via REST API
Scheduled governance scans over NAS data using IAM + file-system authorization
Reuse of S3-speaking application components (Bedrock KB, analytics tools) without moving data out of ONTAP

ONTAP REST API complements this by providing the control-plane and storage-system context — volume management, SnapMirror orchestration, capacity monitoring, snapshot operations — that S3 Access Points are not designed to handle.

👉 Code: automation/fsxn-ops/

S3 Access Point Compatibility Model

FSx for ONTAP S3 Access Points support a subset of S3 APIs, not full S3 bucket semantics. Understanding this boundary is essential for building reliable automation.

Supported operations used in this automation:

ListObjectsV2 — file inventory and scanning
GetObject — file content access for preprocessing
PutObject — writing metadata sidecars and manifests

Notable unsupported operations:

GetBucketNotificationConfiguration — this is why the design uses scheduled polling instead of S3 notification-driven triggers
GetObjectAcl / PutObjectAcl — object ACL management is not available
Presign — presigned URL generation is not supported
Bucket-style management APIs and bucket-notification semantics do not apply in the same way here

Authorization operates at two layers: IAM permissions control AWS-level access, while file-system-level authorization uses the mapped user identity (UNIX or Windows) configured on the S3 Access Point. File-level ACLs are retrieved via the ONTAP REST API; S3 APIs do not expose file-system ACLs.

Architecture

The architecture has four layers, with S3 Access Points as the data-path boundary:

┌─────────────────────────────────────────────────────────┐
│  Orchestration: EventBridge Scheduler / Step Functions   │
├─────────────────────────────────────────────────────────┤
│  Compute: Lambda (Python 3.12, VPC-deployed)            │
├──────────────────────┬──────────────────────────────────┤
│  Data Path:          │  Control Plane:                  │
│  FSx ONTAP S3 AP     │  ONTAP REST API                  │
│  (ListObjectsV2,     │  (volumes, SnapMirror,           │
│   GetObject,         │   snapshots, exports,            │
│   PutObject)         │   security_style, ACLs)          │
├──────────────────────┴──────────────────────────────────┤
│  Storage: FSx for NetApp ONTAP (SMB/NFS + S3 AP)       │
└─────────────────────────────────────────────────────────┘

S3 Access Points = data-path (file listing, content access, sidecar writes)
ONTAP REST API = storage metadata + control-plane (resize, SnapMirror, snapshots, ACLs, export policies)
Step Functions / Lambda = orchestration and compute
EventBridge = scheduled execution (polling, not file-change triggers)

Implementation

1. Data Preprocessor: The S3 Access Point Workflow

This is the core use case that S3 Access Points enable. The preprocessor scans FSx ONTAP volumes through S3 Access Points and enriches the results with ONTAP-specific storage metadata.

class DataPreprocessor:
    def list_source_objects(self, prefix="", suffix_filter=None):
        """List files on FSx ONTAP via S3 Access Point (ListObjectsV2)"""
        response = self.s3.list_objects_v2(
            Bucket=self.s3_access_point_arn,  # FSx ONTAP S3 AP ARN
            Prefix=prefix,
        )
        # Filter by extension, collect basic object metadata
        # (key, size, last_modified, etag)
        ...

    def collect_ontap_metadata(self, volume_name):
        """Get storage-system metadata via ONTAP REST API"""
        vol_detail = self.ontap.get_volume(vol_uuid)
        return {
            "security_style": vol_detail["nas"]["security_style"],
            "export_policy": vol_detail["nas"]["export_policy"]["name"],
            "snapshot_count": len(self.ontap.list_snapshots(vol_uuid)),
        }

S3 Access Points give you data-path operations and basic object-facing metadata (key, size, last modified, ETag). ONTAP REST API provides storage-system metadata and control-plane attributes — security style, export policies, snapshot information, and NAS/storage context that S3 APIs cannot expose.

The preprocessor combines both to generate task manifests for downstream AI/analytics pipelines:

S3 AP: ListObjectsV2 → file inventory (.md, .pdf, .docx)
ONTAP REST: GET /storage/volumes → security_style, export_policy, snapshots
  → Generate preprocessing tasks (batch_size=10)
  → Write manifest to S3 (PutObject)
  → Downstream: Bedrock KB Ingestion, analytics, governance

2. ONTAP REST API Client

The shared Python client handles control-plane operations. Credentials come from Secrets Manager.

class OntapClient:
    def __init__(
        self,
        management_lif: str,
        secret_id: str,
        verify_ssl: bool = True,       # Default: TLS verification enabled
        ca_cert_path: str = None,       # CA bundle for production
    ):
        if not verify_ssl:
            logger.warning("TLS verification disabled — lab/PoC only")

TLS verification is enabled by default. FSx for ONTAP management LIFs use self-signed certificates, so production deployments should provide a CA bundle via ca_cert_path. For lab/PoC environments, verify_ssl=False can be set explicitly — the client logs a warning. The ONTAP_VERIFY_SSL and ONTAP_CA_CERT_PATH environment variables control this at the Lambda level.

3. Capacity Monitor with Guardrails

Runs every 5 minutes via EventBridge Scheduler. Checks filesystem-level capacity (FSx API + CloudWatch) and volume-level usage (ONTAP REST API).

Guardrail	Default	Purpose
`DRY_RUN`	`true`	Safe default — logs actions without executing
`MAX_GROW_PER_ACTION_PCT`	50%	Prevents a single run from doubling a volume
`MAX_GROW_PER_DAY_GIB`	500 GiB	Caps total daily expansion
`VOL_THRESHOLD_PCT`	80%	Aligned with AWS recommendation to keep SSD utilization below 80%

Observed behavior: CloudWatch StorageCapacityUtilization metrics are not always available for new filesystems or those with minimal data. The monitor falls back to ONTAP REST API for volume-level monitoring when CloudWatch data is unavailable.

4. Volume-Level SnapMirror Failover Orchestration

Scope: This automation handles planned failover for volume-level SnapMirror relationships — breaking replication, recreating selected CIFS shares and NFS exports on the DR side, and reversing the process for failback. It is not a complete SVM-DR solution. ONTAP's SVM-DR includes additional considerations such as identity preservation and replicated configuration scope. See NetApp's SVM-DR documentation for the full picture.

The Step Functions state machine orchestrates 10 actions through a single Lambda function with action routing.

SnapMirror Initialization: Two Paths

ONTAP supports documented initialization semantics during relationship creation in supported create flows. The transfers API starts an initialize or update operation depending on the current relationship state.

The automation implements both:

initialize action: Creates the relationship with "state": "snapmirrored" in supported create flows. In workflows using a pre-existing destination volume, explicit transfer may be more reliable.
final_transfer action: Explicit POST /snapmirror/relationships/{uuid}/transfers — starts an initialize or update transfer depending on the current state.

Observed in my tested environment (ONTAP 9.17.1P4D3, FSx SINGLE_AZ_1 with pre-existing destination volume): The create-with-state path resulted in a job failure, so the automation fell back to explicit transfer. Both paths are implemented and tested.

Enabling the S3 Access Point Pattern: Private-Subnet Networking

If you want S3 Access Point-driven serverless automation for ONTAP data in a private-subnet design (no NAT Gateway), this is the endpoint footprint you need:

Service	Type	Why
`secretsmanager`	Interface	ONTAP credentials
`fsx`	Interface	FSx API (describe, update)
`monitoring`	Interface	CloudWatch metrics
`sns`	Interface	SNS notifications
`s3`	Gateway	S3 Access Point data-path — must be associated with Lambda subnet's route table (no hourly endpoint charge)

This applies to private-subnet / no-NAT deployments. If your Lambda functions have another egress path, the endpoint requirements differ. The S3 Gateway endpoint specifically needs to be associated with the route table used by the Lambda subnet.

What I Learned from AWS Verification

Deployed and tested against FSx for ONTAP (ONTAP 9.17.1P4D3). The following are empirical observations from my tested deployment pattern.

SNS VPC endpoint is required for alerts — without it, SNS Publish silently times out in private-subnet Lambda. This is documented AWS behavior for VPC-deployed Lambda, but easy to overlook.
fsxadmin password sync is not automatic — Secrets Manager and FSx ONTAP store the password independently. If someone changes it via the console, Lambda gets 401 errors.
S3 Gateway endpoint route table association matters — it must be the specific route table used by the Lambda subnet, not just any route table in the VPC.

Same-SVM SnapMirror on SINGLE_AZ_1: Test Harness Only

⚠️ This is a low-cost automation test harness, not a real DR architecture. Source and destination volumes remain in the same failure domain (same filesystem, same AZ). Use this only for validating automation logic.

I tested SnapMirror within the same SVM on a SINGLE_AZ_1 deployment. It works for validating the automation without the cost of a second filesystem (~$200/month minimum).

Cost

Component	Monthly
Lambda (4 functions)	~$1.65
Step Functions	~$0.05
EventBridge Scheduler	~$0.00
Secrets Manager	~$0.40
CloudWatch Logs	~$0.50
Serverless subtotal	~$2.60
VPC Interface Endpoints (4 × ~$7.30/AZ)	~$29-58
S3 Gateway Endpoint	$0.00
Total (with dedicated endpoints)	~$32-61

If your VPC already has these endpoints, the incremental cost is the serverless subtotal only. The S3 Gateway endpoint has no hourly endpoint charge, so the dominant networking cost comes from the four interface endpoints.

Extending the S3 Access Point Pattern

Automated Permission Metadata Pipeline

The strongest extension connects S3 Access Points to the RAG system's permission pipeline:

EventBridge (daily)
  → S3 AP: ListObjectsV2 → file inventory
  → ONTAP REST: GET ACL metadata per file
  → Generate .metadata.json with allowed_group_sids
  → S3 AP: PutObject → write sidecars alongside source files
  → Trigger Bedrock KB Ingestion Job

This eliminates manual .metadata.json management — the automation reads NTFS ACLs from ONTAP REST API and generates permission metadata automatically, writing it back through the S3 Access Point.

Multi-Volume Ingestion Orchestration

For environments with multiple FSx ONTAP volumes, each with its own S3 Access Point:

Step Functions Map:
  → Per volume: S3 AP scan → ONTAP metadata → generate sidecars
  → Per volume: Trigger Bedrock KB Ingestion Job
  → Wait for all → validate vector counts → notify

ONTAP Operations Chatbot

Combine ontap_api_executor with Bedrock Agent for natural language ONTAP management. The security controls (method restrictions, blocked paths) make this safe for read-only chatbots.

Testing

38 unit tests covering TLS verification modes, SnapMirror dual initialization paths, capacity guardrails, and S3 AP operations:

pip install -r automation/fsxn-ops/requirements.txt
pytest automation/fsxn-ops/tests/ -v

# AWS integration tests (auto-deploys, tests, cleans up)
bash automation/fsxn-ops/tests/integration/run_aws_verification.sh

Wrapping Up

FSx for ONTAP S3 Access Points are the architectural enabler that makes this automation suite practical:

AI / data pipelines — ONTAP file data becomes accessible to serverless workflows through S3 Access Points (supported S3 object APIs), enriched with ONTAP REST API storage-system metadata
Management — ONTAP REST API handles control-plane automation (volumes, snapshots, exports)
Capacity — monitored with guardrails and safe expansion defaults
Volume-level DR — planned failover / failback for volume-level SnapMirror relationships (not full SVM-DR)

The serverless compute cost is ~$2.60/month. The code is open source and deploys with a single CloudFormation command.

👉 GitHub: automation/fsxn-ops/
📖 Full project: Yoshiki0705/FSx-for-ONTAP-Agentic-Access-Aware-RAG

Yoshiki Fujiwara

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

🆕 Updated April 2026: v4.0.0 released with 6 new features — Agent Registry, Multimodal RAG, Guardrails, Episodic Memory, Voice Chat, and AgentCore Policy. See what's new.

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 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
📦 Latest Release: v4.0.0 — 6 new features added

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 ONTAP + DynamoDB), AI (Bedrock KB + vector store), WebApp (Lambda + CloudFront), and an optional Embedding stack.

The Core Idea: Permission-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 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 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 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 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 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 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 three modes with one click:

KB Mode: Permission-aware document search and Q&A
Single Agent Mode: Permission-aware autonomous multi-step reasoning via a single Bedrock Agent
Multi Agent Mode: Supervisor + Collaborator pattern for complex multi-agent workflows

Agent mode includes an Agent Directory — a catalog-style management screen where you can create, edit, share, and schedule Bedrock Agents from templates. The directory now includes a Registry tab for importing agents from AWS Agent Registry, and a Teams tab for creating multi-agent teams.

Permission filtering works in all modes. Even when agents autonomously search and reason 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)

Episodic Memory (v4.0.0)

Building on AgentCore Memory, enableEpisodicMemory=true adds a new dimension: the agent remembers how it solved problems, not just what it knows.

While semantic memory stores facts and summaries, episodic memory records complete task episodes — the goal, reasoning steps, actions taken, outcomes, and reflections. When a similar task comes up later, the agent automatically retrieves the top 3 most relevant past episodes and injects them into its reasoning context.

Think of it as giving the agent a "lessons learned" database that grows with every interaction:

Episode recording: After each conversation, a Background Reflection process automatically extracts episodes
Similar episode injection: Before executing a task, the agent searches for similar past episodes and uses them to inform its approach
Episode management UI: Browse, search (semantic, 300ms debounce), and delete episodes from the sidebar
Graceful degradation: If episodic memory fails, core agent functionality continues uninterrupted

The UI shows an "📚 Referenced past experience (N)" badge on responses that leveraged episodic memory.

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 / OIDC Group 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 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.

The implementation uses Next.js next-intl with per-locale message files. Every UI string goes through useTranslations(). The AI's chat responses also match the user's language — a Korean user asking in Korean gets a Korean answer with Korean citation labels.

Here's what the card grid looks like across all 8 languages:

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

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

v4.0.0: Six New Features (April 2026)

v4.0.0 adds six capabilities that extend the system from document search into a more complete enterprise AI platform. All are opt-in via CDK parameters — zero additional cost when disabled.

Agent Registry Integration

enableAgentRegistry=true adds a "Registry" tab to the Agent Directory, connecting to AWS Agent Registry (Amazon Bedrock AgentCore). Your organization's shared Agents, Tools, and MCP Servers become searchable and importable directly from the UI.

Semantic search across registry records
One-click import from registry to local Bedrock Agent (name collision handling with _imported_YYYYMMDD suffix)
Publish local agents to the registry (with approval workflow)
Resource type filters (Agent / Tool / MCP Server)
Cross-region access via agentRegistryRegion parameter
Fault isolation: registry errors don't affect other Agent Directory tabs

Note: Agent Registry is a Preview API as of April 2026. The implementation uses SigV4-signed HTTP with REST path mapping. When the Node.js SDK adds native commands, the client can be swapped with minimal changes.

Multimodal RAG Search

embeddingModel: "nova-multimodal" switches the Knowledge Base from text-only (Titan Text Embeddings v2) to cross-modal search across text, images, video, and audio using Amazon Nova Multimodal Embeddings.

The architecture uses two patterns that make model changes painless:

Embedding Model Registry: Model definitions are configuration objects in a catalog. Adding a new model = adding one entry
KB Config Strategy: Dynamically generates KB configuration, IAM policies, and Lambda environment variables from the registry entry

For gradual migration, multimodalKbMode: "dual" runs two KBs in parallel — text-only (Titan) + multimodal (Nova) — with a query router that directs text queries to the text KB and image-attached queries to the multimodal KB. Users can toggle between them.

Caveat: Nova Multimodal Embeddings is currently available in us-east-1 and us-west-2 only. Changing the embedding model requires KB recreation and full data re-ingestion.

Guardrails Organizational Safeguards

enableGuardrails=true with optional guardrailsConfig gives fine-grained control over Bedrock Guardrails:

Content filter strength: Per-category (sexual, violence, hate, insults, misconduct, prompt attack) input/output filter levels (NONE/LOW/MEDIUM/HIGH)
Topic policies: Block specific topics (e.g., competitor information)
PII detection: Per-entity-type actions (BLOCK or ANONYMIZE for email, phone, credit card, etc.)
Contextual grounding: Hallucination prevention with configurable thresholds

The UI adds:

GuardrailsStatusBadge on every chat response: ✅ safe / ⚠️ filtered / ⚠️ check unavailable
GuardrailsAdminPanel in the sidebar (admin-only, read-only): shows account guardrails config and detects AWS Organizations Organizational Safeguards
EMF metrics: GuardrailsInputBlocked, GuardrailsOutputFiltered, GuardrailsPassthrough → CloudWatch dashboard + SNS alerts

Error handling follows a Fail-Open strategy: if the Guardrails API times out (5s) or returns 5xx, chat continues normally with an error log. The AI never stops working because of a guardrails hiccup.

Voice Chat (Amazon Nova Sonic)

enableVoiceChat=true adds voice interaction. Click the 🎤 microphone button (or Ctrl+Shift+V), speak your question, and get a text + audio response — all through the same permission-aware RAG pipeline.

Phase 1 (current) uses REST + Bedrock Converse API:

Browser (mic) → POST /api/voice/stream → Converse API (speech→text)
                                        → KB/Agent RAG pipeline
                                        → text + audio response → Browser

Waveform animation (Canvas-based, input=blue, output=green, respects prefers-reduced-motion)
30-second silence timeout with auto-stop
Auto-reconnect (max 3 attempts), then text fallback
Works in KB mode, Single Agent mode, and Multi Agent mode
Permission filtering is input-method-agnostic — voice queries get the same SID/UID/GID filtering as text

Phase 2 (planned) will use API Gateway WebSocket + Nova Sonic InvokeModelWithBidirectionalStream for real-time bidirectional streaming.

Estimated monthly cost: $70–$100 (input ~$0.0019/min, output ~$0.0076/min).

AgentCore Policy

enableAgentPolicy=true adds agent behavior control. Define boundaries in natural language — what tools the agent can use, what APIs it can call, what data it can access — and the system enforces them in real-time.

3 policy templates: Security-focused, Cost-focused, Flexibility-focused
PolicyEvaluationMiddleware: Evaluates every agent action against the policy (3s timeout)
Fail-open / Fail-closed: policyFailureMode controls behavior when policy evaluation fails
Violation logging: EMF-format metrics (PolicyViolationCount, PolicyEvaluationLatency) → CloudWatch dashboard
PolicySection in Agent create/edit forms: optional natural language policy input (max 2000 chars)
PolicyBadge (🛡️) on agents with active policies

Note: AgentCore Policy reached GA in March 2026 with a Policy Engine + Gateway architecture. Policies are written in Cedar language (with natural language auto-conversion). The implementation uses SigV4-signed HTTP.

Feature Flags Runtime API

A cross-cutting change that affects all v4 features: the UI no longer relies on NEXT_PUBLIC_* build-time environment variables. Instead, a /api/config/features endpoint reads Lambda environment variables at runtime and returns feature flags. The useFeatureFlags hook caches flags in localStorage for instant page loads.

This means you can enable/disable features by changing CDK parameters and redeploying — without rebuilding the Docker image.

Multi-Agent Collaboration: Now Default-On

When enableAgent=true, multi-agent collaboration (enableMultiAgent) is now enabled by default. Bedrock Agents have zero standby cost, so this adds no running cost. Token consumption only increases (3-6x) when users actually chat in Multi Agent mode. Set enableMultiAgent: false explicitly to disable.

Multi-Agent Collaboration: Permission-Aware Agent Teams

The system uses Amazon Bedrock Agents' Supervisor + Collaborator pattern. Instead of a single agent handling everything, specialized agents work together:

Supervisor Agent: Detects user intent, routes tasks to the right collaborator
Permission Resolver: Resolves SID/UID/GID from the User Access Table
Retrieval Agent: Executes KB search with permission metadata filters
Analysis Agent: Summarizes and reasons over filtered context (no direct KB access)
Output Agent: Generates reports and documents (no direct KB access)

The key design principle: KB access is restricted to Permission Resolver and Retrieval Agent only. Analysis and Output agents receive "filtered context" — they never touch the knowledge base directly. This preserves the same SID/UID/GID permission boundaries that exist in single-agent mode.

Cost Structure

Scenario	Agent Calls	Est. Cost/Request
Single Agent (existing)	1	~$0.02
Multi-Agent (simple query)	2–3	~$0.06
Multi-Agent (complex query)	4–6	~$0.17

Deployment Lessons Learned

CloudFormation AgentCollaboration values: Only DISABLED, SUPERVISOR, and SUPERVISOR_ROUTER are valid. COLLABORATOR is NOT a valid value. Collaborator Agents should not set this property at all.

2-stage deploy is mandatory: You cannot create a Supervisor Agent with SUPERVISOR_ROUTER and collaborators in a single CloudFormation operation. The solution: create with DISABLED first, then a Custom Resource Lambda changes to SUPERVISOR_ROUTER, associates collaborators, and runs PrepareAgent.

IAM permissions: The Supervisor Agent's IAM role needs bedrock:GetAgentAlias + bedrock:InvokeAgent on agent-alias/*/*. The Custom Resource Lambda needs iam:PassRole for the Supervisor role.

Tips for Builders

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).

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.

Existing FSx ONTAP Reuse

If you already have an FSx for ONTAP file system, specify existingFileSystemId, existingSvmId, and existingVolumeId in cdk.context.json to skip FSx creation entirely. This cuts deployment time from 30-40 minutes to under 10 minutes.

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 v4.0.0 release involved 195 files changed, 8-language documentation updates, property-based tests with fast-check, and live AWS environment verification across multiple accounts — 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 ONTAP creation takes 20-30 minutes). Use existingFileSystemId to skip FSx creation if you already have one.

What's Next

The project is at v4.0.0 with 19 implementation aspects and actively evolving. Some directions I'm exploring:

Voice Chat Phase 2: WebSocket via API Gateway + Nova Sonic InvokeModelWithBidirectionalStream for real-time bidirectional streaming (replacing the current REST-based Phase 1)
DynamoDB-driven permission master: Eliminating per-file .metadata.json management for large-scale environments
Multi-volume embedding: Independent S3 Access Points per FSx for ONTAP volume with cross-volume search
Agent Registry GA SDK migration: When the Node.js SDK adds native Agent Registry commands, swap from SigV4 HTTP to SDK calls

I'm looking for feedback on:

Permission models: Are SID/UID-GID/OIDC-group/hybrid strategies sufficient for your use cases?
Voice interaction patterns: What voice-specific workflows would be valuable in enterprise RAG?
Policy templates: What agent behavior boundaries matter most in your organization?
Guardrails configurations: What content filtering rules does your compliance team require?

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 — README available in 8 languages, same as the application 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

FSx for ONTAP S3 Access Points as a Serverless Automation Boundary — AI Data Pipelines, Volume-Level SnapMirror DR, and Capacity Guardrails

The Shift: S3 Access Points Make Serverless NAS Automation Practical

S3 Access Point Compatibility Model

Architecture

Implementation

1. Data Preprocessor: The S3 Access Point Workflow

2. ONTAP REST API Client

3. Capacity Monitor with Guardrails

4. Volume-Level SnapMirror Failover Orchestration

SnapMirror Initialization: Two Paths

Enabling the S3 Access Point Pattern: Private-Subnet Networking

What I Learned from AWS Verification

Same-SVM SnapMirror on SINGLE_AZ_1: Test Harness Only

Cost

Extending the S3 Access Point Pattern

Automated Permission Metadata Pipeline

Multi-Volume Ingestion Orchestration

ONTAP Operations Chatbot

Testing

Wrapping Up

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 RAG

S3 Access Points: The Bridge Between FSx 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)

Episodic Memory (v4.0.0)

Additional Features

Smart Routing (v3.1.0)

Image Analysis RAG (v3.1.0)

6-Layer Security

8-Language i18n — Why It Matters

v4.0.0: Six New Features (April 2026)

Agent Registry Integration

Multimodal RAG Search

Guardrails Organizational Safeguards

Voice Chat (Amazon Nova Sonic)

AgentCore Policy

Feature Flags Runtime API

Multi-Agent Collaboration: Now Default-On

Multi-Agent Collaboration: Permission-Aware Agent Teams

Cost Structure

Deployment Lessons Learned

Tips for Builders

OpenLDAP memberOf Overlay

Geo Restriction Default

Existing FSx ONTAP Reuse

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