データライフサイクルを自動管理してコストを最適化する

[アーティクル]
10/26/2023

データセットには一意のライフサイクルがあります。ライフサイクルの早い段階で、一部のデータに頻繁にアクセスされます。しかし、データが古くなるにつれてアクセスの必要性が急激に低下することがよくあります。使用されずにクラウドに留まるデータや、いったん格納されるとめったにアクセスされないデータもあります。データセットには、作成後数日や数か月で期限切れになるものがある一方で、ライフサイクル全体にわたってアクティブに読み取りと変更が行われるデータセットもあります。 Azure Blob Storage のライフサイクル管理にはルールベースのポリシーが用意されており、これを使用すると、最適なアクセス層に BLOB データを移行したり、データライフサイクルの最後にデータを期限切れにしたりすることができます。

Note

最後のアクセス時刻の更新は、1 日に数千回アクセスされた場合でも、オブジェクトごとに最大で 24 時間ごとに "他のトランザクション" として課金されます。これは、読み取りトランザクションの料金とは別です。

ライフサイクル管理ポリシーを使用すると、以下を行えます。

パフォーマンスを最適化するため、BLOB がアクセスされたときに BLOB をクールからホットに直ちに移行します。
コストを最適化するため、BLOB の現在のバージョン、BLOB の以前のバージョン、BLOB のスナップショットが一定期間アクセスも変更もされていない場合、それらのオブジェクトをよりクールなストレージ層に移行します。
ライフサイクルの最後に、BLOB の現在のバージョン、BLOB の以前のバージョン、BLOB スナップショットを削除します。
ストレージアカウント全体、一部のコンテナー、または名前のプレフィックスや BLOB インデックスタグをフィルターとして使って BLOB のサブセットに規則を適用できます。

データがライフサイクルの初期段階には頻繁にアクセスされるものの、2 週間後にはたまにしかアクセスされなくなるというシナリオについて考えてみましょう。 1 か月を超えると、そのデータセットにはほとんどアクセスされなくなります。このシナリオの初期段階ではホットストレージが最適です。ときどきアクセスされるデータにはクールストレージが適しています。 1 か月以上が経過したデータに最も適しているのは、アーカイブストレージです。ライフサイクル管理ポリシールールを使用して、経過時間に基づいてデータを適切なストレージ層に移動することで、ニーズに合う最もコストのかからないソリューションを設計できます。

汎用 v2、Premium ブロック BLOB、Blob Storage のアカウントでは、ブロック BLOB と追加 BLOB でライフサイクル管理ポリシーがサポートされています。ライフサイクル管理は、$logs コンテナーや $web コンテナーなどのシステムコンテナーには影響を与えません。

重要

データセットが読み取り可能である必要がある場合は、BLOB をアーカイブ層に移動するポリシーを設定しないでください。アーカイブ層の BLOB は、最初にリハイドレートされていない限り読み取ることができません。これは時間とコストがかかる場合があるプロセスです。詳細については、「アーカイブ層からの BLOB のリハイドレートの概要」を参照してください。データセットを頻繁に読み込む必要がある場合は、BLOB をクール層またはコールド層に移動するポリシーを設定しないでください。これにより、トランザクションコストが高くなる可能性があるためです。

ライフサイクル管理ポリシーの定義

ライフサイクル管理ポリシーは、JSON ドキュメントに記述されたルールのコレクションです。次のサンプル JSON に、完全なルール定義を示します。

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

1 つのポリシーは、次の表で説明するように、ルールのコレクションです。

パラメーター名	パラメーターのタイプ	Notes
`rules`	ルールオブジェクトの配列	ポリシーには少なくとも 1 つのルールが必要です。ポリシーでは最大 100 のルールを定義できます。

ポリシー内の各ルールには、次の表で説明するように、いくつかのパラメーターがあります。

パラメーター名	パラメーターのタイプ	Notes	必須
`name`	String	ルール名には最大 256 の英数字を含めることができます。ルール名は大文字と小文字が区別されます。名前は、ポリシー内で一意にする必要があります。	True
`enabled`	Boolean	ルールを一時的に無効にすることを許可する省略可能なブール値。設定されていない場合、既定値は true です。	False
`type`	列挙型の値	現在の有効な種類は `Lifecycle` です。	True
`definition`	ライフサイクルルールを定義するオブジェクト	各定義は、フィルターセットとアクションセットで構成されます。	True

ライフサイクル管理ルールの定義

