S3に「アカウントリージョナル名前空間」が登場 — バケット名の奪取リスクに終止符を打つ新機能

AWSAmazon S3セキュリティバケット名前空間Namesquatting対策
Amazon S3 introduces account regional namespaces for general purpose buckets - AWS Discover more about what aws.amazon.com
Introducing account regional namespaces for Amazon S3 general purpose buckets | Amazon Web Services AWS launches a new feature of Amazon S3 that lets you create general purpose buckets in your own acc... aws.amazon.com
Namespaces for general purpose buckets - Amazon Simple Storage Service Learn about the global and account regional namespaces for Amazon S3 general purpose buckets. docs.aws.amazon.com

S3の汎用バケットにアカウントリージョナル名前空間（Account Regional Namespace）が導入されました（2026年3月12日 AWS What’s New）。自分のアカウント専用の名前空間でバケットを作成でき、他のアカウントがそのバケット名を使用することは不可能になります。

S3のバケット名がグローバルでユニークでなければならないという制約は、2006年のS3ローンチ以来ずっと変わっていませんでした。この制約がセキュリティ上の問題を引き起こしてきたことは、AWSを使っている方なら一度は耳にしたことがあると思います。今回のアップデートは、その根本的な問題に対するAWSの回答です。

バケット名のグローバルユニーク制約が生んでいた問題

従来のS3では、バケット名はAWSパーティション全体でグローバルにユニークである必要がありました。つまり、誰かが my-app-logs というバケットを作成したら、世界中の他のアカウントでは同じ名前を使えません。さらに問題なのは、バケットを削除するとその名前が再び誰でも使える状態に戻ることです。

この仕様を悪用した攻撃がS3 Bucket Namesquatting（バケット名占拠）です。

CDKのデフォルト命名パターンが引き起こした脆弱性

2024年に報告された事例が、この問題の深刻さをよく示しています（2024年10月24日 Aqua Security）。

AWS CDKのブートストラップ（cdk bootstrap）は、デプロイに必要な2つのリソースを作成します。

  1. ステージングS3バケット: cdk-hnb659fds-assets-{AccountID}-{Region} という予測可能な命名パターン
  2. IAMロール群: このバケットを名前で信頼する（FilePublishingRole、DeploymentActionRoleなど）

攻撃は以下の流れで成立します。

  1. 被害者がCDKブートストラップを実行し、バケットとIAMロールが作成される
  2. 何らかの理由でバケットが削除される（環境クリーンアップ、アカウント整理など）。IAMロールは残ったまま
  3. 攻撃者がアカウントIDとリージョンからバケット名を予測し、自分のアカウントに同名のバケットを作成する
  4. 被害者が cdk deploy を実行する。CDKはバケット名だけで判断するため、攻撃者のバケットにCloudFormationテンプレートとLambdaのコードをアップロードしてしまう
  5. 攻撃者はバケットのオーナーなので、アップロードされたテンプレートを読み取り・改ざんできる。たとえばAdminAccess付きのIAMロールを追加する
  6. CloudFormationが改ざんされたテンプレートを取得してデプロイし、被害者のアカウントに攻撃者のバックドアが作成される

ここで重要なのは、CDKが作成するIAMロールがバケットの「所有者」ではなく「名前」を信頼しているという点です。バケットが別のアカウントに存在していても、名前が一致すればCDKはそのまま動作してしまいます。

AWSはCDK v2.149.0でFilePublishingRoleに条件を追加し、自アカウントのバケットのみを信頼するように修正しました。しかし、根本原因は「バケット名がグローバルでユニーク」かつ「予測可能」であるという構造的な問題にありました。AWSの発表によると、CDKユーザーの約1%がこの影響を受けていたとのことです。

削除後の名前再利用リスク

CDKに限らず、バケット名の再利用自体が広いリスクを持っています。バケットを削除すると、その名前は再びグローバル名前空間で誰でも使える状態に戻ります。

たとえば、アプリケーションが my-company-config というバケットを参照している状態でバケットを削除すると、攻撃者がその名前を即座に取得し、悪意のあるコンテンツを配置できてしまいます。アプリケーション側がバケット名をハードコードしていたり、DNSやCloudFormationのOutputsで参照していたりすると、気づかないうちに攻撃者のバケットからデータを読み取ることになります。

アカウントリージョナル名前空間の仕組み

新しいアカウントリージョナル名前空間では、バケット名にアカウントID・リージョン・-anサフィックスを含めることで、自分のアカウント専用の名前空間にバケットを作成します。

公式ドキュメントには以下のように記載されています（AWS Documentation）。

Creating buckets in your account regional namespace is a security best practice. These bucket names can only ever be used by your account. You can have assurance that no other account can create bucket names in your namespace.

命名規則

バケット名のフォーマットは以下のとおりです。

