BLOB 層の設定

この操作により Set Blob Tier 、BLOB のアクセス層が設定されます。 操作は、Premium Storage アカウントのページ BLOB と、BLOB ストレージまたは汎用 v2 アカウント内のブロック BLOB で許可されます。 Premium ページ BLOB の層 (P4/P15//P30P40/P50///P60P6P10/P20) によって、BLOB の許容サイズ、IOPS、帯域幅が決まります。 ブロック BLOB の層によって、ストレージの種類がHotColdArchive/Cool//決まります。 この操作では、BLOB の ETag は更新されません。

ブロック BLOB レベルの階層化の詳細については、「 ホット、クール、アーカイブのストレージ層」を参照してください。

要求

要求は Set Blob Tier 次のように構築できます。 HTTPS を使用することをお勧めします。 myaccount をストレージ アカウントの名前に置き換え、myblob を層を変更する BLOB 名に置き換えます。

Method	要求 URI	HTTP バージョン
PUT	https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=tier	HTTP/1.1

URI パラメーター

次の追加パラメーターを要求 URI に指定できます。

パラメーター	説明
snapshot	省略可能。 スナップショット パラメーターは不透明DateTimeな値であり、存在する場合は、階層を設定する BLOB スナップショットを指定します。 BLOB スナップショットの操作の詳細については、「BLOB のスナップショットをCreateする」を参照してください。
versionid	バージョン 2019-12-12 以降では省略可能です。 パラメーターは versionid 不透明 DateTime な値であり、存在する場合は、階層を設定する BLOB のバージョンを指定します。
timeout	省略可能。 timeout パラメーターは、秒単位で表されます。 詳細については、「 Blob Storage 操作のタイムアウトを設定する」を参照してください。

要求ヘッダー

必須の要求ヘッダーと省略可能な要求ヘッダーを次の表に示します。

要求ヘッダー	説明
Authorization	必須。 承認スキーム、ストレージ アカウント名、署名を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
Date または x-ms-date	必須。 要求に対して協定世界時 (UTC) を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
x-ms-access-tier	必須。 BLOB に設定する層を示します。 許可されている Premium ページ BLOB 層の一覧については、「VM の高パフォーマンスのPremium Storageとマネージド ディスク」を参照してください。 BLOB ストレージまたは汎用 v2 アカウントの場合、有効な値は Hot、 Cool、 Cold、および Archiveです。 メモ：Cold レベルは、バージョン 2021-12-02 以降でサポートされています。 標準 BLOB アカウントの BLOB レベルの階層化の詳細については、「 ホット、クール、アーカイブのストレージ層」を参照してください。
x-ms-version	すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 詳細については、「 Azure Storage Services のバージョン管理」を参照してください。
x-ms-client-request-id	省略可能。 ストレージ分析ログが有効になっているときに分析ログに記録される 1 kB 文字の制限を持つクライアント生成の不透明な値を提供します。 クライアント側のアクティビティをサーバーが受信した要求と関連付けるには、このヘッダーを使用することが強く推奨されます。 詳細については、「Storage Analytics ログについて」を参照してください。
x-ms-rehydrate-priority	省略可能。 アーカイブされた BLOB のリハイドレートに使用する優先度を示します。 ブロック BLOB のバージョン 2019-02-02 以降でサポートされています。 有効な値は です High/Standard。 優先度は、2020-06-12 より前のバージョンの BLOB で 1 回だけ設定できます。このヘッダーは、後続の要求では無視されます。 既定の優先度設定は です Standard。 バージョン 2020-06-12 以降では、リハイドレート優先度は、以前に設定した後に更新できます。 優先度の設定は、このヘッダーを に設定して HighSet Blob Tier を呼び出し、前に設定Highしたのと同じ値に設定x-ms-access-tierすることで、 から Standard に変更できます。 優先度の設定を から High に Standard下げることはできません。

この操作では、指定された条件が満たされた場合にのみ、条件付きヘッダーを使用して BLOB を階層化することもできます。 詳細については、「 Blob Storage 操作の条件付きヘッダーを指定する」を参照してください。

要求本文

[なし] :

Response

応答には、HTTP 状態コードおよび一連の応答ヘッダーが含まれています。

status code

新しいレベルがすぐに有効になった場合は状態コード 200 (OK) が返され、新しいレベルへの移行が保留中の場合は状態コード 202 (Accepted) が返されます。

Premium ストレージ アカウントの場合、ページ BLOB 操作は状態コード 200 (OK) を返します。

ブロック BLOB の場合、BLOB の現在の層と要求された層に基づいて返される HTTP 状態コードを次の表に示します。

レベル	ホット 層に設定する	クール層に設定する	コールド 層に設定する	アーカイブ層に設定する
ホット層の BLOB	200	200	200	200
クール層の BLOB	200	200	200	200
コールド層の BLOB	200	200	200	200
アーカイブ層の BLOB	202	202	202	200
アーカイブ層の BLOB(ホットにリハイドレート)	202	409	409	409
アーカイブ層の BLOB(クールにリハイドレート)	409	202	409	409
アーカイブ層の BLOB(コールドにリハイドレート)	409	409	202	409

状態コードの詳細については、「 状態とエラー コード」を参照してください。

応答ヘッダー

この操作の応答には、次のヘッダーが含まれています。 応答に追加の標準 HTTP ヘッダーが含まれる場合もあります。 すべての標準ヘッダーは 、HTTP/1.1 プロトコル仕様に準拠しています。

応答ヘッダー	説明
x-ms-request-id	作成された要求を一意に識別し、要求のトラブルシューティングに使用できます。 詳細については、「 API 操作のトラブルシューティング」を参照してください。
x-ms-version	要求の実行に使用された Blob Storage のバージョン。 このヘッダーはバージョン 2009-09-19 以降で行った要求に対して返されます。
x-ms-client-request-id	要求と対応する応答のトラブルシューティングに使用できます。 このヘッダーの値は、要求に存在し、その値に 1,024 文字以下の ASCII 文字が含まれている場合、ヘッダーの値 x-ms-client-request-id と等しくなります。 ヘッダーが x-ms-client-request-id 要求に存在しない場合、応答には存在しません。

承認

Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 以下で説明するように、操作を Set Blob Tier 承認できます。

重要

Microsoft では、マネージド ID でMicrosoft Entra IDを使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra IDは、共有キーの承認と比較して優れたセキュリティと使いやすさを提供します。

Microsoft Entra ID (推奨)

Azure Storage では、Microsoft Entra IDを使用して BLOB データへの要求を承認することがサポートされています。 Microsoft Entra IDでは、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティ プリンシパルにアクセス許可を付与できます。 セキュリティ プリンシパルには、ユーザー、グループ、アプリケーション サービス プリンシパル、または Azure マネージド ID を指定できます。 セキュリティ プリンシパルは、OAuth 2.0 トークンを返すためにMicrosoft Entra IDによって認証されます。 その後、そのトークンを、Blob service に対する要求を認可するために使用できます。

Microsoft Entra IDを使用した承認の詳細については、「Microsoft Entra IDを使用して BLOB へのアクセスを承認する」を参照してください。

アクセス許可

Microsoft Entraユーザー、グループ、マネージド ID、またはサービス プリンシパルが操作を呼び出Set Blob Tierすために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。

• Azure RBAC アクション:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
• 最小特権の組み込みロール:ストレージ BLOB データ共同作成者

Azure RBAC を使用したロールの割り当ての詳細については、「 BLOB データにアクセスするための Azure ロールの割り当て」を参照してください。

共有アクセス署名 (SAS)

Shared Access Signature (SAS) は、ストレージ アカウント内のリソースへのセキュリティで保護された委任されたアクセスを提供します。 SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。 クライアントがアクセスできるリソース、それらのリソースに対するアクセス許可、および SAS が有効な期間を指定できます。

この操作では Set Blob Tier 、 ユーザー委任 SAS、 サービス SAS、 アカウント SAS の 3 種類の共有アクセス署名がサポートされています。

セキュリティのベスト プラクティスとして、ストレージ アカウント キーではなくMicrosoft Entra資格情報を使用することをお勧めします。これは、より簡単に侵害される可能性があります。 アプリケーション設計で共有アクセス署名が必要な場合は、可能であれば、Microsoft Entra資格情報を使用してユーザー委任 SAS を作成します。

ストレージ アカウントに対して共有キー アクセスが許可されていない場合、サービス SAS トークンまたはアカウント SAS トークンは、Blob Storage への要求では許可されません。 詳細については、「 共有キーの禁止が SAS トークンにどのように影響するかを理解する」を参照してください。

ユーザー委任 SAS

ユーザー委任 SAS は、Microsoft Entra資格情報と、SAS に対して指定されたアクセス許可によっても保護されます。

Set Blob Tierコンテナーまたは BLOB リソースに委任された SAS トークンを使用して操作を呼び出すには、ユーザー委任 SAS トークンの一部として書き込み (w) アクセス許可が必要です。

ユーザー委任 SAS の詳細については、「ユーザー委任 SAS のCreate」を参照してください。

サービス SAS

サービス SAS は、ストレージ アカウント キーで保護されます。 サービス SAS は、BLOB ストレージなどの単一の Azure Storage サービス内のリソースへのアクセスを委任します。

Set Blob Tierコンテナーまたは BLOB リソースに委任された SAS トークンを使用して操作を呼び出すには、サービス SAS トークンの一部として書き込み (w) アクセス許可が必要です。

サービス SAS の詳細については、「サービス SAS のCreate」を参照してください。

アカウント SAS

アカウント SAS は、ストレージアカウント キーで保護されます。 アカウント SAS は、1 つ以上のストレージ サービスのリソースへのアクセスを委任します。 サービスまたはユーザー委任 SAS を介して実行できるすべての操作は、アカウント SAS を介しても実行できます。

次の表は、アクセスを委任するときに指定する署名付きリソースの種類と署名付きアクセス許可を示しています。

操作	署名済みサービス	署名されたリソースの種類	署名されたアクセス許可
BLOB 層の設定	BLOB (b)	オブジェクト (o)	書き込み (w)

アカウント SAS の詳細については、「アカウント SAS のCreate」を参照してください。

共有キー

この操作では Set Blob Tier 、 共有キーの承認がサポートされています。 アカウント キーを使用した承認は、セキュリティが低く、ほとんどのシナリオでは推奨されません。

可能な場合は、ストレージ アカウントの共有キーの承認を禁止することをお勧めします。 詳細については、「共有キーによる承認の防止」を参照してください。

注釈

Premium アカウントでページ BLOB に BLOB の層を設定する場合、次の制限があります。

• 新しい BLOB 層を既存の BLOB 層よりも低くすることはできません。
• 新しい BLOB 層は、BLOB のコンテンツ長に対応できる必要があります。 レベルの一覧とその許可されるコンテンツの長さについては、 VM の高パフォーマンス Premium Storage とマネージド ディスクに関するページを参照してください。

Blob Storage または汎用 v2 アカウントでブロック BLOB の層を設定する場合、次の制限があります。

• rest バージョン 2019-12-12 では、スナップショットにレベルを設定できます。
• に階層化されたarchiveスナップショットは、スナップショットに再ハイドレートすることはできません。 つまり、スナップショットを または cool レベルにhot戻すことはできません。 スナップショットまたはバージョンからデータを取得するarchive唯一の方法は、新しい BLOB にコピーすることです。
• バージョンがルート BLOB の場合は、 または coolにhotリハイドレートできます。
• 状態のスナップショットまたはバージョンを archive ルートに昇格することはできません。
• バージョン管理が有効になっている場合、リハイドレートが保留中の状態のときにルート BLOB を削除すると、リハイドレートが取り消され、バージョンは状態になります archive 。
• BLOB がリハイドレート保留中および論理的に削除された状態のときに上書きされると、リハイドレートが取り消され、論理的に削除されたスナップショットのバージョンが状態になりますarchive。

サポートされているレベルの一覧は要求バージョンによって制限されず、今後新しいレベルが追加される可能性があります。

注意

ブロック BLOB レベルの階層化の詳細については、「 ホット、クール、アーカイブ ストレージ層」を参照してください。

請求

価格要求は、Blob Storage REST API を介して直接、または Azure Storage クライアント ライブラリから Blob Storage API を使用するクライアントから送信できます。 これらの要求では、トランザクションあたりの料金が発生します。 トランザクションの種類は、アカウントの課金方法に影響します。 たとえば、読み取りトランザクションは、書き込みトランザクションとは異なる課金カテゴリに計上されます。 次の表は、ストレージ アカウントの種類に基づく要求の課金カテゴリ Set Blob Tier を示しています。

操作	ストレージ アカウントの種類	課金カテゴリ
BLOB 層の設定 (階層ダウン)	Premium ブロック BLOB Standard 汎用 v2	書き込み操作
BLOB 層の設定 (階層化)	Premium ブロック BLOB Standard 汎用 v2	操作を読み取ります。

指定した課金カテゴリの価格については、「Azure Blob Storage価格」を参照してください。

こちらもご覧ください

Azure Storage への要求を承認する
状態コードとエラー コード
Blob Storage のエラー コード
Blob Storage 操作のタイムアウトを設定する