STACKIT Object Storage: S3-Kompatibilität clever nutzen.

Kurzüberblick zum Object-Storage-Dienst in STACKIT

Der STACKIT Object Storage ist ein skalierbarer, verteilter Objektspeicher für Backups, Medien, Logs und beliebige Blob-Daten. Er ist auf hohe Verfügbarkeit und Kostenoptimierung ausgelegt und lässt sich in bestehende Anwendungen integrieren, ohne dass deren Grundarchitektur angepasst werden muss.

Für Betreiber und Entwickler bedeutet das: stabile Speicherung großer Datenmengen bei freier Wahl der Werkzeuge zur Verwaltung und Nutzung.

Der Dienst ist S3-kompatibel und speichert Daten automatisch zonenredundant in europäischen Rechenzentren, was ein Plus für Verfügbarkeit und Datenhoheit ist. Zudem punktet STACKIT mit transparenten Kosten: Für den Ingress und Egress von Daten innerhalb der STACKIT Cloud fallen keine Netzwerkkosten an. Alle gespeicherten Daten und Daten im Transit sind standardmäßig mit AES-256 verschlüsselt.

Was „S3-API-Kompatibilität“ praktisch bedeutet

„S3-kompatibel“ heißt, dass API-Schnittstelle, Authentifizierungsmechanismen und die grundlegenden Operationen (Put/Get/List/Delete, Multipart Uploads, Presigned URLs etc.) dem De-facto-Standard von Amazon S3 folgen.

Das ermöglicht Ihnen, bewährte Tools und SDKs direkt einzusetzen. Achten Sie jedoch auf Details, wie:

• Path-Style vs. Virtual-Host-Style

• Signatur-Versionen (v2/v4)

• mögliche Feature-Unterschiede

Diese Feinheiten testen Sie am besten in einem kurzen Proof-of-Concept.

In 3 einfachen Schritten zum managed Object Store in STACKIT:

1. Dienst aktivieren:
   

2. Bucket erstellen:
   

   
   

3. Zugangsdaten anlegen: 

   
   
   
   

   Die Access Key ID und der Secret Access Key, die Ihnen in dieser Maske angezeigt werden, sollten Sie unbedingt speichern. Sie sind nur einmalig zugänglich; andernfalls müssten neue Zugangsdaten erstellt werden. Mit diesen beiden Werten können Sie anschließend über S3-kompatible Tools auf Ihren Bucket zugreifen und mit ihm arbeiten.

Weitere technische Details und Endpoint-Infos finden Sie in der STACKIT-Dokumentation.

Bucket Policies: Zugriffsrechte flexibel steuern

Eine Bucket Policy ist eine Zugriffsrichtlinie in Form eines JSON-Dokuments, das direkt an einen Bucket angehängt wird. Sie legt fest:

• Wer (Principal) auf den Bucket oder Objekte zugreifen darf

• Welche Aktionen (z. B. s3:GetObject, s3:PutObject) erlaubt sind

• Auf welche Ressourcen sich die Rechte beziehen

Neue Buckets sind in STACKIT standardmäßig privat. Mit Policies können Sie dieses Verhalten erweitern oder anpassen.

Typische Anwendungsfälle:

• Zugriff für Nutzer aus anderen Portal-Projekten

• Öffentliche Inhalte (z. B. Bilder oder Dateien für Websites)

Beispiel: Alle Objekte im Bucket öffentlich lesbar machen:

