FSx for ONTAP S3 Access Pointsをサーバーレス自動化境界として使う

この記事は、DEV Communityで公開している「FSx for ONTAP S3 Access Points」シリーズを、日本語読者向けに再構成したものです。

dev.to

単純な翻訳ではなく、AWS上での検証結果、設計判断、日本のエンタープライズ環境での読みどころを補足しながら整理しています。

今回の記事は、その前段となる以下の記事をベースにしています。

dev.to

はじめに

Amazon FSx for NetApp ONTAP（以降、FSx for ONTAP）上のファイルデータは、多くのエンタープライズ環境では SMB / NFS 経由で利用されています。

ファイルサーバとしての使い方はそのままにしつつ、近年はその上に次のような自動化を重ねたい場面が増えています。

AI/ML 向けの前処理
RAG / ナレッジベース向けのメタデータ生成
ガバナンススキャン
容量監視
SnapMirror を使ったDR運用
定期的なファイル棚卸し
監査用サイドカーファイルの生成

このとき課題になるのが、ファイルシステム上のデータをサーバーレスからどう扱うかです。

従来であれば、Lambda を VPC に配置し、ONTAP REST APIなどで操作/管理するストレージのオペレーションに限られました。

FSx for ONTAP S3 Access Points を使うと、この考え方を大きく変えられます。

ONTAP 上のファイルデータを S3 互換の API 経由で扱えるため、Lambda や Step Functions から ListObjectsV2、GetObject、PutObject のような操作でファイルデータにアクセスできます。

この記事では、この仕組みを “NASデータに対するサーバーレス自動化境界” として捉え、AIデータパイプライン、容量監視、SnapMirror DR、メタデータ生成にどう応用できるかを整理します。

今回のポイント

この記事で伝えたいことは、次の3つです。

FSx for ONTAP S3 Access Points は、ファイルデータを別の場所へ移すための仕組みではなく、サーバーレスから扱うための境界として見ると設計しやすい
データパスは S3 Access Points、制御・メタデータは ONTAP REST API、という役割分担が重要
SMB / NFS の利用者体験を変えずに、Lambda / Step Functions / EventBridge などのAWSサーバーレスサービスを組み合わせられる

なぜ S3 Access Points が効くのか

FSx for ONTAP のファイルデータは、従来どおり SMB / NFS で利用できます。

一方で、サーバーレス処理からは S3 Access Points 経由でアクセスします。

つまり、利用者のファイルアクセス経路を変えずに、自動化・AI処理・メタデータ生成だけを S3 API 側に逃がせます。

構造としては、次のように考えると分かりやすいです。

利用者 / 業務アプリ
  → SMB / NFS
  → FSx for ONTAP

サーバーレス処理
  → S3 Access Point
  → FSx for ONTAP

制御・メタデータ取得
  → ONTAP REST API
  → FSx for ONTAP

この分離により、Lambda がNASを直接マウントしなくても、ファイル一覧取得、ファイル内容の読み取り、サイドカーファイルの書き込みといった処理を実装できます。

S3 APIだけで足りる部分、足りない部分

FSx for ONTAP S3 Access Points は便利ですが、通常のS3バケットと完全に同じ意味で使えるわけではありません。

設計上は、S3 APIで扱うべき領域と、ONTAP REST APIで扱うべき領域を分ける必要があります。

S3 Access Pointsで扱いやすいもの

S3 Access Points 経由では、主に次のようなデータパス操作を扱います。

ListObjectsV2
- ファイル一覧の取得
- スキャン対象の棚卸し
- 拡張子やprefixによる対象抽出
GetObject
- ファイル内容の読み取り
- AI/ML 前処理
- テキスト抽出やメタデータ生成の入力
PutObject
- 生成したメタデータファイルの書き込み
- manifestファイルの保存
- sidecar JSON の出力

S3 APIだけでは見えないもの

一方で、S3 APIだけでは見えない、または扱うべきではない情報もあります。

