S3講座

この講座では、AWSのオブジェクトストレージサービスであるS3について学びます。

  • オブジェクトストレージの概念と特徴
  • Amazon S3の基本(バケット・オブジェクト・プレフィックス)
  • ストレージクラスとライフサイクル管理
  • バケットポリシーとアクセス制御
  • バージョニングとデータ保護
  • 静的ウェブサイトホスティング
  • その他の便利な機能(署名付きURL・イベント通知・マルチパートアップロード)

1. S3の概要

1.1 オブジェクトストレージとは

オブジェクトストレージとは、データを階層的なフォルダではなく、平らな領域で管理する仕組みのことです。

私たちが普段パソコンで使っているファイルシステムは、フォルダの中にさらにフォルダを作るという階層構造でデータを整理しますが、オブジェクトストレージにはこの階層という概念がありません。データ本体にIDと、そのデータに関する詳細情報をセットにした「オブジェクト」という単位で、一つの巨大な保管庫に並列に保存していきます。保存場所の階層を意識する必要がなく、IDさえ指定すればどこからでもデータを取り出せるのが特徴です。

オブジェクトストレージのメリットは以下の通りです。

容量の制約がない

1つ目は、容量の制約から解放される点です。従来のシステムでは事前にディスク容量の上限を決めて設計する必要があり、データが増えるたびに増設や移行の手間がかかっていました。しかし、オブジェクトストレージには実質的な容量制限がなく、データがどれだけ増えてもシステム構成を変えることなく、無尽蔵に保存し続けることができます。

もちろん、サービス提供側が保有している設備の上限が物理的な限界とはなりますが、裏側での保存リソースの拡張や管理といった作業をすべてサービス提供側が担ってくれるため、利用者は容量を気にせず使い続けることができるメリットがあります。

クラウドとの親和性

2つ目は、Webシステムとの親和性が高く、サーバ構成を柔軟にできる点です。

従来のサーバ内部に保存する方法では、ロードバランサーやオートスケーリングによってサーバを複数台に増やした際、データが特定のサーバに閉じ込められてしまい、すべてのサーバ間でデータを共有するのが困難でした。

対してオブジェクトストレージは、サーバから独立した場所にあり、インターネット経由でどこからでもアクセスできます。これにより、サーバ本体にデータを持たせる必要がなくなり、いつでもサーバを増やしたり作り直したりできる、クラウドらしい柔軟な構成が可能になります。

耐久性が高い

3つ目は、手軽に高いデータ耐久性が手に入る点です。

自前でデータを守ろうとすると高価なバックアップ装置が必要でしたが、クラウドのオブジェクトストレージは、データを保存した瞬間に自動的に複数の場所へ複製が作られる仕組みになっています。利用者は意識することなく、低コストで最高レベルのデータ耐久性を得ることができます。

つまり、従来のファイルシステムは、整理整頓はしやすいものの容量に限界があったのに対し、物理的な場所や容量の上限を気にせず使える「巨大な自動倉庫」へと進化したのがオブジェクトストレージであり、大量のデータを扱う現代のシステム構築には欠かせない存在となっています。

1.2 Amazon S3とは

Amazon S3(Amazon Simple Storage Service)は、AWSで利用できるオブジェクトストレージサービスです。

S3では、バケットオブジェクトという単位でデータを管理します。バケットとは、データを保存する領域(コンテナ)のことで、S3におけるデータの入れ物となります。1つのAWSアカウント内で、いくつも作成することができます。S3のバケット名は、全世界で一意でなければなりません。例えばABCというバケットが既に存在していた場合、自分のアカウントの中にABCというバケットが存在しなくても、世界のどこかでABCというバケットが存在すると、作成することはできません。そのため、日付やアカウントID、サービス名をつけるなど、工夫が必要です。

オブジェクトは、アップロードされるデータそのものです。厳密にはファイルシステムとは異なりますが、通常のファイルシステムにおけるファイルそのものと捉えて問題ありません。バケットの中にオブジェクトを保存することで、S3におけるデータ管理ができます。

