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