NTFS ACL
UNIX permission / export policy
security style
volume metadata
Snapshot情報
SnapMirror関係
CIFS share / NFS exportの制御
volume resize
storage utilization

これらは、S3 Access Points ではなく ONTAP REST API の領域です。

そのため、今回の設計では次のように役割を分けます。

S3 Access Points
  = データパス
  = ListObjectsV2 / GetObject / PutObject

ONTAP REST API
  = 制御プレーン
  = volume / Snapshot / ACL / export policy / SnapMirror / capacity

この分担を明確にしておくと、設計がかなり整理されます。

アーキテクチャ全体像

この前段記事で扱うアーキテクチャは、次の4層で考えています。

┌─────────────────────────────────────────────┐
│ Orchestration                               │
│ EventBridge Scheduler / Step Functions      │
├─────────────────────────────────────────────┤
│ Compute                                     │
│ Lambda                                      │
├─────────────────────┬───────────────────────┤
│ Data Path           │ Control Plane         │
│ S3 Access Point     │ ONTAP REST API        │
│ - ListObjectsV2     │ - volumes             │
│ - GetObject         │ - Snapshots           │
│ - PutObject         │ - SnapMirror          │
│                     │ - ACL / export policy │
├─────────────────────┴───────────────────────┤
│ Storage                                     │
│ FSx for NetApp ONTAP                        │
│ SMB / NFS + S3 Access Points                │
└─────────────────────────────────────────────┘

ポイントは、FSx for ONTAP を system of record として維持することです。

データを別のS3バケットへ移してから処理するのではなく、FSx for ONTAP 上のファイルを S3 Access Points 経由で処理します。

これにより、既存のSMB/NFS利用者は今までどおりファイルにアクセスでき、サーバーレス処理だけがS3互換API経由でデータを扱う形になります。

実装したもの

この前段では、主に次の自動化コンポーネントを実装しました。

1. Data Preprocessor

FSx for ONTAP S3 Access Point 経由でファイル一覧を取得し、対象ファイルを抽出します。

そのうえで、ONTAP REST API から取得した volume metadata や security style などを組み合わせ、下流のAI / 分析処理向けのmanifestを生成します。

イメージとしては次の流れです。

S3 Access Point: ListObjectsV2
  → ファイル一覧取得

ONTAP REST API
  → volume / security_style / export_policy / Snapshot情報取得

Lambda
  → preprocessing task生成
  → manifest生成

S3 Access Point: PutObject
  → manifest / sidecar metadataを書き戻し

この設計により、ファイルの実体はFSx for ONTAP上に置いたまま、サーバーレス処理からファイル一覧を取得し、AI/ML向けの処理単位に分割できます。

2. ONTAP REST API Client

S3 APIだけでは取得できないストレージ側の情報を扱うため、ONTAP REST API clientを用意しました。

このclientでは、次のような操作を扱います。

volume情報の取得
Snapshot一覧の取得
export policy / security styleの取得
SnapMirror relationshipの操作
容量監視に必要な情報の取得

S3 Access Points はデータパスとしては非常に便利ですが、ストレージの制御プレーンそのものではありません。

そのため、volume、Snapshot、SnapMirror、ACL、export policy などの情報は ONTAP REST API から取得します。

本番環境ではTLS検証を有効にし、必要に応じてCA bundleを指定する設計にしています。

3. Capacity Monitor

容量監視は、エンタープライズファイル基盤では非常に重要です。

この実装では、EventBridge Schedulerで定期的にLambdaを実行し、FSx API、CloudWatch、ONTAP REST APIを組み合わせて容量を監視します。

主なガードレールは次のとおりです。

DRY_RUN
- デフォルトでは実際の拡張は行わずログ出力のみ
VOL_THRESHOLD_PCT
- ボリューム使用率のしきい値
MAX_GROW_PER_ACTION_PCT
- 1回の実行で増やせる最大比率
MAX_GROW_PER_DAY_GIB
- 1日に拡張できる最大容量

「自動化するが、勝手に大きく増やしすぎない」ことを重視した設計です。