さらに、S3ではフォルダを作成し、従来のファイルシステムのように階層管理することができます。しかし、これはシステムとしてディレクトリ構造を保存しているのではなく、S3が便宜上、オブジェクト名の「プレフィックス(接頭辞)」をフォルダのように見せているだけであり、実際にオブジェクトがフォルダ構成で管理されているわけではありません。

1.3 S3の耐久性

S3の最大の特徴は、常識外れとも言える「データの消えにくさ(耐久性)」にあります。

S3の耐久性は「99.999999999%」と設計されています。9が11個並ぶことから、通称「イレブンナイン」と呼ばれます。これがどれくらい凄い確率かというと、「もしS3に1万個のファイルを保存したとして、そのうちの1個が失われるのに平均で1,000万年かかる」という計算になります。つまり、人間の感覚で言えば「データが消えることはまずあり得ない」と言えるレベルの信頼性です。

なぜこれほどの耐久性を実現できるのでしょうか。その秘密は、AWSの物理的な設備構成にあります。私たちがS3にファイルを1つアップロードすると、AWSの裏側では、そのファイルが自動的に最低3箇所の離れたデータセンター群(アベイラビリティゾーン)にコピーされます。

これらは数キロメートル以上離れた場所に建設されており、それぞれ別の電源やネットワーク設備を持っています。そのため、仮に落雷や火災などで1つのデータセンターが壊滅するような大災害が起きたとしても、別の場所にあるデータが生き残るため、ファイルは守られます。

利用者は「コピーしてください」と指示する必要はありません。S3に保存した瞬間に、この強力なバックアップ体制が自動的に適用されます。

2. セキュリティとアクセス管理

2.1 ブロックパブリックアクセス

ブロックパブリックアクセスは、S3バケットが全世界に公開されることを防ぐための保護機能です。

S3バケットは、設定によってインターネット上で一般公開することができます。しかし、個人情報などの機密データをS3にて扱うことも多く、それが万が一にもミスにより公開されてしまえば、企業の存続が危ぶまれる程の重大なセキュリティインシデントになりかねません。

そのため、この「ブロックパブリックアクセス」を有効にしておけば、他の設定で誤って公開許可をしてしまってもインターネット上には公開されず、安全にS3バケットのデータを保護できます。

AWSでもベストプラクティスとして、基本はブロックパブリックアクセスをオンにしておくことを推奨しています。

なお、現在は新規でS3バケットを作成すれば、ブロックパブリックアクセスはデフォルトでオンになるようになっています。

2.2 バケットポリシー

バケットポリシーは、S3バケットそのものに設定するアクセス権限の管理機能です。

AWSの一般的な権限管理では、ユーザ(操作する人)に対して「何をしてもよいか」というIAMポリシーを与えますが、S3ではバケット(データがある場所)側に「誰になら触らせてよいか」というルールを持たせることができます。これを「リソースベースポリシー」と呼び、S3ではIAMと同様、JSON形式の記述ルールを用いて設定します。

具体的には、「会社の特定のIPアドレスからのみアクセスを許可する」といったネットワーク制限をかけたり、「別のAWSアカウントからのデータ保存を許可する」といったアカウントをまたいだ連携を行う際によく利用されます。

また、同じアカウント内でも、特定のユーザしか見られないようにS3側で保護することもできます。例えば、個人情報が含まれるバケットは、インフラ管理者であっても中身を見られないようにし、特定の担当者だけがアクセスできるようにしたいとします。この場合、通常インフラ管理者は「Administrator Access」の権限を持つことが多いため、S3バケットの個人情報を見られてしまいます。それを防ぐために、S3のバケットポリシー側で「拒否ルール」を設定しておけば、たとえAdministrator Accessの権限を持っていても、S3バケットのデータにはアクセスできなくなります。

非常に強力な機能ですが、記述内容を誤ると、誰も(自分自身すら)アクセスできなくなってしまうこともあります。

💡 ポイント
バケットポリシーの設定を誤ると、自分自身を含めて誰もアクセスできなくなることがあります。設定変更は慎重に行ってください。

2.3 暗号化

S3には、データを保存する際に自動的に暗号化を行うサーバサイド暗号化(Server-Side Encryption)という機能が備わっています。