{プレフィックス}-{アカウントID}-{リージョン}-an

たとえば、アカウントID 123456789012 で us-west-2 リージョンに my-app-logs というプレフィックスのバケットを作る場合、バケット名は以下になります。

my-app-logs-123456789012-us-west-2-an

末尾の -an は「Account Regional Namespace」を示す固定サフィックスです。このサフィックスを含むバケット名は、そのアカウントID・リージョンの組み合わせを持つアカウントからしか作成できません。

63文字制限への影響

注意が必要なのは、アカウントリージョナルサフィックスがバケット名の63文字制限に含まれることです。たとえばサフィックスが -012345678910-us-east-1-an（26文字）の場合、プレフィックスに使えるのは37文字になります。ap-northeast-1 のようなリージョンコードが長い場合はさらに短くなり、-012345678910-ap-northeast-1-an（32文字）で残り31文字です。

従来のグローバル名前空間との比較

項目グローバル名前空間アカウントリージョナル名前空間
バケット名の一意性パーティション全体でグローバルにユニーク自分のアカウント内でのみユニーク
削除後の名前再利用誰でも同じ名前で再作成可能自分のアカウントでのみ再作成可能
命名の自由度任意の名前（空いていれば）プレフィックス + 固定サフィックス
同名バケットの複数リージョン作成不可能同じプレフィックスで複数リージョンに作成可能
S3機能の対応すべてすべて（同等）

特に「同じプレフィックスで複数リージョンに作成可能」という点は、マルチリージョン構成において非常に便利です。従来はリージョンごとに異なるバケット名を考える必要がありましたが、アカウントリージョナル名前空間では my-app-data-{AccountID}-{Region}-an のように統一的な命名が可能になります。

IAM/SCPによるポリシー制御

セキュリティチームにとって最も重要な機能の1つが、ポリシーによるアカウントリージョナル名前空間の強制です。

新しい条件キー s3:x-amz-bucket-namespace を使うことで、アカウントリージョナル名前空間以外でのバケット作成を禁止できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireAccountRegionalBucketCreation",
      "Effect": "Deny",
      "Action": "s3:CreateBucket",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-bucket-namespace": "account-regional"
        }
      }
    }
  ]
}

このポリシーはIAMポリシー、SCP（Service Control Policy）、RCP（Resource Control Policy）のいずれでも使用できます。Organizations全体でこのSCPを適用すれば、組織内のすべてのアカウントでアカウントリージョナル名前空間の使用を強制できます。

自分はこの条件キーの追加が今回のアップデートで一番評価している点です。機能を提供するだけでなく、ガバナンスとして「使わせる」仕組みまで用意しているのは、セキュリティ設計として正しいアプローチだと思います。

実際に試してみた

自分の環境でアカウントリージョナル名前空間のバケットを作成し、挙動を確認してみました。

  • AWS CLI: aws-cli/2.34.8（--bucket-namespace オプションは2.34.8で追加。CHANGELOG 2.34.8）
  • リージョン: ap-northeast-1

バケットの作成

aws s3api create-bucket \
  --profile your-profile \
  --bucket my-app-bucket-123456789012-ap-northeast-1-an \
  --bucket-namespace account-regional \
  --region ap-northeast-1 \
  --create-bucket-configuration LocationConstraint=ap-northeast-1
{
    "Location": "http://my-app-bucket-123456789012-ap-northeast-1-an.s3.amazonaws.com/",
    "BucketArn": "arn:aws:s3:::my-app-bucket-123456789012-ap-northeast-1-an"
}

問題なく作成できました。レスポンスにはBucketArnも返ってきます。ARNの形式は従来のバケットと同じです。

他アカウントのサフィックスでの作成を試みる

アカウントIDが異なるサフィックスでバケットを作成しようとすると、明確なエラーが返ります。

aws s3api create-bucket \
  --profile your-profile \
  --bucket my-app-bucket-999999999999-ap-northeast-1-an \
  --bucket-namespace account-regional \
  --region ap-northeast-1 \
  --create-bucket-configuration LocationConstraint=ap-northeast-1
An error occurred (InvalidBucketNamespace) when calling the CreateBucket operation:
The requested bucket is an account-regional namespace bucket, but the requested
AWS Account ID '999999999999' does not match the caller's AWS Account ID
'123456789012'. Specify the caller's AWS Account ID in the bucket name.

エラーメッセージが非常に親切で、何が間違っているかが明確にわかります。

リージョン不一致のサフィックスでの作成を試みる

サフィックスのリージョンと実際のリクエスト先リージョンが異なる場合もエラーになります。

aws s3api create-bucket \
  --profile your-profile \
  --bucket my-app-bucket-123456789012-us-west-2-an \
  --bucket-namespace account-regional \
  --region ap-northeast-1 \
  --create-bucket-configuration LocationConstraint=ap-northeast-1