特に容量拡張は、一度自動化すると便利な一方で、誤検知や設定ミスによって意図しない容量増加が起こる可能性があります。

そのため、デフォルトでは DRY_RUN にし、実際に変更する場合も1回あたり・1日あたりの上限を設けています。

4. Volume-level SnapMirror failover orchestration

SnapMirrorを使ったvolume-levelのplanned failover / failbackも実装しました。

ただし、ここで扱っているのは volume-level SnapMirror の自動化であり、完全なSVM-DRではありません。

実装では、Step FunctionsからLambdaを呼び出し、次のような操作を順番に実行します。

SnapMirror relationshipの確認
final transfer
quiesce / break
CIFS share / NFS exportの再作成
failback時のreverse処理

ここで重要なのは、Same-SVM SnapMirrorを使ったテストは、あくまで低コストな自動化検証用ハーネスであり、本番DR構成そのものではないという点です。

本番DRを設計する場合は、SVM-DR、別AZ / 別リージョン、ネットワーク、名前解決、認証、クライアント切替などを含めて設計する必要があります。

Private Subnet構成で必要になったVPC Endpoint

今回の検証では、Lambdaをprivate subnetに配置し、NAT Gatewayなしで動かす構成も考慮しました。

この場合、必要になるVPC Endpointを意識する必要があります。

代表的には次のような構成です。

Service	Endpoint Type	用途
S3	Gateway	S3 Access Point経由のデータパス
Secrets Manager	Interface	ONTAP認証情報の取得
FSx	Interface	FSx API呼び出し
CloudWatch / monitoring	Interface	メトリクス取得
SNS	Interface	通知送信

特に重要だったのは、S3 Gateway EndpointをLambda subnetで使うroute tableに関連付ける必要があることです。

単にVPC内にS3 Gateway Endpointを作るだけでは不十分で、Lambdaが使うsubnetのroute tableに正しく関連付いていないと、S3 Access Pointへの通信が成立しません。

また、SNS通知を行う場合は SNS の Interface Endpoint も必要です。

容量監視やDRオーケストレーションでは、異常検知時の通知が重要になるため、SNS Endpoint は見落としやすいものの、実運用では重要な構成要素になります。

AWS上で検証して分かったこと

実際にAWS上で検証して、いくつか重要な学びがありました。

1. S3 Gateway Endpointのroute table関連付けが重要

S3 Gateway Endpointは作成しただけでは不十分です。

Lambdaが配置されているsubnetのroute tableに関連付けられている必要があります。

これはprivate subnet / no NAT構成では特に見落としやすいポイントです。

S3 Access Pointを使っている場合でも、通信経路としてはS3 APIを使うため、S3 Gateway Endpointのroute table設定が正しくないと通信に失敗します。

private subnetのLambdaからSNSへ通知する場合、SNS用のInterface Endpointが必要です。

これがないと、アラート送信処理でタイムアウトします。

容量監視やDRオーケストレーションでは通知が重要なので、SNS endpointは忘れずに設計に含める必要があります。

3. fsxadmin passwordはSecrets ManagerとFSx側で自動同期されない

ONTAP REST APIの認証情報をSecrets Managerに保存していても、FSx側でパスワードを変更した場合、Secrets Manager側が自動更新されるわけではありません。

この状態になると、LambdaからONTAP REST APIを呼び出した際に401エラーになります。

運用上は、パスワード変更手順とSecrets Manager更新手順をセットで管理する必要があります。

これは非常に基本的なことですが、実際の運用では見落としやすいポイントです。

4. Same-SVM SnapMirrorはテストハーネスとしては有効だが、DR構成ではない

検証では、コストを抑えるために同一SVM内のSnapMirrorを使って自動化ロジックを確認しました。

ただし、これは同一ファイルシステム・同一AZ内にsource volumeとdestination volumeが存在するため、本番DR構成ではありません。

あくまで、自動化ロジックを低コストで検証するためのテストハーネスです。