利用者が暗号化・復号の処理を意識する必要はほとんどありません。データをS3にアップロードすると、S3が書き込み時に自動でデータを暗号化し、逆にデータをダウンロードする際には自動で復号して返してくれます。つまり、保管されている間は堅牢に守られ、正規の利用者が使うときはいつも通り使える、という便利な仕組みです。

暗号化に使う「鍵」の管理方法によって、主に以下の2つのパターンが使い分けられます。

1つ目はSSE-S3です。これはS3が鍵の作成から管理まですべてを行ってくれる方式です。現在、すべてのS3バケットはこの設定がデフォルトで有効になっており、追加料金もかかりません。一般的な用途であれば、この基本機能だけで十分なセキュリティが確保できます。

2つ目はSSE-KMSです。これはAWSの鍵管理サービス「AWS KMS」と連携する方式です。SSE-S3との最大の違いは、「誰がいつ鍵を使ってデータを復号したか」という操作履歴を追跡できる点です。そのため、厳しいセキュリティ要件や監査対応が必要な企業のシステムでは、こちらが選ばれることがあります。

3. ストレージクラスとライフサイクル

3.1 ストレージクラスとライフサイクルルール

ライフサイクルルールによるストレージクラスの自動移行の流れを以下に示します。

flowchart LR
    S1["S3 Standard"] -- "30日後" --> S2["Standard-IA"]
    S2 -- "90日後" --> S3G["Glacier<br>Instant Retrieval"]
    S3G -- "180日後" --> S4["Glacier<br>Deep Archive"]
    S4 -. "期限後に自動削除" .-> DEL["削除"]

S3には、データの利用頻度に応じて料金や性能が異なる「ストレージクラス」というプランがいくつか用意されています。

標準的な「S3 Standard」は、頻繁にアクセスするデータ向けで、データの出し入れは高速ですが、保管料は比較的高めに設定されています。

一方、あまり使わないデータ向けには「S3 Standard-IA(低頻度アクセス)」や、長期保存用の「S3 Glacier」シリーズがあります。これらは保管料が非常に安くなる代わりに、データを取り出す際に料金がかかったり、取り出しに時間がかかったりします。例えば、「S3 Glacier Deep Archive」というクラスを使えば、磁気テープ並みの低コストでデータを保管できます。

基本的なストレージクラスを下記表にまとめます。

クラス名 主な用途 コストの特徴 移行の目安
S3 Standard 頻繁にアクセスするデータ 保管費は高め、取り出しは無料 初期状態
S3 Standard-IA 月1回程度しか使わないデータ 保管費は安い、取り出しは有料 30日後
S3 Glacier Instant Retrieval 数ヶ月に1回しか使わないデータ 保管費はさらに安い、取り出しは高め 90日後
S3 Glacier Deep Archive 年単位で保存するログやアーカイブ 保管費は最安、取り出しに時間がかかる 180日後

しかし、膨大な数のファイルを手動で変更するのは現実的ではありません。そこで役立つのがライフサイクルルールです。

ライフサイクルルールを設定すると、「作成から30日が経過したらStandard-IAへ移動」「1年経過したらGlacierへ移動」「3年経過したら自動的に削除」といった運用を自動化できます。詳しい仕様はManaging the lifecycle of objects(AWS公式ドキュメント)に記載があります。

これにより、最初はアクセスしやすい場所に置き、古くなるにつれて安価な倉庫へ移し、最終的には廃棄するといった、データのライフサイクルに合わせたコスト最適化を、手間をかけずに実現できます。

4. S3の便利な機能

4.1 バージョニング

バージョニング機能は、誤ってファイルを削除したり上書きしてしまった際に、元の状態に戻すことができる「保険」のような機能です。

通常、同じ名前のファイルをアップロードするとデータは上書きされてしまいますが、バージョニングを有効にしたバケットでは、古いデータも消えずに「過去のバージョン」として裏側で保存され続けます。これにより、いつでも特定の日時の状態にファイルを巻き戻すことが可能です。

