TL

Cloud Service

ストレージ

オブジェクト(Object Storage)・ブロック(Block Volume)・ファイル(File Storage)の使い分けと、ストレージ階層・性能(VPU/GB)の選び方を即断する早見表。

基礎
最終更新: 2026-06-04

3種類の使い分け

タイプサービスアクセス用途
オブジェクトObject StorageHTTP(S) / REST API配信・バックアップ・データレイク
ブロックBlock Volume1 インスタンスにアタッチ（共有アタッチは例外）OS / DB のディスク
ファイルFile Storage複数から同時マウント（NFSv3）共有フォルダ・HPC・OKE の共有 PV

迷ったら

  • HTTP で取得・容量無制限・静的配信 → Object Storage（揮発でよい一時領域は DenseIO の NVMe ローカル）
  • インスタンスの高速ディスク（永続） → Block Volume（OS 起動ディスクも同じ基盤の Boot Volume）
  • 複数サーバーで同じファイルを共有 → File Storage（NFSv3。VCN 内のマウントターゲット経由）
まず「入れ物」と「所属」を押さえる

すべてのストレージは コンパートメント（IAM で分離する論理単位）に所属し、IAM ポリシーでアクセスを制御します。配置範囲は Object Storage = リージョン単位、Block Volume / File Storage = 可用性ドメイン（AD）単位。別 AD・別リージョンへはバックアップのコピーやレプリケーションで広げます。

Object Storage の階層選び

アクセス頻度階層ポイント
高頻度Standard標準・低レイテンシで即時アクセス
低頻度・即時取り出しInfrequent Access保存単価が安い／取り出しに別途課金。即時アクセス可
アーカイブ・長期保管Archive最安／読むにはリストア（復元）が必要・取り出しに時間
自動で安くする

アクセスパターンが読めなくても、ライフサイクルポリシーで「N 日後に Standard → Infrequent Access → Archive、その後自動削除」と移行できます（S3 ライフサイクル相当）。Archive はオフラインで、読むにはリストアが必要なので、即時に読みたいデータは置かないこと。一時的な共有は**期限付き PAR（Pre-Authenticated Request）**で行い、バケットを Public にしないのが鉄則です。

Block Volume の性能（VPU/GB）選び

性能は固定値ではなく VPU/GB（Volume Performance Units）× 容量で自動算出され、稼働中にオンラインで変更できます。

VPU/GB性能階層向いている用途
0Lower Cost（HDD 相当）低頻度アクセス・コスト最優先のバルク領域
10Balanced（既定）本番の OS / DB / アプリ全般。まずここから
20Higher Performance高 IOPS・高スループットが要るワークロード
30〜120Ultra High Performance超低遅延・最高 IOPS のミッションクリティカル
Block Volume と NVMe ローカルを混同しない

Block Volume はネットワーク越しの永続ストレージで、インスタンスを終了してもデータは残ります。一方 DenseIO シェイプの NVMe ローカル SSD は超高速だが揮発性で、インスタンス終了で消えます。永続が要るデータは必ず Block Volume / Object Storage / File Storage へ。バックアップは増分で Object Storage に保存され、別リージョンへコピーして DR を設計します。

File Storage のスループット選び

項目オンデマンド（既定）プロビジョンド最大スループット
課金の考え方使った容量に応じた従量。帯域は容量連動固定帯域を確保すると追加課金
性能容量が増えるほど帯域も増える容量に関係なく一定の帯域を保証
向く用途汎用の共有・ホームディレクトリHPC・常時高帯域が要る並列アクセス
プロトコルNFSv3（ロックは NLM）NFSv3（同左）
共有が要るかどうかで即断

複数インスタンスから同時マウント＝File Storage（NFSv3 / ReadWriteMany）、単一インスタンスの高速ブロックディスク＝Block Volume（原則 ReadWriteOnce）、HTTP API のオブジェクト（配信・バックアップ・データレイク）＝Object Storage。OKE で複数 Pod から書き込むなら File Storage の CSI を使います（Block Volume の ReadWriteOnce では満たせない）。

つまずきやすいポイント
  • 複数同時マウント＝File Storage、Block Volume は原則1 インスタンスにアタッチ（Read/Write Shareable 等のクラスタ用途のみ例外）
  • File Storage は NFSv3（AWS EFS は NFSv4.1）。ロックは NLM、ポートは 111 / 2048 / 2049 の許可が必要
  • Object Storage の Archive はオフライン。読むにはリストアが必要で、即時アクセスはできない
  • Block Volume は拡張は可・縮小は不可。インスタンスを停止してもボリュームの課金は継続する
  • バックアップを同一リージョンにのみ置くと、リージョン障害で復旧不能。重要データは別リージョンへコピー
セキュリティのアンチパターン
  • Object Storage: 共有目的でバケットを Public にするのは NG。期限付きの PAR を発行し、用が済んだら失効させる
  • File Storage: マウントターゲットを広い CIDR（0.0.0.0/0）で開放したり、エクスポートを全許可・root 無制限で放置するのは NG。NFSv3 はネットワーク到達性＝アクセス権になりがちなので、送信元 CIDR を絞り、root squash を有効化し、必要に応じ **in-transit 暗号化（oci-fss-utils）**を併用
  • 共通: 保存時暗号化は既定で有効。要件が高いものは **Vault の顧客管理鍵（CMK）**へ。アクセスは IAM ポリシー＋コンパートメントで最小権限に

関連: Object Storage / Block Volume / File Storage

OCI Service

ストレージを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

cheatsheets

比較で見る軸

クラウド: OCI / カテゴリ: cheatsheets / 難易度: basic

導入後に効く点

導入後の運用手順、権限、監視、更新方法まで含めて評価します。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
OCI
カテゴリ
cheatsheets
難易度
basic
関連資格
—
設計柱
—

判断チェックリスト

  • 自社の用途が「cheatsheets」に近いか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

cheatsheets