本番DRを検討する場合は、障害ドメイン、SVM-DR、クライアント切替、認証、DNS、ネットワーク、復旧手順まで含めて別途設計する必要があります。

コスト感

この前段で扱った自動化は、サーバーレス部分だけで見るとかなり低コストです。

主なコスト要素は次のとおりです。

Lambda
Step Functions
EventBridge Scheduler
Secrets Manager
CloudWatch Logs

一方で、private subnet / no NAT構成で専用のInterface Endpointを複数作る場合、VPC Endpointの固定費が相対的に大きくなります。

S3 Gateway Endpoint自体には時間課金がないため、支配的なのはFSx、Secrets Manager、SNS、CloudWatchなどのInterface Endpointです。

すでに共通VPCにこれらのEndpointがある環境では、追加コストはかなり小さくできます。

この点は、PoC環境と本番環境で見え方が変わります。

PoCではVPC Endpointの固定費が目立つ一方で、本番の共通ネットワーク基盤では既存Endpointを共有できることが多いため、実質的な追加コストはサーバーレス処理分に近づきます。

このパターンをどう拡張できるか

FSx for ONTAP S3 Access Pointsをサーバーレス自動化境界として使うと、いくつか自然な拡張が見えてきます。

1. 権限メタデータ生成パイプライン

RAGやBedrock Knowledge Basesと組み合わせる場合、ドキュメントごとに権限メタデータを生成したいことがあります。

その場合、次のような流れが考えられます。

EventBridge（日次）
  → S3 Access Point: ListObjectsV2
  → ONTAP REST API: ACL / security metadata取得
  → allowed_group_sids を含む .metadata.json を生成
  → S3 Access Point: PutObject
  → Bedrock Knowledge Base ingestion

これにより、手動で .metadata.json を作るのではなく、ONTAP側の権限情報を元に自動生成できます。

RAG構成では、検索結果に対するアクセス制御が重要になります。

ファイル本体の権限とベクトル検索側の権限がずれてしまうと、意図しない情報露出につながる可能性があります。

そのため、ONTAP側のACLを元にメタデータを生成し、ナレッジベース側へ反映するパイプラインは有効な拡張です。

2. 複数ボリュームの一括処理

複数のFSx ONTAP volumeを扱う場合は、Step Functions Map stateでvolumeごとに処理を並列化できます。

Step Functions Map
  → volumeごとにS3 AP scan
  → ONTAP metadata取得
  → sidecar生成
  → ingestion / analytics実行
  → 全volume完了後に通知

この構成では、volumeごとにS3 Access Pointを分け、処理単位もvolume単位で分離できます。

業務部門ごと、データ分類ごと、アクセス制御境界ごとにvolumeが分かれている環境では、このような分割が自然です。

3. ONTAP運用チャットボット

ONTAP REST API clientを安全にラップすれば、Bedrock Agentなどと組み合わせて、読み取り専用のONTAP運用チャットボットを作ることもできます。

たとえば、次のような問い合わせです。

どのvolumeの使用率が高いか
Snapshot数が多いvolumeはどれか
SnapMirror relationshipの状態はどうか
export policyの一覧を確認したい
CIFS shareやNFS exportの設定を確認したい

ただし、実運用では操作可能なAPI、IAM、認証、監査ログを慎重に制限する必要があります。

特に、書き込み系APIや構成変更系APIを自然言語から直接実行できるようにする場合は、承認フロー、dry-run、監査証跡、ロール分離が必須になります。

まとめ

この記事では、FSx for NetApp ONTAP S3 Access Pointsを、単なるS3互換アクセス機能ではなく、NASデータに対するサーバーレス自動化境界として捉える考え方を整理しました。

ポイントは、既存のSMB/NFSによるファイル利用を維持したまま、Lambda、Step Functions、EventBridgeなどのAWSサーバーレスサービスからはS3互換API経由でファイルデータを扱うことです。

これにより、ファイルデータを別のS3バケットへ移動しなくても、以下のような処理を実装できます。

