3行まとめ
Amazon S3 objectsに名前付きの大きなコンテキストを付けられるAmazon S3 annotationsが発表された。
AI生成要約、文字起こし、分類結果、監査メモをS3 objectに近い場所へ置き、annotation tableで検索できる点を見る。
object tags、user-defined metadata、外部DBの置き換えと決めつけず、料金、反映遅延、copy、versioning、暗号化を確認する。
S3 annotationsは便利な保存先ではなく、検索・分析したい文脈をどう管理するかの設計課題として読む。
- AWSは2026年6月16日、Amazon S3 objectsに名前付きの大きなコンテキストを付けられるAmazon S3 annotationsを発表しました。S3 User Guideでは、1つのobject versionに最大1,000件、各annotationは1 byteから1 MiBまでと説明されています。
- 実務上の焦点は、単に「S3にメモを付けられる」ことではありません。AI生成要約、文字起こし、分類結果、監査メモをS3 objectに近い場所へ置き、S3 Metadataのannotation tableでAthenaなどから検索できる点です。
- ただし、object tags、user-defined metadata、外部DBをそのまま置き換える機能ではありません。料金、反映遅延、copy、versioning、ETag、暗号化、未対応機能を確認してからPoCへ進むべき更新です。
Amazon S3 annotationsは、2026年6月のAWSデータ基盤更新の中でも、AIエージェントやデータレイク運用に直結しやすい発表です。AWS News Blogは2026年6月16日、S3 objectにリッチで検索可能なコンテキストを直接付ける新しいmetadata capabilityとして紹介しました。Hacker NewsやAWSコミュニティでも反応が出ており、読者が気にしているのは「便利そう」より先の、既存metadata設計やデータ検索基盤との分担です。
この記事では、公式ブログ、Amazon S3 User Guide、annotation tableのドキュメント、S3 pricingをもとに、S3 annotationsを導入前チェックリストとして読みます。Amazon Watch JapanはAmazonおよびAWSとは非提携の解説サイトです。本文は投資助言ではなく、AWSサービスの利用判断を助けるための整理です。
S3やAWSの更新は、同じ月の流れで見ると判断しやすくなります。2026年6月の主なAmazon/AWSトピックは、<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月 重要トピックまとめ</a>にも集約しています。
S3 annotationsとは何か
- 1S3 object version
保存済みのobject versionに対して、名前付きのannotationを関連付ける。
- 2annotation payload
AI summary、transcript、moderation、technical metadata、compliance noteのような大きめの情報を扱う。
- 3専用API
PutObjectAnnotation、GetObjectAnnotation、ListObjectAnnotations、DeleteObjectAnnotationで操作する。
- 4annotation table
保存したannotationを検索・分析の対象にし、Athenaなどから確認できるようにする。
オブジェクト本体を書き換えずに文脈を更新できる一方、API、権限、課金、削除方針の設計は別途必要になる。
S3 annotationsは、Amazon S3 objectに名前付きのデータpayloadを付ける仕組みです。従来のuser-defined metadataやobject tagsより大きな文脈を扱えるため、AI生成の説明、文字起こし、分類結果、コンテンツ審査結果、データ系譜、コンプライアンスラベル、処理ステータスのような情報をobjectと近い場所に残しやすくなります。
User Guideでは、各annotationは1 byteから1 MiBまでのcustom metadata payloadで、1つのobject versionに最大1,000件まで関連付けられると説明されています。annotation nameはobject version内で一意である必要があり、payloadは有効なUTF-8 textです。JSON、XML、YAML、plain textのような形式を保存できます。
オブジェクト本体を書き換えずに文脈を更新できる
条件: APIと権限の対象として扱う
これまでS3 objectに後から大きな文脈を付けたい場合、sidecar fileを置く、外部DBにkeyを持つ、object tagsに短い分類を入れる、user-defined metadataをcopyで更新する、といった方法がよく使われました。それぞれ有効ですが、オブジェクトとの対応関係、検索性、更新コスト、権限設計がばらけやすくなります。
S3 annotationsでは、PutObjectAnnotation、GetObjectAnnotation、ListObjectAnnotations、DeleteObjectAnnotationという専用APIでannotationを操作します。オブジェクト本体を再アップロードしなくても、annotationを追加、取得、一覧化、削除できます。
ただし、これは「何でもS3に押し込めばよい」という話ではありません。annotationにもAPI、権限、課金、検索設計、削除設計が必要です。大きな文脈をobjectへ近づけるほど、誰がその文脈を作り、いつ更新し、誤りをどう直すかが重要になります。
annotation tableで検索できることが実務上の要点
根拠: S3 Metadataと組み合わせて読む
S3 annotationsの実務上の強みは、S3 Metadataと組み合わせたannotation tableです。S3 Metadataの設定にannotation tableを追加すると、bucket内のannotationsをマネージドなApache Iceberg tableとして保持し、Athenaなどの分析サービスから照会できるようになります。
たとえば、動画objectにmediainfoというannotationを付け、音声トラック数、字幕、解像度、durationをJSONで保存しておけば、後からAthenaで「音声トラックが8本を超える動画」や「特定のclassificationが付いたファイル」を探す構成を作れます。AIエージェントやデータカタログが、objectを毎回取得せずに文脈を探せる点が重要です。
この検索性は魅力的ですが、即時反映を前提にしない方が安全です。AWS News Blogはjournal tableがnear real time、annotation tableがwithin an hourで更新されると説明しています。annotation table docsでは、backfill中に既存objectのannotationsを取り込み、完了後は通常1時間以内に更新が反映されると説明されています。大量のobjectがあるbucketでは、backfillに時間がかかる前提で計画してください。
AIワークフローで想定される使い道
注意点: 品質管理は別に設計する
AIワークフローでは、object本体と、そのobjectを理解するための文脈が分離しがちです。PDF、画像、動画、音声、ログ、研究データ、契約書、サポート記録をS3に置き、生成AIが要約や分類を作る構成では、生成結果をどこに保存するかが問題になります。
S3 annotationsは、AI生成要約、文字起こし、moderation label、document classification、PII flag、retention policy、処理済みステータス、レビュー結果のような情報をobjectにひも付ける候補になります。sidecar fileや外部DBを使わない設計にできる場面もあります。
一方で、AIが生成したannotationは常に正しいとは限りません。生成元モデル、プロンプト、生成日時、レビュー状態、再生成条件、削除条件を別途持たないと、古い要約や誤分類が検索結果に残ります。S3 annotationsは文脈を保存する場所を提供しますが、文脈の品質管理までは自動化しません。
user-defined metadata、object tags、S3 Metadataとの違い
サイズだけで優劣を決めず、アクセス制御、更新頻度、検索方法、既存ワークフローへの影響で分ける。
S3 annotationsを理解するには、既存のmetadata関連機能と混ぜないことが大事です。S3にはsystem-defined metadata、user-defined metadata、object tags、S3 Metadata、そして今回のannotationsがあります。名前は似ていますが、役割は違います。
user-defined metadataはアップロード時の小さな補助情報
評価基準: 既存のheader前提を壊さない
user-defined metadataは、objectの作成時に指定できるカスタムmetadataです。User Guideは、objectをアップロードしたあとにこのuser-defined metadataを直接変更できず、変更するにはobjectをcopyしてmetadataを設定し直す必要があると説明しています。
つまり、user-defined metadataはアップロード時点で決まる小さな補助情報に向きます。アプリケーションがHTTP headerとして参照する情報、互換性のために残す情報、既存ワークフローが依存している情報を、無理にannotationsへ移す必要はありません。
S3 annotationsが向くのは、後から生成され、更新され、比較的大きく、検索や分析に回したい文脈です。たとえば動画の文字起こし、AI summary、審査結果、ETL処理結果は、user-defined metadataよりannotationsの方が検討しやすい領域です。
object tagsはアクセス制御やlifecycle用途を残す
確認項目: IAM、Lifecycle、cost allocation
object tagsは、1つのobject versionにつき最大10個までのkey-value分類です。S3 User Guideの比較表では、object tagsはkeyが128 characters、valueが256 charactersまで、annotationsはnameが512 bytesまで、payloadが1 MiBまでと整理されています。
サイズだけを見るとannotationsの方が強く見えますが、役割は違います。object tagsはIAM policy integration、S3 Lifecycle rule filtering、cost allocation reportingに使える点が重要です。アクセス制御、ライフサイクル、費用配賦に使っているタグを、単に大きなpayloadが持てるからといってannotationsへ移すと、運用ルールが壊れます。
判断の目安はシンプルです。短い分類で、IAM、Lifecycle、cost allocationに使うならobject tags。大きな構造化文脈を保存し、後から検索・分析したいならannotations。アップロード時に小さく付ける情報ならuser-defined metadataです。
S3 Metadataとannotation tableは検索面の受け皿
条件: table設計とquery costを見る
S3 Metadataは、S3 objectのmetadataをマネージドなApache Iceberg tablesとして扱い、Athenaなどからqueryしやすくする機能です。annotationsはobjectに付ける文脈で、annotation tableはそのannotationsを検索・分析するための受け皿です。
この2つを混同すると、「annotationsを付ければ自動的にあらゆる検索基盤が完成する」と誤解しやすくなります。実際には、S3 Metadata configuration、annotation table、IAM、Athena、Iceberg互換エンジン、query cost、更新反映時間を別々に確認する必要があります。
特にAIエージェント用途では、annotation tableを検索してobject候補を見つける設計と、S3 VectorsやOpenSearchのような検索基盤を使う設計が併存します。S3 annotationsはベクトルDBの代替ではなく、objectに付随する文脈を保存し、検索可能にする部品として見るのが現実的です。
AIワークフローで使う前のデータ設計
summary、transcript、moderation、pii_review、etl_statusのように粒度と命名をそろえる。
plain text、JSON、XML、YAMLのどれで保存するかを、検索したい項目から逆算する。
model_id、source_version、generated_at、confidenceを残し、どの入力から作られたかを追えるようにする。
review_status、人間の確認有無、誤りを直す手順、再生成のタイミングを決めておく。
AI生成annotationは検索しやすくなるほど誤情報も広がりやすいため、品質と責任の設計を先に置く。
S3 annotationsをAIワークフローで使うなら、最初に設計すべきなのはpayloadの中身です。AIで作った要約や分類を大量に保存するのは簡単ですが、あとで検索、削除、監査、再生成をするには、annotation name、format、生成元、レビュー状態を先に決める必要があります。
annotation nameと形式を先に決める
確認項目: 名前、形式、検索条件
annotation nameは、後から検索や運用で使う識別子です。summary、transcript、moderation、technical_metadata、pii_review、etl_statusのように粒度を分けるのか、用途ごとにprefixを付けるのかを決めておきます。
payload形式も重要です。plain textは人間が読みやすい一方、Athenaで条件検索したいならJSONの方が扱いやすい場面があります。たとえばlanguage、confidence、review_status、generated_at、model_id、source_versionを検索したいなら、単なる文章ではなく構造化しておく方が後で楽です。
JSON、XML、YAML、plain textを混ぜられることは柔軟さです。ただし、柔軟すぎる設計は後から集計しづらくなります。AIチーム、データエンジニア、セキュリティ担当が、それぞれ勝手な形式でannotationを増やすと、annotation tableはあっても検索条件が揃いません。
AI生成annotationの品質と責任を分ける
注意点: 検索性が上がるほど誤情報も広がる
AI生成annotationには、本文とは別の責任があります。誰が作ったのか、どのモデルが作ったのか、どの入力を使ったのか、人間が確認したのか、いつ再生成するのか、誤りが見つかったらどう直すのか。これらを決めないまま使うと、検索性が上がるほど誤情報も広がります。
たとえば、動画のAI summaryをannotationに保存し、AIエージェントがそのsummaryを見てobjectを選ぶとします。summaryが古かったり、内容を取り違えていたりすると、エージェントは間違ったobjectを選びます。annotationを「検索対象」にするなら、annotationの品質も検索基盤の品質です。
品質管理のためには、annotation本文にすべてを詰め込むより、ai_summary、ai_summary_review、source_metadataのように責任を分ける設計も考えられます。公式ドキュメントはこうした設計の正解を決めてくれません。自社の監査、データ分類、レビュー体制に合わせる必要があります。
機密情報と削除要件を見落とさない
確認項目: 分類、暗号化、削除権限
S3 annotationsはobjectと近い場所に置かれます。そのため、個人情報、契約情報、医療・金融情報、社外秘の分類結果をannotationに入れる場合は、親objectと同じくらい慎重に扱うべきです。
User Guideでは、annotationsは親objectの暗号化設定を継承すると説明されています。SSE-S3、SSE-KMS、DSSE-KMSに関する扱いは確認できますが、暗号化されることと、誰が読めるか、いつ消すか、どのログに残るかは別問題です。
削除も軽く見ない方がよいです。User Guideは、annotation deletionはpermanent and irreversibleで、versioned bucketでもannotationにはdelete markerやversion historyがないと説明しています。誤って消したannotationをあとから戻せる前提で運用しないでください。
annotation tableで検索する時の確認点
- 対象を決める
どのannotationを、どの頻度で、どのqueryで、誰が使うのかを先に決める。
- tableを有効にする
metadata table configurationの中でannotation tableを追加し、bucket内のannotationsを追跡する。
- backfillを待つ
既存のannotated objectsがある場合は、object数に応じてbackfillにminutes to hoursかかる前提で見る。
- Athenaで確認する
name、object_key、version_id、text_value、JSON path、日時、レビュー状態などを検索条件にする。
- 即時制御に使わない
更新反映は通常1時間以内という扱いのため、数秒単位のワークフロー制御は別の仕組みも検討する。
annotation tableは検索・分析の入口であり、リアルタイム制御の前提にしないことが重要になる。
annotation tableは、S3 annotationsをただの付随情報から、検索・分析可能なデータに変える重要な部品です。とはいえ、導入前には「どのannotationを、どの頻度で、どのqueryで、誰が使うのか」を決める必要があります。
反映遅延とbackfillを前提にする
根拠: 公式説明でも即時反映ではない
annotation table docsによると、metadata table configurationにはjournal tableが含まれ、annotation tableは任意で追加できます。annotation tableはbucket内のannotationsの最新状態を追跡し、特定のannotation keyやvalue、annotationを付けたprincipalを探す用途に使えます。
既存のannotated objectsがあるbucketでannotation tableを有効にすると、Amazon S3がbackfillを行います。User Guideは、object数に応じてこの処理にminutes to hoursかかると説明しています。AWS News Blogは、既存annotationのbackfillがobjects数に応じてseveral hours to daysかかる場合があると説明しています。いずれにせよ、即時に検索できる前提ではありません。
また、backfill完了後の更新も通常1時間以内という扱いです。リアルタイムのワークフロー制御や、数秒単位の状態確認をannotation tableだけに任せる設計は避けた方がよいでしょう。
Athenaで何を検索したいかを先に決める
条件: payloadをqueryから逆算する
annotation tableを使うなら、保存前にqueryを考えるべきです。name、object_key、version_id、text_value、JSON path、日時、レビュー状態、principalなど、検索条件に使いたい項目を洗い出します。
たとえば、text_valueに自由文だけを保存すると、人間には読みやすくても条件検索が弱くなります。後から「日本語のtranscriptがあり、PII reviewが未完了で、AI confidenceが0.8未満のobject」を探したいなら、最初からJSON fieldsとして持たせる方が現実的です。
Athenaで検索する以上、query costやtable設計も無視できません。annotationが増えるほど、検索対象も増えます。S3 annotationsの上限だけを見て大きく設計するのではなく、よく使うquery、更新頻度、保存期間、削除条件を合わせて決めてください。
journal tableとannotation tableの役割を分ける
注意点: 変更検知と全体検索を混同しない
S3 Metadata configurationにはjournal tableがあり、objectに起きたeventsを記録します。annotation tableは、最新のannotationsを検索しやすくするためのtableです。変更検知に近い用途と、最新状態の検索は、見るtableを分ける必要があります。
「新しいannotationが付いたらすぐ次の処理を起動したい」場合、annotation tableだけではなく、S3 events、EventBridge、Lambda、Batch Operationsなどを合わせて考えることになります。S3 annotationsは文脈保存の土台であり、ワークフロー全体のイベント処理を単独で置き換えるものではありません。
AIエージェントに使う場合も同じです。エージェントがquery時にannotation tableを見るのか、事前に別の検索indexへ同期するのか、human review後のannotationだけを対象にするのか。ここを決めないと、AIは古い文脈や未レビューの文脈を拾います。
コスト、copy、versioning、暗号化で詰まるところ
導入判断では、親objectの保存費だけでなく、annotationの保存、検索、移行、削除、権限までまとめて見る。
S3 annotationsは便利ですが、運用時に詰まりやすいのは華やかなユースケースではなく、費用、copy、versioning、暗号化、未対応機能です。本番導入前には、このH2をチェックリストとして使ってください。
annotation storageは親objectのstorage classと分けて見る
評価基準: 保存量、request、queryを分ける
AWS News Blogは、annotation storageは親objectがS3 Glacierなど別のstorage classにあっても、常にS3 Standard ratesで課金されると説明しています。S3 pricingページも、annotation requestやCOPY時の扱いを確認する必要があるページです。
これは重要です。アーカイブ済みobjectにAI要約だけ大量に付けると、親objectのstorage classだけを見た費用見積もりでは足りません。annotation storage、annotation request、Athena query、backfill、Batch Operations、Lambdaなど周辺処理も含めて見る必要があります。
費用管理の観点では、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-42-aws-finops-agent-preview-cost-anomaly-automation/" rel="noopener">AWS FinOps Agentプレビューの記事</a>で扱ったようなコスト異常調査の考え方も参考になります。S3 annotations自体の料金はS3 pricingで確認しつつ、AIワークフロー全体の費用は別枠で監視してください。
copyとreplicationは条件を読み違えやすい
確認項目: 単純copyとmultipart copyを分ける
User Guideでは、CopyObject APIでobjectをcopyする場合、5 GiB未満のobjectについてはannotationsも単一operationでcopyされると説明されています。一方、multipart uploadを使うcopyでは、annotationsはdefaultではcopyされません。AWS CLIやSDKが大きなobjectでmultipart copyを使う場合、--copy-props all相当の設定を確認する必要があります。
この違いを見落とすと、移行先bucketにobject本体はあるのにannotationがない、という状態が起きます。メディアライブラリ、データレイク移行、cross-Region copy、環境分離、本番復旧の手順では、object本体だけでなくannotationsのcopy結果も確認してください。
Pricingページには、annotationsが付いたobjectをCOPYすると、各annotationのcopyがannotation request rateのPUTとして課金されるという説明もあります。大量copyでは、保存容量だけでなくrequest費用も見積もり対象です。
versioningとETagの挙動を先に押さえる
注意点: annotation更新はETagを変えない
User Guideでは、annotationsは特定のobject versionに付くと説明されています。あるversionに付いたannotationsは、別versionのannotationsから独立しています。新しいversionを作っても前versionのannotationsは自動的にcopyされません。
また、annotationの追加、更新、削除は親objectのETagを変更しません。既存のデータ処理パイプラインがETagだけを見て変更検知している場合、annotationの更新を見逃す可能性があります。
versioned bucketでも、annotation自体は独立したversion historyを持ちません。同じannotation nameを上書きすると前の値は置き換わります。削除したannotationは復旧できない前提で、削除権限、監査、事前backup、誤更新時の運用を設計してください。
暗号化と未対応機能を本番前に読む
確認項目: KMS権限と未対応サービス
S3 annotationsは、親objectのserver-side encryption configurationを継承します。SSE-S3の場合はSSE-S3、SSE-KMSの場合は同じKMS key、DSSE-KMSの場合は同じkeyで暗号化されます。S3 Bucket Keysもサポートされます。一方、SSE-Cで暗号化されたobjectにはannotationsを追加できません。
KMSを使う場合は、暗号化方式だけでなく、annotation APIを呼ぶprincipalが必要なKMS権限を持っているかを確認します。AI処理用のrole、データカタログ用のrole、Athena用のroleが分かれている場合、object本体のread権限だけでは足りないことがあります。
未対応機能も重要です。User Guideは、S3 Inventory Reports、API Gateway、S3 Storage Lens、Amazon S3 File Gateway、Amazon FSx、S3 on Outposts、S3 Express One Zoneのdirectory buckets、Amazon S3 Filesではannotationsがサポートされないと説明しています。既存の棚卸し、監査、ファイルゲートウェイ、directory bucket運用に乗る前提で設計しないようにしてください。
導入前チェックリスト
user-defined metadata、object tags、外部DB、sidecar file、S3 Metadata、OpenSearch、データカタログの役割を分ける。
AI summary、transcript、moderation result、PII flag、review status、ETL status、compliance noteを分類する。
1objectあたりの件数、payloadサイズ、保存期間、bucket単位の増加量を見積もる。
PutObjectAnnotation、GetObjectAnnotation、ListObjectAnnotations、DeleteObjectAnnotationをPoC用の環境で確認する。
annotation tableのbackfill、反映遅延、検索条件、JSON path、レビュー状態のqueryを確認する。
AI生成annotationの生成元、レビュー、削除、監査、再生成の責任を本番前に決める。
確認日は2026年6月17日。料金、リージョン、未対応機能、API仕様は公開後に変わる可能性がある。
最後に、S3 annotationsを試す前に見る項目を整理します。S3 annotationsは発表直後の機能なので、公式ドキュメントは更新される可能性があります。確認日は2026年6月17日です。公開後に料金、リージョン、未対応機能、API仕様が変わる場合があります。
今すぐ確認する項目
確認項目: 役割分担と保存量
まず、既存のmetadata設計を棚卸しします。user-defined metadata、object tags、外部DB、sidecar file、S3 Metadata、OpenSearch、S3 Vectors、データカタログのどれが何を担っているかを分けてください。
次に、annotationに入れたい情報を分類します。AI summary、transcript、moderation result、technical metadata、PII flag、review status、ETL status、compliance noteを、1つのannotationにまとめるのか、用途ごとに分けるのかを決めます。
さらに、保存量を概算します。1objectあたり最大1,000件、各1MiBまでという上限は、便利さであると同時にコスト上限ではありません。実際に何件、何KB、何日保存するのかを、bucket単位で見積もってください。
PoCで確認する項目
確認項目: API、table、copyを小さく試す
検証用の環境では、PutObjectAnnotation、GetObjectAnnotation、ListObjectAnnotations、DeleteObjectAnnotationを一通り試します。versioned bucketとnon-versioned bucketの両方で、object overwrite、delete marker、specific version delete、annotation deleteを確認してください。
annotation tableを使う場合は、S3 Metadata configuration、backfill、Athena query、更新反映、再有効化、table削除、課金を確認します。検証では小さなbucketだけでなく、実際のobject数に近い規模で反映時間やquery設計を見た方が安全です。
copyの検証も必須です。5 GiB未満の単純copy、大きなobjectのmultipart copy、AWS CLI、SDK、Batch Operations、replicationを分けて、annotationsが想定通り移るかを確認してください。
本番前に確認する項目
評価基準: 権限、監査、費用を閉じる
本番前には、権限、削除、監査、費用、未対応機能を固めます。誰がannotationを作成できるのか、誰が削除できるのか、誤ったannotationをどう直すのか、AI生成annotationを誰が承認するのかを決めます。
データ分類も見ます。機密情報や個人情報をannotationに含めるなら、KMS key、log、Athena query権限、削除依頼、法務・監査の扱いを確認します。SSE-KMSを使う場合は、object本体だけでなくannotation操作に必要な権限も検証してください。
最後に、S3 annotationsを入れる目的を言語化します。「AIで便利そう」では弱いです。検索したいobjectを早く見つける、レビュー済みデータだけをAIに渡す、データレイク内の処理状態を追跡する、コンプライアンス確認をobject単位で残す。目的が明確なら、保存するannotationも、queryも、削除方針も決めやすくなります。
AWSの製品・サービス更新を継続して見る場合は、<a href="https://amzn-watch.blog.mo-gmo.com/category/products-services-solutions/" rel="noopener">製品・サービス・ソリューション</a>のカテゴリも確認してください。一次情報の確認方法は、<a href="https://amzn-watch.blog.mo-gmo.com/source-checks/" rel="noopener">資料・確認ログ</a>にもまとめています。
次に読むなら
参照した主な情報源
- AWS News Blog: Amazon S3 annotations: attach rich, queryable context directly to your objects
https://aws.amazon.com/blogs/aws/amazon-s3-annotations-attach-rich-queryable-context-directly-to-your-objects/
- Amazon S3 User Guide: Annotating your objects
https://docs.aws.amazon.com/AmazonS3/latest/userguide/annotations-overview.html
- Amazon S3 User Guide: Enabling or disabling annotation tables
https://docs.aws.amazon.com/AmazonS3/latest/userguide/metadata-tables-enable-disable-annotation-tables.html
- Amazon S3 User Guide: Working with object metadata
https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingMetadata.html
- Amazon S3 Pricing
https://aws.amazon.com/s3/pricing/
確認日: 2026年6月17日 JST。料金、リージョン、annotation tableの反映、未対応機能は変更される可能性があるため、本番導入前に必ず公式ページを再確認してください。