Unit 5.2: Object Storage

Introduction

Object Storage is the backstop of the data architecture. It is where the audit-log exports from Unit 2.3 land for their long-term, tamper-evident life, where Backup Service and database dumps come to rest, where ML datasets and build artifacts sit, and where event-streaming dead letters accumulate. It earns this position because it is durable, S3-compatible, and priced for bulk. The two decisions that make or break it, however, are taken once and cannot be undone: the bucket's type and region, and whether Object Lock is on. This unit treats those decisions first, then builds the bucket in the Data Center Designer with the locks and lifecycle rules that turn raw storage into a compliant retention tier.

1. What Object Storage Is, and the Roles It Plays

IONOS Cloud Object Storage adheres to the AWS S3 API (v2 of the S3 protocol), so the same tooling, SDKs, and applications that target S3-compatible platforms work against it. Data lives in a flat namespace: objects (each carrying metadata and a unique key) inside buckets, with no real directory tree underneath. Authentication is by an Access Key and Secret Key pair generated per user (92 and 64 characters in the current format, up to 5 keys per user); the DCD uses these credentials to drive the web interface, and the same pair is what any S3 client or SDK presents. A single object can be up to 5 TiB, and the only storage class is STANDARD. Pricing is pay-as-you-go on storage and outbound transfer per gigabyte with no per-request charge, which is why bulk and archival workloads land here rather than on Block Storage.

These properties decide where Object Storage fits in the FinCorp architecture:

Audit archive. Activity Logs are per-contract, read-only, and retained for only 35 days (Unit 2.3). Exporting them to a bucket before that window closes gives FinCorp the multi-year, tamper-evident retention its regulators expect. Object Lock (Section 2) is what makes that archive tamper-evident.
Backup target. Backup Service and database dump/restore output (Units 5.3, 5.7) write here. Note the honest boundary: Backup Service (Acronis) scope is VMs and Block Storage, it does not back up managed databases, and it does not provide immutable backups itself. Object Lock on the destination bucket is how FinCorp adds the immutability Backup Service does not.
Dataset and artifact store. The AI tier (Module 6) reads its training corpus and stores model artifacts here; a customer-built retrieval-augmented-generation corpus also lives in Object Storage. The flat namespace is well suited to large volumes of unstructured data outside a database.
Dead-letter destination. Managed Kafka (Unit 5.6) writes its archive and dead-letter tail to a bucket, where unprocessed records accumulate cheaply for later inspection.

The platform's documented use cases also include website asset storage, static website hosting, multimedia asset hosting, and private file storage; for FinCorp, backup/restore and storing unstructured data are the primary uses.

2. The Two Irreversible Decisions: Bucket Type, Region, and Object Lock

2.1 Bucket type and region are bound at creation

A bucket is either contract-owned or user-owned, and the type also constrains which regions are available. It changes ownership, visibility, and which endpoints serve the bucket.

Contract-owned buckets make the contract owner the owner of every bucket. Every user in the contract can see the full bucket list, and the contract owner or an administrator grants access and defines permissions through Bucket Policy settings. This is the right model for a single organization like FinCorp that wants centralized governance.
User-owned buckets are owned independently by each user, who creates and manages them without the contract owner's approval, with no combined list across users. This predates contract-owned buckets and suits cases where users are separate entities.

Region selection is constrained by type. The two tables below are the authoritative region lists per bucket type.

Contract-owned buckets can be created only in the following regions:

Data Center	Region
Frankfurt, Germany	eu-central-4
Berlin, Germany	eu-central-3
Lenexa, USA	us-central-1

User-owned buckets can be created only in the following regions:

Data Center	Region
Frankfurt, Germany	de
Berlin, Germany	eu-central-2
Logroño, Spain	eu-south-2

