AWS S3の解説記事は数多くありますが、実際にバケットを1つ作る段になると、名前が3〜63文字であることも、作成直後に確認すべき設定も、署名付きURLが最大7日までしか延ばせないことも書かれていません。この記事ではAWS CLIとboto3で手を動かす前提に絞り、バケット作成・アップロード・同期・権限設計・署名付きURLの発行・ライフサイクルによる保管費の圧縮までを、実行できるコマンドと公式ドキュメントの数値で通します。AWSでS3を使う場面は単体の置き場にとどまらず、CloudFrontでの配信やLambdaによるアップロード後の処理と組み合わせる構成が実務の標準形なので、その接続部分の設定もコード付きで扱います。2026年3月に追加されたアカウントリージョナル名前空間も扱いました。S3そのものの仕組みやストレージクラスの選び方はAmazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説にまとめてあるため、本記事は実装側に集中します。
まとめ｜AWS S3を触る前に決める4項目と請求事故を防ぐ初期設定
先に結論を置きます。S3を使い始めるとき決めるのは、①バケット名の付け方（グローバル名前空間か、末尾-anのアカウントリージョナル名前空間か）、②リージョン、③公開の可否とブロックパブリックアクセスの4設定、④保管クラスとライフサイクルの4点です。この4つを先に決めておけば、後から取り返しがつかない項目はほぼ消えます。
取り返しがつかない項目も明示します。バケット名とリージョンは作成後に変更できません。既存バケットをアカウントリージョナル名前空間へ改名することもできません。名前を間違えたら作り直しです。
請求事故の入口も先に潰します。S3 Standard-IAとOne Zone-IAは最小保存期間30日・最小課金サイズ128KB、Glacier Instant Retrievalは90日、Deep Archiveは180日です。小さいファイルを大量に置いてライフサイクルで即日IAへ送ると、30日分の料金と128KB分の切り上げが二重に効いて、移行前より高くつきます。東京リージョンの実単価と月額の試算はS3の料金を実額で計算する｜東京リージョンの単価内訳とコストを下げる設定手順にまとめました。
オブジェクト単位で保管するS3の構造とバケット命名規則の実数
S3はファイルシステムではありません。ディレクトリは存在せず、キー文字列に含まれる/を画面上の区切りとして見せているだけです。この構造の差が、命名とパフォーマンス設計の両方に効いてきます。
バケット・オブジェクト・プレフィックスの3要素と1秒あたりの上限値
S3の登場人物は、入れ物であるバケット、実体であるオブジェクト、キーの先頭部分であるプレフィックスの3つです。公式ドキュメントのS3概要にある通り、オブジェクトはデータ本体とメタデータの組で、キーはバケット内で一意になります。
プレフィックスは見た目のフォルダではなく、性能の単位です。パフォーマンスのベストプラクティスには、分割されたプレフィックスごとに毎秒3,500回のPUT/COPY/POST/DELETE、5,500回のGET/HEADを最低でも処理できると書かれています。プレフィックスの数に上限はありません。10本に分ければ読み取りは毎秒55,000回まで伸びる計算です。
1オブジェクトの大きさにも上限があります。マルチパートアップロードの上限表では、最大オブジェクトサイズは48.8TiB、1回のアップロードで使えるパートは最大10,000個、パートサイズは5MiB〜5GiBです（2026年9月時点の記載）。100MBに達したらマルチパートを検討するよう公式が案内しており、後述するaws s3 cpは閾値を超えると自動で分割します。古い解説に残る「S3は最大5TB」は、現行の上限ではありません。
全ファイルをキー直下にフラットに置くと、スケール中に503（Slow Down）が返り始めます。日付やテナントIDでプレフィックスを割る設計は、見た目の整理ではなく上限の分散が狙いです。構造の背景はオブジェクトストレージとは？仕組みとS3互換API・ブロックとの違いを実装視点で解説にまとめてあります。
3〜63文字と予約サフィックスに縛られるバケット名の付け方の実務
バケット名の規則は命名規則のページに列挙されています。数値だけ拾うと、長さは3文字以上63文字以下、使える文字は小文字英字・数字・ピリオド・ハイフンのみ、先頭と末尾は英字か数字です。アンダースコアと大文字は通りません。
落とし穴は予約された接頭辞・接尾辞のほうです。xn--、sthree-、amzn-s3-demo-で始まる名前は作れません。末尾も-s3alias（アクセスポイント）、--ol-s3（Object Lambda）、.mrap（マルチリージョンアクセスポイント）、--x-s3（ディレクトリバケット）、--table-s3（S3 Tables）が予約済みです。
ピリオドは避けてください。名前に含めると仮想ホスト形式のHTTPSアクセスで証明書の検証が通らず、Transfer Accelerationも使えなくなります。
汎用・ディレクトリ・テーブル・ベクトルの4種類で名前が一意になる範囲の違い、種類ごとのバケット数の上限、削除した名前を他アカウントに取られるリスクはS3バケットの4種類と管理手順｜作成・一覧・容量確認から上限数と削除までで整理しています。
AWS CLIで通すバケット作成・アップロード・同期の実行手順
ここからは実際のコマンドです。前提としてAWS CLI v2が入っていること、aws configureまたはaws sso loginで認証が通っていることを確認してください。導入と認証の詳細はAWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順にあります。
create-bucketでのリージョン指定と作成直後に確認する3設定
東京リージョンにバケットを作る場合、--regionだけでは足りません。create-bucketのリファレンスにある通り、us-east-1以外ではLocationConstraintを明示する必要があります。
aws s3api create-bucket \
--bucket example-app-assets-20260908 \
--region ap-northeast-1 \
--create-bucket-configuration LocationConstraint=ap-northeast-1
aws s3api get-public-access-block --bucket example-app-assets-20260908
aws s3api put-bucket-versioning --bucket example-app-assets-20260908 \
--versioning-configuration Status=Enabled
aws s3api get-bucket-encryption --bucket example-app-assets-20260908作成直後に見るのは、ブロックパブリックアクセスの状態、バージョニング、既定の暗号化の3つです。新規バケットは公開を許さない状態で作られますが、後からポリシーで開けてしまえるため、意図した状態かをコマンドで確かめておきます。
cpとsyncの使い分けとマルチパート閾値8MBを変える調整方法
s3コマンドのリファレンスにあるcpは単発のコピー、syncは差分同期です。syncはサイズと更新時刻を比較して変更分だけ転送するため、静的ファイルの配布やバックアップの再実行はこちらが向きます。
aws s3 cp ./dist/index.html s3://example-app-assets-20260908/index.html
aws s3 sync ./dist s3://example-app-assets-20260908/static \
--delete --exclude "*.map"
aws configure set default.s3.multipart_threshold 64MB
aws configure set default.s3.multipart_chunksize 16MB
aws configure set default.s3.max_concurrent_requests 20転送が遅いときに触るのは並列度と分割サイズです。CLIのS3設定の既定値は、同時リクエスト10、キュー1,000、マルチパート閾値8MB、チャンクサイズ8MB、帯域上限なし。大きいファイルを少数扱うならチャンクを16MB以上へ、小さいファイルを大量に扱うなら並列度を上げます。--deleteは転送先にしか無いファイルを消すため、本番前に--dryrunで確認してください。
フィルタの評価順、標準入力からのストリーム転送、終了コード1と2の違いなどcpの細かな挙動はaws s3 cpの使い方｜再帰コピー・フィルタ・ストリーム転送と終了コードの実装手順で手順ごとに整理しています。
s3コマンドとs3apiコマンドの守備範囲の違いと使い分け基準
CLIにはS3向けの系統が2つあります。aws s3はcp・mv・sync・lsといった高レベル操作で、マルチパート分割や並列転送を内部で面倒みてくれます。一方aws s3apiはREST APIと1対1で、put-bucket-policyやput-bucket-lifecycle-configurationのようなバケット設定はこちらにしかありません。
使い分けの基準は単純です。ファイルを動かすならaws s3、バケットの設定を書き換えるならaws s3api。スクリプトで結果をJSONとして受け取りjqで処理したい場合もs3api側になります。
aws s3 lsは1,000件ごとのページングを裏で処理するため、数百万オブジェクトのバケットで全件を舐めると時間もリクエスト料金もかかります。棚卸しならS3 Inventoryで日次レポートを出すほうが安く済みます。
ブロックパブリックアクセス4設定とIAMで組むS3権限設計の実務
S3の事故報道はほぼ全て権限設定の誤りです。設定の名前が似ていて効き方が違うため、4つの違いを押さえないまま「とりあえず全部オン」にすると、必要な配信まで止まります。
ブロックパブリックアクセス4設定それぞれの効き方と適用範囲の差
ブロックパブリックアクセスのドキュメントによれば、4設定はそれぞれ独立して働きます。
BlockPublicAcls：公開ACLを含むPutObjectやPutBucketAclの呼び出し自体を失敗させる。既存のACLは書き換えないIgnorePublicAcls：バケットと配下オブジェクトの公開ACLを無視する。設定の投入は許すが効果を消すBlockPublicPolicy：公開を許すバケットポリシーのPutBucketPolicyを拒否する。既存ポリシーには触れないRestrictPublicBuckets：公開ポリシーを持つバケットへのアクセスを、AWSサービスプリンシパルと所有アカウント内の利用者だけに絞る
ACL系の2つは「入口で弾く」か「効果を無効化する」かの差、ポリシー系の2つは「新しい公開ポリシーを拒む」か「すでに公開なバケットの到達範囲を縮める」かの差です。組織全体で公開を封じるならアカウント単位で4つとも有効化します。バケット単位とアカウント単位で設定が食い違う場合、厳しいほうが採用されます。
バケットポリシーとIAMポリシーの役割分担と最小権限の書き方
誰に許すかをアカウント側から書くのがIAMポリシー、リソース側から書くのがバケットポリシーです。クロスアカウントやCloudFrontからの到達制御には後者を使います。構造はAWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説で扱っています。
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowAppRoleReadWritePrefix",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:role/app-runtime" },
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::example-app-assets-20260908/tenant-a/*",
"Condition": { "Bool": { "aws:SecureTransport": "true" } }
}]
}書き方で外せない点が3つあります。Resourceをバケット全体ではなくプレフィックスまで絞ること、s3:*ではなく必要な動詞だけ並べること、aws:SecureTransportでHTTPを弾くこと。ListBucketだけはオブジェクトではなくバケットARNに対して与える点も間違えやすい箇所です。
ACLを既定で無効にするObject Ownershipと400エラーになる書き込み
新規バケットはS3 Object Ownershipが「バケット所有者の強制（Bucket owner enforced）」で作られ、ACLは無効です。誰が書き込んでもオブジェクトはバケット所有者のものになり、アクセス可否はIAMポリシーとバケットポリシーだけで決まります。
影響が出るのは、古いサンプルコードやアップロード用ライブラリがpublic-readなどのACLを付けてPutObjectを呼ぶ場合です。ACL無効のバケットが受け付けるのは、ACLを指定しない書き込みとbucket-owner-full-control付きの書き込みだけ。それ以外はAccessControlListNotSupportedの400エラーで失敗します。既存システムを新しいバケットへ移した直後にアップロードだけが落ちるなら、まずコード側のACL指定を疑ってください。
aws s3api get-bucket-ownership-controls --bucket example-app-assets-20260908出力のObjectOwnershipがBucketOwnerEnforcedなら既定どおりです。他のAWSアカウントへオブジェクトを渡す要件があっても、ACLを戻すのではなくバケットポリシーで許可する方針を取ります。
既定の暗号化とバージョニングで決まる誤削除・漏えいの復旧余地
既定の暗号化はSSE-S3で有効です。監査要件でキー管理の記録が要るならSSE-KMSへ切り替えますが、KMSのリクエスト課金と秒間クォータが乗ります。小さいオブジェクトを大量に読み書きするならバケットキーを有効にして呼び出し回数を減らしてください。
バージョニングは一度有効にすると停止（Suspended）はできても無効には戻せません。有効時の削除は削除マーカーを置くだけで実体が残るため、誤削除から戻せる代わりに消したつもりのデータへ課金が続きます。旧バージョンの失効ルールはセットで入れるものと考えてください。
署名付きURLとSDKでアプリからファイルを受け渡す実装手順
バケットを公開せずにファイルを渡す標準的な方法が署名付きURLです。バケットポリシーを開けずに済むため、権限設計を壊さないまま一時的な配布ができます。
CLIで最大7日・コンソールで最大12時間という有効期限の上限
署名付きURLのドキュメントには上限が明記されています。AWS CLIから発行した場合の最大は作成時点から7日、マネジメントコンソールから発行した場合は12時間です。コンソールで共有できるオブジェクトは5TBまでと記されています。
aws s3 presign s3://example-app-assets-20260908/report.pdf \
--expires-in 604800 --region ap-northeast-1--expires-inの単位は秒で、604800秒がちょうど7日です。見落とされやすいのは権限の寿命との関係で、URLに埋まるのは発行者の認証情報になります。ロールの一時認証情報から発行すると、セッションが切れた時点でURLも死にます。7日と指定してもセッションが1時間なら1時間です。長期配布が要るならAmazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断を実装者目線で解説で扱う署名付きURLへ寄せる判断になります。
boto3のgenerate_presigned_urlでアップロードまで任せる書き方
アプリから発行するならboto3のS3クライアントを使います。ダウンロード用はget_object、ブラウザからの直接アップロード用はput_objectをメソッド名に渡します。
import boto3
s3 = boto3.client("s3", region_name="ap-northeast-1")
download_url = s3.generate_presigned_url(
ClientMethod="get_object",
Params={"Bucket": "example-app-assets-20260908", "Key": "tenant-a/report.pdf"},
ExpiresIn=900,
)
upload_url = s3.generate_presigned_url(
ClientMethod="put_object",
Params={
"Bucket": "example-app-assets-20260908",
"Key": "tenant-a/upload/raw.csv",
"ContentType": "text/csv",
},
ExpiresIn=300,
)アップロード用URLでは、Paramsに入れたContentTypeをクライアント側のリクエストヘッダと一致させてください。ずれると署名検証で403が返ります。サイズ制限をかけたいときはgenerate_presigned_postを使い、Conditionsにcontent-length-rangeを指定してください。ブラウザからS3へ直接送れるため、大きなファイルの受け取りでアプリサーバーのメモリと帯域を消費せずに済みます。
AWSの他サービスとS3をつなぐCloudFront配信とLambdaのイベント処理
AWSでS3を使う案件の大半は、S3単体では完結しません。静的ファイルや利用者がアップロードした画像はCloudFront経由で配信し、アップロードを合図にLambdaでサムネイル生成やCSVの取り込みを走らせる構成が典型です。ここでは両者をつなぐ設定を、公式ドキュメントの例に沿って示します。
CloudFrontのOACで非公開バケットのまま配信するバケットポリシー
CloudFrontのS3オリジン制限のドキュメントは、従来のOAI（オリジンアクセスアイデンティティ）ではなくOAC（オリジンアクセスコントロール）を推奨しています。OACはSSE-KMSで暗号化したオブジェクトと、PUT・DELETEのような動的リクエストに対応し、2022年12月以降に追加されたオプトインリージョンでも使えます。OAIはこの3点に対応していません。
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowCloudFrontServicePrincipalReadOnly",
"Effect": "Allow",
"Principal": { "Service": "cloudfront.amazonaws.com" },
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-app-assets-20260908/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
}
}
}]
}PrincipalはIAMロールではなくcloudfront.amazonaws.comというサービスプリンシパルで、AWS:SourceArnの条件によって自分のディストリビューションだけに絞ります。この条件を外すと、他人が作ったディストリビューションからも読める状態になります。OACを使うときはObject Ownershipを既定の「バケット所有者の強制」にしておく必要があり、静的ウェブサイトホスティングのエンドポイントをオリジンにした構成ではOACを使えません。SSE-KMSで暗号化している場合は、KMSのキーポリシーにも同じ条件でCloudFrontの復号を許可する文を足します。
S3イベント通知でLambdaを起動する設定と自己呼び出しループの回避
S3イベント通知は、オブジェクトの作成・削除・復元やライフサイクルによる移行などを、SNS・SQS・Lambda・EventBridgeへ送る機能です。関数の実行モデルと課金はAWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説、複数の宛先へ振り分ける設計はAmazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説で扱っています。
aws lambda add-permission \
--function-name thumbnail-generator \
--statement-id s3-invoke \
--action lambda:InvokeFunction \
--principal s3.amazonaws.com \
--source-arn arn:aws:s3:::example-app-assets-20260908 \
--source-account 111122223333
# notification.json
{
"LambdaFunctionConfigurations": [{
"Id": "incoming-to-thumbnail",
"LambdaFunctionArn": "arn:aws:lambda:ap-northeast-1:111122223333:function:thumbnail-generator",
"Events": ["s3:ObjectCreated:*"],
"Filter": { "Key": { "FilterRules": [{ "Name": "prefix", "Value": "incoming/" }] } }
}]
}
aws s3api put-bucket-notification-configuration \
--bucket example-app-assets-20260908 \
--notification-configuration file://notification.json外せない点は2つあります。1つ目は宛先側の権限です。Lambdaのリソースベースポリシーにs3.amazonaws.comからの呼び出し許可が無いと、通知設定の投入そのものが検証エラーで失敗します。2つ目がループの回避です。Lambdaの開発者ガイドは、トリガー元と同じバケットへ関数が書き込むと関数が自分自身を間接的に呼び続けると警告し、バケットを分けるか、受け付け用のプレフィックスだけをトリガー対象にする方法を示しています。上の例でincoming/に絞り、生成物をthumbnails/へ書き出す設計にしているのはこのためです。
配信の性質も設計に響きます。通知は少なくとも1回届く設計で、通常は数秒、ときに1分以上遅れます。同じイベントが2回届いても結果が変わらないよう、処理側はキーとETagで処理済みかを判定してください。SQSのFIFOキューは直接の宛先に指定できないため、順序を保ちたい場合はEventBridgeを経由させます。
ストレージクラスとライフサイクルで決まるS3保管コストの構造
S3の請求はストレージ容量だけでは決まりません。クラスごとの最小保存期間と最小課金サイズ、そしてリクエスト数が乗ります。ここを外すと、安いクラスへ移したのに請求が増えるという逆転が起きます。
最小保存期間30日・最小課金128KBが効くクラス移行の損益分岐
ストレージクラスの比較表に、判断に必要な数値が揃っています。以下の表ではクラス名の接頭辞「S3」を省き、アーカイブ系はS3 Glacier Instant Retrieval・S3 Glacier Flexible Retrieval・S3 Glacier Deep Archiveの正式名を短く記しました。
| S3ストレージクラス | 可用性設計値 | AZ数 | 最小保存期間 | 最小課金サイズ | 取り出し料金 |
|---|---|---|---|---|---|
| Standard | 99.99% | 3以上 | なし | なし | なし |
| Intelligent-Tiering | 99.9% | 3以上 | なし | なし | なし（監視料あり） |
| Standard-IA | 99.9% | 3以上 | 30日 | 128KB | あり |
| One Zone-IA | 99.5% | 1 | 30日 | 128KB | あり |
| Glacier Instant | 99.9% | 3以上 | 90日 | 128KB | あり |
| Glacier Flexible | 99.99%（復元後） | 3以上 | 90日 | 40KBを加算 | あり |
| Glacier Deep Archive | 99.99%（復元後） | 3以上 | 180日 | 40KBを加算 | あり |
損益分岐の判断はこうです。平均サイズが128KBを大きく下回るならIA系へ移す意味はありません。10KBのファイルを100万個送ると課金上は128KB×100万個として扱われ、容量が12.8倍に膨らみます。アクセス頻度が読めない資産はIntelligent-Tieringに預けるほうが安全でしょう。128KB未満は監視対象外のまま高頻度層に残ります。取り出し時間の差はAmazon S3 Glacierとは？3つのアーカイブストレージクラスと取り出し時間・料金・採用判断を実装者目線で解説で比較しています。
ライフサイクルルールで移行と失効を自動化するJSONの設定例
移行と削除の自動化はライフサイクル設定で書きます。構成例のページにあるJSONを、ログ保管の典型形に落とすと次のようになります。
{
"Rules": [{
"ID": "logs-tiering-and-expiry",
"Filter": { "Prefix": "logs/" },
"Status": "Enabled",
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 180, "StorageClass": "GLACIER_IR" }
],
"Expiration": { "Days": 1095 },
"NoncurrentVersionExpiration": { "NoncurrentDays": 90 }
}]
}投入はaws s3api put-bucket-lifecycle-configuration --bucket <name> --lifecycle-configuration file://lifecycle.jsonです。落とし穴はNoncurrentVersionExpirationで、バージョニングを有効にしているのにこれを書かないと、削除したはずのデータが旧バージョンとして残り、課金され続けます。
2026年3月追加のアカウントリージョナル名前空間で変わる命名設計
ここが本記事の独自論点です。S3のバケット名は長年、全AWSアカウント・全リージョンで一意という制約を背負ってきました。2026年3月にこの前提が変わり、既存の解説記事の記述が古くなっています。
末尾-anとx-amz-bucket-namespaceヘッダで作る新しいバケット
2026年3月12日のAWS公式ブログで、汎用バケット向けのアカウントリージョナル名前空間が発表されました。名前空間のドキュメントによれば、バケット名は{プレフィックス}-{12桁のアカウントID}-{リージョン}-anという形式を取り、この名前空間の中では自分のアカウントしかバケットを作れません。
aws s3api create-bucket \
--bucket app-assets-111122223333-ap-northeast-1-an \
--bucket-namespace account-regional \
--region ap-northeast-1 \
--create-bucket-configuration LocationConstraint=ap-northeast-1API側ではx-amz-bucket-namespace: account-regionalヘッダ、boto3ではBucketNamespaceパラメータ、CloudFormationではBucketNamespace: "account-regional"が対応します。全長3〜63文字の制約は従来どおりで、37リージョンで使え、追加料金はかかりません。組織として強制するなら、IAMのs3:x-amz-bucket-namespace条件キーでこの名前空間以外への作成を拒否できます。
既存バケットは改名不可という制約と移行時に取るべき現実的な手順
制約もはっきりしています。既存のグローバル名前空間のバケットを、そのままアカウントリージョナル名前空間へ改名することはできません。移すなら新規に作って中身をコピーし、参照側を切り替える作業が要ります。
ここは判断が分かれます。稼働中のバケットを名前空間の統一だけのために移すのは、aws s3 syncの転送費とアプリ側の参照差し替えに見合いません。一方、これから作る環境は新方式を既定にする価値があります。app-assets-111122223333-ap-northeast-1-anとapp-assets-444455556666-ap-northeast-1-anが並立できるため、ステージングと本番でプレフィックス名を揃えられ、Terraformのモジュールに乱数サフィックスを埋め込まずに済みます。
削除済みバケット名を第三者に取得され、旧名宛てのリクエストを受け取られる懸念もこの名前空間なら消えます。マルチアカウント構成の案件では、新規バケットを末尾-anで作る方針にしてよい段階です。
AWS S3を採用する条件と別のストレージへ寄せる場面の判断基準
最後に線引きをします。S3は汎用のオブジェクトストレージとして守備範囲が広い一方、向かない使い方も明確です。
受託開発の現場でS3を第一候補にする条件と見送るべき2つの場面
第一候補にする条件は3つ。ファイル単位で読み書きが完結すること、AWS内の他サービス（CloudFront・Lambda・Athena・Glue）と接続する予定があること、保管期間が年単位で伸びる見込みがあること。これが揃うならストレージ設計で悩む時間のほうが高くつきます。S3に置いたログやCSVをサーバーを立てずにSQLで集計する構成はAmazon Athena（アテナ）とは？使い方・クエリの書き方・料金・Redshiftとの違いを解説で扱っています。
見送る場面は2つです。1つ目は、既存アプリケーションがPOSIXのファイルシステムを前提に、ファイルの一部だけを書き換える処理を持っている場合。S3のオブジェクトは部分更新ができず、1バイト変えるだけでも全体を再アップロードするため、Amazon EFSやFSxのほうが素直です。2つ目は、頻繁に読み出すデータをインターネットへ大量配信する場合。請求は保管より外向き通信で膨らむため、CloudFrontを前段に置く設計が要ります。バケット設計・権限設計・ライフサイクルまで含めて構成を固めたい場合は、インフラ構築（AWS・Google Cloud・Azure）で要件整理から対応しています。
よくある質問
AWS S3の実装で検索されている質問に、公式ドキュメントの記載をもとに答えます。
S3のバケット名に使える文字と長さの制限は何ですか？
3文字以上63文字以下で、小文字の英字・数字・ピリオド・ハイフンだけが使えます。先頭と末尾は英字か数字で、ピリオドの2連続もIPアドレス形式も通りません。xn--・sthree-・amzn-s3-demo-で始まる名前と、-s3alias・--ol-s3・.mrap・--x-s3・--table-s3で終わる名前は予約済みです。作成後に名前もリージョンも変更できないため、命名は最初に決め切ってください。
aws s3コマンドとaws s3apiコマンドはどう使い分けますか？
ファイルを動かす操作はaws s3、バケットの設定を書き換える操作はaws s3apiです。前者はマルチパート分割と並列転送を内部で処理する高レベルコマンド、後者はREST APIと1対1に対応します。バケットポリシー、ライフサイクル、バージョニング、ブロックパブリックアクセスの設定はすべてs3api側にしかありません。
S3の署名付きURLは何日まで有効にできますか？
AWS CLIで発行する場合の上限は作成時点から7日間（604800秒）、マネジメントコンソールからは12時間です。ただしURLに紐づくのは発行者の認証情報なので、ロールの一時認証情報から発行するとセッション切れと同時に無効になります。7日と指定しても実際には1時間で使えなくなる場合があるということです。
S3のストレージクラスを変えたのに料金が下がらないのはなぜですか？
最小保存期間と最小課金サイズが効いている可能性が高いです。Standard-IAとOne Zone-IAは30日・128KB、Glacier Instant Retrievalは90日・128KB、Deep Archiveは180日が下限で、下回っても下限分が請求されます。加えて移行操作そのものにオブジェクト単位のリクエスト料金がかかるため、小さいファイルを大量に移すルールは移行費だけで赤字になります。
バケット名の重複を避けるにはどうすればよいですか？
2026年3月に追加されたアカウントリージョナル名前空間を使うと、{プレフィックス}-{アカウントID}-{リージョン}-an形式の名前が自分のアカウント専用になり、衝突が起きなくなります。aws s3api create-bucketに--bucket-namespace account-regionalを付けて作成します。追加料金はなく37リージョンで使えますが、既存バケットの改名はできません。従来の名前空間で作る場合は、末尾にGUIDを付ける方法が公式ドキュメントで推奨されています。
関連記事
- Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説：S3の概念とクラス選定の判断はこちらに。
- AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説：バケットポリシーの前提になる権限設計。
- AWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順：本記事のコマンドを動かす前段の環境構築。
- Amazon S3 Glacierとは？3つのアーカイブストレージクラスと取り出し時間・料金・採用判断を実装者目線で解説：アーカイブ移行先の取り出し時間の比較。
- オブジェクトストレージとは？仕組みとS3互換API・ブロックとの違いを実装視点で解説：S3互換APIとブロックストレージとの構造差。