ポリシー内の各ルール定義には、フィルターセットとアクションセットが含まれます。フィルターセットは、コンテナー内の特定のオブジェクトセットまたはオブジェクト名にルールアクションを制限します。アクションセットは、階層化または削除アクションをオブジェクトのフィルター処理されたセットに適用します。

ルールのサンプル

次のサンプルルールは、sample-container 内に存在し、blob1 で始まるオブジェクトに対してアクションを実行するようにアカウントをフィルター処理します。

BLOB を最後に変更されたときから 30 日後にクール層に階層化する
BLOB を最後に変更されたときから 90 日後にアーカイブ層に階層化する
BLOB を最後に変更されたときから 2,555 日 (7 年) 後に削除する
以前のバージョンを作成から 90 日後に削除する

{
  "rules": [
    {
      "enabled": true,
      "name": "sample-rule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90,
              "daysAfterLastTierChangeGreaterThan": 7
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

注意

ライフサイクル管理ポリシーの baseBlob 要素は、BLOB の現在のバージョンを参照します。 version要素は、以前のバージョンを参照します。

ルールフィルター

フィルターを使用すると、ルールアクションをストレージアカウント内の BLOB のサブセットに限定できます。複数のフィルターが定義されている場合、すべてのフィルターで論理 AND が実行されます。フィルターを使用して、含める BLOB を指定できます。フィルターでは、除外する BLOB を指定する手段はありません。

フィルターには次のものが含まれます。

フィルター名	フィルターの種類	Notes	必須
blobTypes	定義済みの列挙型の値の配列。	現在のリリースでは `blockBlob` および `appendBlob` をサポートしています。 `appendBlob` では Delete アクションのみがサポートされています。Set Tier はサポートされていません。	はい
prefixMatch	プレフィックスを照合する文字列の配列。各ルールで大文字と小文字を区別するプレフィックスを最大 10 個定義できます。プレフィックス文字列はコンテナー名で始まる必要があります。たとえば、`https://myaccount.blob.core.windows.net/sample-container/blob1/...` のすべての BLOB を照合する場合は、prefixMatch を `sample-container/blob1` として指定します。このフィルターは、blob1 で名前が始まるサンプルコンテナー内のすべての BLOB を照合します。 .	prefixMatch を定義していない場合、ルールはストレージアカウント内のすべての BLOB に適用されます。プレフィックス文字列では、ワイルドカード一致はサポートされていません。 `*` や `?` などの文字は、文字列リテラルとして扱われます。	いいえ
blobIndexMatch	照合する BLOB インデックスタグキーと値条件で構成されるディクショナリ値の配列。各ルールには、最大 10 個の BLOB インデックスタグ条件を定義できます。たとえば、ルールとして `https://myaccount.blob.core.windows.net/` の下にあるすべての BLOB を `Project = Contoso` に一致させたい場合、blobIndexMatch は `{"name": "Project","op": "==","value": "Contoso"}` になります。	blobIndexMatch を定義していない場合、ルールはストレージアカウント内のすべての BLOB に適用されます。	いいえ

BLOB インデックス機能と、既知の問題および制限事項の詳細については、BLOB インデックスを使用して Azure Blob Storage でデータを管理および検索することに関するページを参照してください。

ルールのアクション

実行条件が満たされている場合、アクションはフィルター処理された BLOB に適用されます。

ライフサイクル管理では、BLOB、以前の BLOB バージョン、および BLOB スナップショットの階層化と削除がサポートされています。各ルールに対して少なくとも 1 つのアクションを定義します。

注意

Premium ブロック BLOB ストレージアカウントでは、階層化はまだサポートされていません。他のすべてのアカウントでは、階層化はブロック BLOB でのみ許可され、追加およびページ BLOB では許可されません。

アクション	現在のバージョン	スナップショット	以前のバージョン
tierToCool	`blockBlob` でサポート	サポートされています	サポートされています
tierToCold	`blockBlob` でサポート	サポートされています	サポートされています
enableAutoTierToHotFromCool¹	`blockBlob` でサポート	サポートされていません	サポートされていません
tierToArchive⁴	`blockBlob` でサポート	サポートされています	サポートされています
delete^2、3	`blockBlob` および `appendBlob` に対してサポートされています	サポートされています	サポートされています

¹enableAutoTierToHotFromCool アクションは、daysAfterLastAccessTimeGreaterThan 実行条件で使用する場合にのみ使用できます。この条件については、次の表で説明します。

² 階層型名前空間が有効になっているアカウントに適用すると、削除アクションによって空のディレクトリが削除されます。ディレクトリが空でない場合、削除アクションでは、最初のライフサイクルポリシー実行サイクル内のポリシー条件を満たすオブジェクトが削除されます。そのアクションの結果、空のディレクトリになり、ポリシー条件も満たされる場合、そのディレクトリは次の実行サイクル内で削除される、というように続きます。

³ ライフサイクル管理ポリシーでは、その BLOB に関連付けられている以前のバージョンまたはスナップショットが削除されるまで、BLOB の現在のバージョンは削除されません。ストレージアカウント内の BLOB に以前のバージョンまたはスナップショットがある場合は、ポリシーの一部として削除アクションを指定するときに、以前のバージョンとスナップショットを含める必要があります。

⁴ アーカイブアクセス層への BLOB の移動は、LRS、GRS、または RA-GRS 用に構成されたストレージアカウントでのみサポートされます。アーカイブアクセス層は、ZRS、GZRS、RA-GZRS のアカウントではサポートされていません。このアクションは、アカウントに構成された冗長性に基づいて一覧表示されます。

Note

同じ BLOB に複数のアクションを定義した場合、ライフサイクル管理によって最も低コストのアクションが BLOB に適用されます。たとえば、delete アクションは tierToArchive アクションよりも低コストです。 tierToArchive アクションは tierToCool アクションよりも低コストです。

実行条件は、古さに基づいています。現在のバージョンでは、最終変更時刻または最終アクセス時刻を使用し、以前の BLOB バージョンではバージョン作成時刻を使用し、BLOB スナップショットでは、スナップショットの作成時刻を使用して古さが追跡されます。

アクションの実行条件	条件値	説明
daysAfterModificationGreaterThan	古さを日数で示す整数値	現在のバージョンの blob に対するアクションの条件
daysAfterCreationGreaterThan	古さを日数で示す整数値	現在のバージョンまたは以前のバージョンの BLOB または BLOB のスナップショットに対するアクションの条件
daysAfterLastAccessTimeGreaterThan¹	古さを日数で示す整数値	アクセス追跡が有効になっている場合の現在のバージョンの blob の条件
daysAfterLastTierChangeGreaterThan	BLOB 層の最終変更時刻から経過した日数を示す整数値	この条件は `tierToArchive` アクションにのみ適用され、`daysAfterModificationGreaterThan` 条件との併用でのみ使用できます。

¹最終アクセス時間の追跡が有効でない場合、daysAfterLastAccessTimeGreaterThan には、BLOB の LastAccessTime プロパティではなく、ライフサイクルポリシーが有効になった日付が使われます。この日付は、LastAccessTime プロパティが null 値の場合にも使用されます。最終アクセス時刻の追跡の使用の詳細については、「最終アクセス時刻に基づいてデータを移動する」を参照してください。

ライフサイクルポリシーの実行

ライフサイクルポリシーは、プラットフォームによって 1 日に 1 回実行されます。ライフサイクルポリシーを構成または編集すると、変更が有効になり、最初の実行が開始されるまでに最大で 24 時間かかる場合があります。ポリシーアクションが完了するまでにかかる時間は、評価および操作される BLOB の数によって異なります。

ポリシーを無効にすると、新しいポリシー実行はスケジュールされませんが、実行が既に進行中の場合、その実行は完了まで続行され、実行の完了に必要なアクションがあれば、それに対して課金されます。「リージョン別の可用性と料金」を参照してください。

ライフサイクルポリシーが完了したイベント

ライフサイクル管理ポリシーで定義されたアクションが実行されると、LifecyclePolicyCompleted イベントが生成されます。次の JSON は、LifecyclePolicyCompleted エントリの例を示しています。

{
    "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
    "subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
    "eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
    "eventTime": "2022-05-26T00:00:40.1880331",    
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "data": {
        "scheduleTime": "2022/05/24 22:57:29.3260160",
        "deleteSummary": {
            "totalObjectsCount": 16,
            "successCount": 14,
            "errorList": ""
        },
        "tierToCoolSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToArchiveSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        }
    },
    "dataVersion": "1",
    "metadataVersion": "1"
}

次の表で、LifecyclePolicyCompleted イベントのスキーマについて説明します。

フィールド	タイプ	説明
scheduleTime	string	ライフサイクルポリシーがスケジュールされた時刻。
deleteSummary	ベクター<バイト>	delete 操作のためにスケジュールされた BLOB の結果の概要
tierToCoolSummary	ベクター<バイト>	tier-to-cool 操作のためにスケジュールされた BLOB の結果の概要
tierToArchiveSummary	ベクター<バイト>	tier-to-archive 操作にスケジュールされた BLOB の結果の概要

ライフサイクルポリシーの例

次の例では、ライフサイクルポリシールールを使用して一般的なシナリオに対処する方法を示します。

古いデータをよりクールな層に移動する

次の例は、プレフィックス sample-container/blob1 または container2/blob2 が付いたブロック BLOB を移行する方法を示しています。このポリシーでは、30 日以上変更されていない BLOB をクールストレージに移行し、90 日間変更されていない BLOB をアーカイブ層に移行します。

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

最終アクセス時刻に基づいてデータを移動する

最終アクセス時刻の追跡を有効にすると、BLOB データの階層化と保持を管理するためのフィルターとして、BLOB が最後に読み書きされた時刻の記録を保持することができます。最終アクセス時刻の追跡を有効にする方法については、「オプションであるアクセス時間の追跡を有効にする」を参照してください。

最終アクセス時刻追跡機能が有効になっている場合、BLOB が読み取られるか書き込まれるときに LastAccessTime という名前の BLOB プロパティが更新されます。 Get Blob 操作はアクセス操作と見なされます。 BLOB プロパティの取得、BLOB メタデータの取得、および BLOB タグの取得は、アクセス操作ではないので、最終アクセス時刻を更新しません。

最終アクセス時間の追跡が有効な場合、ライフサイクル管理は LastAccessTime を使って実行条件 daysAfterLastAccessTimeGreaterThan が満たされているかどうかを判断します。ライフサイクル管理では、次の場合、LastAccessTime ではなく、ライフサイクルポリシーが有効になった日付が使用されます。

BLOB の LastAccessTime プロパティの値が null 値である。

Note

最後のアクセス時刻の追跡が有効になってから BLOB へのアクセスがない場合、BLOB の lastAccessedOn プロパティは null です。
最終アクセス時刻の追跡が有効になっていない。

読み取りアクセス待ち時間への影響を最小限に抑えるために、過去 24 時間の最初の読み取りのみが最終アクセス時刻を更新します。同じ 24 時間内のその後の読み取りでは、最終アクセス時刻は更新されません。読み取り間で BLOB が変更された場合、最終アクセス時刻は 2 つの値のうち新しい方になります。

次の例では、BLOB は、30 日間アクセスされない場合に、クールストレージに移動されます。 enableAutoTierToHotFromCool プロパティはブール値であり、BLOB がクールに階層化された後で再びアクセスされた場合に、BLOB を自動的にクールからホットに階層化するかどうかを示します。

ヒント

BLOB がクール層に移動され、30 日が経過する前に自動的に戻された場合、早期削除料金が課金されます。 enablAutoTierToHotFromCool プロパティを設定する前に、予想外の課金を減らせるよう、必ずデータのアクセスパターンを分析してください。

{
  "enabled": true,
  "name": "last-accessed-thirty-days-ago",
  "type": "Lifecycle",
  "definition": {
    "actions": {
      "baseBlob": {
        "enableAutoTierToHotFromCool": true,
        "tierToCool": {
          "daysAfterLastAccessTimeGreaterThan": 30
        }
      }
    },
    "filters": {
      "blobTypes": [
        "blockBlob"
      ],
      "prefixMatch": [
        "mylifecyclecontainer/log"
      ]
    }
  }
}

取り込み後にデータをアーカイブする

クラウド内でアイドル状態に留まり、あったとしてもまれにしかアクセスされないデータもあります。次のライフサイクルポリシーは、取り込み直後にデータをアーカイブするように構成されます。この例では、archivecontainer という名前のコンテナー内のブロック BLOB をアーカイブ層に移行します。この移行は、最終変更時刻の 0 日後に BLOB を処理することによって実現されます。

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { 
                "daysAfterModificationGreaterThan": 0
              }
          }
        }
      }
    }
  ]
}

