diff --git a/pages/index.md b/pages/index.md index b7f73c0eb1e..6934a041f36 100644 --- a/pages/index.md +++ b/pages/index.md @@ -843,6 +843,7 @@ + [Object Storage - Use Object Storage with Pure Storage Flashblade](storage_and_backup/object_storage/s3_pure_storage_flashblade) + [Object Storage - Manage an Object Storage bucket with Terraform](storage_and_backup/object_storage/s3_terraform) + [Object Storage – How to share an object or file externally](storage_and_backup/object_storage/s3_share_object_externally) + + [Object Storage - Combining lifecycle policies and asynchronous replication](storage_and_backup/object_storage/s3_use_cases_lifecycle_replication) + [Security](products/public-cloud-storage-object-storage-s3-security) + [Object Storage - Encrypt your server-side objects with SSE-C](storage_and_backup/object_storage/s3_encrypt_your_objects_with_sse_c) + [Object Storage - Managing object immutability with Object Lock (WORM)](storage_and_backup/object_storage/s3_managing_object_lock) diff --git a/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/guide.en-gb.md b/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/guide.en-gb.md new file mode 100644 index 00000000000..cbe89bdcd40 --- /dev/null +++ b/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/guide.en-gb.md @@ -0,0 +1,1085 @@ +--- +title: "Object Storage - Combining lifecycle policies and asynchronous replication" +excerpt: "Learn how to combine Object Storage lifecycle policies and asynchronous replication to address advanced data management use cases" +updated: 2026-04-17 +--- + +## Objective + +OVHcloud Object Storage offers two powerful automation features that, when combined, can address a wide range of production data management challenges: + +- **Lifecycle policies** automate transitions between storage classes (Standard → Infrequent Access → Active Archive → Cold Archive) and the expiration (deletion) of objects based on rules you define. +- **Asynchronous replication** automatically copies objects from a source bucket to one or more destination buckets, within the same region or across different regions. + +Used in isolation, each feature already provides significant value. Used together, they unlock architectures that are simultaneously cost-efficient, resilient, and compliant. + +This guide covers seven production-ready use cases that combine both features: + +1. [Regulatory archiving and compliance](#use-case-1-regulatory-archiving-and-compliance) +2. [Disaster recovery](#use-case-2-disaster-recovery) +3. [Data lake and automated tiering](#use-case-3-data-lake-and-automated-tiering) +4. [Geographic content distribution](#use-case-4-geographic-content-distribution) +5. [Dev/Staging environment management](#use-case-5-devstaging-environment-management) +6. [Logs and observability](#use-case-6-logs-and-observability) +7. [SaaS multi-tenant backup](#use-case-7-saas-multi-tenant-backup) + +## Requirements + +- An active [OVHcloud Public Cloud project](https://www.ovhcloud.com/en-gb/public-cloud/) +- Object Storage buckets created in one or more OVHcloud regions. Refer to our guide [Getting started with Object Storage](/pages/storage_and_backup/object_storage/s3_getting_started_with_object_storage/guide.en-gb) if needed +- A working understanding of OVHcloud storage classes. Refer to our guide [Choosing the right storage class for your needs](/pages/storage_and_backup/object_storage/s3_storage_class/guide.en-gb) +- A working understanding of lifecycle policies. Refer to our guide [Object Storage - Managing object lifecycle](/pages/storage_and_backup/object_storage/s3_lifecycle/guide.en-gb) +- A working understanding of asynchronous replication. Refer to our guide [Object Storage - Mastering asynchronous replication across your buckets](/pages/storage_and_backup/object_storage/s3_replication/guide.en-gb) +- **For CLI steps only**: the AWS CLI installed and configured with your OVHcloud Object Storage credentials and endpoint. Refer to our guide [Getting started with Object Storage](/pages/storage_and_backup/object_storage/s3_getting_started_with_object_storage/guide.en-gb) + +> [!primary] +> Every step in this guide can be performed either via the **OVHcloud Control Panel** or via the **AWS CLI**. Both approaches are described for each step. CLI examples use the OVHcloud endpoint format: +> ```bash +> --endpoint-url https://s3..io.cloud.ovh.net +> ``` +> Replace `` with your actual region slug (e.g. `gra`, `sbg`, `de`, `uk`), and replace all placeholder bucket names and prefixes with your own values. + +## Storage class mapping reference + +All CLI examples in this guide use the S3 API `StorageClass` values as required for **write operations** (PUT, lifecycle transitions, replication destination) on the OVHcloud `.io` endpoint. The mapping differs between **3-AZ regions** and **1-AZ regions**. + +> [!primary] +> The mapping below reflects the current state as of **2026-01-03**. Refer to the [Object Storage - Endpoints and geoavailability](/pages/storage_and_backup/object_storage/s3_location/guide.en-gb) guide for the full and up-to-date reference. + +**3-AZ regions (e.g. Paris `eu-west-par`, Milan `eu-south-mil`)** + +| S3 API `StorageClass` value | OVHcloud storage tier | +|---|---| +| `EXPRESS_ONEZONE` | High Performance | +| `STANDARD` (also `INTELLIGENT_TIERING` or default) | Standard | +| `STANDARD_IA` (also `ONEZONE_IA`) | Infrequent Access | +| `GLACIER_IR` (also `GLACIER`) | Active Archive | +| `DEEP_ARCHIVE` | Cold Archive | + +**1-AZ regions (e.g. GRA, SBG, DE, UK, BHS, WAW, ...)** + +| S3 API `StorageClass` value | OVHcloud storage tier | +|---|---| +| `EXPRESS_ONEZONE` | High Performance | +| `STANDARD` (also `INTELLIGENT_TIERING` or default) | Standard | +| `STANDARD_IA` (also `ONEZONE_IA`, `GLACIER_IR`, `GLACIER`, `DEEP_ARCHIVE`) | Infrequent Access | + +> [!warning] +> In **1-AZ regions**, `GLACIER_IR`, `GLACIER`, and `DEEP_ARCHIVE` all map to **Infrequent Access** - there are no deeper archive tiers available. Cold Archive is currently available in 3-AZ regions only, and only in Paris (`eu-west-par`). + +> [!warning] +> This mapping applies to the `.io` endpoint only. The legacy `.perf` endpoint uses a different mapping and is maintained for backward compatibility purposes only. + +--- + +## Use case 1 - Regulatory archiving and compliance + +### Context + +Organisations in regulated industries (finance, healthcare, legal) must retain certain data for legally mandated periods - often 5 to 10 years - while keeping storage costs under control and ensuring data is available in a secondary jurisdiction if required. A typical requirement combines: + +- Automatic transition to cheaper storage classes as data ages +- A compliant copy in a geographically separate region + +### Architecture + +| Bucket | Region | Role | +|--------|--------|------| +| `compliance-primary-` | e.g. GRA | Receives all new objects; applies the lifecycle transitions | +| `compliance-archive-` | e.g. DE | Replication destination; receives a copy of every object for long-term retention | + +The lifecycle policy on the **primary bucket** handles cost optimisation. Asynchronous replication to the **secondary bucket** handles geographic redundancy and jurisdiction requirements. The secondary bucket can have its own, independent lifecycle policy for long-term retention. + +### Step 1 - Enable versioning on both buckets + +Asynchronous replication requires versioning to be enabled on both the source and destination buckets. + +**Via the OVHcloud Control Panel** + +Log in to the [OVHcloud Control Panel](https://www.ovh.com/auth/), go to the `Public Cloud`{.action} section, and select your project. Click `Object Storage`{.action} in the left-hand menu, then on the `My containers`{.action} tab. Click the name of your source bucket (`compliance-primary-`), then select the `Versioning`{.action} tab. Toggle versioning to **Enabled** and click `Save`{.action}. Repeat this operation for the destination bucket (`compliance-archive-`). + +**Via the AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket compliance-primary- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket compliance-archive- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 2 - Configure replication on the primary bucket + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your source bucket, then select the `Replication`{.action} tab. Click `Add a replication rule`{.action}. Set the destination bucket to `compliance-archive-`, set the destination storage class to **Standard**, enable **Delete marker replication**, and click `Save`{.action}. + +**Via the AWS CLI** + +Create a file named `replication-compliance.json`: + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-all-to-compliance-region", + "Status": "Enabled", + "Priority": 1, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Enabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::compliance-archive-", + "StorageClass": "STANDARD" + } + } + ] +} +``` + +Apply it: + +```bash +aws s3api put-bucket-replication \ + --bucket compliance-primary- \ + --replication-configuration file://replication-compliance.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 3 - Apply the lifecycle policy on the primary bucket + +This configuration transitions objects through Infrequent Access, Active Archive, and Cold Archive as data ages. Archive tiers are only available in 3-AZ regions. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your source bucket and select the `Lifecycle rules`{.action} tab. Click `Add a rule`{.action}. Leave the prefix filter empty. For **3-AZ regions**, add three transition actions: **Infrequent Access** at day 30, **Active Archive** at day 90, and **Cold Archive** at day 365. For **1-AZ regions**, add only the **Infrequent Access** transition at day 30. Click `Save`{.action}. + +**Via the AWS CLI** + +Create a file named `lifecycle-compliance.json`: + +> [!primary] +> The example below targets a **3-AZ region** (e.g. Paris `eu-west-par`). It uses `GLACIER_IR` for Active Archive and `DEEP_ARCHIVE` for Cold Archive, both available in 3-AZ only. For **1-AZ regions**, remove both archive transitions - only `STANDARD_IA` is available. + +```json +{ + "Rules": [ + { + "ID": "compliance-tiering", + "Status": "Enabled", + "Filter": {}, + "Transitions": [ + { "Days": 30, "StorageClass": "STANDARD_IA" }, + { "Days": 90, "StorageClass": "GLACIER_IR" }, + { "Days": 365, "StorageClass": "DEEP_ARCHIVE" } + ] + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket compliance-primary- \ + --lifecycle-configuration file://lifecycle-compliance.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 4 - Apply a long-term retention lifecycle on the secondary bucket + +This configuration retains objects for 7 years (2555 days) before expiration. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your destination bucket and select the `Lifecycle rules`{.action} tab. Click `Add a rule`{.action}. Leave the prefix filter empty. Add an expiration action set to **2555 days**. Click `Save`{.action}. + +**Via the AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "long-term-retention", + "Status": "Enabled", + "Filter": {}, + "Expiration": { "Days": 2555 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket compliance-archive- \ + --lifecycle-configuration file://lifecycle-archive.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!primary] +> Replication copies the object at the time of its creation. If the object transitions to a cheaper storage class on the primary bucket, the replica in the secondary bucket retains its own storage class independently. This means you can optimise costs differently on each side. + +--- + +## Use case 2 - Disaster recovery + +### Context + +A disaster recovery (DR) strategy for Object Storage requires a copy of all data in a remote region, with a recovery time objective (RTO) and recovery point objective (RPO) that align with your SLA. The typical pattern is: + +- **Primary bucket**: short retention, Standard storage class, low cost +- **DR bucket**: full copy in a remote region, longer retention in Infrequent Access class to reduce standby cost + +Asynchronous replication ensures the DR bucket stays up to date (~15 minutes lag). Lifecycle policies on the primary bucket keep costs down by expiring objects that are already safely replicated. + +### Architecture + +| Bucket | Region | Role | +|--------|--------|------| +| `dr-primary-` | e.g. GRA | Production data; short retention lifecycle | +| `dr-backup-` | e.g. UK | DR replica; Infrequent Access class; longer retention | + +### Step 1 - Enable versioning on both buckets + +**Via the OVHcloud Control Panel** + +Log in to the [OVHcloud Control Panel](https://www.ovh.com/auth/), go to `Public Cloud`{.action} and select your project. Click `Object Storage`{.action} then `My containers`{.action}. For each bucket (`dr-primary-` and `dr-backup-`), click its name, select the `Versioning`{.action} tab, toggle to **Enabled**, and click `Save`{.action}. + +**Via the AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket dr-primary- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket dr-backup- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 2 - Configure replication to the DR bucket + +Replicated objects are stored directly in Infrequent Access on the DR side to reduce standby storage costs. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your primary bucket and select the `Replication`{.action} tab. Click `Add a replication rule`{.action}. Set the destination to `dr-backup-`, set the destination storage class to **Infrequent Access**, disable **Delete marker replication** to protect the DR copy from accidental deletions, and click `Save`{.action}. + +**Via the AWS CLI** + +Create a file named `replication-dr.json`: + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "dr-replication", + "Status": "Enabled", + "Priority": 1, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::dr-backup-", + "StorageClass": "STANDARD_IA" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket dr-primary- \ + --replication-configuration file://replication-dr.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 3 - Apply a short-retention lifecycle on the primary bucket + +Objects expire after 60 days; non-current versions are cleaned up after 7 days. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your primary bucket and select the `Lifecycle rules`{.action} tab. Click `Add a rule`{.action}. Leave the prefix empty. Add an expiration action set to **60 days** and a non-current version expiration set to **7 days**. Click `Save`{.action}. + +**Via the AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "primary-short-retention", + "Status": "Enabled", + "Filter": {}, + "Expiration": { "Days": 60 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 7 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket dr-primary- \ + --lifecycle-configuration file://lifecycle-dr-primary.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 4 - Apply a longer retention lifecycle on the DR bucket + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your DR bucket and select the `Lifecycle rules`{.action} tab. Click `Add a rule`{.action}. Leave the prefix empty. Set expiration to **365 days** and non-current version expiration to **30 days**. Click `Save`{.action}. + +**Via the AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "dr-retention", + "Status": "Enabled", + "Filter": {}, + "Expiration": { "Days": 365 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 30 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket dr-backup- \ + --lifecycle-configuration file://lifecycle-dr-backup.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!warning] +> **Delete marker replication** is disabled in the DR replication rule above. This prevents deletions on the primary bucket from propagating to the DR bucket, protecting the replica against accidental or malicious deletions. Adjust this setting if your use case requires full consistency between both buckets. + +--- + +## Use case 3 - Data lake and automated tiering + +### Context + +Data lake architectures generate large volumes of objects that are queried frequently when fresh (hot), occasionally after a few weeks (warm), and rarely beyond a few months (cold). Storing everything at the same storage class is unnecessarily expensive. The combination of lifecycle tiering on a central bucket and replication to an analytics-dedicated bucket enables: + +- Automatic cost reduction as data ages on the primary lake bucket +- A stable, always-Standard copy available to analytics tools in another region, unaffected by the tiering transitions + +### Architecture + +| Bucket | Region | Role | +|--------|--------|------| +| `datalake-main-` | e.g. GRA | Primary data lake; tiered lifecycle | +| `datalake-analytics-` | e.g. DE | Analytics replica; remains in Standard class | + +### Step 1 - Enable versioning on both buckets + +**Via the OVHcloud Control Panel** + +Log in to the [OVHcloud Control Panel](https://www.ovh.com/auth/), go to `Public Cloud`{.action} and select your project. Click `Object Storage`{.action} then `My containers`{.action}. For each bucket, click its name, select the `Versioning`{.action} tab, toggle to **Enabled**, and click `Save`{.action}. + +**Via the AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket datalake-main- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket datalake-analytics- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 2 - Configure replication to the analytics bucket + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your main data lake bucket and select the `Replication`{.action} tab. Click `Add a replication rule`{.action}. Leave the prefix filter empty. Set the destination to `datalake-analytics-`, set the destination storage class to **Standard**, disable **Delete marker replication**, and click `Save`{.action}. + +**Via the AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-to-analytics", + "Status": "Enabled", + "Priority": 1, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::datalake-analytics-", + "StorageClass": "STANDARD" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket datalake-main- \ + --replication-configuration file://replication-datalake.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 3 - Apply prefix-based tiering lifecycle on the main bucket + +This configuration applies different tiering schedules to raw data and processed data using prefix filters. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your main bucket and select the `Lifecycle rules`{.action} tab. Use `Add a rule`{.action} to add two rules separately: + +- **Rule 1** - prefix `raw/`: transitions to **Infrequent Access** at day 30, **Active Archive** at day 90, **Cold Archive** at day 365 (3-AZ only) +- **Rule 2** - prefix `processed/`: transitions to **Infrequent Access** at day 60, **Active Archive** at day 180 (3-AZ only) + +**Via the AWS CLI** + +> [!primary] +> `GLACIER_IR` maps to Active Archive and `DEEP_ARCHIVE` maps to Cold Archive - both are available in **3-AZ regions** only. For **1-AZ regions**, use only `STANDARD_IA`. + +```json +{ + "Rules": [ + { + "ID": "tier-raw-data", + "Status": "Enabled", + "Filter": { "Prefix": "raw/" }, + "Transitions": [ + { "Days": 30, "StorageClass": "STANDARD_IA" }, + { "Days": 90, "StorageClass": "GLACIER_IR" }, + { "Days": 365, "StorageClass": "DEEP_ARCHIVE" } + ] + }, + { + "ID": "tier-processed-data", + "Status": "Enabled", + "Filter": { "Prefix": "processed/" }, + "Transitions": [ + { "Days": 60, "StorageClass": "STANDARD_IA" }, + { "Days": 180, "StorageClass": "GLACIER_IR" } + ] + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket datalake-main- \ + --lifecycle-configuration file://lifecycle-datalake.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!primary] +> The analytics replica keeps all objects in Standard class regardless of transitions applied on the source. Your analytics tools always access immediately available data without retrieval delays or additional restore costs. + +--- + +## Use case 4 - Geographic content distribution + +### Context + +Organisations distributing static assets (media files, software packages, firmware updates, documentation) to users in multiple regions benefit from keeping copies close to their end users. The combination of replication and lifecycle gives you: + +- Automatic propagation of new content to regional buckets +- Automatic expiration of outdated versions locally, preventing storage drift over time + +### Architecture + +| Bucket | Region | Role | +|--------|--------|------| +| `content-origin-` | e.g. GRA | Master origin; all content is uploaded here | +| `content-eu-west-` | e.g. UK | Regional edge replica | +| `content-eu-central-` | e.g. DE | Regional edge replica | + +### Step 1 - Enable versioning on all buckets + +**Via the OVHcloud Control Panel** + +Log in to the [OVHcloud Control Panel](https://www.ovh.com/auth/) and go to `Public Cloud`{.action} > `Object Storage`{.action} > `My containers`{.action}. For each of the three buckets, click its name, select the `Versioning`{.action} tab, toggle to **Enabled**, and click `Save`{.action}. + +**Via the AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket content-origin- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket content-eu-west- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket content-eu-central- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 2 - Configure multi-destination replication on the origin bucket + +OVHcloud Object Storage supports multiple replication rules on a single bucket. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your origin bucket and select the `Replication`{.action} tab. Click `Add a replication rule`{.action}. Leave the prefix empty, set the destination to `content-eu-west-`, enable **Delete marker replication**, and click `Save`{.action}. Click `Add a replication rule`{.action} again to add a second rule with destination `content-eu-central-` and the same settings. + +**Via the AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-to-eu-west", + "Status": "Enabled", + "Priority": 1, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Enabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::content-eu-west-", + "StorageClass": "STANDARD" + } + }, + { + "ID": "replicate-to-eu-central", + "Status": "Enabled", + "Priority": 2, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Enabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::content-eu-central-", + "StorageClass": "STANDARD" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket content-origin- \ + --replication-configuration file://replication-content.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 3 - Apply expiration lifecycle on the regional buckets + +Remove non-current versions after 30 days to prevent accumulation of stale content. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of a regional bucket and select the `Lifecycle rules`{.action} tab. Click `Add a rule`{.action}. Leave the prefix empty. Set non-current version expiration to **30 days** and abort incomplete multipart upload cleanup to **7 days**. Click `Save`{.action}. Repeat for the other regional bucket. + +**Via the AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "expire-noncurrent-versions", + "Status": "Enabled", + "Filter": {}, + "NoncurrentVersionExpiration": { "NoncurrentDays": 30 }, + "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket content-eu-west- \ + --lifecycle-configuration file://lifecycle-regional.json \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-lifecycle-configuration \ + --bucket content-eu-central- \ + --lifecycle-configuration file://lifecycle-regional.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!primary] +> With **Delete marker replication** enabled, when you delete an object on the origin bucket, the delete marker propagates to all regional replicas. The `NoncurrentVersionExpiration` rule then cleans up the superseded version data after 30 days automatically - no manual cleanup is required. + +--- + +## Use case 5 - Dev/Staging environment management + +### Context + +Development and staging environments often need a realistic copy of production data to run meaningful tests. Without automation, data synchronisation is manual and error-prone. The combination of replication and aggressive lifecycle policies enables: + +- Automatic one-way sync from production to staging using replication +- Automatic cleanup of staging data using short lifecycle expiration rules, preventing cost accumulation on non-production environments + +### Architecture + +| Bucket | Region | Role | +|--------|--------|------| +| `prod-data-` | e.g. GRA | Production bucket; standard lifecycle | +| `staging-data-` | e.g. GRA (same region) | Staging replica; aggressive expiration | + +> [!primary] +> Replication between two buckets in the same region is supported and incurs no egress cost. This is the typical configuration for dev/staging use cases where geographic separation is not required. + +### Step 1 - Enable versioning on both buckets + +**Via the OVHcloud Control Panel** + +Log in to the [OVHcloud Control Panel](https://www.ovh.com/auth/) and go to `Public Cloud`{.action} > `Object Storage`{.action} > `My containers`{.action}. For each bucket, click its name, select the `Versioning`{.action} tab, toggle to **Enabled**, and click `Save`{.action}. + +**Via the AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket prod-data- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket staging-data- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 2 - Configure replication from production to staging + +Only the `datasets/` prefix is replicated to limit the volume of data copied to staging. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your production bucket and select the `Replication`{.action} tab. Click `Add a replication rule`{.action}. Set the prefix filter to `datasets/`, set the destination to `staging-data-`, leave the storage class as **Standard**, disable **Delete marker replication**, and click `Save`{.action}. + +**Via the AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "prod-to-staging", + "Status": "Enabled", + "Priority": 1, + "Filter": { "Prefix": "datasets/" }, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::staging-data-", + "StorageClass": "STANDARD" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket prod-data- \ + --replication-configuration file://replication-staging.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 3 - Apply aggressive expiration on the staging bucket + +Objects expire after 14 days; non-current versions are cleaned up after 3 days. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your staging bucket and select the `Lifecycle rules`{.action} tab. Click `Add a rule`{.action}. Leave the prefix empty. Set expiration to **14 days**, non-current version expiration to **3 days**, and abort incomplete multipart upload cleanup to **1 day**. Click `Save`{.action}. + +**Via the AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "staging-cleanup", + "Status": "Enabled", + "Filter": {}, + "Expiration": { "Days": 14 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 3 }, + "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 1 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket staging-data- \ + --lifecycle-configuration file://lifecycle-staging.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!warning] +> **Delete marker replication** is disabled in the replication rule above. This ensures that deletions in the production bucket do not propagate to staging, allowing staging environments to continue working with their local copy of the data even after production objects have been removed. + +--- + +## Use case 6 - Logs and observability + +### Context + +Log data has heterogeneous retention requirements depending on its type: + +- **Access logs**: short retention (30 days), high volume, low value after a few weeks +- **Application error logs**: medium retention (90 days), useful for incident post-mortems +- **Audit and security logs**: long retention (1 to 7 years), required for compliance + +The combination of prefix-based lifecycle policies with replication to a centralised SIEM or security bucket enables granular, automated retention management without manual intervention. + +### Architecture + +| Bucket | Region | Role | +|--------|--------|------| +| `logs-primary-` | e.g. GRA | Receives all logs under typed prefixes | +| `logs-security-` | e.g. DE | Security/SIEM replica; receives only audit logs | + +### Step 1 - Enable versioning on both buckets + +**Via the OVHcloud Control Panel** + +Log in to the [OVHcloud Control Panel](https://www.ovh.com/auth/) and go to `Public Cloud`{.action} > `Object Storage`{.action} > `My containers`{.action}. For each bucket, click its name, select the `Versioning`{.action} tab, toggle to **Enabled**, and click `Save`{.action}. + +**Via the AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket logs-primary- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket logs-security- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 2 - Configure selective replication for audit logs only + +Only the `audit/` prefix is replicated to the security bucket. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your primary logs bucket and select the `Replication`{.action} tab. Click `Add a replication rule`{.action}. Set the prefix filter to `audit/`, set the destination to `logs-security-`, set the destination storage class to **Infrequent Access**, disable **Delete marker replication**, and click `Save`{.action}. + +**Via the AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-audit-to-security", + "Status": "Enabled", + "Priority": 1, + "Filter": { "Prefix": "audit/" }, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::logs-security-", + "StorageClass": "STANDARD_IA" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket logs-primary- \ + --replication-configuration file://replication-logs.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 3 - Apply differentiated lifecycle policies on the primary bucket + +Apply separate expiration and transition rules per log type using prefix filters. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your primary logs bucket and select the `Lifecycle rules`{.action} tab. Use `Add a rule`{.action} to create three rules: + +- **Rule 1** - prefix `access/`: expiration at **30 days** +- **Rule 2** - prefix `errors/`: transition to **Infrequent Access** at day 30, expiration at **90 days** +- **Rule 3** - prefix `audit/`: transition to **Infrequent Access** at day 90, **Active Archive** at day 365 (3-AZ only), **Cold Archive** at day 730 (3-AZ only), expiration at **2555 days** + +**Via the AWS CLI** + +> [!primary] +> `GLACIER_IR` (Active Archive) and `DEEP_ARCHIVE` (Cold Archive) are available in **3-AZ regions** only. For **1-AZ regions**, use only `STANDARD_IA` for the `audit/` rule. + +```json +{ + "Rules": [ + { + "ID": "expire-access-logs", + "Status": "Enabled", + "Filter": { "Prefix": "access/" }, + "Expiration": { "Days": 30 } + }, + { + "ID": "expire-error-logs", + "Status": "Enabled", + "Filter": { "Prefix": "errors/" }, + "Transitions": [ + { "Days": 30, "StorageClass": "STANDARD_IA" } + ], + "Expiration": { "Days": 90 } + }, + { + "ID": "archive-audit-logs", + "Status": "Enabled", + "Filter": { "Prefix": "audit/" }, + "Transitions": [ + { "Days": 90, "StorageClass": "STANDARD_IA" }, + { "Days": 365, "StorageClass": "GLACIER_IR" }, + { "Days": 730, "StorageClass": "DEEP_ARCHIVE" } + ], + "Expiration": { "Days": 2555 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket logs-primary- \ + --lifecycle-configuration file://lifecycle-logs.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 4 - Apply long-term retention on the security bucket + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your security bucket and select the `Lifecycle rules`{.action} tab. Click `Add a rule`{.action}. Leave the prefix empty. For **3-AZ regions**, add transitions: **Infrequent Access** at day 90, **Active Archive** at day 365, and **Cold Archive** at day 730. For **1-AZ regions**, add only the **Infrequent Access** transition at day 90. Set expiration to **2555 days**. Click `Save`{.action}. + +**Via the AWS CLI** + +> [!primary] +> `GLACIER_IR` (Active Archive) and `DEEP_ARCHIVE` (Cold Archive) are available in **3-AZ regions** only. For **1-AZ regions**, use only `STANDARD_IA`. + +```json +{ + "Rules": [ + { + "ID": "security-long-term-retention", + "Status": "Enabled", + "Filter": {}, + "Transitions": [ + { "Days": 90, "StorageClass": "STANDARD_IA" }, + { "Days": 365, "StorageClass": "GLACIER_IR" }, + { "Days": 730, "StorageClass": "DEEP_ARCHIVE" } + ], + "Expiration": { "Days": 2555 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket logs-security- \ + --lifecycle-configuration file://lifecycle-security.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!primary] +> By structuring your log pipeline with typed prefixes (`access/`, `errors/`, `audit/`), you can apply precise lifecycle rules to each category independently. Adding a new log type only requires a new prefix and a new lifecycle rule - no pipeline refactoring is needed. + +--- + +## Use case 7 - SaaS multi-tenant backup + +### Context + +SaaS platforms serving multiple tenants often need to provide per-tenant backup and data isolation guarantees. Common requirements include: + +- Per-tenant data isolation (each tenant's data stored under a dedicated prefix) +- Per-tenant retention policies reflecting contractual SLAs +- Offsite replication of tenant data for resilience and compliance + +This use case demonstrates a **prefix-per-tenant** model within a shared bucket, combined with tag-based lifecycle rules to enforce per-tenant policies. + +### Architecture + +| Bucket | Region | Role | +|--------|--------|------| +| `saas-tenants-` | e.g. GRA | Primary multi-tenant bucket; per-prefix data isolation | +| `saas-backup-` | e.g. DE | Offsite backup replica for all tenants | + +Objects are stored under `tenants//` prefixes. Each tenant's objects are tagged at upload time with a `tenant-tier` tag (e.g. `standard` or `premium`), enabling differentiated lifecycle policies. + +### Step 1 - Enable versioning on both buckets + +**Via the OVHcloud Control Panel** + +Log in to the [OVHcloud Control Panel](https://www.ovh.com/auth/) and go to `Public Cloud`{.action} > `Object Storage`{.action} > `My containers`{.action}. For each bucket, click its name, select the `Versioning`{.action} tab, toggle to **Enabled**, and click `Save`{.action}. + +**Via the AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket saas-tenants- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket saas-backup- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 2 - Upload objects with tenant metadata tags + +Objects must be tagged at upload time so that tag-based lifecycle rules can identify them correctly. + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your tenants bucket. Select the `Objects`{.action} tab and click `+ Add objects`{.action}. Before confirming the upload, expand the **Tags** section. Add a tag with key `tenant-id` and value `tenant-abc123`, and a second tag with key `tenant-tier` and value `premium`. Select your file and click `Import`{.action}. + +**Via the AWS CLI** + +```bash +aws s3api put-object \ + --bucket saas-tenants- \ + --key "tenants/tenant-abc123/backup-2025-04-15.tar.gz" \ + --body backup-2025-04-15.tar.gz \ + --tagging "tenant-id=tenant-abc123&tenant-tier=premium" \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 3 - Configure replication to the backup bucket + +**Via the OVHcloud Control Panel** + +From the `My containers`{.action} tab, click the name of your tenants bucket and select the `Replication`{.action} tab. Click `Add a replication rule`{.action}. Set the prefix filter to `tenants/`, set the destination to `saas-backup-`, set the destination storage class to **Infrequent Access**, disable **Delete marker replication**, and click `Save`{.action}. + +**Via the AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-all-tenants", + "Status": "Enabled", + "Priority": 1, + "Filter": { "Prefix": "tenants/" }, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::saas-backup-", + "StorageClass": "STANDARD_IA" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket saas-tenants- \ + --replication-configuration file://replication-saas.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Step 4 - Apply tag-based lifecycle policies for differentiated retention + +> [!primary] +> Tag-based lifecycle filters are currently configurable via the AWS CLI. For tag-based rules in the OVHcloud Control Panel, check the `Lifecycle rules`{.action} tab of your bucket - support for tag filters may have been added since this guide was published. + +**Via the AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "standard-tier-retention", + "Status": "Enabled", + "Filter": { + "Tag": { "Key": "tenant-tier", "Value": "standard" } + }, + "Transitions": [ + { "Days": 30, "StorageClass": "STANDARD_IA" } + ], + "Expiration": { "Days": 90 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 7 } + }, + { + "ID": "premium-tier-retention", + "Status": "Enabled", + "Filter": { + "Tag": { "Key": "tenant-tier", "Value": "premium" } + }, + "Transitions": [ + { "Days": 60, "StorageClass": "STANDARD_IA" }, + { "Days": 180, "StorageClass": "GLACIER_IR" }, + { "Days": 365, "StorageClass": "DEEP_ARCHIVE" } + ], + "Expiration": { "Days": 730 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 30 } + } + ] +} +``` + +> [!primary] +> `GLACIER_IR` (Active Archive) and `DEEP_ARCHIVE` (Cold Archive) in the `premium` rule are available in **3-AZ regions** only. For **1-AZ regions**, use only `STANDARD_IA`. + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket saas-tenants- \ + --lifecycle-configuration file://lifecycle-saas.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!warning] +> Tag-based lifecycle rules require that each object is tagged correctly at upload time. Consider enforcing this at the application layer to ensure consistency across all tenant uploads. If a tenant's tier changes, re-tagging existing objects will cause the appropriate lifecycle rule to apply going forward. + +--- + +## Summary + +The table below provides a quick reference for the key configuration choices across all seven use cases: + +| Use case | Replication scope | Delete marker replication | Primary lifecycle | Secondary lifecycle | +|----------|------------------|--------------------------|-------------------|---------------------| +| Regulatory archiving | All objects | Enabled | Tiering (30 → 90 → 365 days) | Expiration at 7 years | +| Disaster recovery | All objects | Disabled | Expiration at 60 days | Expiration at 1 year | +| Data lake tiering | All objects | Disabled | Tiering by prefix | None (Standard class retained) | +| Geo content distribution | All objects | Enabled | None on origin | Noncurrent version expiration | +| Dev/Staging sync | Prefix filter (`datasets/`) | Disabled | Standard | Expiration at 14 days | +| Logs & observability | Prefix filter (`audit/`) | Disabled | Per-prefix differentiated expiration | Long-term retention + tiering | +| SaaS multi-tenant | Prefix filter (`tenants/`) | Disabled | Tag-based differentiated retention | Infrequent Access (all tenants) | + +> [!warning] +> Object Storage lifecycle rules are evaluated once per day. There may be a delay of up to 24 hours between the moment an object meets the criteria for a transition or expiration and the moment the action is actually performed. During this delay, objects continue to be billed at their current storage class rate. + +## Go further + +- [Object Storage - Managing object lifecycle](/pages/storage_and_backup/object_storage/s3_lifecycle/guide.en-gb) +- [Object Storage - Mastering asynchronous replication across your buckets](/pages/storage_and_backup/object_storage/s3_replication/guide.en-gb) +- [Object Storage - Choosing the right storage class for your needs](/pages/storage_and_backup/object_storage/s3_storage_class/guide.en-gb) +- [Object Storage - Getting started with Object Storage](/pages/storage_and_backup/object_storage/s3_getting_started_with_object_storage/guide.en-gb) +- [Object Storage - Endpoints and geoavailability](/pages/storage_and_backup/object_storage/s3_location/guide.en-gb) + +Join our [community of users](https://community.ovh.com/en/). + +--- + +*1: S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc.* diff --git a/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/guide.fr-fr.md b/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/guide.fr-fr.md new file mode 100644 index 00000000000..8fafdc4bed8 --- /dev/null +++ b/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/guide.fr-fr.md @@ -0,0 +1,1085 @@ +--- +title: "Object Storage - Combiner les lifecycle policies et la réplication asynchrone" +excerpt: "Apprenez à combiner les lifecycle policies et la réplication asynchrone de l'Object Storage OVHcloud pour répondre à des cas d'usage avancés de gestion des données" +updated: 2026-04-17 +--- + +## Objectif + +OVHcloud Ovhect Storage propose deux fonctionnalités d'automatisation puissantes qui, combinées, permettent de répondre à un large éventail de cas de gestion de données en production : + +- Les **lifecycle policies** automatisent les transitions entre classes de stockage (High Performance -> Standard -> Infrequent Access -> Active Archive -> Cold Archive) et l'expiration (suppression) des objets selon des règles que vous définissez. +- La **réplication asynchrone** copie automatiquement les objets d'un bucket source vers un ou plusieurs buckets de destination, au sein d'une même région ou entre différentes régions. + +Utilisées séparément, chacune de ces fonctionnalités apporte déjà une valeur significative. Combinées, elles permettent de mettre en place des architectures à la fois économiques, résilientes et conformes. + +Ce guide couvre sept cas d'usage qui combinent ces deux fonctionnalités : + +1. [Archivage réglementaire et conformité](#cas-dusage-1-archivage-reglementaire-et-conformite) +2. [Reprise après sinistre](#cas-dusage-2-reprise-apres-sinistre) +3. [Data lake et tiering automatisé](#cas-dusage-3-data-lake-et-tiering-automatise) +4. [Distribution géographique de contenu](#cas-dusage-4-distribution-geographique-de-contenu) +5. [Gestion des environnements Dev/Staging](#cas-dusage-5-gestion-des-environnements-devstaging) +6. [Logs et observabilité](#cas-dusage-6-logs-et-observabilite) +7. [Sauvegarde SaaS multi-tenant](#cas-dusage-7-sauvegarde-saas-multi-tenant) + +## Prérequis + +- Un [projet Public Cloud OVHcloud](https://www.ovhcloud.com/fr/public-cloud/) actif +- Des buckets Object Storage créés dans une ou plusieurs régions OVHcloud. Consultez notre guide [Premiers pas avec l'Object Storage](/pages/storage_and_backup/object_storage/s3_getting_started_with_object_storage/guide.fr-fr) si nécessaire +- Une connaissance des classes de stockage OVHcloud. Consultez notre guide [Choisir la classe de stockage adaptée à vos besoins](/pages/storage_and_backup/object_storage/s3_storage_class/guide.fr-fr) +- Une connaissance des lifecycle policies. Consultez notre guide [Object Storage - Gérer le cycle de vie des objets](/pages/storage_and_backup/object_storage/s3_lifecycle/guide.fr-fr) +- Une connaissance de la réplication asynchrone. Consultez notre guide [Object Storage - Maîtriser la réplication asynchrone sur vos buckets](/pages/storage_and_backup/object_storage/s3_replication/guide.fr-fr) +- **Pour les étapes CLI uniquement** : l'AWS CLI installée et configurée avec vos identifiants et endpoint Object Storage OVHcloud. Consultez notre guide [Premiers pas avec l'Object Storage](/pages/storage_and_backup/object_storage/s3_getting_started_with_object_storage/guide.fr-fr) + +> [!primary] +> Chaque étape de ce guide peut être réalisée via l'**espace client OVHcloud** ou en utilisant la **CLI AWS**. Les deux approches sont décrites pour chaque étape. Les exemples CLI utilisent le format d'endpoint OVHcloud : +> ```bash +> --endpoint-url https://s3..io.cloud.ovh.net +> ``` +> Remplacez `` par le slug de votre région (par exemple `gra`, `sbg`, `de`, `uk`) et remplacez tous les noms de buckets et préfixes par vos propres valeurs. + +## Référence du mapping des classes de stockage + +Tous les exemples CLI de ce guide utilisent les valeurs de `StorageClass` de l'API S3 requises pour les **opérations d'écriture** (PUT, transitions lifecycle, destination de réplication) sur l'endpoint `.io` d'OVHcloud. Le mapping diffère entre les **régions 3-AZ** et les **régions 1-AZ**. + +> [!primary] +> Le mapping ci-dessous reflète l'état actuel depuis le **2026-01-03**. Consultez le guide [Object Storage - Endpoints et disponibilité géographique](/pages/storage_and_backup/object_storage/s3_location/guide.fr-fr) pour la référence complète et à jour. + +**Régions 3-AZ (ex. Paris `eu-west-par`, Milan `eu-south-mil`)** + +| Valeur `StorageClass` de l'API S3 | Classe de stockage OVHcloud | +|---|---| +| `EXPRESS_ONEZONE` | High Performance | +| `STANDARD` (aussi `INTELLIGENT_TIERING` ou défaut) | Standard | +| `STANDARD_IA` (aussi `ONEZONE_IA`) | Infrequent Access | +| `GLACIER_IR` (aussi `GLACIER`) | Active Archive | +| `DEEP_ARCHIVE` | Cold Archive | + +**Régions 1-AZ (ex. GRA, SBG, DE, UK, BHS, WAW, ...)** + +| Valeur `StorageClass` de l'API S3 | Classe de stockage OVHcloud | +|---|---| +| `EXPRESS_ONEZONE` | High Performance | +| `STANDARD` (aussi `INTELLIGENT_TIERING` ou défaut) | Standard | +| `STANDARD_IA` (aussi `ONEZONE_IA`, `GLACIER_IR`, `GLACIER`, `DEEP_ARCHIVE`) | Infrequent Access | + +> [!warning] +> Dans les **régions 1-AZ**, `GLACIER_IR`, `GLACIER` et `DEEP_ARCHIVE` mappent tous vers **Infrequent Access** - aucun niveau d'archivage plus profond n'est disponible dans les régions 1-AZ. Cold Archive est actuellement disponible uniquement dans les régions 3-AZ, et uniquement à Paris (`eu-west-par`). + +> [!warning] +> Ce mapping s'applique uniquement à l'endpoint `.io`. L'ancien endpoint `.perf` utilise un mapping différent et n'est maintenu qu'à des fins de rétrocompatibilité. + +--- + +## Cas d'usage 1 - Archivage réglementaire et conformité + +### Contexte + +Les organisations des secteurs réglementés (finance, santé, juridique) doivent conserver certaines données pendant des durées légalement imposées - souvent 5 à 10 ans - tout en maîtrisant les coûts de stockage et en garantissant la disponibilité des données dans une juridiction secondaire si nécessaire. Une exigence typique combine : + +- Une transition automatique vers des classes de stockage moins coûteuses à mesure que les données vieillissent +- Une copie conforme dans une région géographiquement distincte + +### Architecture + +| Bucket | Région | Rôle | +|--------|--------|------| +| `compliance-primary-` | ex. GRA | Reçoit tous les nouveaux objets ; applique les transitions lifecycle | +| `compliance-archive-` | ex. DE | Destination de réplication ; reçoit une copie de chaque objet pour la rétention à long terme | + +La lifecycle policy sur le **bucket primaire** gère l'optimisation des coûts. La réplication asynchrone vers le **bucket secondaire** assure la redondance géographique et les exigences de juridiction. Le bucket secondaire peut avoir sa propre lifecycle policy indépendante pour la rétention à long terme. + +### Étape 1 - Activer le versioning sur les deux buckets + +La réplication asynchrone nécessite que le versioning soit activé sur les buckets source et destination. + +**Via l'espace client OVHcloud** + +Connectez-vous à l'[espace client OVHcloud](https://www.ovh.com/auth/), accédez à la section `Public Cloud`{.action} et sélectionnez votre projet. Cliquez sur `Object Storage`{.action} dans le menu de gauche, puis sur l'onglet `Mes conteneurs`{.action}. Cliquez sur le nom de votre bucket source (`compliance-primary-`), puis sélectionnez l'onglet `Versioning`{.action}. Activez le versioning et cliquez sur `Enregistrer`{.action}. Répétez cette opération pour le bucket de destination (`compliance-archive-`). + +**Via l'AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket compliance-primary- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket compliance-archive- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 2 - Configurer la réplication sur le bucket primaire + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket source, puis sélectionnez l'onglet `Réplication`{.action}. Cliquez sur `Ajouter une règle de réplication`{.action}. Définissez le bucket de destination sur `compliance-archive-`, choisissez **Standard** comme classe de stockage de destination, activez la **réplication des marqueurs de suppression** et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +Créez un fichier nommé `replication-compliance.json` : + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-all-to-compliance-region", + "Status": "Enabled", + "Priority": 1, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Enabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::compliance-archive-", + "StorageClass": "STANDARD" + } + } + ] +} +``` + +Appliquez-le : + +```bash +aws s3api put-bucket-replication \ + --bucket compliance-primary- \ + --replication-configuration file://replication-compliance.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 3 - Appliquer la lifecycle policy sur le bucket primaire + +Cette configuration fait transiter les objets par Infrequent Access, Active Archive et Cold Archive à mesure qu'ils vieillissent. Les niveaux d'archivage ne sont disponibles que dans les régions 3-AZ. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket source et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Cliquez sur `Ajouter une règle`{.action}. Laissez le filtre de préfixe vide. Pour les **régions 3-AZ**, ajoutez trois actions de transition : **Infrequent Access** au jour 30, **Active Archive** au jour 90 et **Cold Archive** au jour 365. Pour les **régions 1-AZ**, ajoutez uniquement la transition **Infrequent Access** au jour 30. Cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +Créez un fichier nommé `lifecycle-compliance.json` : + +> [!primary] +> L'exemple ci-dessous cible une **région 3-AZ** (ex. Paris `eu-west-par`). Il utilise `GLACIER_IR` pour Active Archive et `DEEP_ARCHIVE` pour Cold Archive, tous deux disponibles en 3-AZ uniquement. Pour les **régions 1-AZ**, supprimez les deux transitions d'archivage - seul `STANDARD_IA` est disponible. + +```json +{ + "Rules": [ + { + "ID": "compliance-tiering", + "Status": "Enabled", + "Filter": {}, + "Transitions": [ + { "Days": 30, "StorageClass": "STANDARD_IA" }, + { "Days": 90, "StorageClass": "GLACIER_IR" }, + { "Days": 365, "StorageClass": "DEEP_ARCHIVE" } + ] + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket compliance-primary- \ + --lifecycle-configuration file://lifecycle-compliance.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 4 - Appliquer une lifecycle de rétention à long terme sur le bucket secondaire + +Cette configuration retient les objets pendant 7 ans (2555 jours) avant expiration. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket de destination et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Cliquez sur `Ajouter une règle`{.action}. Laissez le filtre de préfixe vide. Ajoutez une action d'expiration définie à **2555 jours**. Cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "long-term-retention", + "Status": "Enabled", + "Filter": {}, + "Expiration": { "Days": 2555 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket compliance-archive- \ + --lifecycle-configuration file://lifecycle-archive.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!primary] +> La réplication copie l'objet au moment de sa création. Si l'objet transite vers une classe de stockage moins coûteuse sur le bucket primaire, le réplica dans le bucket secondaire conserve sa propre classe de stockage de manière indépendante. Vous pouvez ainsi optimiser les coûts différemment de chaque côté. + +--- + +## Cas d'usage 2 - Reprise après sinistre + +### Contexte + +Une stratégie de reprise après sinistre pour l'Object Storage nécessite une copie de toutes les données dans une région distante, avec des objectifs de délai de reprise (RTO) et de point de reprise (RPO) alignés sur votre SLA. Le schéma type est le suivant : + +- **Bucket primaire** : rétention courte, classe Standard, coût réduit +- **Bucket DR** : copie complète dans une région distante, rétention plus longue en classe Infrequent Access pour réduire le coût en veille + +La réplication asynchrone maintient le bucket RAS à jour. Les lifecycle policies sur le bucket primaire maîtrisent les coûts en faisant expirer les objets déjà répliqués en sécurité. + +### Architecture + +| Bucket | Région | Rôle | +|--------|--------|------| +| `dr-primary-` | ex. GRA | Données de production ; lifecycle de rétention courte | +| `dr-backup-` | ex. UK | Réplica DR ; classe Infrequent Access ; rétention plus longue | + +### Étape 1 - Activer le versioning sur les deux buckets + +**Via l'espace client OVHcloud** + +Connectez-vous à l'[espace client OVHcloud](https://www.ovh.com/auth/), accédez à `Public Cloud`{.action} et sélectionnez votre projet. Cliquez sur `Object Storage`{.action} puis `Mes conteneurs`{.action}. Pour chaque bucket (`dr-primary-` et `dr-backup-`), cliquez sur son nom, sélectionnez l'onglet `Versioning`{.action}, activez-le et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket dr-primary- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket dr-backup- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 2 - Configurer la réplication vers le bucket RAS + +Les objets répliqués sont stockés directement en Infrequent Access côté DR pour réduire les coûts en veille. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket primaire et sélectionnez l'onglet `Réplication`{.action}. Cliquez sur `Ajouter une règle de réplication`{.action}. Définissez la destination sur `dr-backup-`, choisissez **Infrequent Access** comme classe de stockage de destination, désactivez la **réplication des marqueurs de suppression** pour protéger la copie RAS des suppressions accidentelles, et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +Créez un fichier nommé `replication-dr.json` : + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "dr-replication", + "Status": "Enabled", + "Priority": 1, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::dr-backup-", + "StorageClass": "STANDARD_IA" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket dr-primary- \ + --replication-configuration file://replication-dr.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 3 - Appliquer une lifecycle de rétention courte sur le bucket primaire + +Les objets expirent après 60 jours ; les versions non courantes sont nettoyées après 7 jours. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket primaire et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Cliquez sur `Ajouter une règle`{.action}. Laissez le préfixe vide. Ajoutez une action d'expiration à **60 jours** et une expiration des versions non courantes à **7 jours**. Cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "primary-short-retention", + "Status": "Enabled", + "Filter": {}, + "Expiration": { "Days": 60 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 7 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket dr-primary- \ + --lifecycle-configuration file://lifecycle-dr-primary.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 4 - Appliquer une lifecycle de rétention plus longue sur le bucket DR + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket RAS et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Cliquez sur `Ajouter une règle`{.action}. Laissez le préfixe vide. Définissez l'expiration à **365 jours** et l'expiration des versions non courantes à **30 jours**. Cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "dr-retention", + "Status": "Enabled", + "Filter": {}, + "Expiration": { "Days": 365 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 30 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket dr-backup- \ + --lifecycle-configuration file://lifecycle-dr-backup.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!warning] +> La **réplication des marqueurs de suppression** est désactivée dans la règle de réplication DR ci-dessus. Cela empêche les suppressions effectuées sur le bucket primaire de se propager vers le bucket DR, protégeant le réplica contre les suppressions accidentelles ou malveillantes. Ajustez ce paramètre si votre cas d'usage nécessite une cohérence totale entre les deux buckets. + +--- + +## Cas d'usage 3 - Data lake et tiering automatisé + +### Contexte + +Les architectures data lake génèrent de grands volumes d'objets interrogés fréquemment lorsqu'ils sont récents (chauds), occasionnellement après quelques semaines (tièdes), et rarement au-delà de quelques mois (froids). Stocker l'ensemble des données dans la même classe de stockage est inutilement coûteux. La combinaison du tiering lifecycle sur un bucket central et de la réplication vers un bucket dédié à l'analytique permet de : + +- Réduire automatiquement les coûts à mesure que les données vieillissent sur le bucket data lake principal +- Disposer d'une copie stable en classe Standard pour les outils d'analytique dans une autre région, non affectée par les transitions de tiering + +### Architecture + +| Bucket | Région | Rôle | +|--------|--------|------| +| `datalake-main-` | ex. GRA | Data lake principal ; lifecycle de tiering | +| `datalake-analytics-` | ex. DE | Réplica analytique ; reste en classe Standard | + +### Étape 1 - Activer le versioning sur les deux buckets + +**Via l'espace client OVHcloud** + +Connectez-vous à l'[espace client OVHcloud](https://www.ovh.com/auth/), accédez à `Public Cloud`{.action} et sélectionnez votre projet. Cliquez sur `Object Storage`{.action} puis `Mes conteneurs`{.action}. Pour chaque bucket, cliquez sur son nom, sélectionnez l'onglet `Versioning`{.action}, activez-le et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket datalake-main- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket datalake-analytics- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 2 - Configurer la réplication vers le bucket analytique + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket data lake principal et sélectionnez l'onglet `Réplication`{.action}. Cliquez sur `Ajouter une règle de réplication`{.action}. Laissez le filtre de préfixe vide. Définissez la destination sur `datalake-analytics-`, choisissez **Standard** comme classe de stockage de destination, désactivez la **réplication des marqueurs de suppression** et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-to-analytics", + "Status": "Enabled", + "Priority": 1, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::datalake-analytics-", + "StorageClass": "STANDARD" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket datalake-main- \ + --replication-configuration file://replication-datalake.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 3 - Appliquer la lifecycle de tiering par préfixe sur le bucket principal + +Cette configuration applique des calendriers de tiering différents aux données brutes et aux données traitées, grâce aux filtres de préfixe. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket principal et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Utilisez `Ajouter une règle`{.action} pour créer deux règles séparément : + +- **Règle 1** - préfixe `raw/` : transitions vers **Infrequent Access** au jour 30, **Active Archive** au jour 90, **Cold Archive** au jour 365 (3-AZ uniquement) +- **Règle 2** - préfixe `processed/` : transitions vers **Infrequent Access** au jour 60, **Active Archive** au jour 180 (3-AZ uniquement) + +**Via l'AWS CLI** + +> [!primary] +> `GLACIER_IR` mappe vers Active Archive et `DEEP_ARCHIVE` vers Cold Archive - les deux sont disponibles uniquement dans les **régions 3-AZ**. Pour les **régions 1-AZ**, utilisez uniquement `STANDARD_IA`. + +```json +{ + "Rules": [ + { + "ID": "tier-raw-data", + "Status": "Enabled", + "Filter": { "Prefix": "raw/" }, + "Transitions": [ + { "Days": 30, "StorageClass": "STANDARD_IA" }, + { "Days": 90, "StorageClass": "GLACIER_IR" }, + { "Days": 365, "StorageClass": "DEEP_ARCHIVE" } + ] + }, + { + "ID": "tier-processed-data", + "Status": "Enabled", + "Filter": { "Prefix": "processed/" }, + "Transitions": [ + { "Days": 60, "StorageClass": "STANDARD_IA" }, + { "Days": 180, "StorageClass": "GLACIER_IR" } + ] + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket datalake-main- \ + --lifecycle-configuration file://lifecycle-datalake.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!primary] +> Le réplica analytique conserve tous les objets en classe Standard, quelle que soit la transition appliquée sur la source. Vos outils d'analytique accèdent toujours à des données immédiatement disponibles, sans délai de restauration ni coûts supplémentaires. + +--- + +## Cas d'usage 4 - Distribution géographique de contenu + +### Contexte + +Les organisations qui distribuent des assets statiques (fichiers média, paquets logiciels, mises à jour de firmware, documentation) à des utilisateurs dans plusieurs régions ont intérêt à conserver des copies proches de leurs utilisateurs finaux. La combinaison de la réplication et des lifecycles vous offre : + +- La propagation automatique du nouveau contenu vers les buckets régionaux +- L'expiration automatique des versions obsolètes en local, évitant la dérive du stockage dans le temps + +### Architecture + +| Bucket | Région | Rôle | +|--------|--------|------| +| `content-origin-` | ex. GRA | Origine principale ; tout le contenu est téléversé ici | +| `content-eu-west-` | ex. UK | Réplica de périphérie régional | +| `content-eu-central-` | ex. DE | Réplica de périphérie régional | + +### Étape 1 - Activer le versioning sur tous les buckets + +**Via l'espace client OVHcloud** + +Connectez-vous à l'[espace client OVHcloud](https://www.ovh.com/auth/) et accédez à `Public Cloud`{.action} > `Object Storage`{.action} > `Mes conteneurs`{.action}. Pour chacun des trois buckets, cliquez sur son nom, sélectionnez l'onglet `Versioning`{.action}, activez-le et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket content-origin- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket content-eu-west- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket content-eu-central- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 2 - Configurer la réplication multi-destination sur le bucket d'origine + +L'Object Storage OVHcloud supporte plusieurs règles de réplication sur un même bucket. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket d'origine et sélectionnez l'onglet `Réplication`{.action}. Cliquez sur `Ajouter une règle de réplication`{.action}. Laissez le préfixe vide, définissez la destination sur `content-eu-west-`, activez la **réplication des marqueurs de suppression** et cliquez sur `Enregistrer`{.action}. Cliquez à nouveau sur `Ajouter une règle de réplication`{.action} pour ajouter une seconde règle avec pour destination `content-eu-central-` et les mêmes paramètres. + +**Via l'AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-to-eu-west", + "Status": "Enabled", + "Priority": 1, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Enabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::content-eu-west-", + "StorageClass": "STANDARD" + } + }, + { + "ID": "replicate-to-eu-central", + "Status": "Enabled", + "Priority": 2, + "Filter": {}, + "DeleteMarkerReplication": { "Status": "Enabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::content-eu-central-", + "StorageClass": "STANDARD" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket content-origin- \ + --replication-configuration file://replication-content.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 3 - Appliquer la lifecycle d'expiration sur les buckets régionaux + +Supprimez les versions non courantes après 30 jours pour éviter l'accumulation de contenu obsolète. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom d'un bucket régional et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Cliquez sur `Ajouter une règle`{.action}. Laissez le préfixe vide. Définissez l'expiration des versions non courantes à **30 jours** et le nettoyage des uploads multipart incomplets à **7 jours**. Cliquez sur `Enregistrer`{.action}. Répétez l'opération pour l'autre bucket régional. + +**Via l'AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "expire-noncurrent-versions", + "Status": "Enabled", + "Filter": {}, + "NoncurrentVersionExpiration": { "NoncurrentDays": 30 }, + "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket content-eu-west- \ + --lifecycle-configuration file://lifecycle-regional.json \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-lifecycle-configuration \ + --bucket content-eu-central- \ + --lifecycle-configuration file://lifecycle-regional.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!primary] +> Lorsque la **réplication des marqueurs de suppression** est activée, la suppression d'un objet sur le bucket d'origine propage le marqueur de suppression vers tous les réplicas régionaux. La règle `NoncurrentVersionExpiration` nettoie ensuite automatiquement les données de version obsolètes après 30 jours - aucun nettoyage manuel n'est nécessaire. + +--- + +## Cas d'usage 5 - Gestion des environnements Dev/Staging + +### Contexte + +Les environnements de développement et de staging ont souvent besoin d'une copie réaliste des données de production pour exécuter des tests significatifs. Sans automatisation, la synchronisation des données est manuelle et sujette aux erreurs. La combinaison de la réplication et de lifecycles agressives permet de : + +- Synchroniser automatiquement les données de production vers le staging grâce à la réplication +- Nettoyer automatiquement les données de staging grâce à des règles d'expiration courtes, évitant l'accumulation de coûts sur les environnements non-production + +### Architecture + +| Bucket | Région | Rôle | +|--------|--------|------| +| `prod-data-` | ex. GRA | Bucket de production ; lifecycle standard | +| `staging-data-` | ex. GRA (même région) | Réplica staging ; expiration agressive | + +> [!primary] +> La réplication entre deux buckets dans la même région est supportée et n'engendre pas de coût d'egress. Il s'agit de la configuration typique pour les cas d'usage dev/staging où la séparation géographique n'est pas requise. + +### Étape 1 - Activer le versioning sur les deux buckets + +**Via l'espace client OVHcloud** + +Connectez-vous à l'[espace client OVHcloud](https://www.ovh.com/auth/) et accédez à `Public Cloud`{.action} > `Object Storage`{.action} > `Mes conteneurs`{.action}. Pour chaque bucket, cliquez sur son nom, sélectionnez l'onglet `Versioning`{.action}, activez-le et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket prod-data- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket staging-data- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 2 - Configurer la réplication de la production vers le staging + +Seul le préfixe `datasets/` est répliqué afin de limiter le volume de données copiées vers le staging. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket de production et sélectionnez l'onglet `Réplication`{.action}. Cliquez sur `Ajouter une règle de réplication`{.action}. Définissez le filtre de préfixe sur `datasets/`, la destination sur `staging-data-`, laissez la classe de stockage **Standard**, désactivez la **réplication des marqueurs de suppression** et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "prod-to-staging", + "Status": "Enabled", + "Priority": 1, + "Filter": { "Prefix": "datasets/" }, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::staging-data-", + "StorageClass": "STANDARD" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket prod-data- \ + --replication-configuration file://replication-staging.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 3 - Appliquer une expiration agressive sur le bucket staging + +Les objets expirent après 14 jours ; les versions non courantes sont nettoyées après 3 jours. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket staging et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Cliquez sur `Ajouter une règle`{.action}. Laissez le préfixe vide. Définissez l'expiration à **14 jours**, l'expiration des versions non courantes à **3 jours** et le nettoyage des uploads multipart incomplets à **1 jour**. Cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "staging-cleanup", + "Status": "Enabled", + "Filter": {}, + "Expiration": { "Days": 14 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 3 }, + "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 1 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket staging-data- \ + --lifecycle-configuration file://lifecycle-staging.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!warning] +> La **réplication des marqueurs de suppression** est désactivée dans la règle de réplication ci-dessus. Cela garantit que les suppressions effectuées sur le bucket de production ne se propagent pas vers le staging, permettant aux environnements de staging de continuer à fonctionner avec leur copie locale des données même après la suppression des objets en production. + +--- + +## Cas d'usage 6 - Logs et observabilité + +### Contexte + +Les données de logs ont des exigences de rétention hétérogènes selon leur type : + +- **Logs d'accès** : rétention courte (30 jours), volume élevé, valeur faible après quelques semaines +- **Logs d'erreurs applicatifs** : rétention moyenne (90 jours), utiles pour les post-mortems d'incidents +- **Logs d'audit et de sécurité** : rétention longue (1 à 7 ans), requise pour la conformité + +La combinaison de lifecycles par préfixe et de la réplication vers un bucket de sécurité ou SIEM centralisé permet une gestion granulaire et automatisée de la rétention sans intervention manuelle. + +### Architecture + +| Bucket | Région | Rôle | +|--------|--------|------| +| `logs-primary-` | ex. GRA | Reçoit tous les logs sous des préfixes typés | +| `logs-security-` | ex. DE | Réplica sécurité/SIEM ; reçoit uniquement les logs d'audit | + +### Étape 1 - Activer le versioning sur les deux buckets + +**Via l'espace client OVHcloud** + +Connectez-vous à l'[espace client OVHcloud](https://www.ovh.com/auth/) et accédez à `Public Cloud`{.action} > `Object Storage`{.action} > `Mes conteneurs`{.action}. Pour chaque bucket, cliquez sur son nom, sélectionnez l'onglet `Versioning`{.action}, activez-le et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket logs-primary- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket logs-security- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 2 - Configurer la réplication sélective pour les logs d'audit uniquement + +Seul le préfixe `audit/` est répliqué vers le bucket de sécurité. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket de logs primaire et sélectionnez l'onglet `Réplication`{.action}. Cliquez sur `Ajouter une règle de réplication`{.action}. Définissez le filtre de préfixe sur `audit/`, la destination sur `logs-security-`, choisissez **Infrequent Access** comme classe de stockage de destination, désactivez la **réplication des marqueurs de suppression** et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-audit-to-security", + "Status": "Enabled", + "Priority": 1, + "Filter": { "Prefix": "audit/" }, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::logs-security-", + "StorageClass": "STANDARD_IA" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket logs-primary- \ + --replication-configuration file://replication-logs.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 3 - Appliquer des lifecycles différenciées sur le bucket primaire + +Appliquez des règles d'expiration et de transition distinctes par type de log grâce aux filtres de préfixe. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket de logs primaire et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Utilisez `Ajouter une règle`{.action} pour créer trois règles : + +- **Règle 1** - préfixe `access/` : expiration à **30 jours** +- **Règle 2** - préfixe `errors/` : transition vers **Infrequent Access** au jour 30, expiration à **90 jours** +- **Règle 3** - préfixe `audit/` : transition vers **Infrequent Access** au jour 90, **Active Archive** au jour 365 (3-AZ uniquement), **Cold Archive** au jour 730 (3-AZ uniquement), expiration à **2555 jours** + +**Via l'AWS CLI** + +> [!primary] +> `GLACIER_IR` (Active Archive) et `DEEP_ARCHIVE` (Cold Archive) sont disponibles uniquement dans les **régions 3-AZ**. Pour les **régions 1-AZ**, utilisez uniquement `STANDARD_IA` pour la règle `audit/`. + +```json +{ + "Rules": [ + { + "ID": "expire-access-logs", + "Status": "Enabled", + "Filter": { "Prefix": "access/" }, + "Expiration": { "Days": 30 } + }, + { + "ID": "expire-error-logs", + "Status": "Enabled", + "Filter": { "Prefix": "errors/" }, + "Transitions": [ + { "Days": 30, "StorageClass": "STANDARD_IA" } + ], + "Expiration": { "Days": 90 } + }, + { + "ID": "archive-audit-logs", + "Status": "Enabled", + "Filter": { "Prefix": "audit/" }, + "Transitions": [ + { "Days": 90, "StorageClass": "STANDARD_IA" }, + { "Days": 365, "StorageClass": "GLACIER_IR" }, + { "Days": 730, "StorageClass": "DEEP_ARCHIVE" } + ], + "Expiration": { "Days": 2555 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket logs-primary- \ + --lifecycle-configuration file://lifecycle-logs.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 4 - Appliquer la rétention à long terme sur le bucket de sécurité + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket de sécurité et sélectionnez l'onglet `Règles de cycle de vie`{.action}. Cliquez sur `Ajouter une règle`{.action}. Laissez le préfixe vide. Pour les **régions 3-AZ**, ajoutez les transitions : **Infrequent Access** au jour 90, **Active Archive** au jour 365 et **Cold Archive** au jour 730. Pour les **régions 1-AZ**, ajoutez uniquement la transition **Infrequent Access** au jour 90. Définissez l'expiration à **2555 jours**. Cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +> [!primary] +> `GLACIER_IR` (Active Archive) et `DEEP_ARCHIVE` (Cold Archive) sont disponibles uniquement dans les **régions 3-AZ**. Pour les **régions 1-AZ**, utilisez uniquement `STANDARD_IA`. + +```json +{ + "Rules": [ + { + "ID": "security-long-term-retention", + "Status": "Enabled", + "Filter": {}, + "Transitions": [ + { "Days": 90, "StorageClass": "STANDARD_IA" }, + { "Days": 365, "StorageClass": "GLACIER_IR" }, + { "Days": 730, "StorageClass": "DEEP_ARCHIVE" } + ], + "Expiration": { "Days": 2555 } + } + ] +} +``` + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket logs-security- \ + --lifecycle-configuration file://lifecycle-security.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!primary] +> En structurant votre pipeline de logs avec des préfixes typés (`access/`, `errors/`, `audit/`), vous pouvez appliquer des règles de lifecycle précises à chaque catégorie indépendamment. L'ajout d'un nouveau type de log ne nécessite qu'un nouveau préfixe et une nouvelle règle de lifecycle - aucune refactorisation du pipeline n'est nécessaire. + +--- + +## Cas d'usage 7 - Sauvegarde SaaS multi-tenant + +### Contexte + +Les plateformes SaaS servant plusieurs tenants doivent souvent fournir des garanties de sauvegarde et d'isolation des données par tenant. Les exigences courantes incluent : + +- L'isolation des données par tenant (données de chaque tenant stockées sous un préfixe dédié) +- Des politiques de rétention par tenant reflétant les SLA contractuels +- La réplication hors site des données tenant pour la résilience et la conformité + +Ce cas d'usage illustre un modèle **préfixe par tenant** au sein d'un bucket partagé, combiné à des règles de lifecycle basées sur les tags pour appliquer des politiques différenciées par tenant. + +### Architecture + +| Bucket | Région | Rôle | +|--------|--------|------| +| `saas-tenants-` | ex. GRA | Bucket multi-tenant principal ; isolation des données par préfixe | +| `saas-backup-` | ex. DE | Réplica de sauvegarde hors site pour tous les tenants | + +Les objets sont stockés sous les préfixes `tenants//`. Les objets de chaque tenant sont tagués au moment du téléversement avec un tag `tenant-tier` (ex. `standard` ou `premium`), permettant des lifecycles différenciées. + +### Étape 1 - Activer le versioning sur les deux buckets + +**Via l'espace client OVHcloud** + +Connectez-vous à l'[espace client OVHcloud](https://www.ovh.com/auth/) et accédez à `Public Cloud`{.action} > `Object Storage`{.action} > `Mes conteneurs`{.action}. Pour chaque bucket, cliquez sur son nom, sélectionnez l'onglet `Versioning`{.action}, activez-le et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```bash +aws s3api put-bucket-versioning \ + --bucket saas-tenants- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net + +aws s3api put-bucket-versioning \ + --bucket saas-backup- \ + --versioning-configuration Status=Enabled \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 2 - Téléverser les objets avec les tags de métadonnées tenant + +Les objets doivent être tagués au moment du téléversement pour que les règles de lifecycle basées sur les tags puissent les identifier correctement. + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket tenants. Sélectionnez l'onglet `Objets`{.action} et cliquez sur `+ Ajouter des objets`{.action}. Avant de confirmer le téléversement, développez la section **Tags**. Ajoutez un tag avec la clé `tenant-id` et la valeur `tenant-abc123`, et un second tag avec la clé `tenant-tier` et la valeur `premium`. Sélectionnez votre fichier et cliquez sur `Importer`{.action}. + +**Via l'AWS CLI** + +```bash +aws s3api put-object \ + --bucket saas-tenants- \ + --key "tenants/tenant-abc123/backup-2025-04-15.tar.gz" \ + --body backup-2025-04-15.tar.gz \ + --tagging "tenant-id=tenant-abc123&tenant-tier=premium" \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 3 - Configurer la réplication vers le bucket de sauvegarde + +**Via l'espace client OVHcloud** + +Depuis l'onglet `Mes conteneurs`{.action}, cliquez sur le nom de votre bucket tenants et sélectionnez l'onglet `Réplication`{.action}. Cliquez sur `Ajouter une règle de réplication`{.action}. Définissez le filtre de préfixe sur `tenants/`, la destination sur `saas-backup-`, choisissez **Infrequent Access** comme classe de stockage de destination, désactivez la **réplication des marqueurs de suppression** et cliquez sur `Enregistrer`{.action}. + +**Via l'AWS CLI** + +```json +{ + "Role": "", + "Rules": [ + { + "ID": "replicate-all-tenants", + "Status": "Enabled", + "Priority": 1, + "Filter": { "Prefix": "tenants/" }, + "DeleteMarkerReplication": { "Status": "Disabled" }, + "Destination": { + "Bucket": "arn:aws:s3:::saas-backup-", + "StorageClass": "STANDARD_IA" + } + } + ] +} +``` + +```bash +aws s3api put-bucket-replication \ + --bucket saas-tenants- \ + --replication-configuration file://replication-saas.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +### Étape 4 - Appliquer des lifecycles basées sur les tags pour une rétention différenciée + +> [!primary] +> Les filtres de lifecycle basés sur les tags sont actuellement configurables via l'AWS CLI. Pour les règles à base de tags dans l'espace client OVHcloud, vérifiez l'onglet `Règles de cycle de vie`{.action} de votre bucket - la prise en charge des filtres par tag peut avoir été ajoutée depuis la publication de ce guide. + +**Via l'AWS CLI** + +```json +{ + "Rules": [ + { + "ID": "standard-tier-retention", + "Status": "Enabled", + "Filter": { + "Tag": { "Key": "tenant-tier", "Value": "standard" } + }, + "Transitions": [ + { "Days": 30, "StorageClass": "STANDARD_IA" } + ], + "Expiration": { "Days": 90 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 7 } + }, + { + "ID": "premium-tier-retention", + "Status": "Enabled", + "Filter": { + "Tag": { "Key": "tenant-tier", "Value": "premium" } + }, + "Transitions": [ + { "Days": 60, "StorageClass": "STANDARD_IA" }, + { "Days": 180, "StorageClass": "GLACIER_IR" }, + { "Days": 365, "StorageClass": "DEEP_ARCHIVE" } + ], + "Expiration": { "Days": 730 }, + "NoncurrentVersionExpiration": { "NoncurrentDays": 30 } + } + ] +} +``` + +> [!primary] +> `GLACIER_IR` (Active Archive) et `DEEP_ARCHIVE` (Cold Archive) dans la règle `premium` sont disponibles uniquement dans les **régions 3-AZ**. Pour les **régions 1-AZ**, utilisez uniquement `STANDARD_IA`. + +```bash +aws s3api put-bucket-lifecycle-configuration \ + --bucket saas-tenants- \ + --lifecycle-configuration file://lifecycle-saas.json \ + --endpoint-url https://s3..io.cloud.ovh.net +``` + +> [!warning] +> Les règles de lifecycle basées sur les tags nécessitent que chaque objet soit tagué correctement au moment du téléversement. Pensez à appliquer cette contrainte au niveau applicatif pour garantir la cohérence entre tous les téléversements des tenants. Si le niveau d'un tenant change, retaguer les objets existants permettra à la règle de lifecycle appropriée de s'appliquer à partir de ce moment. + +--- + +## Récapitulatif + +Le tableau ci-dessous fournit une référence rapide des choix de configuration clés pour les sept cas d'usage : + +| Cas d'usage | Périmètre de réplication | Réplication des marqueurs de suppression | Lifecycle primaire | Lifecycle secondaire | +|----------|------------------|--------------------------|-------------------|---------------------| +| Archivage réglementaire | Tous les objets | Activée | Tiering (30 -> 90 -> 365 jours) | Expiration à 7 ans | +| Reprise après sinistre | Tous les objets | Désactivée | Expiration à 60 jours | Expiration à 1 an | +| Data lake tiering | Tous les objets | Désactivée | Tiering par préfixe | Aucune (classe Standard conservée) | +| Distribution géo de contenu | Tous les objets | Activée | Aucune sur l'origine | Expiration des versions non courantes | +| Sync Dev/Staging | Filtre préfixe (`datasets/`) | Désactivée | Standard | Expiration à 14 jours | +| Logs et observabilité | Filtre préfixe (`audit/`) | Désactivée | Expiration différenciée par préfixe | Rétention long terme + tiering | +| SaaS multi-tenant | Filtre préfixe (`tenants/`) | Désactivée | Rétention différenciée par tag | Infrequent Access (tous tenants) | + +> [!warning] +> Les règles de lifecycle de l'Object Storage sont évaluées une fois par jour. Il peut y avoir un délai allant jusqu'à 24 heures entre le moment où un objet remplit les critères d'une transition ou d'une expiration et le moment où l'action est effectivement réalisée. Pendant ce délai, les objets continuent d'être facturés au tarif de leur classe de stockage actuelle. + +## Aller plus loin + +- [Object Storage - Gérer le cycle de vie des objets](/pages/storage_and_backup/object_storage/s3_lifecycle/guide.fr-fr) +- [Object Storage - Maîtriser la réplication asynchrone sur vos buckets](/pages/storage_and_backup/object_storage/s3_replication/guide.fr-fr) +- [Object Storage - Choisir la classe de stockage adaptée à vos besoins](/pages/storage_and_backup/object_storage/s3_storage_class/guide.fr-fr) +- [Object Storage - Premiers pas avec l'Object Storage](/pages/storage_and_backup/object_storage/s3_getting_started_with_object_storage/guide.fr-fr) +- [Object Storage - Endpoints et disponibilité géographique](/pages/storage_and_backup/object_storage/s3_location/guide.fr-fr) + +Échangez avec notre [communauté d'utilisateurs](https://community.ovh.com/). + +--- + +*1 : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services d'OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque manière que ce soit à Amazon Technologies, Inc.* diff --git a/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/meta.yaml b/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/meta.yaml new file mode 100644 index 00000000000..23f838e8991 --- /dev/null +++ b/pages/storage_and_backup/object_storage/s3_use_cases_lifecycle_replication/meta.yaml @@ -0,0 +1,3 @@ +id: adc655e5-de9e-4a0b-be58-0e1415dfba53 +full_slug: public-cloud-storage-s3-use-cases-lifecycle-replication +reference_category: public-cloud-storage-object-storage-s3-tutorials