ファイルサーバーをS3に置き換えると何が変わるか — SMBとの前提の違い

古くなった社内ファイルサーバーを、クラウドのオブジェクトストレージに移す。容量の心配が消え、機器の更新からも解放される — そこまでは検討資料によく書かれています。この記事は、その先で実際に効いてくる前提の違いを扱います。移行してから気づくと、運用で吸収するしかなくなる種類のものです。

最終更新: 2026年9月9日

フォルダーという実体が無い — 名前の変更が重い操作になる

S3 にはフォルダーがありません。あるのはキーと値の対だけで、2025_案件/設計/図面.dwg というキーの中の / が、階層のように見えているだけです。

ふだんは意識せずに済みます。効いてくるのは、フォルダーの名前を変えたときです。

SMB のファイルサーバーなら、フォルダー名の変更はメタデータの書き換え1回です。中に何万ファイルあっても一瞬で終わります。

S3 では、そのフォルダーに属する全オブジェクトを1件ずつコピーして、元を削除することになります。ドライブとして見せるソフトが裏でやっているのは、おおよそ次のことです。

1. その接頭辞（2025_案件/）に一致するキーを一覧する
2. 1件ずつ、新しいキーにコピーして、古いキーを削除する

運用としての結論はひとつです。大きなフォルダーの名前を後から変えなくて済むように、最初の階層設計を決めてから移行してください。年度やプロジェクト名を階層の上位に置く場合はとくに、あとで一括改名したくなる場面が来ないかを先に確認しておくと安全です。

ファイルロックが無い — 同時編集の結末が変わる

これは移行時にいちばん見落とされ、いちばん実害が出るところです。

SMB にはファイルロックがあります。誰かが Excel ファイルを開いていれば、次の人には「使用中です。読み取り専用で開きますか」と表示されます。仕組みとして上書きが防がれています。

S3 にはその仕組みがありません。オブジェクトは PUT で丸ごと置き換わるだけで、「いま誰かが開いている」という状態を持ちません。

「同時に開かない運用にする」で回避しようとすると、全員が守り続けることが前提になります。事故は、守れなかった1回で起きます。

現実的な対処は、保存の直前に、開いてから変わっていないかを確かめることです。変わっていたら、相手の変更を上書きせずに自分の編集を別名で退避し、その旨を通知する。どちらの変更も失われませんが、あとで人が突き合わせる作業は残ります。S3 DriveBridge はこの動作をします。

遅延が桁で変わる — 効くアプリと効かないアプリ

LAN 内のファイルサーバーへの往復は 1 ミリ秒未満です。インターネット越しの S3 は、その数十倍かかります。1回あたりは小さくても、細かい読み書きを何百回も行うアプリでは体感が変わります。

とくに効くのは、フォルダーを開いた瞬間です。エクスプローラーは一覧を取ったあと、表示のために項目ごとの問い合わせを行います。素直に実装すると、N 件のフォルダーで N 回の追加往復が発生します。実用的な速度にするには、一覧の結果を短時間キャッシュして、直後の問い合わせをそこから返す必要があります。

影響が出やすい作業と、出にくい作業をおおまかに分けると次のようになります。

費用の形が変わる — 容量ではなくリクエスト数

ファイルサーバーの費用は、機器とディスクを買った時点でほぼ決まります。使い方を変えても金額は動きません。

S3 は違います。費用は主に置いている容量・リクエストの回数・外向きの転送量で決まります。つまり使い方によって金額が動きます。

容量は見積もりやすいので、多くの検討資料はそこだけを比べます。実際に見込みと外れるのはリクエスト数の方です。前の章で書いたフォルダー名の変更のように、画面上は一瞬の操作が、裏では何万回のリクエストになることがあるためです。

S3 DriveBridge は、リクエスト数と転送量を端末側で計測し、単価表を適用して概算費用を表示します。部門・端末・ドライブごとに集計でき、CSV に出力できます。まず一部の部署で使い、実測から全体を判断する、という進め方ができます。

権限の考え方が変わる

ファイルサーバーの権限は、NTFS の ACL と Active Directory のグループで組まれているのが普通です。フォルダーごとに細かく、継承もあります。

S3 の権限はバケットやプレフィックス単位で、粒度も考え方も違います。既存の ACL をそのまま持ち込むことはできません。

現実的には、次のどちらかになります。

• 用途ごとにバケットやプレフィックスを分け、それぞれに接続情報を割り当てる。 フォルダーごとの細かい権限を、ドライブの分割に置き換える考え方です。
• 読み取り専用で配る。 参照だけの資料や過去案件のアーカイブは、書き込みを禁止したドライブとして配れば、誤操作でも暗号化被害でも中身は変わりません。同じバケットを、部署によって読み書き可・読み取り専用と使い分けることもできます。

復元は「スナップショット」から「バージョニング」へ

「前の版に戻したい」という要求は移行後も必ず出ます。ファイルサーバーではシャドウコピーやバックアップからの復元でしたが、S3 ではバケットのバージョニングがその役目を負います。

性質が少し違います。スナップショットはある時点のサーバー全体ですが、バージョニングはオブジェクトごとの世代です。「昨日の 18 時の状態にフォルダーごと戻す」という操作は、そのままの形では行えません。逆に、特定のファイルだけを何世代でも遡るのは得意です。

向くもの・向かないもの

最後に、率直なところをまとめます。

全部を一度に移す必要はありません。アーカイブから始めて、日常的に使う領域は後から判断するのが、いちばん失敗が少ない進め方です。実際の使われ方と費用は、動かしてみないと分かりません。