Blog

Automatisieren Sie Einblicke in Ihr Arbeitsaufkommen

Joris Conijn

Joris Conijn

Aktualisiert Oktober 15, 2025
3 Minuten

Die Verwaltung von mehr als einem AWS-Konto kann zu einer Herausforderung werden. AWS Organizations bietet eine Möglichkeit, viele Konten zu verwalten. Sie können die Erstellung und Verwaltung von Konten automatisieren. Wenn Sie ein Benennungsschema verwenden, können Sie landingzone-organization nutzen!

Benennungsschema?

Die Verwendung eines Namensschemas verbessert Ihre Fähigkeit, das richtige Konto schneller zu finden. Nehmen wir zum Beispiel an, Ihr Unternehmen Xebia hat einige Workloads. Jede Arbeitslast erfordert eine vollständige DTAP-Umgebung. Wenn Sie die Best Practices von AWS befolgen, werden Sie am Ende ein Konto pro Umgebung verwenden.

Bei Verwendung eines Namensschemas würde Ihr Kontoname folgendermaßen aussehen: xebia-<workloadname>-<environment>

Wenn Sie AWS SSO nutzen, sehen Sie eine Liste von Konten. In jedem Konto haben Sie eine oder mehrere Rollen, die Sie übernehmen können. Je nach Ihren Berechtigungen kann das keines oder alle Konten sein.

Wenn Sie ein Workload-Ingenieur sind, werden Sie eine kurze Liste haben. Wenn Sie ein Plattformbetreiber oder ein Wirtschaftsprüfer sind, haben Sie vielleicht Zugriff auf alle Konten. Im letzteren Fall ist es hilfreich, wenn Sie dieses Schema angewendet haben. Sie können zum Beispiel nach dem Namen des Workloads suchen. Dadurch wird die Liste herausgefiltert und zeigt nur das Umgebungskonto für diesen Workload an. Oder Sie können nach der Umgebung oder sogar einer Kombination suchen.

Einen Schritt weiter gehen

Wenn Sie ein Namensschema mit einem OU-Layout kombinieren, erhalten Sie noch mehr Flexibilität.

Lassen Sie uns zunächst die offensichtlichen Vorteile ansprechen. Wenn Sie eine OE-Struktur wie folgt verwenden:

  • workloads/development/xebia-myworkloadname-development
  • workloads/testing/xebia-myworkloadname-testing
  • workloads/acceptance/xebia-myworkloadname-acceptance
  • workloads/production/xebia-myworkloadname-production

Damit können Sie einen SCP auf der OU workloads platzieren, der für alle Workloads gilt. Sie haben aber auch die Möglichkeit, einen SCP auf jede einzelne Umgebungs-OU anzuwenden. Dieser SCP wird dann z.B. nur auf die Entwicklungskonten angewendet. Ich werde nicht auf SCP eingehen, das ist ein Thema für sich.

Der andere Vorteil ist, dass Sie jetzt wissen, wo sich Ihre Arbeitslasten befinden. Kombinieren Sie das mit der Landingzone-Organisation und Sie können Dinge wie diese tun:

from landingzone_organization import AWSOrganization

# Fetch the organization information and instantiate the organization object
organization = AWSOrganization().parse()

# Define the OU structure where the workload accounts live
nested_ou = ["Workloads"]

# Iterate over all workloads in the provided OU location
for workload in organization.workloads(nested_ou):
    # Display the workload name
    print(f"Workload: {workload.name}")

    # Iterate over each account in the workload
    for account in workload.accounts:
        # Display the environment name and id of the account (aka the workload environment)
        print(f"tEnvironment: {account.environment} has {account.account_id}")

Warum hilft mir das?

Es ist schwierig, den Überblick über die tatsächlich laufenden Workloads zu behalten. Aber wenn es kein Produktionskonto gibt, wissen Sie, dass der Workload noch nicht in Produktion ist. Außerdem ist es schwierig, den Überblick darüber zu behalten, welche Workloads in Ihrem Unternehmen existieren. Meistens geschieht dies anhand von Tabellen. Wie halten Sie diese auf dem neuesten Stand?

Mit diesem Tool können Sie alle benötigten Daten zur späteren Verwendung in eine CSV-Datei schreiben. Es könnte die Quelle der Wahrheit in Ihrem Unternehmen werden und Sie können automatisieren!

Fazit

Automatisierung macht Ihr Leben einfacher! Hören Sie also auf, Ihr Arbeitspensum auf die altmodische Art und Weise zu verwalten und verwenden Sie Automatisierungstools.

Es gibt verschiedene Anwendungsmöglichkeiten dafür, die ich in einem zukünftigen Blog behandeln werde, bleiben Sie also dran!

Foto von Pexels - Sangria Lips

Verfasst von

Joris Conijn

Joris is the AWS Practise CTO of the Xebia Cloud service line and has been working with the AWS cloud since 2009 and focussing on building event-driven architectures. While working with the cloud from (almost) the start, he has seen most of the services being launched. Joris strongly believes in automation and infrastructure as code and is open to learning new things and experimenting with them because that is the way to learn and grow.

Contact

Let’s discuss how we can support your journey.