Amazon S3は、バックアップ、ログ、画像、分析用データなどを保存できるオブジェクトストレージです。
導入時に決めるのは保存先だけではありません。誰が読み書きするのか、いつまで残すのか、障害時にどこまで戻せればよいのか、取り出し時間と費用をどこまで許容するのかを先に整理する必要があります。
この記事では、Amazon S3の基本から、ストレージクラス、セキュリティ、コスト、性能、データ分析までを順に説明します。Google Cloud Storage（GCS）とAzure Blob Storageとの比較では、単純な優劣ではなく、既存環境と運用要件に合うサービスを選ぶための軸を示します。
Amazon S3の仕組み
オブジェクトストレージは、データ本体とメタデータを一つのオブジェクトとして扱い、識別子で読み書きする保存方式です。サーバーのディスクをディレクトリとして直接操作するファイルシステムとは、管理方法が異なります。
- バケット
- オブジェクトを収める論理的な入れ物です。リージョン、アクセス制御、ライフサイクルなどの設定単位になります。
- オブジェクト
- 画像、ログ、文書、バックアップなどのデータ本体と、その属性情報です。
- キー
- バケット内でオブジェクトを識別する名前です。
logs/2026/09/app.json.gzのように書けますが、斜線は階層そのものではなく、一覧表示や整理に使う接頭辞の一部です。 - メタデータとタグ
- コンテンツ種別、管理部門、機密区分、保存方針などを表す情報です。検索、権限制御、費用配賦、運用確認に使えます。
S3は、オブジェクトの作成、上書き、削除と一覧取得について強い整合性を提供します。書き込み成功後の読み取りで古い内容を前提にする必要はありません。ただし、同じキーへ複数の処理が同時に書き込む場合の競合制御や、複数キーをまとめた原子的な更新はアプリケーション側で設計します。詳細はAmazon S3のデータ整合性モデルで確認できます。
バケット作成前に決める要件
ストレージ設計は、製品機能の比較より先に、保存するデータの性質を整理すると進めやすくなります。
| 確認項目 | 決める内容 | 判断に与える影響 |
|---|---|---|
| 用途 | 配信、バックアップ、ログ、分析、長期保管 | 必要な読み取り速度、連携サービス、復旧手順が変わる |
| 機密区分 | 公開、社内限定、個人情報、機密情報 | 権限、暗号鍵、ネットワーク経路、監査範囲が変わる |
| アクセス頻度 | 常時、月数回、年数回、予測不能 | ストレージクラスと取り出し費用の選択に影響する |
| 保持期間 | 削除期限、法令や契約上の保存期間、保留の有無 | ライフサイクルとObject Lockの要否が決まる |
| 復旧目標 | 許容できるデータ損失と復旧時間 | バージョニング、複製、バックアップ、復旧試験の設計が変わる |
| 利用場所 | 利用者、アプリケーション、分析基盤のリージョン | 遅延、ネットワーク構成、データ転送費に影響する |
RPOは、障害時にどの時点までデータが戻っても許容できるかを表す目標です。RTOは、業務をどの程度の時間で復旧させるかを表します。たとえば、保存できていても復元に長時間かかるクラスでは、短いRTOを満たせない場合があります。
代表的な利用方法
データレイク
データレイクは、分析前の生データから整形済みデータまでをまとめて保持する基盤です。原本、整形済み、分析用をプレフィックスやバケットで分け、形式、所有者、保持期間を定義します。
S3上のデータはAthena、Glue、Lake Formationなどと連携できます。SQL分析の設計は、関連記事のAmazon Athenaと他クラウドのサーバーレスSQL比較でも解説しています。
バックアップとアーカイブ
更新頻度が低いデータを低頻度アクセス用またはアーカイブ用のクラスへ移すと、保存費を調整できます。ただし、バージョニングだけをバックアップ全体の代わりにはできません。保持期間、削除権限、別アカウントや別リージョンへの分離、復元試験までを一つの運用として決めます。
静的コンテンツ配信
画像、JavaScript、CSS、配布ファイルなどをS3へ保存し、CloudFrontから配信できます。S3を直接公開せず、CloudFrontのOrigin Access Control（OAC）を使う構成を検討します。役割の違いと設定の考え方はAmazon S3とCloudFrontの使い分けを参照してください。
ログとイベントデータ
アプリケーションやAWSサービスのログを集約し、調査や分析に使えます。保存するだけでは運用にならないため、検索方法、保存期間、改ざん対策、閲覧権限、削除後の扱いも決めます。
アプリケーションのアップロード先
利用者が送信する画像や文書の保存先として使う場合は、アプリケーションサーバーを経由させず、期限付きの署名URLで直接転送する構成も選べます。ファイル種別と容量の検証、ウイルス検査、公開範囲の判定は、保存処理とは別に設計します。
S3ストレージクラスの選び方
ストレージクラスは、アクセス頻度、復元までの時間、冗長性、料金条件が異なる保存区分です。保存単価だけで決めると、取り出し料金や最低保存期間による費用が想定を超えることがあります。
| クラス | 向いているデータ | 事前に確認する点 |
|---|---|---|
| S3 Standard | 頻繁に読み書きするデータ | 保存容量、リクエスト数、外部への転送量 |
| S3 Intelligent-Tiering | アクセス頻度が変化する、または予測しにくいデータ | オブジェクト数に応じた監視と自動化の費用、小さなオブジェクトの扱い |
| S3 Standard-IA | 長く保存し、読み取りは少ないが即時取得したいデータ | 取り出し料金、最低保存期間、最小課金サイズ |
| S3 One Zone-IA | 別の場所から再作成でき、単一AZの保存で要件を満たすデータ | AZ喪失への耐性を必要としないか |
| S3 Glacier Instant Retrieval | ほとんど読まないが、必要時にはすぐ取得したいアーカイブ | 最低保存期間と取り出し料金 |
| S3 Glacier Flexible Retrieval | 復元を待てる長期アーカイブ | 復元時間、取り出し方式、最低保存期間 |
| S3 Glacier Deep Archive | 読み取りがまれで、長く保管するデータ | 長い復元時間をRTOが許容できるか |
現在のクラスと制約はAWS公式のS3ストレージクラス比較で確認できます。料金と最低保存期間は変更される可能性があるため、ライフサイクルを本番へ適用する前に、対象件数と移行後の取り出し方を試算します。
ライフサイクルでは、作成から一定期間後に別クラスへ移す、非現行バージョンを整理する、期限を過ぎたオブジェクトを削除するといった規則を設定できます。最初から複雑な規則を多数作らず、データの用途ごとに所有者、移行条件、削除条件を明記し、検証用のプレフィックスで動作を確認します。
セキュリティの初期設計
公開を前提にしない
新しいバケットは非公開を基本にします。S3 Block Public Accessは、バケット、アカウント、組織などの単位で公開を制限します。設定階層が複数ある場合は、より厳しい組み合わせが適用されます。公開が必要な用途でも、要件を記録したうえで配信経路を分離します。詳しい動作はS3 Block Public Accessの公式説明を参照してください。
ポリシーを権限管理の中心にする
利用者やアプリケーションには、必要な操作と対象だけを許可します。新しいバケットではObject OwnershipのBucket owner enforcedが既定で、ACLは無効です。IAMポリシー、バケットポリシー、アクセスポイントポリシーなどを使い、許可と明示的な拒否を管理します。既存システムでACLを使っている場合は、無効化前に依存関係を調べます。
暗号化の目的を分ける
S3へ新しく保存されるオブジェクトには、SSE-S3が基本のサーバー側暗号化として適用されます。SSE-KMSは、鍵の利用権限や監査を分けたい場合の選択肢です。ただし、KMSの権限、リクエスト量、費用、復旧時の鍵アクセスも設計対象になります。現在の既定動作はS3既定暗号化の公式FAQで確認できます。
削除と上書きから守る
バージョニングを有効にすると、上書きや削除の前の版を保持できます。Object Lockはバージョニングが有効なバケットで動作し、指定したオブジェクト版を保持期間またはリーガルホールドで保護します。とくにComplianceモードは途中解除できない制約が強いため、保持要件と運用責任を確認してから使います。
操作を追跡できるようにする
CloudTrail、S3 Inventory、Storage Lens、CloudWatchなどは目的が異なります。誰が何を操作したか、どのオブジェクトがあるか、保存量や保護状態がどう変わったか、アプリケーションに異常がないかを分けて監視します。証跡の設計はAWS CloudTrailの監査ログ設計も参考になります。
コストと性能を同時に見る
S3の費用は保存容量だけでは決まりません。少なくとも次の項目を同じ期間で見積もります。
- ストレージクラスごとの保存容量
- PUT、GET、一覧取得などのリクエスト
- 低頻度クラスやアーカイブからの取り出し
- 最低保存期間より前の削除やクラス変更
- インターネット、リージョン間、他クラウドへのデータ転送
- レプリケーション、監視、インベントリ、暗号鍵などの関連機能
性能面では、古い情報にある「キー先頭をランダム化すれば必ず速くなる」という設計をそのまま採用しません。S3は高いリクエストレートへ自動的に拡張し、複数のプレフィックスと並列処理で読み書きを増やせます。ただし、拡張は徐々に進み、実際の性能はワークロードによって変わります。S3の性能最適化に関する公式ガイドを基準に、実データに近い負荷で測定します。
大きなファイルではマルチパートアップロードを使うと、複数部分の並列転送や失敗部分の再送ができます。遠距離からのアップロード、配信キャッシュ、SSE-KMSの利用がボトルネックに関係する場合は、それぞれを分けて測定します。
データ分析での使い方
分析基盤では、データを置くだけでなく、発見しやすさと変更しやすさを設計します。たとえば、次の三つの領域を分けます。
- Raw：受け取った原本を保持する領域
- Cleansed：形式や品質を整えた領域
- Curated：用途ごとに分析しやすく加工した領域
date=2026-09-13/region=ap-northeast-1/のようなパーティションを使う場合は、クエリで絞り込む項目に合わせます。日付や地域を付けること自体が目的ではありません。利用者がどの条件で検索し、どの単位で更新するかに合わせて決めます。
ファイル形式、圧縮、スキーマ管理、権限の単位がそろっていないと、保存後の分析が複雑になります。Athena、Glue、Lake Formationなどの役割を分け、データ所有者と基盤運用者の責任範囲も文書化します。
S3、GCS、Azure Blob Storageの比較
三つはいずれもクラウドのオブジェクトストレージですが、用語、階層化の方法、ID管理、ネットワーク、分析サービスとの接続に違いがあります。
| 比較項目 | Amazon S3 | Google Cloud Storage | Azure Blob Storage |
|---|---|---|---|
| 主な入れ物 | バケット | バケット | ストレージアカウント配下のコンテナー |
| 主な保存区分 | Standard、Intelligent-Tiering、IA、Glacier系など | Standard、Nearline、Coldline、Archiveなど | Hot、Cool、Cold、Archiveなど |
| 自動階層化と期限管理 | Intelligent-Tiering、S3 Lifecycle | Autoclass、Object Lifecycle Management | Smart tier、Blob Lifecycle Management |
| 権限管理の中心 | AWS IAMと各種ポリシー | Google Cloud IAM | Microsoft Entra IDとAzure RBAC、用途に応じたSAS |
| 分析サービスの例 | Athena、Glue、Lake Formation | BigQueryとの連携 | Azure Synapse Analyticsなどとの連携 |
GCSは、オブジェクトの書き込み、更新、削除、一覧取得などで強いグローバル整合性を提供します。公開キャッシュや権限変更などは別の挙動を持つため、Cloud Storageの整合性に関する公式資料で対象操作を確認します。
Azure Blob Storageでは、オンラインで取得できるHot、Cool、Coldと、復元処理が必要なArchiveで取り出し方が異なります。階層ごとに最低保存期間や早期削除の料金条件があるため、Azure Blob Storageのアクセス層の公式資料を見ながら保持期間を設計します。
選定を絞り込む六つの質問
- アプリケーションと運用担当者は、どのクラウドを日常的に使っているか。
- 利用中のID基盤と権限管理へ無理なく統合できるか。
- 分析、配信、バックアップなど、周辺サービスとの接続はどれが簡潔か。
- 必要な復元時間を満たす保存区分があるか。
- リージョン間またはクラウド間の転送量と費用を説明できるか。
- 障害対応、監査、退避、将来の移行を誰が運用できるか。
「最も安い層へ集約する」「複数クラウドへ同じデータを置く」といった方針だけでは、運用負荷や転送費を判断できません。通常時の読み書きに加え、復旧時と移行時のデータ移動まで試算して選びます。
導入を進める手順
- 対象を一つに絞る：最初はログ、静的ファイル、バックアップなど、用途を混ぜずに選びます。
- 要件表を作る：所有者、機密区分、読み書きする主体、保持期間、RPO、RTOを記録します。
- 非公開の検証環境を作る：Block Public Access、Object Ownership、暗号化、バージョニングを確認します。
- 権限と失敗時の動作を試す：許可された操作だけでなく、禁止した操作が拒否されることも確認します。
- ライフサイクルを小さく試す：検証用プレフィックスで移行と削除を確認し、復元手順も実行します。
- 監視と費用を定期確認する：保存量、リクエスト、取り出し、転送、失敗を用途別に追跡します。
設計チェックリスト
- バケットとキーの命名規則に、所有者と用途が反映されているか。
- 公開、社内限定、機密などの区分が権限と一致しているか。
- 不要なACLに依存せず、最小権限のポリシーになっているか。
- 暗号方式と鍵を使える主体が決まっているか。
- バージョニング、削除権限、Object Lockの要否を検討したか。
- ライフサイクルの移行先、削除条件、最低保存期間を確認したか。
- RPOとRTOに沿った復元試験を実施したか。
- 監査ログ自体の保存先と閲覧権限を分離したか。
- リクエスト、取り出し、データ転送を含めて費用を見積もったか。
- サービス終了時やクラウド移行時の取り出し方法を決めたか。
よくある質問
S3バケットは公開してもよいですか
用途によりますが、通常は非公開を基本にします。Web配信が必要なら、S3を直接公開する前にCloudFrontとOACを使う構成を検討します。例外を作る場合は、公開対象、理由、期限、確認担当者を記録します。
Intelligent-Tieringならライフサイクル設計は不要ですか
不要にはなりません。アクセス頻度に応じた階層化と、保持期限を過ぎたデータの削除は別の要件です。非現行バージョンや中断したマルチパートアップロードの扱いも含めて決めます。
S3へ保存すればバックアップは完了ですか
S3は保存先になれますが、バックアップ運用には取得方法、保持、権限分離、改ざん対策、監視、復元試験が必要です。複数サービスを含む復旧設計はクラウド時代のバックアップ設計と復旧運用も参照してください。
マルチクラウドなら三社へ同じデータを置くべきですか
常に必要とは限りません。障害分離や移行性を得られる一方、複製、整合性確認、権限管理、監査、転送費が増えます。守りたい障害シナリオと復旧手順を定め、その要件を満たす範囲に絞ります。
参照した公式資料
- Amazon S3のデータ整合性モデル
- Amazon S3のストレージクラス
- S3 Object OwnershipとACL
- S3 Object Lock
- Google Cloud Storageのストレージクラス
- Microsoft Entra IDによるBlobアクセス認可
Amazon S3を運用へつなげるために
S3の初期設計では、非公開、権限、暗号化、バージョニング、ライフサイクル、監査を別々に扱わず、同じ要件表にまとめます。ストレージクラスは実際のアクセスと復元目標から選び、適用後も取り出し時間と費用を確認します。
クラウドを比較するときも、機能数や印象的な料金だけで順位を付けるのではなく、既存のID基盤、分析環境、ネットワーク、運用担当者、移行時のデータ移動まで含めて判断します。小さな対象で保存、拒否、削除、復元を一巡させると、本番運用で不足している決定を見つけやすくなります。
この記事に関連する株式会社greedenの取り組み
オブジェクトストレージは、料金だけでなく権限、復旧、監視まで設計して初めて業務で安定して使えます。株式会社greedenは、Webシステム開発の要件整理からAWS環境の設計、構築、保守運用まで一気通貫で支援します。