Amazon S3 のライフサイクル設定においてワイルドカードが使えない

こんにちは!
今日はこんなことを書きたいと思います。AWS S3 のライフサイクル設定で「ワイルドカード(*)が使えない」という盲点についてです。

一般的にオブジェクトをまとめて管理するとき、たとえば「logs/2023/01/」「logs/2023/02/」「logs/2023/03/」といったフォルダに対して一発でルールを適用したくなりますよね。
「ここは logs/2023/* と書けば全部いけるんじゃない?」
と思って試したら、何も動かずに焦った経験がある方も多いはずです。


ライフサイクル設定のフィルタはプレフィックスかタグのみ

AWS S3 のライフサイクルルールでは、オブジェクトを絞り込む方法として 「プレフィックス(接頭辞)」「タグ」 のいずれか一つだけをサポートしています。
残念ながら、*? などのワイルドカード文字を使ったフィルタリングはできません。
ここ、意外と知られていないポイントです。

なぜワイルドカードが使えないのか?

S3 のオブジェクトキーは「文字列そのもの」として扱われます。
つまり、Prefix="logs/2023/*" と書いても * はワイルドカードではなく、フォルダ名の一部です。
結果として、実際にオブジェクトキーに logs/2023/* という名前が含まれるアイテムしか対象になりません。
まるで魔法の杖が使えないような気分ですよね。

とはいえ、AWS 側には「複雑なパターンマッチ」は本来想定されておらず、シンプルに高速でスケーラブルな処理を実現するための設計です。
裏を返せば、ワイルドカードや正規表現をサポートしない代わりに、膨大なオブジェクトキー を秒単位で評価できる仕組みになっているわけです。


よくある誤解と失敗パターン

1.プレフィックスに * を含めて設定

<Filter>
  <Prefix>logs/2023/*</Prefix>
</Filter>

→ エラーにはならないが、対象アイテムが “実質ゼロ” と見なされ、ライフサイクルが動作しない。

2.複数の接頭辞を一つのルールでまとめようとする
「images/2024/」 と 「thumbnails/2024/」 を同時に管理したい場合、

<Filter>
  <Prefix>*/2024/</Prefix>
</Filter>

などと書いてみても、やはり文字列として解釈されるだけでミスマッチ。

3.タグを後回しにして Prefix だけで何とかしようとする
タグは後付けで管理しづらい場合もありますが、ライフサイクルと相性が良いので、タグベースの運用は検討の価値ありです。

これらの失敗パターンにハマると、気づかぬうちにストレージコストだけが膨れ上がり、
「せっかく設定したのに 30 日後に Glacier に移行されていない!」
なんてことにもなりかねません。


ワイルドカードが使えないときの主な回避策

1. タグフィルタリングを活用する

オブジェクトをアップロードするときに、キー構造だけでなく タグ も付与しておく方法です。
たとえばログファイルなら

  • Key: logs/2023/01/01.log
  • Tag: year=2023

のようにしておき、ライフサイクルではタグ条件で絞り込めば細かなパターンもカバーできます。

<Filter>
  <Tag>
    <Key>year</Key>
    <Value>2023</Value>
  </Tag>
</Filter>

タグは運用コストが少し増えますが、柔軟性 が格段に向上します。

2. 複数ルールを分割して定義する

Prefix のみで対応するなら、対象ごとにルールを分けてしまうのも手です。

  • Rule A: <Prefix>logs/2023/01/</Prefix>
  • Rule B: <Prefix>logs/2023/02/</Prefix>

少し面倒ですが、GUI から簡単に複製できるので、一度設定すればあとは安心です。

3. 共通プレフィックスを見直す

複数の接頭辞に共通部分があるなら、そこだけをPrefixに切り出す方法もあります。

  • sales1999/, sales2000/, sales2001/<Prefix>sales</Prefix>

こうすれば3つまとめて対象にできますが、やりすぎると他のオブジェクトも誤って含まれる可能性があるので要注意です。


タグ運用のコツと注意点

  • タグ付けルールをドキュメント化 して、チーム全員が同じ運用を行う
  • ライフサイクルの検証 はステージングバケットや小規模バケットで入念に行う
  • コスト試算 を忘れずに。タグベースだと PUT リクエスト数が増える場合があります

とはいえ、最初から完璧を目指すよりも「小さく始めて、運用しながら改善する」ことが大切です。


まとめ:制約を理解して設計を工夫しよう

AWS S3 のライフサイクルルールは、シンプルな設計ゆえに「ワイルドカード不可」という制約があります。
慣れないうちは

「ワイルドカードが使えないなんて不便だ!」

と感じるかもしれません。ですが、この制約こそが 高速・大量スケール を実現する秘訣でもあるわけです。

というわけで、以下のポイントを押さえてみてください。

  1. プレフィックスとタグ、どちらが向いているか考える
  2. タグ運用のルールを決め、小規模バケットで検証する
  3. 複数パターンはルール分割や共通プレフィックスでカバー

これらを組み合わせれば、ワイルドカードなしでも柔軟なライフサイクル管理が可能になります。
S3 ストレージコストを賢くコントロールして、快適なクラウドライフを楽しみましょう!