Example 7: Compliant ILM policy for S3 Object Lock
Suggest changes
PDFs
You can use the S3 bucket, ILM rules, and ILM policy in this example as a starting point when defining an ILM policy to meet the object protection and retention requirements for objects in buckets with S3 Object Lock enabled.
|
If you used the legacy Compliance feature in previous StorageGRID releases, you can also use this example to help manage any existing buckets that have the legacy Compliance feature enabled. |
|
The following ILM rules and policy are only examples. There are many ways to configure ILM rules. Before activating a new policy, simulate the proposed policy to confirm it will work as intended to protect content from loss. |
Bucket and objects for S3 Object Lock example
In this example, an S3 tenant account named Bank of ABC has used the Tenant Manager to create a bucket with S3 Object Lock enabled to store critical bank records.
| Bucket definition | Example value |
|---|---|
Tenant Account Name |
Bank of ABC |
Bucket Name |
bank-records |
Bucket Region |
us-east-1 (default) |
Each object and object version that is added to the bank-records bucket will use the following values for retain-until-date and legal hold settings.
| Setting for each object | Example value |
|---|---|
|
Each object version has its own |
|
A legal hold can be placed or lifted on any object version at any time during the retention period. If an object is under a legal hold, the object cannot be deleted even if the |
ILM rule 1 for S3 Object Lock example: Erasure Coding profile with bucket matching
This example ILM rule applies only to the S3 tenant account named Bank of ABC. It matches any object in the bank-records bucket and then uses erasure coding to store the object on Storage Nodes at three data center sites using a 6+3 Erasure Coding profile. This rule satisfies the requirements of buckets with S3 Object Lock enabled: an erasure-coded copy is kept on Storage Nodes from day 0 to forever, using Ingest Time as the reference time.
| Rule definition | Example value |
|---|---|
Rule Name |
Compliant Rule: EC objects in bank-records bucket - Bank of ABC |
Tenant Account |
Bank of ABC |
Bucket Name |
|
Advanced filtering |
Object Size (MB) greater than 0.20 Note: This filter ensures that erasure coding is not used for objects 200 KB or smaller. |
| Rule definition | Example value |
|---|---|
Reference Time |
Ingest Time |
Placements |
From day 0 store forever |
Erasure Coding Profile |
|
ILM rule 2 for S3 Object Lock example: Non-compliant rule
This example ILM rule initially stores two replicated object copies on Storage Nodes. After one year, it stores one copy on a Cloud Storage Pool forever. Because this rule uses a Cloud Storage Pool, it is not compliant and will not apply to the objects in buckets with S3 Object Lock enabled.
| Rule definition | Example value |
|---|---|
Rule Name |
Non-Compliant Rule: Use Cloud Storage Pool |
Tenant Accounts |
Not specified |
Bucket Name |
Not specified, but will only apply to buckets that do not have S3 Object Lock (or the legacy Compliance feature) enabled. |
Advanced filtering |
Not specified |
| Rule definition | Example value |
|---|---|
Reference Time |
Ingest Time |
Placements |
|
ILM rule 3 for S3 Object Lock example: Default rule
This example ILM rule copies object data to storage pools in two data centers. This compliant rule is designed to be the default rule in the ILM policy. It does not include any filters and it satisfies the requirements of buckets with S3 Object Lock enabled: two object copies are kept on Storage Nodes from day 0 to forever, using Ingest as the reference time.
| Rule definition | Example value |
|---|---|
Rule Name |
Default Compliant Rule: Two Copies Two Data Centers |
Tenant Account |
Not specified |
Bucket Name |
Not specified |
Advanced filtering |
Not specified |
| Rule definition | Example value |
|---|---|
Reference Time |
Ingest Time |
Placements |
From Day 0 to forever, keep two replicated copies—one on Storage Nodes in Data Center 1 and one on Storage Nodes in Data Center 2. |
Compliant ILM policy for S3 Object Lock example
To create an ILM policy that will effectively protect all objects in your system, including those in buckets with S3 Object Lock enabled, you must select ILM rules that satisfy the storage requirements for all objects. Then, you must simulate and activate the proposed policy.
Adding rules to the policy
In this example, the ILM policy includes three ILM rules, in the following order:
-
A compliant rule that uses erasure coding to protect objects larger than 200 KB in a specific bucket with S3 Object Lock enabled. The objects are stored on Storage Nodes from day 0 to forever.
-
A non-compliant rule that creates two replicated object copies on Storage Nodes for a year and then moves one object copy to a Cloud Storage Pool forever. This rule does not apply to buckets with S3 Object Lock enabled because it uses a Cloud Storage Pool.
-
The default compliant rule that creates two replicated object copies on Storage Nodes from day 0 to forever.
Simulating the proposed policy
After you have added rules in your proposed policy, chosen a default compliant rule, and arranged the other rules, you should simulate the policy by testing objects from the bucket with S3 Object Lock enabled and from other buckets. For example, when you simulate the example policy, you would expect test objects to be evaluated as follows:
-
The first rule will only match test objects that are larger than 200 KB in the bucket bank-records for the Bank of ABC tenant.
-
The second rule will match all objects in all non-compliant buckets for all other tenant accounts.
-
The default rule will match these objects:
-
Objects 200 KB or smaller in the bucket bank-records for the Bank of ABC tenant.
-
Objects in any other bucket that has S3 Object Lock enabled for all other tenant accounts.
-
Activating the policy
When you are completely satisfied that the new policy protects object data as expected, you can activate it.