また、ファイルを削除した場合でも、即座にデータが消滅するわけではありません。「削除マーカー」という目印が付いて見えなくなるだけで、データ自体は残っています。そのため、あとからこのマーカーを取り除けば、削除前のデータを復元することができます。

非常に安心な機能ですが、変更を加えるたびにすべての履歴が累積して保存されるため、頻繁にファイルを書き換えるシステムでは、保存容量が増え続け、保管料金が高額になってしまう可能性がある点には注意が必要です。

4.2 MFA Delete(多要素認証削除)

バージョニングと合わせて設定することで、セキュリティをさらに高める機能が「MFA Delete」です。

バージョニングを有効にしていても、管理者権限を持つユーザのアカウントが乗っ取られてしまえば、過去のバージョンを含めてすべてのデータを消去されてしまうリスクが残ります。

MFA Deleteを有効にすると、過去のバージョンを「完全に削除」したり、バージョニング設定を「無効化」したりする重要な操作を行う際に、認証デバイス(スマホアプリなど)に表示されるワンタイムパスワードの入力が必須になります。

これにより、万が一IDやパスワードが漏洩しても、物理的な認証デバイスを持っている本人以外はデータを消すことができなくなり、データ保護のレベルを格段に高めることができます。

4.3 静的ウェブサイトホスティング

S3には、保存したファイルをWebサイトとして直接公開する静的ウェブサイトホスティングという機能があります。

通常、Webサイトを公開するためにはWebサーバ(EC2など)を構築し、Webサーバソフトを動かす必要があります。しかし、S3のこの機能を有効にすれば、HTMLファイルや画像、CSS、JavaScriptなどをバケットに配置するだけで、サーバを立てることなくWebサイトとして公開できます。

注意点として、あくまで「静的」なコンテンツの配信に限られるという点です。

ユーザが見ているブラウザ上で動くJavaScriptなどは問題ありませんが、PHPやRuby、Pythonのように、サーバ側でデータベースと通信したり、複雑な計算処理を行ったりする「動的」なプログラムをS3上で実行することはできません。

そのため、情報の更新頻度が低いコーポレートサイトやランディングページ(LP)、あるいはReactやVue.jsなどで作られたシングルページアプリケーション(SPA)の配信基盤として、非常に低コストかつ手軽に利用されています。

また、この機能単体では通信の暗号化(HTTPS)ができず、高度なセキュリティ機能も適用されません。そのため、実運用レベルでWebサイトを公開する場合は、次の講座で説明する「CloudFront」と組み合わせて利用することが一般的です。

4.4 署名付きURL (Presigned URL)

S3のデータは基本的には非公開(プライベート)ですが、特定のファイルだけを一時的に共有したい場合に便利なのが署名付きURL(Presigned URL)です。

これは、本来アクセス権限を持たないユーザに対して、あらかじめ「許可証(署名)」と「有効期限」を埋め込んだ専用のURLを発行する機能です。このURLを知っている人は、AWSのアカウントを持っていなくても、指定された期間内であれば対象のファイルをダウンロードしたり、逆にファイルをアップロードしたりすることができます。

例えば、有料会員限定の動画コンテンツを配信したり、スマホアプリのユーザが自分のプロフィール画像をS3に直接アップロードしたりする機能を作る際によく利用されます。バケット全体を公開することなく、必要な操作だけをピンポイントかつ安全に許可できるため、セキュリティとアプリケーション開発には欠かせない機能です。

4.5 イベント通知 (Event Notifications)

S3には、データに変化があった時に他の処理を自動で動かすイベント通知(Event Notifications)という機能があります。

S3のイベントをトリガーとして各サービスへ通知するパターンを以下に示します。

graph TD
    S3["S3バケット<br>(イベント発生)"]
    Lambda["Lambda<br>(プログラム実行)"]
    SNS["SNS<br>(メール通知)"]
    SQS["SQS<br>(メッセージキュー)"]

    S3 -- "ファイルアップロード" --> Lambda
    S3 -- "ファイル削除" --> SNS
    S3 -- "イベント通知" --> SQS

例えば、ファイルがアップロードされたり、削除されたりしたタイミングを検知して、AWS Lambda(プログラム実行)やAmazon SNS(メールやチャット通知)、Amazon SQS(メッセージキュー)といった他のサービスに信号を送ることができます。

