S3バケットは、オブジェクトを入れる容器であると同時に、名前・リージョン・暗号化といった後から変えられない設定を抱えるリソースです。2026年10月時点のAmazon S3には汎用・ディレクトリ・テーブル・ベクトルの4種類のバケットがあり、名前が一意になる範囲も作れる数の上限も種類ごとに異なる仕様です。この記事では、種類の違いを整理したうえで、AWS CLIでの作成コマンド、一覧と容量の確認、バケット数の上限、空にして削除する手順を公式ドキュメントに沿って示します。命名規則の細部や権限設計まで含めたS3全体の使い方はAWS S3の使い方｜CLIでのバケット作成から権限設計・署名付きURLまでの実装手順にまとめてあるため、本記事はバケットというリソースの扱いに絞ります。
まとめ｜S3バケットを作る前に決める種類・上限・削除時の名前の扱い
普通のファイル保存なら汎用バケット1択です。ディレクトリ・テーブル・ベクトルの3種類は、低レイテンシ、Apache Icebergの表、埋め込みベクトルという特定の用途のために用意された別系統で、APIの名前空間もs3express・s3tables・s3vectorsと分かれています。
作成前に決めることは2つあります。1つ目は名前とリージョンで、どの種類も作成後に変更できません。2つ目は汎用バケットを置く名前空間で、共有のグローバル名前空間に作ると、削除した名前を別のAWSアカウントが取得できます。新規ならアカウントリージョナル名前空間（末尾が-anの名前）を選ぶのが安全です。
作れる数は汎用が1アカウント1万、ディレクトリが既定100、テーブルが1リージョン100、ベクトルが1リージョン1万です。2025年以前の解説に残る「1アカウント100個まで」は旧い値です。削除はバケットを空にしてからで、バージョニングが有効なバケットはaws s3 rb --forceでは消えません。
汎用・ディレクトリ・テーブル・ベクトルの4種類で変わるS3バケットの性格
AWSのユーザーガイドは、What is Amazon S3?の「Buckets」節で4種類のバケットを並べて定義しています。同じ「バケット」という名前でも、入れるデータの形と操作するAPIが別物だと捉えると混乱しません。
4種類のバケットが入れるデータとAPIの名前空間の違いを比べる
種類ごとの違いを、入れるデータ、APIの名前空間、主な用途で並べると次のとおりです。
| 種類 | 入れるデータ | APIの名前空間 | 主な用途 |
|---|---|---|---|
| 汎用バケット | 任意のオブジェクト | s3 | 画像・ログ・バックアップなど大半の用途 |
| ディレクトリバケット | 階層ディレクトリ配下のオブジェクト | s3express | 1桁ミリ秒の読み書きが要る処理 |
| テーブルバケット | Apache Iceberg形式の表 | s3tables | Athena・Sparkで集計する分析データ |
| ベクトルバケット | 埋め込みベクトルとメタデータ | s3vectors | RAGや類似検索の索引 |
汎用バケットだけがS3 Express One Zone以外の全ストレージクラスを使え、複数のアベイラビリティーゾーンへ冗長に保存されます。ディレクトリバケットは1つのアベイラビリティーゾーンに閉じるため、ゾーン障害時にデータが使えなくなる可能性があり、作成画面ではこの点への同意のチェックが必須です。テーブルバケットの仕組みはAmazon S3 Tablesとは？テーブルバケットの仕組みと東京リージョンの料金・作成手順、ベクトルバケットのAPIはAmazon S3 Vectors APIとは？操作一覧・料金とRAG構築の解説で詳しく扱っています。
名前の一意性が世界・ゾーン・アカウント単位で分かれる命名の範囲
バケット名が重複してはいけない範囲は種類ごとに異なる仕様です。汎用バケットは既定でパーティション（通常のAWSリージョン群）全体で一意で、他人が使っている名前はBucketAlreadyExistsの409で弾かれます。ディレクトリバケットは選んだゾーン内で一意で、名前の末尾に--apne1-az4--x-s3のようなゾーンIDの接尾辞が必須です。テーブルバケットとベクトルバケットは、自分のアカウントの同一リージョン内で一意であればよいとされています。
実務で効くのは汎用バケットの差です。2026年3月に追加されたアカウントリージョナル名前空間に作ると、名前は接頭辞-12桁のアカウントID-リージョン-anの形になり、他のアカウントは同じ名前を作れません。接尾辞も63文字の上限に数えるため、東京リージョンなら接尾辞-123456789012-ap-northeast-1-anが31文字で、接頭辞に使えるのは32文字です。
作成後に変えられない名前・リージョン・種類・暗号化の4項目の確認
作成後に変更できない項目は、4種類に共通する名前とリージョンに加え、種類ごとに増えます。ディレクトリバケットはバケットの種類とアベイラビリティーゾーン、SSE-KMSで指定した顧客管理キーも固定で、別のキーを使うには新しいバケットへコピーし直すしかありません。ベクトルバケットの作成ページも、暗号化の設定は作成後に変えられないと明記しています。
名前を変えたくなったときは「新しいバケットを作って中身を移し、古いほうを消す」以外に手段がありません。名前に環境名（dev・stg・prod）や用途を入れておくと、後で分割したくなったときの移行範囲を小さくできます。
AWS CLIで4種類のS3バケットを作成するコマンドと東京リージョンの指定
以下はAWS CLI v2（2026年10月時点のリファレンス表記は2.37.7）で動くコマンドです。CLIの導入と認証がまだならAWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順を先に済ませてください。アカウントIDやバケット名は自分の値に置き換えます。
汎用バケットをアカウントリージョナル名前空間で東京に作る手順
汎用バケットはs3api create-bucketで作ります。--bucket-namespace account-regionalを付け、名前に自分のアカウントIDとリージョンの接尾辞を含めるのが新しい作り方です。作成後はブロックパブリックアクセスが4項目とも有効かを確かめます。
aws s3api create-bucket \
--bucket app-logs-123456789012-ap-northeast-1-an \
--bucket-namespace account-regional \
--region ap-northeast-1 \
--create-bucket-configuration LocationConstraint=ap-northeast-1
aws s3api get-public-access-block \
--bucket app-logs-123456789012-ap-northeast-1-an東京リージョンではLocationConstraintを省くとエラーになるため、--regionと同じ値を必ず書きます。組織全体でアカウントリージョナル名前空間を強制したい場合は、条件キーs3:x-amz-bucket-namespaceでs3:CreateBucketを拒否するIAMポリシーやSCPを使えます。
ディレクトリバケットを東京のapne1-az4に作るときの構成指定
ディレクトリバケットの対応ゾーン一覧では、東京リージョンのアベイラビリティーゾーンIDはapne1-az1とapne1-az4の2つです。AZ名（ap-northeast-1aなど）ではなくAZ IDで指定する点に注意してください。
aws s3api create-bucket \
--bucket app-cache--apne1-az4--x-s3 \
--create-bucket-configuration 'Location={Type=AvailabilityZone,Name=apne1-az4},Bucket={DataRedundancy=SingleAvailabilityZone,Type=Directory}' \
--region ap-northeast-1この書式はディレクトリバケット作成ページのCLI例と同じです。名前の接尾辞とName=のAZ IDが食い違うと作成に失敗します。ブロックパブリックアクセスは全項目が有効のまま変更できず、ACLも有効化できません。
テーブルバケットとベクトルバケットを東京で専用コマンドから作る手順
テーブルバケットとベクトルバケットはs3apiではなく、それぞれ専用のコマンド群で作ります。どちらも既定の暗号化はSSE-S3です。
aws s3tables create-table-bucket \
--region ap-northeast-1 \
--name analytics-tables
aws s3vectors create-vector-bucket \
--region ap-northeast-1 \
--vector-bucket-name rag-embeddingsテーブルバケットのARNはarn:aws:s3tables:、ベクトルバケットはarn:aws:s3vectors:で始まり、汎用バケットのarn:aws:s3:::とは別の書き方になります。IAMポリシーでs3:*を許可しても、この2種類の操作は許可されません。権限はs3tables:・s3vectors:のアクションで別に書きます。
S3バケットの一覧・容量・オブジェクト数を確かめる方法と使い分け
バケットが増えると「どこに何があり、どれだけ使っているか」の把握が先に問題になります。一覧はAPIで即時に、容量はCloudWatchの日次メトリクスで取るのが基本です。
list-bucketsの–prefixと–bucket-regionによる一覧抽出
list-bucketsのリファレンスには、名前の先頭で絞る--prefixと、リージョンで絞る--bucket-regionがあります。出力のBucketRegionで各バケットの所在も分かります。
aws s3api list-buckets \
--prefix app- \
--bucket-region ap-northeast-1 \
--query "Buckets[].[Name,CreationDate,BucketRegion]" \
--output tableこのコマンドが返すのは汎用バケットだけです。ディレクトリバケットはaws s3api list-directory-buckets、テーブルバケットはaws s3tables list-table-buckets、ベクトルバケットはaws s3vectors list-vector-bucketsで別に引きます。棚卸しのスクリプトでは4本とも呼ばないと漏れが出ます。
CloudWatchのBucketSizeBytesで日次の容量を取り出す
バケットの容量は、S3が1日1回CloudWatchへ送るBucketSizeBytesで確かめます。メトリクスの定義では、この値は現行と旧バージョンのオブジェクト、未完了のマルチパートアップロードの部品まで含めた合計です。
aws cloudwatch get-metric-statistics \
--namespace AWS/S3 \
--metric-name BucketSizeBytes \
--dimensions Name=BucketName,Value=app-logs-123456789012-ap-northeast-1-an Name=StorageType,Value=StandardStorage \
--start-time 2026-09-25T00:00:00Z \
--end-time 2026-10-02T00:00:00Z \
--period 86400 \
--statistics Average \
--region ap-northeast-1StorageTypeはストレージクラスごとに値が分かれ、標準ならStandardStorage、標準IAならStandardIAStorageです。標準IAへ移したのに標準の値しか見ていないと、容量が急に減ったように見えます。オブジェクト数はNumberOfObjectsとAllStorageTypesの組み合わせで取れます。
aws s3 lsの–summarizeを大きなバケットで使わない理由
aws s3 ls s3://バケット名 --recursive --summarize --human-readableでも合計サイズは出ます。ただし全オブジェクトを列挙するため、数百万件あるバケットでは完了まで時間がかかり、LISTリクエストの料金も件数に比例して発生します。旧バージョンや未完了のアップロードは集計の対象外なので、請求額と合わない原因にもなる点に注意が必要です。
使い分けは単純です。数千件程度の検証用バケットで今の値をすぐ見たいときだけls --summarize、それ以外はCloudWatchのメトリクスを見ます。アカウント全体の傾向を掴みたい場合に使うのはStorage Lensです。容量が請求にどう効くかはS3の料金を実額で計算する｜東京リージョンの単価内訳とコストを下げる設定手順で試算しています。
汎用1万・ディレクトリ100・テーブル100・ベクトル1万のバケット数の上限
種類ごとの既定の上限と、その範囲を表にまとめます。値は2026年10月2日時点の各ドキュメントの記載です。
| 種類 | 既定の上限 | 数える単位 | 引き上げ |
|---|---|---|---|
| 汎用バケット | 10,000 | アカウント | Service Quotasで申請 |
| ディレクトリバケット | 100 | アカウント（リージョンごと） | Service Quotasで申請 |
| テーブルバケット | 100 | アカウント×リージョン | サポートへ申請 |
| ベクトルバケット | 10,000 | アカウント×リージョン | 制限ページは値のみ記載 |
テーブルバケットは、作成ページでは1リージョン100としている一方、S3全体の概要ページには10という記載が残っています。設計の前提にする前に、Service Quotasのコンソールで自分のアカウントの実値を確認してください。ベクトルバケットの値はS3 Vectorsの制限ページによるもので、1バケットあたりのインデックスも1万までです。
汎用バケットの上限1万の既定値をバージニア北部で確認する手順
汎用バケットの制限ページによると、既定で1アカウントあたり1万個まで作れ、1バケットに入れられるオブジェクトの数と容量には上限がありません。上限の確認や引き上げの申請は、商用リージョンでは米国東部（バージニア北部）のService Quotasからしか行えません。東京リージョンを選んだままコンソールを開くと値が見つからないのは、この仕様のためです。
上限を1万より上げると非ページングのListBucketsが拒否される条件
同じ制限ページには、上限を1万より引き上げたアカウントでは、ページングしないListBucketsリクエストがすべて拒否されると書かれています。古いSDKや自作スクリプトが一覧を1回の呼び出しで取っている場合、上限を上げた日から一覧処理が失敗します。
AWS CLI v2のlist-bucketsは自動でページングし、--page-sizeで1回あたりの件数を1〜10,000で指定できます。SDKで書いたコードは、ContinuationTokenを受け取って次のページを引く実装になっているかを、上限を上げる前に確認しておくと安全です。
S3バケットを空にして削除する手順とバージョニング有効時の落とし穴
削除の手順ページの前提は、バケットが空であること、同一アカウントのアクセスポイントが付いていないこと、s3:DeleteBucketの権限があることの3つです。削除したバケットはAWSにも復元できません。
rb –forceがバージョニング有効のバケットで失敗する仕組み
バージョニングが無効なバケットなら、aws s3 rb s3://バケット名 --forceの1行で中身ごと削除できます。バージョニングが有効または停止中のバケットでは、このコマンドは旧バージョンを消さないため、空にならずに削除が失敗します。aws s3 rm --recursiveも同じで、バージョニング有効のバケットでは削除マーカーを積むだけです。
確実なのはコンソールの「空にする」で、空にする手順のページによれば全バージョンと削除マーカーまで消えます。Elastic Beanstalkが作ったバケットのように、バケットポリシーにs3:DeleteBucketのDenyが入っている場合は、先にその記述を外します。
大きなバケットをライフサイクルルールで空にするJSONの設定例
オブジェクトが大量にあるバケットは、ライフサイクルルールで空にする方法が推奨されています。現行バージョン、旧バージョン、未完了のマルチパートアップロード、期限切れの削除マーカーの4つをすべて対象にしないと、何かが残って削除できません。
{
"Rules": [
{
"ID": "expire-all-objects",
"Filter": {},
"Status": "Enabled",
"Expiration": { "Days": 1 },
"NoncurrentVersionExpiration": { "NoncurrentDays": 1 },
"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 1 }
},
{
"ID": "remove-delete-markers",
"Filter": {},
"Status": "Enabled",
"Expiration": { "ExpiredObjectDeleteMarker": true }
}
]
}このJSONをempty.jsonとして保存し、aws s3api put-bucket-lifecycle-configuration --bucket バケット名 --lifecycle-configuration file://empty.jsonで適用します。削除マーカーの指定は日数指定と同じExpirationに書けないため、ルールを2つに分けた構成です。失効は非同期で、空になるまで数日かかることがあります。対象としてマークされた時点で、そのオブジェクトの保管料金はかからなくなります。
削除したバケット名を他アカウントに取られるリスクと空で残す判断
グローバル名前空間の汎用バケットを削除すると、その名前は誰でも作り直せるようになります。削除ページは、別のアカウントが同じ名前のバケットを作り、本来こちら宛てだったリクエストを受け取れてしまう危険を明記しています。ELBのアクセスログやCloudFrontのオリジン、アプリの設定ファイルに古いバケット名が残っていると、ログや利用者のアップロードが他人のバケットへ届きかねません。
外部から参照される可能性が少しでもある名前は、削除せずに空にして残し、バケットポリシーで全リクエストを拒否しておくのが安全です。空のバケットに保管料金はかかりません。この問題はアカウントリージョナル名前空間のバケットには起きないため、新規に作る分から切り替えておくと、将来の削除判断が楽になります。
バケット種類の選び方と汎用バケット以外を見送るべき場面の判断基準
種類が4つあっても、受託開発で扱う業務システムやWebサービスの大半は汎用バケットだけで足ります。どこで分けるかを先に決めておくと、作りすぎも作り直しも防げます。
受託開発でまず汎用バケット1つから始める条件と用途別に分ける境界
画像やPDFのアップロード、ログ、バックアップといった用途は、汎用バケット1つにプレフィックスで分けて置くところから始めます。バケットを分けるのは、次のどれかに当たるときです。
- 本番と検証で権限を完全に分けたい（環境ごとにバケットを分ける）
- 公開配信するファイルと非公開のファイルが混ざる（配信用を別にする）
- 保存期間やObject Lockなど、バケット単位の設定が用途で異なる
- リージョンを変える必要がある（データの所在の要件がある）
この4つに当たらないのに顧客ごとにバケットを作る設計は、上限より先に運用で破綻します。公開配信の作り方はAWS S3の使い方のCloudFront連携の章、ストレージクラスの選び方はAmazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金を参照してください。
ディレクトリバケットとベクトルバケットを採用しない2つの場面
ディレクトリバケットは、レイテンシが処理時間を直接左右しない用途では採用しません。単一のアベイラビリティーゾーンに閉じるうえ、ディレクトリバケットの概要によると90日以上リクエストが無いと非アクティブになり、再開までの数分は503が返ります。夜間バッチの中間ファイルを置く程度なら、汎用バケットのほうが障害にも放置にも強い構成です。
ベクトルバケットは、検索件数が多く応答時間に厳しい要件があるRAGでは第一候補にしません。長期保存と1秒未満の検索を安く両立させる設計で、件数の少ない社内文書検索には向きますが、1インデックスあたりの書き込みは毎秒1,000リクエストまでといった制限があります。要件の切り分けやAWS上の構成の設計から相談したい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で、既存システムの構成を踏まえた提案を受け付けています。
よくある質問
S3バケットについて検索されることの多い質問に、2026年10月時点の公式ドキュメントの記載をもとに答えます。
S3のバケットは1アカウントでいくつまで作れますか？
汎用バケットは既定で1アカウントあたり10,000個まで作れ、Service Quotasで引き上げを申請できます。かつての上限は100個で、古い解説記事にはその値が残っています。ディレクトリバケットは既定100、テーブルバケットは1リージョン100、ベクトルバケットは1リージョン10,000が既定値です。1つのバケットに入れられるオブジェクトの数と容量に上限はありません。
S3バケットの中にバケットやフォルダを作れますか？
バケットの中に別のバケットは作れません。汎用バケットの「フォルダ」は、reports/2026/のようにキーの先頭に付けたプレフィックスをコンソールが階層に見せているもので、実体のディレクトリはありません。実際の階層構造を持つのはディレクトリバケットで、区切り文字はスラッシュだけが使えます。
S3バケットの名前やリージョンは後から変更できますか？
どの種類のバケットも、作成後に名前とリージョンは変更できません。変えたい場合は新しいバケットを作り、aws s3 syncやS3 Batch Operationsで中身を移してから、古いバケットを空にして削除します。古い名前を外部から参照されている可能性があるなら、削除せず空のまま残す判断も検討してください。
S3バケットの容量を確認するにはどうすればよいですか？
CloudWatchのAWS/S3名前空間にあるBucketSizeBytesを見ます。更新頻度は1日1回で、旧バージョンや未完了のマルチパートアップロードも集計対象です。ストレージクラスごとにStorageTypeが分かれるため、標準IAやGlacierへ移したデータは別の値として確認します。小さなバケットならaws s3 ls --recursive --summarizeでもすぐに合計を出せます。
S3バケットが削除できないのはなぜですか？
多いのは、バケットが空になっていないケースです。バージョニングが有効だと旧バージョンと削除マーカーが残るため、コンソールの「空にする」かライフサイクルルールで消します。ほかに、同一アカウントのアクセスポイントが付いている、IAMやSCP、バケットポリシーにs3:DeleteBucketの拒否がある、といった原因もあります。
関連記事
- AWS S3の使い方｜CLIでのバケット作成から権限設計・署名付きURLまでの実装手順：命名規則と権限設計を含むS3全体の手順。
- Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説：バケットに入れるデータのストレージクラスの考え方。
- Amazon S3 Tablesとは？テーブルバケットの仕組みと東京リージョンの料金・作成手順【2026年版】：テーブルバケットを分析基盤で使う場合の詳細。
- S3の料金を実額で計算する｜東京リージョンの単価内訳とコストを下げる設定手順：容量とリクエストが請求に効く仕組み。
- aws s3 cpの使い方｜再帰コピー・フィルタ・ストリーム転送と終了コードの実装手順：作ったバケットへのファイル転送。