注意

効率を高めるためには、BLOB をアーカイブ層に直接アップロードすることをお勧めします。アーカイブ層は、Put BLOB または Put Block List 操作の x-ms-access-tier ヘッダーで指定できます。 x-ms-access-tier ヘッダーは、REST バージョン 2018-11-09 以降または最新の BLOB ストレージクライアントライブラリでサポートされています。

古さに基づいてデータを期限切れにする

データの中には、作成後数日または数か月後に失効することが想定されているものがあります。データを古さに基づいて削除することでデータを期限切れに設定するように、ライフサイクル管理ポリシーを構成できます。次の例は、過去 365 日間に変更されていないすべてのブロック BLOB を削除するポリシーを示しています。

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

BLOB インデックスタグを使用してデータを削除する

一部のデータは、削除対象として明示的にマークされている場合のみ有効期限切れになる必要があります。期限切れにするには、データに BLOB インデックスのキー/値属性でタグ付けして、ライフサイクル管理ポリシーを構成します。次の例は、Project = Contoso でタグ付けされたすべてのブロック BLOB を削除するポリシーを示しています。 BLOB インデックスの詳細については、「BLOB インデックスを使用して Azure Blob Storage でデータを管理および検索する」を参照してください。

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

以前のバージョンを管理する

有効期間全体にわたって定期的に変更およびアクセスされるデータの場合は、BLOB ストレージのバージョン管理を有効にすることで、オブジェクトの以前のバージョンを自動的に管理できます。ポリシーを作成して、以前のバージョンを階層化または削除することができます。バージョンの古さは、バージョンの作成時刻を評価することによって決定されます。このポリシールールは、バージョンの作成後 90 日以上経過したコンテナー activedata 内の以前のバージョンをクール層に移動し、365 日またはそれ以前のバージョンを削除します。

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata/"
          ]
        }
      }
    }
  ]
}

