Cloud Storage Advisor: Egress-Spitzen mit IAM prüfen

Der allgemein verfügbare Storage Intelligence advisor macht auffälligen regionsübergreifenden Egress, Fehler und Operationsspitzen in Cloud Storage sichtbar. Vor der Nutzung müssen Betreiber Storage Intelligence für die passende Ressourcenebene aktivieren und dem Betriebsteam die erforderlichen IAM-Berechtigungen geben.

Danach lässt sich ein Befund von der Organisation oder dem Ordner bis zum betroffenen Projekt, Bucket, Präfix und Dienstkonto untersuchen. Der Advisor führt jedoch keine Korrektur aus: Fehlende Projektrechte und zu eng gesetzte Bucket-Filter begrenzen die Analyse, während jede vorgeschlagene Maßnahme fachlich geprüft werden muss.

Ressourcenbereich und Zuständigkeiten festlegen

Wählen Sie zuerst, ob Storage Intelligence für ein Projekt, einen Ordner oder die gesamte Organisation gelten soll. Laut den Cloud-Storage-Release-Notes ist der Storage Intelligence advisor seit dem 10. September 2026 allgemein verfügbar und unterstützt alle drei Ebenen.

Die passende Ebene folgt der betrieblichen Verantwortung. Ein zentrales Plattform- oder FinOps-Team benötigt meist eine organisations- oder ordnerweite Sicht, während ein eigenständig verwaltetes Anwendungsteam mit einer Projektkonfiguration auskommen kann. Halten Sie zusätzlich fest, wer die Konfiguration verwaltet, wer Befunde untersucht und wer Änderungen an Anwendungen, Speicherklassen oder Ressourcenstandorten freigibt.

IAM und Aktivierung gemeinsam vorbereiten

Für die Konfiguration empfiehlt Google die Rolle Storage Admin mit der Kennung roles/storage.admin auf der gewählten Projekt-, Ordner- oder Organisationsebene. Die Konfigurationsanleitung von Google nennt dafür die Berechtigungen zum Lesen und Ändern der Storage-Intelligence-Konfiguration; benutzerdefinierte oder andere vordefinierte Rollen sind möglich, sofern sie die benötigten Rechte vollständig enthalten.

Öffnen Sie anschließend in der Google Cloud Console die Konfigurationsseite von Storage Intelligence, wählen Sie „Enable Storage Intelligence“ und den vorgesehenen Ressourcenbereich. Optional können Sie Buckets nach Standort oder über reguläre Ausdrücke für Bucket-Namen ein- und ausschließen. Bestätigen Sie die Konfiguration und kontrollieren Sie danach, ob für die Ressource der Status „Enabled“ angezeigt wird.

Prüfen Sie Filter besonders sorgfältig: Ein ausgeschlossener Standort oder ein zu enges Namensmuster entfernt die betroffenen Buckets aus dem Geltungsbereich. Bestehen bereits ältere Storage-Insights-Datasets, empfiehlt Google, sie zu löschen oder zu entfernen, wenn zusätzliche Speicherkosten vermieden werden sollen. Das betrifft vorhandene Datasets und ist nicht mit einem vom Advisor automatisch erzeugten Befund gleichzusetzen.

Berechtigungslücken vor der Ursachenanalyse schließen

Die Rolle für die Konfiguration allein garantiert noch keine lückenlose organisationsweite Untersuchung. Zum Anzeigen des Advisors empfiehlt Google ebenfalls Storage Admin; alternativ muss eine eigene Rolle unter anderem die Berechtigungen für Findings, Bucket-Details sowie relevante Cloud-Monitoring-Metadaten und -Metriken enthalten.

Die offizielle Anleitung zur Advisor-Ansicht dokumentiert sowohl Warnungen bei unzureichendem Zugriff auf einzelne Projekte als auch Befunde für Class-A/B-Operationen, 429-Fehler, regionsübergreifenden Egress und über dem Trend liegendes Speicherwachstum. Eine solche Warnung ist kein bloßer Oberflächenhinweis: Das Projekt kann in einer zusammengefassten Ansicht erscheinen, ohne dass der angemeldete Benutzer dort die Details bis zum Bucket untersuchen kann.

