Entwerfen Sie Ihre Hierarchie (mit Unternehmensbeispielen)
Principles and worked patterns for AWS Organizations, single accounts, multi-cloud groups, MSPs and regulated regions.
Entwerfen Sie Ihre Hierarchie (mit Unternehmensbeispielen)
So entscheiden Sie, wie Ihr Baum aussehen soll, und fünf ausgearbeitete Muster: eine AWS-Organisation, ein nach Tags aufgeteiltes AWS-Konto, viele Clouds und Organisationen, viele Kunden und regulierte Regionen.
Where in CostGlassSettings → Hierarchy
PlanAll plans
Who can do thisAnyone planning the structure; see the Hierarchy guide for who can edit
Time needed15 minutes to read
Kurz und bündig
- Spiegeln Sie, wie Sie für Geld verantwortlich sind, und nicht, wie die Cloud aufgebaut ist. Die Geschäftseinheit, dann das Team und dann die Umgebung funktionieren für die meisten Unternehmen.
- Nutzen Sie die Hierarchie für Eigentum und Zugriff: ein Ort pro Konto und die richtigen Personen sehen die richtigen Konten.
- Verwenden Sie virtuelle Tags für alles, was kontoübergreifend ist oder sich innerhalb eines Kontos befindet, z. B. Produkt, Kostenstelle oder Kunde.
- Verwenden Sie gespeicherte Filter, um einen Teil der Ausgaben in Ansichten und Berichten wiederzuverwenden.
- CostGlass importiert Ihr AWS-OU-Layout nicht. Sie erstellen die Knoten und platzieren die Konten selbst (von Hand, per Regel oder per CSV).
Bevor Sie beginnen
- Sie haben Einrichten Ihrer Organisationshierarchie Daher sind die Namen der Schaltflächen sinnvoll.
- Sie wissen, wer in Ihrem Unternehmen für jede Gruppe von Cloud-Konten verantwortlich ist.
- Ihre Cloud-Konten sind verbunden (oder Sie wissen, wie viele Sie verbinden werden).
Was ist die beste Hierarchie?
Es gibt keinen einzigen besten Baum, aber einen guten Test: Können Sie für jeden Knoten eine Person oder ein Team benennen, die für die Ausgaben verantwortlich ist? Wenn Sie können, ist der Knoten nützlich. Wenn ein Knoten nur existiert, weil „dort zufällig das Konto ist“, ist er wahrscheinlich nicht vorhanden.
Prinzipien
- Spiegeln Sie die Verantwortung wider. Oberste Ebene: die größten Teile des Unternehmens (Geschäftsbereiche, Tochtergesellschaften oder Regionen). Als nächstes: die Teams, denen die Budgets gehören. Zuletzt, falls sinnvoll: Umgebungen wie Produktion und Nichtproduktion.
- Halten Sie es flach. Drei oder vier Ebenen sind ausreichend. Jedes zusätzliche Level ist etwas, das man beibehalten muss.
- Ein Konto, ein Knoten. Ein Konto kann sich nur in einem Knoten befinden. Wählen Sie daher die Dimension aus, die exklusiv sein soll, normalerweise derjenige, dem es gehört. Fügen Sie die sich überschneidenden Dimensionen (Produkt, Projekt, Kunde) in virtuelle Tags ein.
- Machen Sie die Cloud nicht zur obersten Ebene. Ein Baum, der mit „AWS“, „Azure“ und „Google“ beginnt, antwortet mit „Wie viel geben wir für jede Cloud aus?“ welche Cost Explorer und Cloud Spend bereits anzeigen. Put clouds at the bottom: each team node holds that team's accounts from every cloud.
- Benennen Sie Knoten nach Dingen, die von Dauer sind. Teamnamen ändern sich seltener als Projektnamen.
- Planen Sie den Zugang. Jeder, den Sie an einen Knoten binden, sieht alles darunter. Stellen Sie sicher, dass ein Knoten niemals Konten enthält, die eine Gruppe nicht sehen sollte.
| Form | Gut, wenn | Achten Sie auf |
|---|---|---|
| Geschäftsbereich → Team → Umgebung | Es gibt Chargebacks oder Showbacks durch das Team, und verschiedene Personen sind für die Produktion und Entwicklung verantwortlich. | Viele kleine Knoten, wenn Sie Hunderte von Konten haben. Verwenden Sie Regeln oder eine CSV-Datei, anstatt zu klicken. |
| klicken Tochtergesellschaft oder Region → Team | Verschiedene juristische Personen oder Länder bezahlen ihre eigenen Rechnungen. | Teams, die über Niederlassungen hinweg arbeiten, benötigen Konten an mehr als einem Ort. |
| Vom Cloud-Anbieter | Nur ein eigenes Team kümmert sich um jede Cloud. | Versteckt, wem das Geld gehört, und dupliziert, was Cloud Spend bereits anzeigt. |
| Nach Produkt | Ein Produktteam besitzt alle seine Konten. | Geteilte Konten (Netzwerk, Protokollierung) passen nirgendwo hinein. Give them their own "Shared services" node. |
Wie Hierarchie, virtuelle Tags und gespeicherte Filter zusammenpassen
HierarchyWho owns it and who can see it
Ein Knotenbaum. Jedes Cloud-Konto befindet sich in genau einem Knoten. Steuert Rollup-Gesamtsummen und Zugriff: Eine an einen Knoten gebundene Person sieht nur die Konten darunter.
Virtual tagsHow to slice spend
Regeln, die in Rechnung gestellte Kosten kennzeichnen, z. B. „jede Gebühr in Service X“ oder markiert team=zur Kasse, gehört zu Produkt = Checkout". Sie sind kontenübergreifend und arbeiten innerhalb eines Kontos. Wird für die Gruppierung in Berichten, im Kosten-Explorer und in Budgets verwendet. Sie schränken nicht ein, wer etwas sehen kann.
Saved filtersA reusable selection
Ein benannter Satz von Einschluss- und Ausschlussbedingungen (Dienste, Regionen, Konten, Anbieter), die Sie auf gespeicherte Ansichten und Berichte anwenden, sodass jeder dieselbe Definition von beispielsweise „Produktionsberechnung“ verwendet.
Eine einfache Faustregel: Wenn die Antwort exklusiv sein muss und über den Zugriff entscheidet, verwenden Sie die Hierarchie. Wenn es sich um ein Ausgabenetikett handelt, verwenden Sie ein virtuelles Tag. Wenn es sich um eine wiederholte Betrachtungsweise der Ausgaben handelt, speichern Sie sie als Filter.
Was die Hierarchie nicht tut
Die Hierarchie ist keine Gruppierungsoption in Cost Explorer oder Reports. Um die Ausgaben auf diesen Seiten nach Team gruppiert anzuzeigen, drücken Sie das Team als virtuelles Tag aus (z. B. anhand von Konto-IDs). Die Hierarchieseite selbst zeigt das Rollup für jeden Knoten.
Muster A: eine AWS-Organisation mit Organisationseinheiten
Situation. Sie verfügen über eine AWS-Organisation mit Mitgliedskonten, die in AWS-Organisationseinheiten (OUs) wie Produktion, Nichtproduktion Und Sandkasten, und Teams besitzen darin Konten.
CostGlass importiert keine Organisationseinheiten
CostGlass liest, welche Konten in Ihrer Organisation vorhanden sind, liest jedoch nicht das OU-Layout. Sie erstellen die gewünschte Struktur neu und entscheiden, ob sie Ihre Organisationseinheiten kopiert oder Teams folgt.
Option 1: Spiegeln Sie die Organisationseinheiten
Am besten ist es, wenn Ihre Organisationseinheiten bereits angeben, wer verantwortlich ist.
1
Verbinden Sie die Organisation
Verwenden Sie die Organisationseinrichtung in Verbinden Sie AWS damit die Mitgliedskonten gefunden werden. Warten Sie auf die ersten Kostendaten. Konten werden auf der Baumseite angezeigt, sobald sie erkannt werden.
2
Erstellen Sie einen Knoten pro Organisationseinheit
On Settings → Hierarchy click + New Department OU for each OU, using the same names. Add sub-nodes with + Add Sub-OU if you have nested OUs.
3
Exportieren Sie Ihre Kontoliste aus AWS
Listen Sie in der AWS Organizations-Konsole jedes Konto mit seiner Organisationseinheit auf. Sie benötigen jeweils die 12-stellige Konto-ID und den OU-Namen.
4
Erstellen Sie eine CSV-Datei
Make a file with the columns provider, native_account_id and one column per level. Verwenden
aws as the provider.5
Importiere es
Click Bulk CSV Import, choose the file and click Upload & Build Tree. Überprüfen Sie das Ergebnis auf übersprungene Zeilen.
6
Halten Sie es aktuell
When you add an account in AWS, it appears at the root in Root Unplaced Accounts. Platzieren Sie es manuell oder laden Sie die CSV-Datei erneut hoch.
Beispiel-CSV (anschauliche Konto-IDs)
Option 2: Folgen Sie Teams, nicht OUs
Am besten, wenn eine OU mehrere Teams mischt. Machen Sie die Teams zur obersten Ebene und platzieren Sie dann Umgebungen darunter. Das CSV hat die gleiche Form, wobei das Team an erster Stelle und die Umgebung an zweiter Stelle steht.
If your account display names carry a convention (for example every name contains "prod"), an Auto-Rules rule with Display Name contains Produkt can place many accounts in one click of Run Rules Now.
Ein mittelständisches Unternehmen
Die Wurzel hat zwei Knoten: Produktentwicklung Und Daten & Analysen. Unter jedem stehen die Teams und unter jedem Team Produktion Und Nichtproduktion die Konten führen. Der Datenleiter ist an Daten & Analysen und sieht nur diese Konten. Der Finanzleiter ist nicht gebunden und sieht alles.
Muster B: ein AWS-Konto, Arbeitslasten nur durch Tags getrennt
Situation. Alles läuft in einem einzigen AWS-Konto. Teams oder Produkte werden nur durch Ressourcen-Tags wie Team oder Produkt.
Eine Hierarchie kann ein Konto
Die Hierarchie platziert ganze Konten. Ein Konto ist ein Knoten, daher können Sie seine Ausgaben nicht auf Teams mit Knoten aufteilen. Verwenden Sie virtuelle Tags stattdessen.
1
ein Halten Sie den Baum einfach
Belassen Sie das Konto im Stammverzeichnis oder platzieren Sie es in einem einzelnen Knoten wie Ingenieurwesen.
2
Überprüfen Sie Ihre Tags
Offen Tag-Explorer Und Tag-Konformität um zu sehen, welche Tag-Schlüssel vorhanden sind und wie viel Ausgaben nicht markiert sind.
3
Erstellen Sie ein virtuelles Tag
In Virtuelles Tagging Erstellen Sie einen Schlüssel wie Team. Fügen Sie pro Wert eine Regel hinzu, die Ihrem Cloud-Tag entspricht (z. B. dem Ressourcen-Tag Team gleicht Kasse) und legen Sie einen Standardwert für alles fest, was nicht übereinstimmt.
4
Bericht darüber
Gruppieren Sie nach dem virtuellen Tag in Berichten und im Kosten-Explorer und legen Sie Budgets pro Tagwert fest.
Hinweis
Tags werden mithilfe der Tags abgeglichen, die CostGlass für jede Ressource hat. Ausgaben, die ohne Ressourcen-ID abgerechnet werden (z. B. einige Support- oder Datenübertragungsleitungen), können keinem Tag zugeordnet werden und fallen in den Standardwert. Weitere Informationen finden Sie im Virtual Tagging-Leitfaden.
Tipp
Wenn Sie heute so arbeiten, überlegen Sie, ob separate AWS-Konten pro Team später hilfreich wären. Das ist Ihre Entscheidung, aber durch separate Konten kann die Hierarchie auch einschränken, wer was sieht, was mit welchen Tags allein nicht möglich ist.
Muster C: mehrere AWS Organizations, Azure-Mandanten, Google-Rechnungskonten und Oracle-Mandanten
Situation. Eine Gruppe mit Tochtergesellschaften, jede mit ihrer eigenen AWS-Organisation, ihrem eigenen Azure-Mandanten, ihrem eigenen Google Cloud-Rechnungskonto oder ihrem eigenen Oracle-Mandanten, und Sie möchten einen Überblick über alle haben.
1
Verbinden Sie jedes einzeln
Connect every AWS Organization, Azure tenant, Google Cloud billing account and Oracle tenancy on its own, from Settings → Cloud Accounts. Use Integrate another in the AWS wizard to add a second AWS Organization. Sehen Verbinden Sie Ihre Clouds.
2
Überprüfen Sie das Planlimit
Ihr Plan legt eine maximale Anzahl von Verbindungen fest. Wenn Sie mit einer Upgrade-Eingabeaufforderung abgelehnt werden, haben Sie es erreicht. Siehe Abrechnung und Pläne.
3
Setzen Sie Tochtergesellschaften oder Regionen ganz oben auf
Erstellen Sie unter dem Stamm einen Knoten pro Tochtergesellschaft (oder Region). Erstellen Sie darunter die Teams.
4
Platzieren Sie Konten aus jeder Cloud
In the CSV use one row per account with the right provider value, for example
aws Und azurblau. Mehrere Clouds können sich im selben Teamknoten befinden.5
Anführer binden
Bind each subsidiary's finance lead to their top node. Die Konzernfinanzierung ist nicht gebunden und sieht jede Tochtergesellschaft.
Beispielbaum (anschaulich)
Hinweis
Cloud Spend, Forecasting and Kubernetes Costs combine spend across the whole organisation and are not narrowed by a person's node. Planen Sie, dass Personen auf Gruppenebene diese sehen oder sehen Welche Seiten respektieren den Geltungsbereich.
Muster D: ein MSP oder Wiederverkäufer mit vielen Kunden
Situation. Sie verwalten die Cloud-Kosten für mehrere Kunden und jeder Kunde darf nie einen anderen sehen.
Verwenden Sie eine CostGlass-Organisation pro Kunde
Eine Hierarchie lebt innerhalb einer einzelnen Organisation, und die Mitarbeiter dieser Organisation teilen ihre Daten. For strict separation between customers, create a separate CostGlass organisation for each, connect that customer's clouds there, and invite that customer's people to it.
- Jede Organisation verfügt über ihren eigenen Plan, ihre eigene Abrechnung, ihr eigenes Team, ihre eigenen API-Schlüssel und ihr eigenes Prüfprotokoll.
- Eine E-Mail-Adresse kann nur zu einer Organisation gehören, daher benötigt einer Ihrer Ingenieure eine separate E-Mail-Adresse für jede Kundenorganisation, in der er arbeitet. Es gibt keinen Bildschirm, auf dem mehrere Organisationen gleichzeitig angezeigt werden.
- Innerhalb eines Kunden können Sie weiterhin die Hierarchie, virtuellen Tags und gespeicherten Filter wie in den anderen Mustern verwenden.
Hinweis
Wenn Sie einem Kunden eine auf seinen eigenen Ausschnitt einer einzelnen Organisation beschränkte Ansicht gewähren möchten, ist hierfür der Bereichszugriff gedacht, der jedoch keine feste Grenze für jede Seite darstellt (siehe Liste der Seiten, auf denen immer die gesamte Organisation angezeigt wird). Für Kunden, die vollständig getrennt sein müssen, verwenden Sie separate Organisationen.
Muster E: regulierte Regionen
Situation. Daten über EU-Benutzer müssen in der EU bleiben, Daten aus dem Vereinigten Königreich im Vereinigten Königreich usw.
Wenn eine Organisation erstellt wird, wählt die Person, die auf der Anmeldeseite eine Region auswählt, aus, wo alle ihre Daten gespeichert werden. Die Region ist von da an festgelegt und kann nicht geändert werden. Jede Region ist ein eigener Standort mit einer eigenen Datenbank, daher kann eine Hierarchie keine Regionen umfassen.
- Erstellen eine CostGlass-Organisation pro Region, jeder hat sich in dieser Region angemeldet. Verbinden Sie nur die Cloud-Konten, deren Kostendaten dorthin gehören.
- Verwenden Sie die Hierarchie innerhalb jeder Organisation wie in den anderen Mustern.
- Die Berichterstattung auf Gruppenebene über Regionen hinweg erfolgt heute außerhalb von CostGlass (z. B. durch die Kombination der Exporte der einzelnen Organisationen), da die Organisationen einander nicht sehen.
- Eine E-Mail-Adresse kann nur in einer Region registriert werden. Eine Person, die in verschiedenen Regionen arbeitet, benötigt in jeder Region eine andere Adresse.
Sehen Datenresidenz und -speicherung für das, was feststeht und was man einstellen kann.
Eine kurze Design-Checkliste
- Schreiben Sie auf, wer für jede Kontengruppe verantwortlich ist.
- Zeichnen Sie den Baum mit maximal vier Ebenen auf Papier.
- Entscheiden Sie, welche Schnitte exklusiv sind (Hierarchie) und welche sich überschneiden (virtuelle Tags).
- Bereiten Sie eine CSV-Datei oder die Regelmuster vor, um die Konten zu platzieren.
- Create the nodes, import, and look at Root Unplaced Accounts: it should reach zero.
- Binden Sie Personen und melden Sie sich dann als einer von ihnen an (oder fragen Sie sie), um zu überprüfen, was sie sehen.
Häufig gestellte Fragen
Soll ich meine AWS-Organisationseinheiten genau kopieren?
Nur wenn die Organisationseinheiten bereits übereinstimmen, wer verantwortlich ist. Ansonsten achten Sie auf Verantwortlichkeit und ordnen Sie Konten zu.
Kann ich den Baum später ändern?Ja. Knoten können umbenannt und verschoben werden, und Konten können jederzeit zwischen Knoten verschoben werden. Bei einer Neuorganisation geht nichts verloren.
Ändert die Hierarchie meine Rechnungs- oder Kostendaten?Nein. Es ändert sich, wie Konten gruppiert werden und wer sie sehen kann. Die Ausgaben selbst bleiben unverändert.
Wie unterscheidet sich das von einem virtuellen Tag?Ein virtueller Tag kennzeichnet Ausgaben und kann kontenübergreifend oder innerhalb von Konten erfolgen, schränkt jedoch nicht ein, wer ihn sieht. Die Hierarchie platziert ganze Konten und steuert den Zugriff.