リージョン別の可用性と料金

ライフサイクル管理機能は、すべての Azure リージョンで使用できます。

ライフサイクル管理ポリシーは無料です。お客様に課金されるのは、Set Blob Tier API 呼び出しの標準的な操作のコストに対してです。削除操作は無料です。ただし、Microsoft Defender for Storage などの他の Azure サービスやユーティリティは、ライフサイクルポリシーを通じて管理される操作に対して課金される場合があります。

BLOB の最終アクセス時刻が更新されるたびに、その他の操作のカテゴリで請求が行われます。

価格の詳細については、「ブロック BLOBの料金」を参照してください。

既知の問題と制限事項

Premium ブロック BLOB ストレージアカウントでは、階層化はまだサポートされていません。他のすべてのアカウントでは、階層化はブロック BLOB でのみ許可され、追加およびページ BLOB では許可されません。
ライフサイクル管理ポリシーは、その全体の読み取りまたは書き込みを行う必要があります。部分的な更新はサポートされません。
各ルールには、最大 10 個の大文字と小文字を区別するプレフィックスと、最大 10 個の BLOB インデックスタグ条件を指定できます。
ストレージアカウントのファイアウォールルールを有効にしている場合、ライフサイクル管理要求がブロックされることがあります。信頼できる Microsoft サービスに例外を指定することで、このような要求のブロックを解除できます。詳細については、ファイアウォールと仮想ネットワークの構成に関する記事の、例外についてのセクションを参照してください。
暗号化スコープを使用する BLOB の層をライフサイクル管理ポリシーで変更することはできません。
ライフサイクル管理ポリシーの削除アクションは、不変コンテナー内の BLOB では機能しません。不変ポリシーを使用すると、オブジェクトを作成および読み取ることはできますが、変更または削除することはできません。詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。