Each region has its own endpoint URL, and a bucket name must be globally unique across all of Object Storage (3 to 63 characters). Region matters for proximity (latency and egress cost near the application or users) and for redundancy (a backup or archive belongs in a region geographically separate from the primary so it survives a local outage). For FinCorp under GDPR and BSI, this is the residency decision from Unit 1.4 applied in practice: keep the audit archive and database backups in German data centers (de, eu-central-3, or eu-central-4) rather than us-central-1. The S3 Object Storage service is covered by both the BSI C5 Type 1 attestation (granted 2023-11-07, German data centers) and the IT-Grundschutz-based ISO 27001 certificate (granted 2022-09-14); placing the archive in a German region is what keeps it inside that scope. Cross-region durability is achieved through replication you design, not an automatic property of one bucket.

2.2 Object Lock and lifecycle: tamper-evidence and cost control

Object Lock implements Write Once Read Many (WORM): an object cannot be erased or modified for a retention period. It has two modes:

GOVERNANCE mode protects objects from ordinary deletion while still allowing privileged users to override the lock.
COMPLIANCE mode is absolute: until the retention date passes, the object is immutable, the mode cannot be disabled, and the retention period cannot be shortened, not even by the bucket owner. This is the mode for FinCorp's regulatory archive, where the requirement is that no one, including an administrator, can tamper with the evidence.

Retention can be set up to 365 days through the DCD; the API supports up to 100 years. The decisive constraint is timing: Object Lock can only be enabled when the bucket is created, never added afterward. Enabling it also turns on versioning, and once enabled neither can be disabled. One composition limit matters: a bucket with Object Lock enabled cannot be a source for replication or tiering, though it can be a destination. If FinCorp needs both a locked archive and outbound replication from the same data, the replication must originate from an unlocked bucket and target the locked one.

Lifecycle rules address cost. A configuration can hold up to 1,000 rules, each scoped to all objects or to a single prefix (one rule per prefix). The actions are: expire current versions after a number of days or on a date; permanently delete noncurrent versions; delete expired object delete markers; and delete incomplete multipart uploads. Because the only storage class is STANDARD, lifecycle cannot transition objects to a cheaper tier; here it is an expiration and cleanup tool, not a tiering tool. It pairs naturally with Object Lock: the COMPLIANCE lock guarantees data survives at least the retention period, while a lifecycle expiration rule guarantees it does not linger and accrue cost once the obligation lapses. Set the expiration at or beyond the lock retention so the two never fight.

3. DCD Implementation Walkthrough

You will create the FinCorp audit-and-backup archive: a contract-owned bucket in a German region, with Object Lock enabled in COMPLIANCE mode at creation, and a lifecycle rule that expires objects once their retention obligation has elapsed. This realizes the tamper-evident retention tier that Unit 2.3's audit export and Unit 5.7's backups depend on.

Build goal: Create a bucket, set object lock and a lifecycle policy.

Prerequisites: A user with the Use Object Storage privilege (granted via group membership, Unit 2.2), and an Object Storage key generated for that user. The first key generation is also what surfaces the Canonical User ID needed to grant cross-user access later.

Steps (in the Data Center Designer):

Open the Object Storage section of the DCD and go to the Buckets tab. Choose to create either a user-owned or contract-owned bucket; for the FinCorp archive, create a contract-owned bucket so governance stays with the contract owner.
Enter a globally unique bucket name (3 to 63 characters) and select the region. For the FinCorp archive choose a German region within the bucket type's allowed set (for a contract-owned bucket, eu-central-4 Frankfurt or eu-central-3 Berlin), keeping the archive inside the C5 and IT-Grundschutz scope.
Enable Object Lock during this creation step. This is the only opportunity to enable it; it cannot be added afterward, and enabling it also enables versioning. Create the bucket.
After creation, open the bucket, click Bucket settings, and go to the Object Lock setting under the Data management section. Set the mode to COMPLIANCE and the retention period to the regulatory horizon (up to 365 days via the DCD). These defaults apply to newly uploaded objects; objects already present follow the settings applied at creation.
Still in Bucket settings, go to the Lifecycle setting under Data management and click Add a rule.
Give the lifecycle rule a unique name and set its scope: all objects, or objects limited to a single prefix (each prefix can carry only one rule).
Select the lifecycle actions. For the archive, choose Expire current versions after a number of days that meets or exceeds the lock retention, and add Permanently delete noncurrent versions and Delete incomplete multipart uploads to control cost from versioning and failed uploads. Save the rule.
Verify in the Buckets list that the bucket shows the correct type, region, and creation date, and confirm the Object Lock and lifecycle settings are present under Bucket settings.

