【AWS再入門2026】Amazon S3の基本を整理してみた

はじめに

この記事では、Amazon S3（Simple Storage Service）について、基本概念・バケット種別・ストレージクラス・アクセス制御・セキュリティ・コストの観点を整理します。

対象読者は以下です。

AWSを学び始めた方で、S3の全体像をつかみたい方
S3を日常的に使っているが、設計観点を改めて整理したい方
2025〜2026年の新機能（S3 Tables・S3 Vectors）の位置づけが気になる方

この記事の内容は2026年6月時点の公式ドキュメントをもとにしています。利用前に最新のAWS公式ドキュメントを確認してください。

この記事で分かること

Amazon S3の概要と基本用語
2026年時点で存在する4種類のバケット
ストレージクラスの使い分け
アクセス制御の設計方針（IAM・バケットポリシー・ACL・Access Points）
セキュリティとコストの観点
実機確認の流れ

Amazon S3とは

Amazon S3は、AWSが提供するオブジェクトストレージサービスです。ファイルを「オブジェクト」として保存し、インターネット経由やプライベート接続(VPC Endopoint経由)でアクセスできます。

主なユースケースは以下のとおりです。

Webアプリやモバイルアプリのファイル保存
バックアップ・アーカイブ
静的Webサイトホスティング
データレイク・分析基盤
ML/AIのデータ保存（学習データ・ベクトルデータ）

ざっくり言うと

「容量無制限のファイル置き場」です。ただし、ディレクトリ構造はなく、バケット内にオブジェクトを「キー」で管理するフラットな構造になっています。

基本用語

用語	説明
バケット（Bucket）	オブジェクトを格納するコンテナ。リージョンを指定して作成する
オブジェクト（Object）	S3に保存するデータの単位。ファイル本体とメタデータで構成される
キー（Key）	バケット内でオブジェクトを一意に識別する名前。パス区切り文字（`/`）を含むことができるが、あくまでキー名の一部であり、実際のディレクトリ構造は存在しない
バージョンID	バージョニングを有効化した場合にオブジェクトごとに付与されるID
プレフィックス（Prefix）	キーの前方一致部分。フォルダのように見せるための慣習的な区切り

バケットの種類（2026年時点）

S3には現在4種類のバケットがあります。用途に応じて使い分けます。

汎用バケット（General Purpose Bucket）

最も一般的なバケット種別で、ほとんどのユースケースに対応しています。

複数AZにまたがって冗長化（S3 Express One Zone以外の全ストレージクラスを利用可能）
グローバル汎用バケット→バケット名はデフォルトで共有グローバル名前空間に作成（全AWSアカウント・全リージョンで一意である必要あり）
アカウントのリージョン名前空間汎用バケット→オプションで、自アカウントのみ利用可能な名前空間にバケットを作成可能、アカウント固有のため当該バケットを別アカウントで再作成は不可(AWSはアカウントのリージョン名前空間にバケットを作成することは、セキュリティのベストプラクティスとしている)

ディレクトリバケット（Directory Bucket）

低レイテンシーおよびデータレジデンシー向けのバケット種別です。

単一AZ内で一桁ミリ秒のレイテンシーを実現
アベイラビリティーゾーンのディレクトリバケットは、S3 Express One Zoneストレージクラスをサポート
Local Zones のディレクトリバケットは、S3 One Zone-Infrequent Access (S3 One Zone-IA、Z-IA) ストレージクラスをサポート
S3 Standardと比べてリクエストコストが50%低い【要確認：2026年時点の料金】
1アカウントあたりデフォルト100個まで作成可能※バケット内に保存できるオブジェクト数には制限なし
公開アクセス(すべてのパブリックアクセス)は常時無効（変更不可）
最低90日間のリクエストがないディレクトリバケットは非アクティブ状態に移行し、一時的に読み取りと書き込みが利用不可となる(データは保持されたまま、既存の料金のまま)、再度アクセスがあると通常数分以内にアクティブな状態へと移行する
MFA Delete、オブジェクトロック、バージョニング、レプリケーション、静的WEBサイトホスティング等S3の一部機能はサポート外