よく寄せられる質問 (FAQ)

「ライフサイクル管理の FAQ」を参照してください。

データライフサイクルを自動管理してコストを最適化する

ライフサイクル管理ポリシーの定義

ライフサイクル管理ルールの定義

ルールのサンプル

ルールフィルター

ルールのアクション

ライフサイクルポリシーの実行

ライフサイクルポリシーが完了したイベント

ライフサイクルポリシーの例

古いデータをよりクールな層に移動する

最終アクセス時刻に基づいてデータを移動する

取り込み後にデータをアーカイブする

古さに基づいてデータを期限切れにする

BLOB インデックスタグを使用してデータを削除する

以前のバージョンを管理する

リージョン別の可用性と料金

既知の問題と制限事項

よく寄せられる質問 (FAQ)

次のステップ

その他のリソース

データ ライフサイクルを自動管理してコストを最適化する

ライフサイクル管理ポリシーの定義

ライフサイクル管理ルールの定義

ルールのサンプル

ルール フィルター

ルールのアクション

ライフサイクル ポリシーの実行

ライフサイクル ポリシーが完了したイベント

ライフサイクル ポリシーの例

古いデータをよりクールな層に移動する

最終アクセス時刻に基づいてデータを移動する

取り込み後にデータをアーカイブする

古さに基づいてデータを期限切れにする

BLOB インデックス タグを使用してデータを削除する

以前のバージョンを管理する

リージョン別の可用性と料金

既知の問題と制限事項

よく寄せられる質問 (FAQ)

次のステップ

その他のリソース

データライフサイクルを自動管理してコストを最適化する

ルールフィルター

ライフサイクルポリシーの実行

ライフサイクルポリシーが完了したイベント

ライフサイクルポリシーの例

BLOB インデックスタグを使用してデータを削除する