「S3 互換なので、エンドポイントとキーを差し替えるだけで移行できます」。GPU の調達コストを理由に、AI 系のワークロードを別のクラウドへ寄せる提案で、この一文を見る機会が増えました。
そして、この説明は嘘ではありません。 SDK もそのまま動き、PutObject も GetObject も期待どおりに返ってきます。検証環境で動作確認をすれば、当然のように通ります。
問題は、通ることと、同じ守り方ができることが別だという点です。2026年8月に Wiz が公開した調査で、その差が具体的な機能名で並べられました。
互換なのは API であって、防御機構ではない
S3 互換をうたうサービスが揃えているのは、リクエストとレスポンスの形です。バケットを作れて、オブジェクトを置けて、署名付き URL が発行できる。アプリケーションから見える範囲は確かに同じように振る舞います。
一方、AWS で S3 を安全に運用するときに実際に効いているものは、API の外側にあります。バケットが公開状態になるのをアカウント単位で禁止する仕組み、誰がどのオブジェクトに触ったかの記録、条件付きで権限を絞り込むポリシーの表現力。これらは S3 の API 仕様ではなく、AWS 側の実装です。
Wiz の主任クラウドセキュリティ研究者である Scott Piper は、この点を「S3 互換は危険な移植性の錯覚を生む」と表現しています。移せるという判断が、守れるという判断にすり替わることが問題だ、という指摘です。
実測で欠けていたもの
調査対象になったのは、GPU クラウド事業者を中心とした6社（Nebius、Crusoe、Vultr、Lambda Labs、Cloudflare R2、DigitalOcean）のマネージドオブジェクトストレージです。S3 と比較した結果、次の差が出ています。
| 機能 | 実測された状況 |
|---|---|
| 公開アクセスの一括ブロック | S3 の Block Public Access に相当するものを備えたサービスは無かった |
| データプレーンのログ | オブジェクト単位のアクセスログを出せるのは Nebius と DigitalOcean のみ |
| 細粒度の IAM | 限定的または不在。読み取り専用やバケット単位の制限を提供するのは Cloudflare、DigitalOcean、Nebius のみ |
この3つは、それぞれ運用上の意味が違います。
公開ブロックが無いということは、設定ミスで公開になったバケットを、組織の設定で事前に止められないということです。S3 でこの機能に助けられた経験がある組織ほど、無い状態を想定できていません。
データプレーンのログが無いということは、インシデントが起きたときに「何が持ち出されたか」を後から特定できないということです。侵入を検知できるかどうか以前に、被害範囲の確定ができません。報告義務のある事故では、ここが致命傷になります。
細粒度の IAM が無いということは、最小権限を作れないということです。「このバケットのこのプレフィックスだけ読める鍵」を発行できなければ、渡す鍵は毎回それより広くなります。委託先や外部ベンダーに渡す権限をどう絞るかは常時権限をやめて必要なときだけ渡す設計でも扱いましたが、そもそも絞る手段が無い環境ではこの設計が成立しません。
実装差は、実際に脆弱性として出ている
IAM の挙動が製品ごとに違うことは、理屈の上の話ではありません。S3 互換の実装で、権限判定そのものに起因する脆弱性が報告されています。
MinIO では、権限昇格を許す不具合が確認されています。RustFS では、テナント分離と認可のセマンティクスが破れる問題が報告されました。いずれも「S3 と同じつもりで書いたポリシー」が、その製品では違う意味に解釈されうることを示しています。
ここから引き出せる実務上の結論は1つです。S3 で通用したポリシーの書き方を、互換製品に持ち込んで検証を省略しないこと。 同じ JSON が受理されても、拒否されるべきリクエストが通る可能性があります。
移行を判断する前に聞く5つの質問
コストを理由に移行の相談が来たとき、動作確認の前に確認しておきたい項目です。
- バケットが公開になるのを組織側で禁止できますか。 できない場合、公開状態を検知する仕組みを自前で用意する必要があります。誰が定期的に確認するかまで決めてください。
- オブジェクト単位のアクセスログは取得できますか。保持期間は。 取れない場合、そのバケットに個人情報や顧客の成果物を置く判断はできません。
- バケット単位・プレフィックス単位で権限を絞れますか。 絞れないなら、用途ごとにアカウントやバケットを分ける前提でコストを再計算します。
- 鍵のローテーションと失効はどう行いますか。 発行した鍵を即座に無効化できるかどうかは、委託先に渡す場合に必ず効きます。
- 暗号化と保持ポリシーは何が使えますか。 保管時暗号化の有無だけでなく、削除の抑止（オブジェクトロック相当）があるかどうかで、ランサムウェア対策の設計が変わります。
この5つのうち2つ以上が「無い」なら、移行そのものを否定する必要はありませんが、置くデータを選ぶ判断が要ります。 モデルの重みや中間生成物のように、漏れても影響が限定的なものだけを寄せる構成は現実的です。逆に、顧客データを含むバケットを丸ごと移すのは割に合いません。
移行のコスト比較を作るときに、この差分を運用側の作業として計上していないケースがよくあります。乗り換えやすさと引き換えに何を持つことになるかの整理はベンダーロックインを避ける判断にまとめています。
次にやること
まず、いま S3 互換ストレージを使っている場合、そのバケット一覧と、それぞれに何が入っているかを書き出してください。 顧客データが含まれるバケットがあるなら、上の5項目をベンダーのドキュメントで確認するのが最初の作業です。
これから移行を検討している場合は、コスト比較表に「公開ブロック」「アクセスログ」「細粒度 IAM」の3行を足してください。 単価だけを並べた比較表は、この3行が抜けている限り判断材料になりません。
クラウドストレージの構成見直し、権限設計、AI ワークロードの移行検討については、グリームハブの開発・AI・自動化のご相談で承っています。扱うデータの性質と現在の構成によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