{
  "Statement": [
  {
    "Sid": "Public GET",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::BUCKETNAME/*"
  }
  ]
}

Weitere Konfigurationsbeispiele finden Sie in der STACKIT-Dokumentation.

Erweiterte Konfigurationsmöglichkeiten

Neben den Basisfunktionen unterstützt STACKIT Object Storage auch erweiterte Features:

• S3 Lifecycle Configurations: Regeln für automatische Übergänge oder Löschungen nach definierten Zeiträumen

• Pre-Signed URLs: Temporäre, signierte Links für den sicheren, zeitlich begrenzten Zugriff auf private Objekte

• Server-Side Encryption (SSE/SSE-C): Verschlüsselung direkt im Storage, mit STACKIT-Schlüsseln oder eigenen Kundenschlüsseln

• CORS (Cross-Origin Resource Sharing): Kontrolle, von welchen Domains Browser-Apps direkt auf Buckets zugreifen dürfen

• Bucket Versioning: Mehrere Versionen desselben Objekts speichern, um versehentliche Löschungen oder Überschreibungen rückgängig zu machen

Praktische GUI-Tools für S3-kompatible Buckets

Da das STACKIT-Portal aktuell keine integrierte Objekt-Browser-Ansicht bietet, empfiehlt sich für die Verwaltung ein externer Client. Besonders S3 Browser (Windows) ist leichtgewichtig, einfach einzurichten und speziell auf S3-Workflows ausgerichtet, was ideal für Nutzer ist, die Buckets und Dateien per Drag & Drop verwalten möchten.

Alternativ können Sie auch Cyberduck (Windows/macOS) verwenden. Eine Schritt-für-Schritt-Anleitung zur Einrichtung finden Sie direkt in der STACKIT-Dokumentation.

Für Automatisierungen und Skripte eignen sich ergänzend Tools wie s3cli oder rclone.

Besonderheiten bei Infrastructure-as-Code und Provider-Kompatibilität

Bei der Verwendung von Infrastructure-as-Code (IaC) mit STACKIT Object Storage ergeben sich spezielle Abhängigkeiten zwischen Ressourcen und Providern, die bei der Planung berücksichtigt werden müssen. Ressourcen wie Buckets, Credential-Gruppen und Secrets werden zunächst über den STACKIT Provider erstellt. Nachfolgend am Beispiel von Terraform dargestellt:

resource "stackit_objectstorage_bucket" "bucket" {
  project_id = var.project_id
  name       = "example-bucket"
}

resource "stackit_objectstorage_credentials_group" "credentials_group" {
  project_id = var.project_id
  name       = "example-bucket"
}

resource "stackit_objectstorage_credential" "bucket_credentials" {
  project_id           = var.project_id
  credentials_group_id = stackit_objectstorage_credentials_group.credentials_group.credentials_group_id
}

Erst danach können diese Informationen genutzt werden, um mit dem AWS Provider auf die S3-kompatible Schnittstelle von STACKIT zuzugreifen, z. B. beim Setzen einer Bucket Policy:

resource "aws_s3_bucket_policy" "public_read_access" {
  bucket = stackit_objectstorage_bucket.bucket.name
  policy = <<POLICY
  {
    "Statement": [
      {
        "Sid": "Public GET",
        "Effect":"Allow",
        "Principal":"*",
        "Action":"s3:GetObject",
        "Resource": "arn:aws:s3:::${stackit_objectstorage_bucket.bucket.name}/*"
      }
    ]
  }
  POLICY
}

Damit dies funktioniert, müssen jedoch alle für den AWS Provider Block benötigten Informationen bereits existieren, bevor dieser initialisiert wird. Anders als Resource-Blöcke unterstützen Provider-Blöcke keine depends_on-Angaben. Der AWS Provider Block muss daher direkt auf die bereits erstellten Credentials zugreifen und den Endpoint korrekt gesetzt bekommen:

provider "aws" {
  region                      = "eu01"
  skip_credentials_validation = true
  skip_region_validation      = true
  skip_requesting_account_id  = true
  access_key                  = stackit_objectstorage_credential.bucket_credentials.access_key
  secret_key                  = stackit_objectstorage_credential.bucket_credentials.secret_access_key
  endpoints {
    s3 = "https://object.storage.eu01.onstackit.cloud"
  }
}

Take-Away: Um Fehler zu vermeiden, dass der Provider auf nicht vorhandene Credentials zugreifen möchte, empfiehlt es sich, die STACKIT-Ressourcen in einem ersten Apply-Schritt zu erstellen und den AWS Provider erst im zweiten Schritt zu verwenden. So wird sichergestellt, dass alle Informationen bei der Initialisierung der Providerblöcke bereits vorhanden sind.

Fazit

Der STACKIT Object Storage bietet eine leistungsfähige, S3-kompatible Lösung für Unternehmen, die Wert auf Datenhoheit, Sicherheit und Kostentransparenz legen. Dank der API-Kompatibilität lassen sich bestehende Tools und Workflows nahezu nahtlos weiterverwenden.

Ob für Backups, Medien-Assets oder Logs: Mit Features wie Lifecycle-Regeln, Pre-Signed URLs und Bucket Policies behalten Sie jederzeit Kontrolle über Datenzugriff und Speicheroptimierung. Externe Clients wie Cyberduck oder S3 Browser ergänzen die Verwaltung sinnvoll.

Kurz gesagt: ein flexibler, sicherer und zukunftsfähiger Object Storage „Made in Europe“.