An error occurred (InvalidBucketNamespace) when calling the CreateBucket operation:
The requested bucket is an account-regional namespace bucket, but the requested
region 'us-west-2' does not match the current region 'ap-northeast-1'.
Specify the targeted region in the bucket name.

—bucket-namespaceヘッダーなしでの作成を試みる

-an サフィックスを持つバケット名を --bucket-namespace オプションなしで作成しようとすると、ヘッダーが必要であることをエラーで教えてくれます。

aws s3api create-bucket \
  --profile your-profile \
  --bucket my-app-bucket-123456789012-ap-northeast-1-an \
  --region ap-northeast-1 \
  --create-bucket-configuration LocationConstraint=ap-northeast-1
An error occurred (MissingNamespaceHeader) when calling the CreateBucket operation:
The requested bucket is an account-regional namespace bucket, but your request
is missing the required x-amz-bucket-namespace header.

つまり、-an サフィックスのパターンに一致するバケット名はS3側で自動的にアカウントリージョナル名前空間のバケットとして認識され、ヘッダーが必須になります。従来のグローバル名前空間で -an 末尾のバケットを作ることはできなくなっているわけです。

同じプレフィックスで別リージョンに作成

同じプレフィックス my-app-bucket で us-east-1 にもバケットを作成してみました。

aws s3api create-bucket \
  --profile your-profile \
  --bucket my-app-bucket-123456789012-us-east-1-an \
  --bucket-namespace account-regional \
  --region us-east-1
{
    "Location": "/my-app-bucket-123456789012-us-east-1-an",
    "BucketArn": "arn:aws:s3:::my-app-bucket-123456789012-us-east-1-an"
}

従来のグローバル名前空間では不可能だった「同じプレフィックスのバケットを複数リージョンに作成する」ことが可能になっています。

CloudFormationとの統合

IaC（Infrastructure as Code）での利用も考慮されています。CloudFormationでは2つの方法でアカウントリージョナル名前空間のバケットを作成できます（2026年3月12日 AWS News Blog）。

方法1: BucketNameにSub関数を使用

BucketName: !Sub "my-app-bucket-${AWS::AccountId}-${AWS::Region}-an"
BucketNamespace: "account-regional"

方法2: BucketNamePrefixを使用（自動サフィックス付与）

BucketNamePrefix: 'my-app-bucket'
BucketNamespace: "account-regional"

BucketNamePrefix を使う方法では、CloudFormationが自動的にアカウントIDとリージョンと -an サフィックスを付与してくれます。既存のテンプレートの移行が楽になるため、こちらのほうが実用的だと思います。

知っておくべき制約事項

公式ブログには以下の記載があります（2026年3月12日 AWS News Blog）。

You can’t rename your existing global buckets to bucket names with account regional namespace, but you can create new general purpose buckets in your account regional namespace.

既存のグローバル名前空間のバケットをアカウントリージョナル名前空間に変換する方法はありません。新規にバケットを作成して、データを移行する必要があります。

その他の制約をまとめます。

  • 対応リージョン: 37のAWSリージョンで利用可能。ただしMiddle East (Bahrain)とMiddle East (UAE)は非対応
  • 対象バケットタイプ: 汎用バケット（General Purpose Buckets）のみ。S3テーブルバケットやベクターバケットは既にアカウントレベルの名前空間を持っており、ディレクトリバケットはゾーナル名前空間を持っています
  • エンドポイント: S3リージョナルエンドポイントの使用が推奨。レガシーのグローバルエンドポイントは us-east-1 でのみ後方互換として動作します

料金

追加料金はかかりません（2026年3月12日 AWS What’s New）。通常のS3バケットと同じ料金体系で利用できます。

まとめ

アカウントリージョナル名前空間の導入は、S3の20年の歴史の中でも非常に大きな変更だと思います。

セキュリティの観点から自分が特に評価しているのは以下の3点です。

  • Namesquatting攻撃の根本的な排除: アカウントIDをサフィックスに含めることで、他者がバケット名を占拠する余地がなくなります
  • 削除後の名前保護: アカウントリージョナル名前空間のバケットを削除しても、その名前は永久に自分のアカウント専用のままです。従来の「削除したバケット名が誰にでも取得可能になる」リスクがなくなります
  • SCPによるガバナンス: 条件キー s3:x-amz-bucket-namespace でOrganizations全体にアカウントリージョナル名前空間の使用を強制できます

一方で、命名規則が固定されるためバケット名が長くなる点、既存バケットの移行が必要な点は意識しておく必要があります。特に63文字制限があるため、リージョンコードが長い場合はプレフィックスの設計に注意が必要です。

新規プロジェクトでは積極的にアカウントリージョナル名前空間を採用し、既存プロジェクトでも段階的に移行を進めることをお勧めします。