ファイル一覧の取得
AI/ML向け前処理
RAG / ナレッジベース向けメタデータ生成
ガバナンススキャン
容量監視
SnapMirrorを使った運用自動化
sidecar JSON / manifestファイルの生成

一方で、S3 Access Pointsだけですべてを扱うのではなく、役割分担が重要です。

S3 Access Points
  = データパス
  = ListObjectsV2 / GetObject / PutObject

ONTAP REST API
  = 制御プレーン
  = volume / Snapshot / ACL / export policy / SnapMirror / capacity

S3 APIはファイルデータへのアクセスや成果物の書き込みに使い、ONTAP REST APIはストレージ側の制御やメタデータ取得に使います。

この分担により、FSx for ONTAPをsystem of recordとして維持しながら、サーバーレスAI/MLや運用自動化を重ねられます。

実際のAWS検証では、いくつか重要な学びもありました。

Private subnet構成では、S3 Gateway Endpointのroute table関連付けが重要
SNS通知にはSNS VPC Endpointが必要
fsxadmin passwordはSecrets ManagerとFSx側で自動同期されない
Same-SVM SnapMirrorは低コストなテストハーネスとしては有効だが、本番DR構成ではない

つまり、FSx for ONTAPのS3 Access Points機能は、ファイルデータを“移動する”ための機能ではありません。

むしろ、既存のファイル基盤を維持したまま、ファイルデータをサーバーレスから扱える境界にするための機能として考えると、設計しやすくなります。

この考え方をベースに、次回以降の記事では、法律、金融、医療、製造、半導体、ゲノミクス、Public Sectorなど、業界別のサーバーレス自動化パターンへ展開していきます。

運び屋 (A carrier(forwarder) changed his career to an engineer)

AWS / Storage / Community / Cloud Native / Kubernetes / コンテナ / SRE / DevOps

Amazon FSx for NetApp ONTAP x S3 Access Pointsを“サーバーレス自動化境界”として使う~NASデータをS3 APIで扱う設計~

FSx for ONTAP S3 Access Pointsをサーバーレス自動化境界として使う

はじめに

今回のポイント

なぜ S3 Access Points が効くのか

S3 APIだけで足りる部分、足りない部分

S3 Access Pointsで扱いやすいもの

S3 APIだけでは見えないもの

アーキテクチャ全体像

実装したもの

1. Data Preprocessor

2. ONTAP REST API Client

3. Capacity Monitor

4. Volume-level SnapMirror failover orchestration

Private Subnet構成で必要になったVPC Endpoint

AWS上で検証して分かったこと

1. S3 Gateway Endpointのroute table関連付けが重要

3. fsxadmin passwordはSecrets ManagerとFSx側で自動同期されない

4. Same-SVM SnapMirrorはテストハーネスとしては有効だが、DR構成ではない

コスト感

このパターンをどう拡張できるか

1. 権限メタデータ生成パイプライン

2. 複数ボリュームの一括処理

3. ONTAP運用チャットボット

まとめ

関連リンク

FSx for ONTAP S3 Access Pointsをサーバーレス自動化境界として使う

はじめに

今回のポイント

なぜ S3 Access Points が効くのか

S3 APIだけで足りる部分、足りない部分

S3 Access Pointsで扱いやすいもの

S3 APIだけでは見えないもの

アーキテクチャ全体像

実装したもの

1. Data Preprocessor

2. ONTAP REST API Client

3. Capacity Monitor

4. Volume-level SnapMirror failover orchestration

Private Subnet構成で必要になったVPC Endpoint

AWS上で検証して分かったこと

1. S3 Gateway Endpointのroute table関連付けが重要

2. SNS VPC Endpointがないと通知で詰まる

3. fsxadmin passwordはSecrets ManagerとFSx側で自動同期されない

4. Same-SVM SnapMirrorはテストハーネスとしては有効だが、DR構成ではない

コスト感

このパターンをどう拡張できるか

1. 権限メタデータ生成パイプライン

2. 複数ボリュームの一括処理

3. ONTAP運用チャットボット

まとめ

関連リンク