AWSサービス解説
Amazon S3とは？オブジェクトストレージを初心者向けに解説
Amazon S3の基本、ユースケース、課金ポイント、セキュリティ注意点をAWS初学者向けに整理します。
Amazon S3は、AWSを学ぶなら最初に理解したい代表的なストレージサービスです。静的サイト、画像保存、ログ保存、バックアップなど幅広く使われます。
結論
S3はオブジェクトストレージです。ファイルをオブジェクトとして保存し、バケットという入れ物で管理します。
オブジェクトストレージとは
オブジェクトストレージは、ファイル本体とメタデータをまとめて保存するストレージです。EC2のディスクとして使うEBSや、複数EC2で共有するEFSとは役割が違います。
S3は大量のファイル保存に強く、Webサイトの画像、静的HTML、ログ、バックアップ、データレイクなどに使われます。
バケットとオブジェクト
S3では、バケットを作り、その中にオブジェクトを保存します。オブジェクトにはキーがあり、パスのように扱えます。
このサイトでは、Next.jsの静的出力で生成されたHTML、CSS、JavaScript、画像をS3に配置しています。
セキュリティ注意点
S3で一番注意すべきなのは公開設定です。誤ってパブリック公開すると、意図しないファイルが外部から見える可能性があります。
静的サイト配信では、S3を直接公開せず、CloudFront OAC経由でアクセスさせる設計が安全です。
コスト注意点
S3は保存容量、リクエスト、データ転送などで課金されます。大容量画像や動画を置きっぱなしにするとコストが増えます。
個人MVPでは、画像を軽量化し、動画は置かず、不要なビルド成果物を残さない運用にします。
試験で問われるポイント
- S3はオブジェクトストレージ
- バケットにオブジェクトを保存する
- 静的Webサイトやバックアップに使える
- ストレージクラスでコスト最適化できる
- CloudFrontと組み合わせて配信できる
S3を理解するための基本モデル
S3はファイルをオブジェクトとして保存するストレージです。保存先の入れ物がバケット、バケット内でオブジェクトを識別する名前がキー、実体とメタデータを合わせたものがオブジェクトです。Amazon S3 とはを確認し、フォルダのように見える表示はキーの接頭辞による整理であることを押さえましょう。
このモデルは、OSのディレクトリとディスクをそのまま置き換えるものではありません。オブジェクトをURLやAPIで扱い、必要な権限を設定して読み書きします。ファイル名の設計、誰がアクセスするか、いつ削除または移行するかまで考えると、保存先としての役割がはっきりします。
静的アセットとバックアップの例
HTML、CSS、JavaScript、画像などの静的アセットをS3に置き、CloudFrontから配信する構成は代表的な使い方です。ログ、帳票の出力、バックアップ、分析用データの置き場としても利用されます。ただし「S3にあるからバックアップ済み」とは限りません。誤削除、上書き、復旧手順、保持期間は用途ごとに考えます。
静的サイトでは、S3をインターネットへ直接公開するより、CloudFrontを入口にしてS3を非公開に保つ設計が扱いやすいです。S3とCloudFrontで静的サイトを公開する方法を読み、配信と保管の役割を分けて確認してください。
S3、EBS、EFSの使い分け
S3はオブジェクト保存、EBSは主にEC2へ接続するブロックストレージ、EFSは複数のコンピューティングから共有しやすいファイルストレージです。既存アプリがPOSIXファイルシステムを必要とするのか、EC2の起動ディスクが必要なのか、HTTPでオブジェクトを保存・配信したいのかで選択します。
たとえばWebサイトの画像配信にEBSを使うのではなくS3とCloudFrontを検討します。一方、EC2上のデータベースのようにブロックデバイスが必要ならEBSが候補です。S3・EBS・EFSの違いで、接続方法とユースケースを並べて確認できます。
Block Public Accessとバケットポリシー
S3で最も注意したいのは意図しない公開です。S3 Block Public Accessを有効にしたうえで、必要なアクセスだけをバケットポリシー、IAMポリシー、CloudFront OACで許可します。オブジェクトURLを推測されにくくすれば安全、という考え方には頼れません。
バケットポリシーはバケット側の誰に何を許可するかを表し、IAMポリシーは主体に付ける権限です。両方がどのように評価されるかを確認し、公開用アセット、非公開のバックアップ、アプリ内のアップロード先を同じバケットと同じ権限で混ぜないようにします。
ライフサイクルとストレージクラス
保存期間やアクセス頻度に応じて、ライフサイクルルールやストレージクラスを検討できます。頻繁に使うデータ、長期間ほぼ参照しないアーカイブ、削除期限のある一時ファイルでは、必要な取り出し方や復元の待ち時間が異なります。費用だけでなく、復元が必要になったときの手順と時間も選定基準です。
単価や無料枠、各クラスの条件は変わり得ます。固定の料金表を記事やコードに書き込むのではなく、最新の公式情報と実際の利用量を確認します。不要なビルド成果物、重複したバックアップ、大きな画像を残し続けない運用が、まず取り組みやすい対策です。
試験で混同しやすい点
S3はオブジェクトストレージで、EC2にマウントして一般的なディスクのように使うEBSとは役割が異なります。S3を静的Webサイトの配信元にできても、アクセス制御を考えずにバケットを公開する理由にはなりません。低遅延な世界規模の配信が問われるなら、S3単体ではなくCloudFrontとの組み合わせを考えます。
「大量のファイル、バックアップ、ログを耐久性を意識して保存」「HTTP経由でオブジェクトを扱う」ならS3が候補です。「EC2のブートボリューム」「複数EC2が共有するファイルシステム」が問われているなら、それぞれEBSやEFSを検討します。
よくある失敗と次の一歩
公開設定を確認せずにアップロードする、秘密情報をファイル名やオブジェクトメタデータへ入れる、バックアップの復元を試さない、ライフサイクルを決めずにファイルを残すことがよくある失敗です。最小権限のIAMロールで一つのオブジェクトをアップロードし、想定した主体だけが取得できることを確認してください。
次にCloudFront OACを使い、S3のオブジェクトを直接公開せずに静的サイトを配信してみます。公開データと非公開データでバケットまたはプレフィックス、ポリシー、保持ルールを分けると、運用の判断がしやすくなります。
アップロードと取得の設計
アプリからS3へアップロードさせる場合、利用者にAWS権限を広く配るのではなく、対象のバケット、キーの接頭辞、操作を限定します。アップロード後にどの名前で保存するか、同名ファイルを上書きするか、コンテンツタイプをどう扱うかを決めます。ブラウザから直接扱う構成ではCORSも必要になるため、許可するOriginとメソッドを最小限にします。
取得用URLを一時的に発行する方式を使う場合も、期限と対象キーを狭めます。URLを知る人だけが読める状態を、恒久的なアクセス制御の代わりにしないよう注意します。公開アセット、利用者ごとの非公開ファイル、バックアップでは、アクセス経路とポリシーを分離します。
継続的な見直し
バケット一覧を定期的に確認し、用途不明のバケット、古いテストデータ、公開範囲の広いポリシーを見つけます。監査ログやアクセスログを有効にするかは、調査の必要性と保存する情報を踏まえて決めます。ログ自体にアクセス情報が含まれるため、ログ保存先にも同じ公開設定の注意が必要です。
S3は多くのAWSサービスの保存先として使われます。だからこそ、最初に作ったバケットを何でも入れる共有場所にせず、データの種類とライフサイクルに合わせて責務を分けることが、将来のセキュリティと費用管理を助けます。
名前付けと削除のルール
キーの名前には、用途、環境、日付、利用者単位など、後で検索と権限設定に役立つ情報を一貫して入れます。ただしメールアドレスや秘密情報をキーに含めると、ログやURLに露出する可能性があるため避けます。アップロード時にサーバー側で安全なIDを発行する方法も選択肢です。
削除は、不要になったファイルを手で消すだけでは運用になりません。一時ファイルの期限、バックアップの保持、誤削除時の復旧、アーカイブへ移した後の取り出しを決め、ライフサイクルルールと手順を対応させます。実際に復旧を試すことで、保存していることと使えることの違いを確認できます。
配信品質を確認する
静的アセットでは、オブジェクトのContent-TypeやCache-Controlが期待どおりかも確認します。誤ったContent-Typeはブラウザの表示に影響し、短すぎるキャッシュ設定は配信効率を落とすことがあります。CloudFrontを前段に置く場合は、S3のメタデータとCloudFrontのキャッシュ方針を一緒に見直します。
試験では、保存対象がファイルやバックアップなのか、EC2に接続するディスクなのか、複数サーバーで共有するファイルシステムなのかを最初に読み取ります。S3は汎用的で便利ですが、すべてのストレージ要件を同じ操作感で満たすサービスではありません。公開範囲、アクセス頻度、復旧の要件を分けて考えると、サービス選択の根拠を説明できます。
バケットを作成するリージョンは、利用者の場所、他サービスとの連携、データ保管の要件を踏まえて選びます。一度アップロードしたデータを別の場所へ移すにはコピーや同期が必要になるため、テスト用と本番用を無計画に混ぜないことも重要です。環境名を付けたバケットやプレフィックスで分け、誤って本番データを操作しない運用にします。
バージョニングや削除保護に関わる機能を使う場合も、保持量が増えることと復旧に役立つことを両方理解します。古い版をどこまで残すか、誤ったアップロードをどう戻すか、アクセス権を失ったときに誰が復旧できるかを決めます。S3のセキュリティは公開設定だけで終わらず、データの作成から削除までの流れを管理することで強くなります。
オブジェクト数や保存量が増えると、一覧表示や棚卸しにも時間がかかります。運用者が必要な情報を見つけられる命名、タグ、保持ルールを用意し、不要になったデータを安全に削除できる状態を保ちます。保存先を増やす前に、責任者と用途を明確にすることが大切です。
費用を確認するときは、保存容量だけでなくリクエスト、転送、復元などの利用方法も見ます。急な増加を早く見つけるため、利用量の確認と通知のルールをチームで共有します。
データを外部へ共有する必要がある場合も、バケット全体を公開するのではなく、対象、期間、操作を限定します。公開後に不要になった権限を取り消す手順まで決めておくと、継続的な安全性を保てます。
定期的な権限レビューを運用に組み込みます。
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。