AWS S3 NoSuchBucketエラーの修正: An error occurred (NoSuchBucket) when calling the operation

TL;DR

An error occurred (NoSuchBucket) when calling the operation が発生する原因は主に3つです：バケット名が間違っている、バケットが想定と異なるAWSリージョンにある、またはバケットが削除された場合です。まず名前を確認し、次にリージョンを確認してください。

# バケットが実際に存在するか確認
aws s3 ls s3://your-bucket-name

# 失敗する場合、実際の場所を調べる
aws s3api get-bucket-location --bucket your-bucket-name

根本原因

S3バケット名はグローバルに一意ですが、バケット自体はリージョン単位で管理されます。AWSが NoSuchBucket をスローする場合、クライアントがターゲットとしているリージョンで指定のバケットが見つからない状態です。バケットが存在しないか、SDKが誤ったリージョンのエンドポイントと通信している可能性があります。

操作によってエラーの表示形式が異なります：

An error occurred (NoSuchBucket) when calling the PutObject operation: The specified bucket does not exist
An error occurred (NoSuchBucket) when calling the GetObject operation: The specified bucket does not exist
An error occurred (NoSuchBucket) when calling the ListObjectsV2 operation: The specified bucket does not exist

約95%のケースは以下の5つの原因によるものです：

リージョンの不一致 — バケットが ap-southeast-1 にあるのに、クライアントが us-east-1 をターゲットにしている
バケット名のタイポ — 名前は大文字小文字を区別し、使用できるのはハイフンのみ（アンダースコア不可）
バケットが削除された — 誰かが terraform destroy を実行したか、チームメンバーが誤った環境をクリーンアップした
AWSアカウントの誤り — ステージング環境で認証しているが、バケットは本番環境にある
古い環境変数 — BUCKET_NAME が前四半期の古いバケットを指したまま

手順ごとの修正方法

Step 1 — バケットの存在を確認する

# アカウント内の全バケットを一覧表示
aws s3 ls

# 特定のバケットが存在するか確認
aws s3 ls s3://your-bucket-name 2>&& echo "EXISTS" || echo "NOT FOUND"

バケットが aws s3 ls に表示されない場合、削除されているか別のアカウントに存在しています。

Step 2 — バケットの実際のリージョンを特定する

aws s3api get-bucket-location --bucket your-bucket-name

出力例：

{
    "LocationConstraint": "ap-southeast-1"
}

null の場合、バケットは us-east-1 にあります — AWSはこの表現を使用します。SDKまたはCLIがこのリージョンと完全に一致していることを確認してください。

Step 3 — AWS CLIのリージョンを修正する

# コマンドごとにリージョンを明示的に指定
aws s3 cp file.txt s3://your-bucket-name/ --region ap-southeast-1

# またはセッション全体で固定する
export AWS_DEFAULT_REGION=ap-southeast-1

Step 4 — boto3（Python）のリージョンを修正する

import boto3

# リージョンをハードコード — 本番環境では環境のデフォルトに依存しない
s3 = boto3.client('s3', region_name='ap-southeast-1')

try:
    s3.put_object(Bucket='your-bucket-name', Key='test.txt', Body=b'hello')
except s3.exceptions.NoSuchBucket as e:
    print(f"Bucket not found: {e}")
except Exception as e:
    print(f"Other error: {e}")

Step 5 — AWS SDK for Node.jsのリージョンを修正する

const { S3Client, PutObjectCommand } = require('@aws-sdk/client-s3');

// リージョンを明示的に指定 — SDKの自動検出に頼らない
const s3 = new S3Client({ region: 'ap-southeast-1' });

try {
  await s3.send(new PutObjectCommand({
    Bucket: 'your-bucket-name',
    Key: 'test.txt',
    Body: 'hello',
  }));
} catch (err) {
  if (err.name === 'NoSuchBucket') {
    console.error('Bucket not found — check name and region');
  }
}

Step 6 — 削除されたバケットを再作成する

# 特定のリージョンに作成（us-east-1以外では必須）
aws s3api create-bucket \
  --bucket your-bucket-name \
  --region ap-southeast-1 \
  --create-bucket-configuration LocationConstraint=ap-southeast-1

# us-east-1は例外 — LocationConstraintを省略する
aws s3api create-bucket --bucket your-bucket-name --region us-east-1

注意点：別のAWSアカウントがそのバケット名をグローバルに所有している場合、BucketAlreadyExists が返されます。別の名前を選択してください — グローバルな一意性は回避できません。

Step 7 — 正しいアカウントにいることを確認する

aws sts get-caller-identity

出力：

{
    "UserId": "AIDA...",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/your-user"
}

アカウント番号が違う場合は、プロファイルを切り替えて再確認してください：

export AWS_PROFILE=production
aws sts get-caller-identity

Step 8 — 古い環境変数を調査する

# シェルが認識しているバケット情報を確認
echo $AWS_DEFAULT_REGION
echo $BUCKET_NAME
echo $S3_BUCKET

# Dockerで動作中の場合、コンテナ内を確認
docker exec your-container env | grep -i bucket
docker exec your-container env | grep -i aws

削除または名前変更されたバケットを指す古い環境変数は、多くの人が認めるより多くの本番インシデントを引き起こします。半年前のデプロイが静かに BUCKET_NAME=myapp-prod-old を設定し、誰も午前2時まで気づかなかったというケースは珍しくありません。

動作確認

インシデントをクローズする前に、フルラウンドトリップテストを実行してください：

# テストオブジェクトを書き込む
echo "test" | aws s3 cp - s3://your-bucket-name/healthcheck.txt --region ap-southeast-1

# 読み返す
aws s3 cp s3://your-bucket-name/healthcheck.txt - --region ap-southeast-1

# クリーンアップ
aws s3 rm s3://your-bucket-name/healthcheck.txt

3つのコマンドすべてがエラーなく成功しましたか？バケットにアクセスでき、設定は正常です。

予防策

すべてのSDKクライアントでリージョンをハードコードする — 自動検出はローカルでは便利ですが、本番環境では使用しない
バケット名はハードコードされた文字列ではなく、SSM Parameter StoreやSecrets Managerに保存する — タイポをなくし、ローテーションを容易にする
アプリの起動時またはヘルスチェックエンドポイントにバケット存在確認を追加する — 設定の不備をリクエスト処理中ではなく、起動時に早期検出できる
重要なバケットにS3バージョニングとMFA削除を有効にする — 誤った terraform destroy 一回でデータが永久に消えることを防ぐ
すべてのバケットに Environment（prod/staging）と Team タグを付ける — 深夜のインシデント対応時に、これらのタグが実際の時間節約になる