1. ホーム
  2. amazon-s3

[解決済み] オブジェクトタグとオブジェクトメタデータの違いとは?

2023-07-05 22:16:02

質問

私は、アップロード処理中にオブジェクトに(私のサーバーからの)小さなデータ片を含める方法を探しています(例:ユーザーID、ファイルID、など)。S3 のドキュメントを見た後、このデータをオブジェクト タグまたはオブジェクト メタデータとして含めることがより適切であるかどうかがわかりません。

タグの目的は分類のためでしょうか?そして、メタデータはオブジェクトごとのデータのため?

どのような違いがあるのでしょうか?この状況では、何がより適切だと思いますか?

どのように解決するのですか?

メタデータとタグはどちらも本質的に "メタデータ" ですが、サービスの動作を変更するために使用できる(またはできない)方法と、その値にアクセスできる(またはできない)方法には重要な相違点があります。

S3内のオブジェクトは、そのメタデータを含めて、--厳密に言えば--不変です。 コンソールは、メタデータを編集する能力を与えますが、それは何が起こっているのかを正確に説明しているわけではありません。 オブジェクトのメタデータを編集する場合、実際には、そのオブジェクトを、メタデータを変更したコピーで上書きしていることになります。 バケツがバージョン管理されている場合、2 つの異なる日付と変更されたメタデータを持つオブジェクトのコピーが 2 つ存在することになります。

タグはサブリソースであり、ある意味、オブジェクトの脇の部分です。

メタデータは PUT リクエストに HTTP ヘッダとして含まれます。 タグは2回目のリクエストを送信することで格納されます。 以下のカウントとサイズ制限までのタグを完全にサポートするには、 2回目のリクエストを送信して ?tagging サブリソースに 2 回目のリクエストを送る必要がありますが、API エンドポイントの PUT (Object) REST 呼び出しでは、タグも限定的にサポートしており、最大 2K までの url エンコードされたクエリパラメータ形式のタグのキーと値を、1 つの x-amz-tagging HTTP PUT というリクエストヘッダがあります。 例えば x-amz-tagging: hipaa_restrict=false&pci_restrict=true&owner=Accounting%20and%20Payroll . ドキュメントでは、2K がヘッダ名自体のバイト長を含むのか、あるいはこの 2K が x-amz-meta-* ユーザーメターデータタグと同じ 2K なのかどうかが不明です。 おそらく、2 つの異なる 2K の制限ですが、2K のタグ制限には、ヘッダーの長さだけでなく、キーと値の URL エンコード形式も含まれるようです。

IAM ユーザーがオブジェクト+メタデータまたはタグを読み書きできるかどうか、ポリシーによって個別に制御することができます。 オブジェクトとメタデータはパーミッションで一緒に扱われますが (一方ができるなら、他方も常にできます)、タグは別のパーミッションです。

あなたが GET を実行すると、実際のメタデータは HTTP レスポンスヘッダで返されます。 これは、オブジェクトをダウンロードするユーザーが、HTTP ヘッダを検査する方法を知っていれば、メタデータを見ることができることを意味します。

逆に、タグは GET リクエストに応答するヘッダにはタグは返されません。 x-amz-tagging-count: ヘッダのみが返され、それが 0 でない場合はオブジェクトのタグの数が報告されます。 しかし、タグが 独自 のデータを保存するのには適していますが、暗号化されていない センシティブ データを保存するのには適していません。

各オブジェクトのすべてのメタデータのキーと値を合計したものが 2KBに制限されます。 . この制限はバイト数で表されるため、マルチバイト文字は1文字あたり1バイト以上消費され、制限値に達することに注意してください。 メタデータのキー数には制限はなく、ユーザーメタデータの合計が2KBに制限されるだけです。 オブジェクトのメタデータのキーと値では、US-ASCII 文字のみが完全にサポートされます。 オブジェクトメタデータはHTTPヘッダとして送信されるため、メタデータはHTTPヘッダとして有効な文字で構成されなければなりません。

タグの制限は、異なる . 各オブジェクトは最大 10 個のタグを持つことができ、各タグキーは 128 個に制限されています。 文字 (バイトではありません)、そして各タグの値は256個までです。 文字 (バイトではありません) に制限されますが、上記のように、タグが PUT のリクエストに対応します。 メタデータと異なり、タグはUTF-8をサポートしています。

メタデータのキーと値は、オブジェクトストレージの請求サイズに貢献する請求可能なバイトとしてカウントされます。 タグは、別の計算式で別々に請求されます。

タグとメタデータのいずれも、オブジェクトのスキャンに使用することはできません。 S3サービスに、特定のタグや特定のメタデータを持つオブジェクトのリストを求めることはできません。

タグは、メタデータができない少なくとも2つの重要な方法で、サービスの動作を変更するために使用することができます(そして、実際、私が今考えていない他の方法があるかもしれません)。

バケット/ユーザー/ロール上のIAMポリシーは、アクセス制御の目的でタグの値をテストできますが、メタデータの値をテストすることはできません。

バケツ

IAM ポリシーには 条件キー で、オブジェクトのアクセス制御を可能にする タグに基づく . メタデータに基づく同様のアクセス制御機能はありません。

バケツ・ライフサイクル・ポリシーはタグの値をテストできますが、メタデータの値をテストすることはできません。

ライフサイクルポリシー は、オブジェクトの保存クラスを変更したり(標準/不定期アクセスまたは氷河に)、設定可能な時間間隔の後にオブジェクトやバージョンをパージするために使用されます。 オブジェクトタグが導入される前は、これらのルールはバケツ全体か、特定のプレフィックス、たとえば images/ . 現在では、タグによってライフサイクルポリシーをオブジェクトタグに基づいて適用できるため、(例えば)一時的なデータを永久的なデータと混ぜながらライフサイクルポリシーを適用することができ、プレフィックスマッチングのためにオブジェクトを異なるキー階層に保存する必要がありません。


質問で説明されている状況では、これらの値が HTTP レスポンスヘッダーで見えるという事実がセキュリティ上の懸念と見なされない限り、これらの値をメタデータに格納することをお勧めします。

CloudFront と共に S3 を使用している場合、S3 のインスタンスに対して Lambda@Edge Originレスポンストリガー を使って、レスポンスからオブジェクトメタデータを再作成または削除し、ブラウザから見えないようにすることができます。Origin Responseトリガーは、Node.jsで書かれたLambda関数で、CloudFrontキャッシュに保存される前にレスポンスをプログラム的に修正することができ、つまり、キャッシュがなくなった時だけ実行すればよいということです。 同様の機能は、HAProxyやNginxなどのEC2内のプロキシサーバーを経由してバケットへのリクエストをルーティングすることでも実現できるが、バケットに直接アクセスする場合はそうはいかない。 S3サービスはHTTPレスポンスヘッダで常にメタデータを返すが、オブジェクトのダウンロード時にはタグの数(オブジェクトにタグがある場合)を返すだけで、タグそのものを返すことはない。