テーブルバケット（Table Bucket） — S3 Tables

表形式データ（テーブルデータ）向けのバケット種別です。
テーブルデータの例: 毎日の購入トランザクション、ストリーミングセンサーデータ、広告インプレッション等

Apache Icebergフォーマットのデータを保存・管理
Amazon Athena、Amazon Redshift、Apache Sparkなどのクエリエンジンと連携
分析・機械学習ワークロード向けにクエリパフォーマンスを自動最適化
1アカウント1リージョンあたりデフォルト10テーブルバケット、1バケットあたり最大10,000テーブル作成可能
すべてのテーブルバケットおよびテーブルは外部公開不可、明示的にアクセス許可が与えられているユーザのみがアクセス可能
S3 Intelligent-Tieringとの組み合わせでコスト自動最適化が可能

ベクトルバケット（Vector Bucket） — S3 Vectors

AIワークロード向けのベクトルデータ専用バケット種別です。

ベクトル埋め込みの保存・類似検索に特化
低頻度のクエリでは1秒未満、高頻度のクエリであれば100ミリ秒のレイテンシーを実現
Amazon BedrockやAmazon OpenSearchとの統合に対応

どれを使うか迷ったら：通常のファイル保存・バックアップ・Webアプリには汎用バケットを選択するのが基本です。

ストレージクラス

S3は用途に応じてストレージクラスを選択できます。アクセス頻度・取得速度・コストのバランスで選びます。

ストレージクラス	特徴	最小保存期間	主なユースケース
S3 Standard	高頻度アクセス。低レイテンシー・高スループット	なし	Webアプリ、動的コンテンツ
S3 Intelligent-Tiering	アクセスパターンに応じて自動でクラス移動	なし	アクセスパターンが不定なデータ
S3 Express One Zone	一桁ミリ秒レイテンシー。単一AZ	1時間	ML推論、低遅延分析
S3 Standard-IA	低頻度アクセス。取得時に追加料金	30日	バックアップ、DR
S3 One Zone-IA	単一AZの低頻度アクセス。Standard-IAより安価	30日	再作成可能なセカンダリバックアップ
S3 Glacier Instant Retrieval	アーカイブ。ミリ秒で取得可能	90日	医療画像、メディアアセット
S3 Glacier Flexible Retrieval	アーカイブ。取得に数分〜12時間	90日	バックアップ・DR（即時性不要）
S3 Glacier Deep Archive	最低コスト。平均取得時間は9～48時間とされている、標準取り出しは通常12時間以内、一括取り出しは通常48時間以内の復元	180日	長期保存・コンプライアンス

注意：最小保存期間を下回って削除した場合、残存期間分の料金が発生します。

S3 Intelligent-Tieringの仕組み

アクセス頻度に応じて3つの階層を自動で移動します。

高頻度アクセス層
  ↓ 30日間未アクセス(自動)
低頻度アクセス層
  ↓ 90日間未アクセス(自動)
アーカイブインスタントアクセス層

オプションで以下のアーカイブ階層を有効化することができます。
オブジェクトが90日間連続でアクセスがなくなった場合に自動的にアーカイブ階層へ移動し、コストを抑えることができます。

アーカイブアクセス層(オプション)※S3 Glacier Flexible Retrievalと同等のパフォーマンス
ディープアーカイブアクセス層(オプション)※S3 Glacier Deep Archiveと同等のパフォーマンス

オブジェクトへアクセスがあると自動的に、高頻度アクセス層に移動します。
具体的にどのようなアクションが対象となるか(Put Object等)は公式ドキュメントをご確認ください。
ListObjects等は対象外のようです。

詳しくは公式ドキュメントを参照ください。

ライフサイクルポリシーとの使い分け

アクセスパターンが予測できる場合はライフサイクルポリシーで明示的に移行
アクセスパターンが不定な場合はIntelligent-Tieringに任せる

アクセス制御の設計

S3のアクセス制御は複数の仕組みが組み合わさっています。全体像を把握してから設計することが重要です。

アクセス制御の仕組み一覧