よくある使い方としては、「画像がアップロードされたら、自動的にスマホ用のサムネイル画像を作るプログラム(Lambda)を動かす」といった画像処理や、「重要なファイルが削除されたら即座に管理者にメール(SNS)を送る」といった監視の仕組みなどに利用されます。

これにより、人間が画面を監視していなくても、データの動きに合わせてシステムが自律的に連携して動く「イベント駆動型(イベントドリブン)」の仕組みを簡単に作ることができます。

4.6 マルチパートアップロード

S3で数GB〜数TBといった巨大なファイルを扱う際に必須となる機能がマルチパートアップロードです。

通常、ファイルは1つの塊としてアップロードされますが、この機能を使うと、1つの大きなファイルを複数の小さな「パート」に分割し、それらを並列(同時)にアップロードすることができます。すべてのパートが届くと、S3側で自動的に結合され、1つのファイルとして保存されます。

メリットは主に2つあります。

1つ目は「高速化」です。並列処理によってネットワーク帯域を効率よく利用できるため、アップロード時間を大幅に短縮できます。

2つ目は「安定性」です。もしアップロード中に通信が途切れてしまっても、失敗したパートだけを再送すれば済むため、最初からすべてやり直す必要がありません。

なお、S3の仕様として、1つのファイルのサイズが5GBを超える場合は、必ずこの方式を利用する必要があります。動画ファイルやデータベースのバックアップなど、大容量データを扱う際には非常に重要な機能です。

5. 主なユースケース

S3は、AWSで最も多目的に活用されるストレージサービスです。以下に代表的なユースケースを紹介します。

5.1 静的コンテンツの配信

Webサイトの画像、CSS、JavaScript、動画などの静的ファイルをS3に保存し、CloudFront経由で配信します。サーバを立てることなく、高速かつスケーラブルなコンテンツ配信が実現できます。ReactやVue.jsで作成したSPAのホスティングにも最適です。

5.2 データレイク・バックアップ基盤

ログファイル、センサーデータ、業務データなど、あらゆる種類のデータを一元的に保存する基盤として利用されます。ライフサイクルルールで古いデータを自動的に低コストなストレージクラスに移行し、長期保存のコストを最適化できます。

5.3 アプリケーションのファイルストレージ

ユーザがアップロードした画像やドキュメント、アプリケーションが生成したレポートファイルなどを保存します。署名付きURLを使用することで、認証されたユーザのみがファイルにアクセスできる仕組みを実現できます。

6. 設計のポイント

S3を設計する際の主要な検討項目を以下にまとめます。

設計項目 検討内容 推奨・注意事項
バケット名 グローバルで一意な名前 プロジェクト名+環境名+用途など、識別しやすい命名規則を策定
ブロックパブリックアクセス 公開設定の制御 基本は全てブロック。公開が必要な場合のみ最小限解除
暗号化 保存データの暗号化 SSE-S3(デフォルト)で十分。監査要件があればSSE-KMSを検討
バージョニング 誤削除・上書きからの保護 重要なデータを扱うバケットでは有効化を推奨
ライフサイクルルール コスト最適化 アクセス頻度に応じてストレージクラスを自動移行
アクセスログ 監査・分析用 セキュリティ要件がある場合は有効化
レプリケーション 災害対策 重要データは別リージョンへのクロスリージョンレプリケーションを検討

7. まとめ

この講座では、AWSのオブジェクトストレージサービスであるS3について学びました。

  • S3はオブジェクトストレージであり、容量無制限・高耐久性(イレブンナイン)・クラウドとの親和性が特徴
  • データはバケット(容器)とオブジェクト(ファイル)という単位で管理する
  • ブロックパブリックアクセスやバケットポリシーでセキュリティを確保し、サーバサイド暗号化でデータを保護する
  • ストレージクラスとライフサイクルルールを使って、データの利用頻度に応じたコスト最適化が可能
  • バージョニング、静的ウェブサイトホスティング、署名付きURL、イベント通知など多彩な機能を持つ