Erfassen Sie deshalb vor der fachlichen Bewertung alle Projekte mit Berechtigungswarnung. Entweder erhält das zuständige Untersuchungsteam die fehlenden Rechte, oder der Befund wird an eine berechtigte Projektverantwortung übergeben. Ohne diese Zuordnung bleibt offen, ob die angezeigte organisationsweite Abweichung vollständig erklärt wurde.

Vom Finding zur technischen Ursache gehen

Beginnen Sie mit „At a glance“, um Speichergröße, Bucket- und Objektanzahl sowie die durchschnittliche Objektgröße einzuordnen. Öffnen Sie danach unter „Top findings“ den relevanten Befund. Auf Organisations- und Ordnerebene zeigt eine Fundkarte mehrere betroffene Projekte zusammengefasst; die eigentliche Ursachenanalyse erfolgt anschließend im jeweiligen Projekt.

Prüfen Sie Kategorie, Aktualisierungszeitpunkt, gemeinsame Einflussfaktoren und den projektweiten Anstieg.
Ermitteln Sie unter „Buckets with largest increases“, welche Buckets die Abweichung prägen.
Öffnen Sie einen betroffenen Bucket und vergleichen Sie die zum Finding gehörende Aktivitätsmetrik.
Untersuchen Sie Präfixe mit den größten Zunahmen sowie die Dienstkonten, von denen zusätzliche API-Anfragen ausgegangen sind.
Ordnen Sie Zeitpunkt und Identität einem bekannten Deployment, Batchjob, Restore, Analyseauftrag oder Datentransfer zu.

Bei einem Egress-Finding sind das regionsübergreifende Übertragungsvolumen und dessen Zunahme entscheidend. Ein Class-A/B-Finding betrifft dagegen häufige Operationen auf Coldline- oder Archive-Daten, während ein 429-Finding auf gedrosselte Anfragen hinweist. Diese Befunde haben unterschiedliche Ursachen und sollten nicht als ein einheitlicher Kostenalarm behandelt werden.

Empfehlungen vor Änderungen validieren

Die im Advisor genannten nächsten Schritte sind Handlungsvorschläge, keine automatisch ausgeführten Korrekturen. Das Zusammenlegen von Compute- und Storage-Ressourcen in derselben Region kann regionsübergreifenden Transfer reduzieren, kann aber auch Latenz-, Resilienz- oder Standortvorgaben berühren. Prüfen Sie deshalb zuerst, welche Anwendung den Transfer erzeugt und ob deren Ressourcenstandort tatsächlich geändert werden darf.

Bei häufigen Operationen auf Coldline- oder Archive-Daten kann eine für regelmäßige Zugriffe geeignete Speicherklasse sinnvoll sein. Maßgeblich sind jedoch das bestätigte Zugriffsmuster und geltende Aufbewahrungsanforderungen. Bei 429-Fehlern sollten Sie das auslösende Dienstkonto, den betroffenen Präfixbereich und die Wiederholungslogik untersuchen, bevor Sie Parallelität oder Architektur verändern.

Für über dem Trend liegendes Speicherwachstum kommen beispielsweise nicht aktuelle Objektversionen oder fehlende Lifecycle-Regeln infrage. Auch hier ersetzt die Empfehlung keine Prüfung des aktiven Datenbestands. Eine belastbare Freigabe verbindet deshalb vier Nachweise: aktivierte Konfiguration, vollständige IAM-Abdeckung, technische Zuordnung des Findings und dokumentierte Bewertung der vorgesehenen Änderung.

Lesen Sie auch:

Cloud Storage Advisor findet Egress-Spitzen – Zugriffsrechte bleiben Pflicht