仕組み	対象	AWSの推奨度
IAMポリシー	IAMユーザー・ロール単位	推奨
バケットポリシー	バケット・オブジェクト単位（リソースベース）	推奨
S3 Access Points	共有データセットへの大規模アクセス管理	推奨（共有用途）
ACL（アクセスコントロールリスト）	バケット・オブジェクト単位（旧来の仕組み）	非推奨

Block Public Access

バケットへの公開アクセスを一括でブロックする設定です。デフォルトでバケットレベルの4項目が全てオンになっています。

静的Webサイトホスティング等で公開が必要な場合のみ該当項目をオフにします。それ以外は変更しないことを推奨します。

BlockPublicAcls:       true  ← 指定されたACLがパブリックである場合やリクエストにパブリックACLが含まれる場合にはリクエストが失敗する
IgnorePublicAcls:      true  ← バケットとオブジェクトすべてのパブリックACLを無視する
BlockPublicPolicy:     true  ← 指定されたバケットポリシーでパブリックアクセスが許可されている場合、Amazon S3 はPutBucketPolicyへの呼び出しを拒否、アカウントレベルでの設定を推奨(バケットポリシーはユーザー側でパブリックアクセスを許可する設定ができるため)
RestrictPublicBuckets: true  ← パブリックポリシーを持つバケットへのアクセスをバケット所有者のアカウントおよびアクセスポイント所有者のアカウント内の AWS のサービスプリンシパルと承認されたユーザーのみに制限

BlockPublicAclsとIgnorePublicAclsが具体的にどう違うのか公式ドキュメントではわかりづらかったので、もう少し深堀してみてみました。

BlockPublicAclsは公式ドキュメントによると以下のように解説されています。

指定されたアクセスコントロールリスト (ACL) がパブリックである場合、PutBucketAcl と PutObjectAcl の呼び出しは失敗します。
リクエストにパブリック ACL が含まれている場合、PutObject の呼び出しは失敗します。
この設定がアカウントに適用されている場合、リクエストにパブリック ACL が含まれていると PUT Bucket の呼び出しは失敗します。

IgnorePublicAclsは以下のように解説されています。

このオプションを TRUE に設定すると、Amazon S3 はバケットとそれに含まれるオブジェクトのすべてのパブリック ACL を無視します。この設定を使用すると、パブリック ACL を含む PutObject 呼び出しを許可しながら、ACL によって許可されたパブリックアクセスを安全にブロックできます (BlockPublicAcls とは異なり、パブリック ACL を含む PutObject 呼び出しを拒否します)。この設定を有効にしても、既存の ACL の永続性には影響せず、新しいパブリック ACL の設定も妨げられません。

この二つの違いは、前者のBlockPublicAclsはパブリックACL付きのオブジェクトのアップロードを拒否するのに対して、後者のIgnorePublicAclsはパブリックACL付きのオブジェクトのアップロードを許可した上で、ACLを無視して匿名ユーザからのアクセスを拒否します。

