Concevoir votre hiérarchie (avec des exemples d'entreprise)
Principles and worked patterns for AWS Organizations, single accounts, multi-cloud groups, MSPs and regulated regions.
Concevoir votre hiérarchie (avec des exemples d'entreprise)
Comment décider à quoi devrait ressembler votre arborescence et cinq modèles fonctionnels : une organisation AWS, un compte AWS divisé par balises, de nombreux cloud et organisations, de nombreux clients et régions réglementées.
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
En bref
- Reflétez la façon dont vous êtes responsable de votre argent, et non la façon dont le cloud est organisé. L'unité commerciale, puis l'équipe, puis l'environnement fonctionnent pour la plupart des entreprises.
- Utilisez la hiérarchie pour la propriété et l'accès : un emplacement par compte et les bonnes personnes voyant les bons comptes.
- Utilisez des balises virtuelles pour tout ce qui concerne plusieurs comptes ou réside dans un seul compte, comme un produit, un centre de coûts ou un client.
- Utilisez les filtres enregistrés pour réutiliser une tranche de dépenses dans les vues et les rapports.
- CostGlass n'importe pas la présentation de votre unité d'organisation AWS. Vous créez les nœuds et placez les comptes vous-même (à la main, par règle ou par CSV).
Avant de commencer
- Vous avez lu Configuration de la hiérarchie de votre organisation donc les noms des boutons ont du sens.
- Vous savez qui, dans votre entreprise, est responsable de chaque groupe de comptes cloud.
- Vos comptes cloud sont connectés (ou vous savez combien vous en connecterez).
Quelle est la meilleure hiérarchie ?
Il n’existe pas de meilleur arbre, mais il existe un bon test : pour chaque nœud, pouvez-vous nommer une personne ou une équipe responsable de ses dépenses ? Si vous le pouvez, le nœud est utile. Si un nœud existe uniquement parce que « c’est là que se trouve le compte », ce n’est probablement pas le cas.
Principes
- Responsabilité miroir. Niveau supérieur : les plus grandes parties de l'entreprise (business units, filiales ou régions). Ensuite : les équipes qui possèdent les budgets. Enfin, si cela est utile : des environnements tels que Production et Non-production.
- Gardez-le peu profond. Trois ou quatre niveaux suffisent. Chaque niveau supplémentaire est quelque chose à maintenir.
- Un compte, un nœud. Un compte ne peut se trouver que dans un seul nœud, choisissez donc la dimension qui doit être exclusive, généralement le propriétaire. Mettez la dimension qui se chevauche (produit, projet, client) dans des balises virtuelles.
- Ne faites pas du cloud le niveau supérieur. Un arbre qui commence par « AWS », « Azure », « Google » répond « combien dépensons-nous pour chaque cloud ? que Cost Explorer et Cloud Spend affichent déjà. Put clouds at the bottom: each team node holds that team's accounts from every cloud.
- Nommez les nœuds d’après des choses qui durent. Les noms des équipes changent moins souvent que les noms des projets.
- Planifiez l’accès. Toute personne que vous liez à un nœud voit tout ce qui se trouve en dessous. Assurez-vous qu'un nœud ne contient jamais de comptes qu'un groupe ne devrait pas voir.
| Forme | Bien quand | Attention à |
|---|---|---|
| Business unit → équipe → environnement | Vous avez une rétrofacturation ou une rétrospective par équipe, et différentes personnes sont responsables de la production et du développement. | Beaucoup de petits nœuds si vous avez des centaines de comptes. Utilisez des règles ou un CSV plutôt que de cliquer. |
| Filiale ou région → équipe | Différentes entités juridiques ou pays paient leurs propres factures. | Les équipes qui travaillent dans plusieurs filiales ont besoin de comptes à plusieurs endroits. |
| Par fournisseur de cloud | Seule une équipe distincte s'occupe de chaque cloud. | Masque le propriétaire de l'argent et duplique ce que Cloud Spend affiche déjà. |
| Par produit | Une équipe produit est propriétaire de tous ses comptes. | Les comptes partagés (réseau, journalisation) ne trouvent leur place nulle part. Give them their own "Shared services" node. |
Comment la hiérarchie, les balises virtuelles et les filtres enregistrés s'articulent
HierarchyWho owns it and who can see it
Un arbre de nœuds. Chaque compte cloud se trouve dans exactement un nœud. Génère les totaux de cumul et accéder: une personne liée à un nœud ne voit que les comptes qui s'y trouvent.
Virtual tagsHow to slice spend
Règles qui étiquettent le coût facturé, par exemple « chaque frais du service X, ou étiqueté équipe = caisse, appartient à Produit = Paiement". Ils recoupent plusieurs comptes et fonctionnent au sein d'un seul compte. Utilisés pour le regroupement dans les rapports, l'Explorateur de coûts et les budgets. Ils ne limitent pas qui peut voir quoi que ce soit.
Saved filtersA reusable selection
Un ensemble nommé de conditions d'inclusion et d'exclusion (services, régions, comptes, fournisseurs) que vous appliquez aux vues et aux rapports enregistrés, afin que tout le monde utilise la même définition, par exemple, de « calcul de production ».
Une règle simple : si la réponse doit être exclusive et décide de l'accès, utilisez la hiérarchie. S'il s'agit d'une étiquette sur les dépenses, utilisez une étiquette virtuelle. S'il s'agit d'une façon répétée d'examiner les dépenses, enregistrez-la en tant que filtre.
Ce que la hiérarchie ne fait pas
La hiérarchie n'est pas une option de regroupement dans Cost Explorer ou Reports. Pour voir les dépenses regroupées par équipe dans ces pages, exprimez l'équipe sous forme de balise virtuelle (par exemple à partir des identifiants de compte). La page de hiérarchie elle-même affiche le cumul pour chaque nœud.
Modèle A : une organisation AWS avec des unités d'organisation
Situation. Vous disposez d'une organisation AWS, avec des comptes membres regroupés en unités organisationnelles (UO) AWS telles que Fabrication, Hors production et Bac à sable, et les équipes possèdent des comptes en leur sein.
CostGlass n'importe pas d'UO
CostGlass lit quels comptes existent dans votre organisation, mais il ne lit pas la présentation de l'unité d'organisation. Vous recréez la structure souhaitée et vous décidez si elle copie vos unités d'organisation ou suit les équipes.
Option 1 : mettre en miroir les unités d'organisation
C’est mieux lorsque vos unités d’organisation représentent déjà qui est responsable.
1
Connecter l'organisation
Utilisez la configuration de l'organisation dans Connecter AWS ainsi les comptes membres sont retrouvés. Attendez les premières données de coût ; les comptes apparaissent dans la page de l'arborescence au fur et à mesure qu'ils sont découverts.
2
Créer un nœud par unité d'organisation
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
Exportez votre liste de comptes depuis AWS
Dans la console AWS Organizations, répertoriez chaque compte avec son unité d'organisation. Vous avez besoin de l'ID de compte à 12 chiffres et du nom de l'UO pour chacun.
4
Créer un CSV
Make a file with the columns provider, native_account_id and one column per level. Utiliser
aws as the provider.5
Importez-le
Click Bulk CSV Import, choose the file and click Upload & Build Tree. Vérifiez le résultat pour les lignes ignorées.
6
Gardez-le à jour
When you add an account in AWS, it appears at the root in Root Unplaced Accounts. Placez-le à la main ou téléchargez à nouveau le CSV.
Exemple CSV (ID de compte illustratifs)
Option 2 : suivre les équipes, pas les UO
Idéal lorsqu'une OU mélange plusieurs équipes. Placez les équipes au plus haut niveau, puis placez les environnements en dessous. Le CSV a la même forme, avec l'équipe en premier et l'environnement en second.
If your account display names carry a convention (for example every name contains "prod"), an Auto-Rules rule with Display Name contains prod can place many accounts in one click of Run Rules Now.
Une entreprise de taille moyenne
La racine a deux nœuds : Ingénierie produit et Données et analyses. Sous chacune se trouvent les équipes, et sous chaque équipe Fabrication et Hors production tenir les comptes. Le Responsable des Données est tenu de Données et analyses et ne voit que ces comptes. Le responsable financier n’est pas lié et voit tout.
Modèle B : un compte AWS, charges de travail séparées uniquement par des balises
Situation. Tout fonctionne dans un seul compte AWS. Les équipes ou les produits sont différenciés uniquement par des balises de ressources telles que équipe ou produit.
Une hiérarchie ne peut pas diviser un compte
La hiérarchie place des comptes entiers. Un compte est un nœud, vous ne pouvez donc pas diviser ses dépenses entre les équipes possédant des nœuds. Utilisez balises virtuelles plutôt.
1
Gardez l'arbre simple
Laissez le compte à la racine ou placez-le dans un seul nœud tel que Ingénierie.
2
Vérifiez vos balises
Ouvrir Explorateur de balises et Conformité des balises pour voir quelles clés de balise existent et combien de dépenses ne sont pas balisées.
3
Créer une balise virtuelle
Dans Tagging virtuel créer une clé telle que Équipe. Ajoutez une règle par valeur qui correspond à votre balise cloud (par exemple la balise de ressource équipe est égal caisse), et définissez une valeur par défaut pour tout ce qui ne correspond pas.
4
Rapport à ce sujet
Regroupez par balise virtuelle dans Reports and Cost Explorer et définissez les budgets par valeur de balise.
Remarque
Les balises sont mises en correspondance à l'aide des balises que CostGlass possède pour chaque ressource. Les dépenses facturées sans ID de ressource (par exemple certaines lignes d'assistance ou de transfert de données) ne peuvent pas être associées à une balise et correspondent à la valeur par défaut. Consultez le guide de marquage virtuel pour connaître la couverture.
Astuce
Si c'est ainsi que vous travaillez aujourd'hui, demandez-vous si des comptes AWS distincts par équipe pourraient être utiles plus tard. C'est votre décision, mais des comptes séparés permettent également à la hiérarchie de restreindre qui voit quoi, ce que les balises seules ne peuvent pas faire.
Modèle C : plusieurs organisations AWS, locataires Azure, comptes de facturation Google et locations Oracle
Situation. Un groupe avec des filiales, chacune avec sa propre organisation AWS, son locataire Azure, son compte de facturation Google Cloud ou sa location Oracle, et vous souhaitez une vue unique sur chacun d'eux.
1
Connectez chacun séparément
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. Voir Connectez vos nuages.
2
Vérifiez la limite du forfait
Votre forfait fixe un nombre maximum de connexions. Si vous êtes refusé avec une invite de mise à niveau, vous l'avez atteint. Voir Facturation et forfaits.
3
Mettre les filiales ou les régions en tête
Sous la racine, créez un nœud par filiale (ou région). Sous chacun, créez les équipes.
4
Placez des comptes depuis n'importe quel cloud
In the CSV use one row per account with the right provider value, for example
aws et azur. Plusieurs cloud peuvent se trouver dans le même nœud d'équipe.5
Lier les dirigeants
Bind each subsidiary's finance lead to their top node. La finance du groupe n'est pas liée et voit chaque filiale.
Exemple d'arborescence (à titre d'illustration)
Remarque
Cloud Spend, Forecasting and Kubernetes Costs combine spend across the whole organisation and are not narrowed by a person's node. Prévoyez que des personnes au niveau du groupe les verront, ou consultez quelles pages respectent la portée.
Modèle D : un MSP ou un revendeur avec de nombreux clients
Situation. Vous gérez les coûts cloud de plusieurs clients et chaque client ne doit jamais en voir un autre.
Utiliser une organisation CostGlass par client
Une hiérarchie vit au sein d’une seule organisation et les membres de cette organisation partagent ses données. 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.
- Chaque organisation dispose de son propre plan, facturation, équipe, clés API et journal d'audit.
- Une adresse e-mail ne peut appartenir qu'à une seule organisation. L'un de vos ingénieurs a donc besoin d'une adresse e-mail distincte pour chaque organisation cliente dans laquelle il travaille. Aucun écran n'affiche plusieurs organisations à la fois.
- Au sein d'un client, vous pouvez toujours utiliser la hiérarchie, les balises virtuelles et les filtres enregistrés comme dans les autres modèles.
Remarque
Si vous souhaitez donner à un client une vue limitée à sa propre partie d'une organisation unique, c'est à cela que sert l'accès limité, mais il ne s'agit pas d'une limite stricte pour chaque page (voir la liste des pages qui montrent toujours l'ensemble de l'organisation). Pour les clients qui doivent être totalement séparés, utilisez des organisations distinctes.
Modèle E : régions réglementées
Situation. Les données sur les utilisateurs de l’UE doivent rester dans l’UE, les données du Royaume-Uni au Royaume-Uni, etc.
Lorsqu'une organisation est créée, la personne choisissant une région sur la page d'inscription choisit où toutes ses données sont stockées. La région est désormais fixée et ne peut pas être modifié. Chaque région est son propre site avec sa propre base de données, une hiérarchie ne peut donc pas s'étendre sur les régions.
- Créer une organisation CostGlass par région, chacun s'est inscrit dans cette région. Connectez uniquement les comptes cloud dont les données de coût y appartiennent.
- Utilisez la hiérarchie au sein de chaque organisation comme dans les autres modèles.
- Les rapports au niveau du groupe à travers les régions sont aujourd'hui effectués en dehors de CostGlass (par exemple en combinant les exportations de chaque organisation), car les organisations ne se voient pas.
- Une adresse e-mail ne peut être enregistrée que dans une seule région. Une personne qui travaille dans plusieurs régions a besoin d’une adresse différente dans chacune.
Voir Résidence et conservation des données pour ce qui est fixe et ce que vous pouvez définir.
Une courte liste de contrôle de conception
- Notez qui est responsable de chaque groupe de comptes.
- Dessinez l'arbre sur papier avec au plus quatre niveaux.
- Décidez quelles coupes sont exclusives (hiérarchie) et lesquelles se chevauchent (balises virtuelles).
- Préparez un CSV, ou les modèles de règles, pour placer les comptes.
- Create the nodes, import, and look at Root Unplaced Accounts: it should reach zero.
- Liez les gens, puis connectez-vous en tant qu'un d'entre eux (ou demandez-leur) de vérifier ce qu'ils voient.
Questions fréquemment posées
Dois-je copier exactement mes unités d'organisation AWS ?
Seulement si les unités d'organisation correspondent déjà à qui est responsable. Sinon, concevez la responsabilité et mappez-y les comptes.
Puis-je changer l'arbre plus tard ?Oui. Les nœuds peuvent être renommés et déplacés, et les comptes peuvent être déplacés entre nœuds à tout moment. Rien n'est perdu lorsque vous vous réorganisez.
La hiérarchie modifie-t-elle mes données de facturation ou de coûts ?Non. Cela change la façon dont les comptes sont regroupés et qui peut les voir. La dépense elle-même est inchangée.
En quoi est-ce différent d’une balise virtuelle ?Une balise virtuelle étiquette les dépenses et peut être transversale ou interne aux comptes, mais ne limite pas qui la voit. La hiérarchie place des comptes entiers et gère l'accès.