Common mistakes:

Forgetting Object Lock at creation. It cannot be enabled on an existing bucket. If you miss it, you must create a new bucket and migrate the data. Decide on WORM before you click Create.
Choosing COMPLIANCE mode without certainty. In COMPLIANCE mode you cannot shorten retention or disable the lock, even as bucket owner. Use GOVERNANCE while testing and reserve COMPLIANCE for data whose retention requirement is firm.
Picking the wrong region for residency. Region is fixed at creation and dictates the endpoint. A US region (us-central-1) puts a German firm's audit archive outside the German-data-center scope of the BSI credentials. Decide residency before naming the bucket.
Assuming a non-unique bucket name will work. Names are globally unique across all of Object Storage, not just your contract. Namespace them (for example, prefix with the organization) to avoid collisions.
Expecting lifecycle to tier to cheaper storage. Only the STANDARD class exists, so lifecycle rules expire and clean up; they do not move objects to a colder tier. Cost control comes from deletion, not tiering.
Wiring replication out of a locked bucket. A bucket with Object Lock enabled cannot be a replication or tiering source. If you need replication, originate it from an unlocked bucket and make the locked archive the destination.

A short S3-client equivalent makes the creation-time-only nature of Object Lock concrete; the flag is set on create-bucket and has no add-later counterpart:

aws s3api create-bucket \
  --bucket fincorp-audit-archive \
  --object-lock-enabled-for-bucket \
  --region=eu-central-4 --create-bucket-configuration LocationConstraint=eu-central-4 \
  --endpoint-url https://s3.eu-central-4.ionoscloud.com

Summary

Object Storage is the architecture's durable, S3-compatible, bulk-priced backstop: audit archive, backup target, dataset and artifact store, and dead-letter tail. Its power as a compliance tier comes from two decisions taken once at creation, bucket type with its region constraint, and Object Lock, and from lifecycle rules layered on top for cost control. Get the type, region, and lock right at creation, because none of them can be changed afterward.

Key Points:

Object Storage uses the AWS S3 API (v2), a flat object-and-bucket namespace, and Access Key plus Secret Key authentication (92 and 64 characters; up to 5 keys per user); objects can reach 5 TiB and the only class is STANDARD.
Bucket type (contract-owned vs user-owned) is bound at creation and constrains the available regions; contract-owned suits centralized governance, and bucket names are globally unique.
Object Lock delivers WORM in GOVERNANCE or COMPLIANCE mode, must be enabled at creation (cannot be added later), also enables versioning, and in COMPLIANCE mode is irreversible; DCD retention is up to 365 days, the API up to 100 years.
Lifecycle rules (up to 1,000, scoped to all objects or one prefix) expire and clean up objects for cost control but cannot tier to a cheaper class, since only STANDARD exists.
Place FinCorp's audit and backup archive in a German region with COMPLIANCE-mode Object Lock to keep it tamper-evident and inside the BSI C5 and IT-Grundschutz service scope.

Important Terminology:

Object Lock (WORM): Write Once Read Many retention applied to objects; GOVERNANCE allows privileged override, COMPLIANCE is immutable until the retention date and cannot be shortened or disabled.
Lifecycle rule: An automated action (expire current versions, delete noncurrent versions, delete expired delete markers, delete incomplete multipart uploads) scoped to a bucket or a single object prefix.
Contract-owned vs user-owned bucket: The ownership and visibility model, fixed at creation, that also determines which regions and endpoints are available.

Learning Objectives