例えば、従来のアプリケーションがパブリックACL付きのオブジェクトをアップロードする機能を持っている場合などに影響を与えることなくS3側でパブリックアクセスを拒否することができます。(IgnorePublicAcls

詳細は以下を参照ください。

ACLとオブジェクト所有権

現在、ACLはデフォルトで無効化されています（オブジェクト所有権はデフォルトでBucket owner enforcedに設定）。

オブジェクト所有権: 
→ バケットにアップロードされたオブジェクトの所有権の制御やACLの有効化が可能

※Bucket owner enforced（デフォルト）によってACLは無効になり、バケット所有者がバケット内のすべてのオブジェクトの所有権を自動で取得します。それにより、所有者がオブジェクトのアクセス権を制御できます。

ACLを有効にする必要があるケースは限定的です。新規構築時はACLを無効のまま使用することを推奨します。

S3 Access Points

AWS公式ドキュメントでは、Access Points は S3 の共有データセットを使うアプリケーションのアクセス管理を大規模に簡素化するための機能であり、バケットにアタッチされる名前付きネットワークエンドポイントだと説明されています。
大規模な共有データセットに対して、アクセスポイントごとに独立したポリシーを設定できます。

バケット
  ├── Access Point A（分析チーム用：読み取り専用）
  ├── Access Point B（アプリチーム用：特定プレフィックスのみ）
  └── Access Point C（VPC内からのみアクセス可）

1バケットに対して複数のアクセスポリシーが必要な場合に有効です。

詳細は以下を参照ください。

セキュリティの観点

観点	確認内容
暗号化	2023年1月5日以降、新規オブジェクトはSSE-S3（AES-256）がデフォルト適用
鍵管理	要件に応じてSSE-S3（AWS管理）・SSE-KMS（カスタマー管理）・SSE-C（自己管理）を選択
通信経路	HTTPS（TLS）での通信のみを許可（バケットポリシーで`aws:SecureTransport`条件を使用）
ログ	CloudTrailでAPIレベルの操作履歴を記録。サーバーアクセスログで詳細リクエストを記録
アクセス分析	IAM Access Analyzer for S3でバケットポリシーを評価し、意図しない公開アクセスを検出
機密データ検出	Amazon Macieで機械学習を使ってPIIなどの機密データを自動検出
オブジェクトロック	WORM（Write Once Read Many）要件がある場合はS3 Object Lockを利用

AWS S3 セキュリティのベストプラクティス

アクセスコントロールリスト (ACL) の無効化
パブリックアクセスブロック等の設定で、バケットが公開されていないことを確認する
複数のAWSアカウントを持つ組織は、組織レベルのパブリックアクセスブロック管理の使用を検討
必要でない限り、顧客側で用意したキー (SSE-C) を使用したサーバー側の暗号化は無効化
アカウントのリージョン名前空間にバケットを作成
最小特権アクセスの実装
Amazon S3アクセスを必要とするアプリケーションとAWSのサービスにIAM ロールを使用
保管時のデータ暗号化の検討
送信時のデータの暗号化を強制する
S3 オブジェクトロックの検討
S3 バージョニングの有効化
S3 クロスリージョンレプリケーションの検討
S3アクセス用のVPCエンドポイントの検討
マネージドAWSセキュリティサービスを使用したデータセキュリティの監視

詳細は以下を参照ください。

コストの観点

S3の料金は主に以下の要素で構成されます。

課金要素	内容
ストレージ料金	保存しているオブジェクトのサイズ × 保存日数に応じて課金
リクエスト料金	PUT/COPY/POST/LIST（1,000件ごと）、GET/SELECT（1,000件ごと）
データ転送料金	インターネットからAWSへの転送は無料、AWSからインターネットへの転送は1か月あたり100GBのインターネットへのデータ転送 (アウト) 無料枠の超過分が課金
ライフサイクル移行料金	ストレージクラス間の移行リクエストに対して課金
早期削除料金	最小保存期間を下回って削除した場合、残存期間分のストレージ料金が発生
レプリケーション料金	宛先として選択したS3ストレージクラスのストレージの料金、プライマリコピーのストレージの料金、レプリケーションPUTリクエストの料金、および該当する低頻度アクセスストレージの取得料金

詳細は以下を参照ください。

コスト最適化のポイント

ライフサイクルポリシーを設定する
アクセスが減ったオブジェクトを自動で安いストレージクラスへ移行し、一定期間後に削除します。

{
  "Rules": [
    {
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

S3 Storage Lensで使用状況を可視化する
メトリクスとダッシュボードで、組織全体のS3利用状況を分析できます。無駄なバケット・未使用オブジェクトの特定に役立ちます。

マルチパートアップロードの未完了データを削除する
大容量ファイルのアップロードが失敗した場合、途中のデータが残り続けます。ライフサイクルポリシーでAbortIncompleteMultipartUploadを設定することを推奨します。指定した日数以内に完了しないマルチパートアップロードを中止し、関連付けられたすべてのパートを削除させることができます。

よく使う構成例

構成例1：静的Webサイトホスティング

ユーザー
  ↓ HTTPS
Amazon CloudFront（CDN・キャッシュ）
  ↓ OAC（Origin Access Control）
Amazon S3（静的ファイル置き場）

CloudFrontのOAC（Origin Access Control）を使うことで、S3バケットを直接公開せずにCloudFront経由のみでアクセスを許可できます。バケットは非公開のまま運用します。

構成例2：アプリケーションのファイルアップロード

ユーザー
  ↓ 署名付きURL（Presigned URL）
Amazon S3（直接アップロード）
  ↓ イベント通知（S3 Event Notifications）
AWS Lambda（アップロード後処理：サムネイル生成・ウイルススキャン等）

署名付きURLを使うことで、アプリサーバーを経由せずにユーザーがS3に直接アップロードできます。サーバーの負荷を下げられます。

構成例3：データレイク（分析基盤）

各種データソース（アプリ・IoT・ログ等）
  ↓
Amazon Kinesis Firehose / AWS Glue
  ↓
Amazon S3（データレイク）
  ↓
Amazon Athena / Amazon Redshift Spectrum
  ↓
分析・可視化

S3をデータレイクの中核に置き、様々なデータソースを集約。Athenaを使ってSQL形式でS3上のデータを直接クエリできます。

実機確認

前提条件

AWSアカウントを利用できること
S3の操作権限（AmazonS3FullAccessまたはカスタムポリシー）を持つIAMユーザー/ロールがあること
AWS CLIが設定済みであること（aws configure完了済み）

作成するリソース

リソース	用途
S3汎用バケット	動作確認用
テストオブジェクト	アップロード・ダウンロード確認用

手順1：バケットを作成する

マネジメントコンソール

S3コンソールを開き、「バケットを作成」をクリック
バケットタイプ「汎用」を選択
バケット名を入力（グローバルで一意な名前）
リージョン「アジアパシフィック（東京）ap-northeast-1」を選択
「パブリックアクセスをすべてブロック」が全てオンであることを確認
「バケットを作成」をクリック

AWS CLI

# 目的：東京リージョンにバケットを作成
# 前提：AWS CLIが設定済み、バケット名が一意であること
# 想定結果：make_bucket: バケット名 と表示される
aws s3 mb s3://バケット名 --region ap-northeast-1

バケットの暗号化設定を確認します。

# 目的：デフォルト暗号化設定を確認（SSE-S3が有効か）
# 想定結果：SSEAlgorithm: AES256 が表示される
aws s3api get-bucket-encryption --bucket バケット名

手順2：オブジェクトをアップロードする

# 目的：テストファイルをアップロード
# 想定結果：upload: ./test.txt to s3://バケット名/test.txt と表示される
echo "hello S3" > test.txt
aws s3 cp test.txt s3://バケット名/test.txt

# 目的：アップロードしたオブジェクトを確認
# 想定結果：オブジェクトのサイズ・更新日時・キーが表示される
aws s3 ls s3://バケット名/

手順3：バケットポリシーを確認する

# 目的：バケットポリシーの有無を確認
# 想定結果：ポリシーなしの場合は「NoSuchBucketPolicy」エラーが返る
aws s3api get-bucket-policy --bucket バケット名

HTTPS強制のバケットポリシー例（設定する場合）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonHTTPS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::バケット名",
        "arn:aws:s3:::バケット名/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

手順4：後片付け

# 目的：テストオブジェクトを削除
aws s3 rm s3://バケット名/test.txt

# 目的：バケットを削除（バケットが空であること）
aws s3 rb s3://バケット名

まとめ

この記事では、Amazon S3について以下を整理しました。

S3はオブジェクトストレージ。バケット・オブジェクト・キーが基本単位
2026年時点で汎用・ディレクトリ・テーブル・ベクターの4種類のバケットが存在する
ストレージクラスはアクセス頻度とコストで使い分け。アクセスパターンが不定ならIntelligent-Tiering
アクセス制御はIAMポリシーとバケットポリシーが基本。ACLは原則無効のまま
Block Public Accessはデフォルトオン。公開が必要なケース以外は変更しない
コストはストレージ・リクエスト・転送料金の組み合わせ。ライフサイクルポリシーで最適化する

S3はAWSの中でも特に用途の広いサービスです。まず汎用バケットで基本を押さえ、用途に応じてストレージクラスやアクセス制御の設計を深めていくのが実践的な順序です。

参考リンク