PCG logo
Fallstudie

Eine AWS Multi-Account Struktur für die digitale Landwirtschaftsindustrie

Die Herausforderung

Der Kunde ist Hersteller einer umfassenden Softwarelösung für die landwirtschaftliche Betriebsführung. Seine Vision ist es, die weltweit größte landwirtschaftliche Plattform zu werden.

Unser Ziel war es, den Kunden dabei zu unterstützen,

  • eine AWS-Kontentrennung durchzuführen um Silos zu vermeiden,
  • den Teams die volle Verantwortung für ihre Plattformen zu übertragen,
  • die Sicherheit zu verbessern und
  • die Kostenkontrolle für die gesamte AWS-Umgebung zu optimieren.
Die Lösung

Wir haben eine Landing Zone implementiert, um unseren Kunden bei der Einrichtung einer sicheren Multi-Account-AWS-Umgebung zu unterstützen, die auf bewährten Best practices basiert. Diese Erfahrungen sind später in die Entwicklung unser kostenlosen Open Source Lösung superwerkerExternal Link eingeflossen.

Eine Landing Zone ist eine AWS-Kontostruktur, die zwei unterschiedlichen Anforderungsklassen gerecht wird: Sie wird aus der Workload-Infrastruktur, die für das Management der Workloads benötigt wird, und den infrastrukturellen Vorgaben des Unternehmens gebildet.

Das Cloud Center of Excellence (CCoE) ist ein Cloud-Kompetenzteam, das Cloud-Best-Practices, Governance-Standards und Automatisierungen initialisiert und somit die digitale Transformation des Unternehmens vorantreibt. Wenn das CCoE es richtig anpackt, kann es im Unternehmen einen kulturellen Wandel hin zu Innovation und einer „Change-is-normal“-Mentalitätvollziehen.

Das CCoE ist verantwortlich dafür,

  1. Umgebungen bereitzustellen, in denen die Beteiligten arbeiten bzw. ihre Software einsetzen können,
  2. die organisatorischen Anforderungen in diesen Umgebungen abzubilden.

In diesem Szenario ist das CCoE sowohl ein interner Dienstleister als auch Berater innerhalb des Unternehmens. Daraus ergibt sich folgende Herausforderung: Wie kann das CCoE seine Autoritätsposition beibehalten, um die Mitarbeiter:innen dazu zu bringen, das „Richtige“ zu tun, und gleichzeitig schnell genug auf Anfragen von organisatorischer Seite reagieren?

Schulungen, Prozess-Frameworks und Tools sowie externe Berater:innen können sicherlich hilfreich sein. Diese Herausforderung lässt sich jedoch am besten mit einem kollaborativen Ansatz meistern. Um eine bestmögliche Zusammenarbeit zu ermöglichen, stellt das CCoE dem gesamten Unternehmen Konfigurationen als Infrastructure-as-Code zur Verfügung (z. B. mit CloudFormation/CDK oder Terraform). Diese werden kontinuierlich über Pipelines bereitgestellt, wobei jede:r Mitarbeitende Pull-Requests stellen kann, während Merge-and-Deployment CCoE-Mitgliedern vorbehalten ist, so dass

  1. alle Mitarbeiter:innen zu Änderungen, Ergänzungen und Fehlerbehebungen in der Infrastruktur beitragen und
  2. CCoE-Stakeholder die volle Souveränität über die Plattform behalten.

Eine der Herausforderungen für das Unternehmen bestand darin, die Synergien zwischen den Entwicklungs- und Operations-Teams zu erhöhen. Vom traditionellen Operations-Team-Ansatz abweichend setzten wir ein CCoE ein – ein multidisziplinäres Team, das die infrastrukturellen Grenzen zwischen den Umgebungen der Stakeholder ausloten sollte. Wir begannen, diese Grenzen zu definieren und in der Gruppe zu diskutieren.

Im Anschluss wurden die jeweils relevanten Bereiche der verschiedenen Entwicklungsteams definiert und auf dieser Grundlage die Strategie der Kontentrennung festgelegt.

Wir entschieden uns für den Einsatz von AWS Control TowerExternal Link, um die Bereitstellung neuer AWS-Konten innerhalb der organisatorischen Einschränkungen und der Umsetzung von AWS-Best-Practices zu vereinfachen. Control Tower arbeitet nämlich mit AWS OrganizationsExternal Link zusammen, was die Verwaltung von AWS-Konten und Organizational UnitsExternal Link vereinfacht.

Dank der reibungslosen Integration zwischen Control Tower und AWS Single Sign-OnExternal Link konnten wir die Azure Active Directory-Benutzer und -Gruppen des Kunden integrieren und benutzerdefinierte Permission SetsExternal Link erstellen, die unseren spezifischen Anwendungsfällen entsprechen.

Wir beschlossen außerdem, dass jede Domäne (Workload) ihre eigene AWS Organizational Unit mit einem eigenen Satz von AWS-Konten haben sollte, die die verschiedenen Umgebungen (Sandbox, Stage und Prod) repräsentieren. Dadurch waren wir flexibel, jeweils spezifische GuardrailsExternal Link für die verschiedenen Workloads einzurichten.

Dank der Tagging Policies und Cost Allocation TagsExternal Link, die wir in der Organisation definiert hatten, konnten wir die Kosten pro Service/Umgebung viel besser im Auge behalten.

Die nächste Herausforderung bestand darin, die Entwicklungsteams stärken, indem wir ihnen mehr Freiräume und Eigenverantwortung übertrugen. Wir durften sie aber auch nicht mit Aufgaben überfordern, die nicht in ihren Zuständigkeitsbereich fallen, etwa Networking. So übertrugen wir den Entwicklungsteams die Verantwortung für ihre Plattform. Für Themen wie Networking war das CCoE verantwortlich und wurde als „Service“ zur Verfügung gestellt.

Gemäß den Best Practices erstellten wir das Netzwerk-Layout auf einem vom CCoE verwalteten Konto. Die Netzwerkkomponenten der einzelnen Workloads und Umgebungen wurden dann mit den entsprechenden Konten geteilt. Dadurch, dass das Netzwerk-Themen an einem zentralen Ort lokalisiert sind, wurde die Komplexität reduziert und die Wartungsfreundlichkeit des Terraform-Codes erhöht.

Darüber hinaus stellt das CCoE den Teams eine Reihe von CDK-Konstrukten und -Bibliotheken zur Verfügung, um sinnvolle Standardeinstellungen einzurichten.

Als Nächstes musste eine einfache, konsistente und zentrale Methode zur Implementierung der infrastrukturellen Einschränkungen in den Workloads bereitgestellt werden. Wir entschieden uns für das AWS Deployment FrameworkExternal Link, das eine umfassende und flexible Lösung für die stufenweise, parallele, multi-account und regionsübergreifende Bereitstellung von Anwendungen oder Ressourcen über AWS-StrukturenExternal Link bietet. Gleichzeitig nutzten wir Services wie AWS CodePipelineExternal Link, AWS CodeBuildExternal Link und AWS CodeCommitExternal Link, um den erhöhten Arbeitsaufwand im Vergleich zu einem herkömmlichen CI/CD-Set-Up zu verringern.

Wir konnten alle Guardrails und ihre automatische Bearbeitung in völlig unabhängigen Pipelines implementieren, sodass der Aufwand für das CCoE-Team minimal und die Komplexität überschaubar blieb. Zudem erhielten die Teams eine Reihe von Vorlagen für zukünftige Erweiterungen.

Schließlich implementierten wir eine Reihe von Communities of Practice zu verschiedenen übergreifenden Themen wie DevOps, Monitoring und Logging, um Raum für Zusammenarbeit und Ideenaustausch zu schaffen und damit Synergieeffekte zwischen den Teams freizusetzen.

Hinweis: Grundlegende Konten können als Bausteine für die restliche Multi-Account-Strategie betrachtet werden; diese Konten werden von Control Tower bereitgestellt und haben spezifische Konfigurationen und Guardrails, um zu verhindern, dass Benutzer:innen bestimmte Aktionen ausführen, die die Konfiguration der Landing Zone gefährden könnten.

Resultate und Vorteile

Die Kerninfrastruktur und die organisatorischen Einschränkungen werden nun zentral verwaltet und dabei konsistent und vollautomatisch auf die verschiedenen Workload-Konten verteilt. Änderungen werden nach dem 4-Augen-Prinzip begutachtet und automatisch für das gesamte Unternehmen übernommen. Eine neue Workload-Umgebung ist mit wenigen Klicks bereitgestellt; sie steht dem Entwicklungsteam in weniger als zwei Stunden zur Verfügung.

Einsicht in Kosten und Nutzung der verschiedenen Workloads/Umgebungen ist jetzt direkt und unkompliziert möglich.

Durch die Einführung der AWS Landing Zone konnte der Kunde eine verstärkte Interaktion zwischen dem CCoE- und dem Entwicklungsteam feststellen. Die Entwicklungsteams sind nun selbst für die Services verantwortlich, die sie in ihren Konten ausführen und können sich auf ihre Kerntätigkeiten konzentrieren und sich darauf verlassen, dass die Plattform sicher, zuverlässig und in verschiedenen Umgebungen einheitlich nutzbar ist.

Über PCG

Die Public Cloud Group (PCG) unterstützt Unternehmen bei ihrer digitalen Transformation durch den Einsatz von Public Cloud-Lösungen.

Mit einem Portfolio, das darauf ausgerichtet ist, Unternehmen aller Größe auf ihrer Cloud Journey zu begleiten, sowie der Kompetenz von zahlreichen zertifizierten Expert:innen, mit denen Kunden und Partner gerne zusammenarbeiten, positioniert sich PCG als verlässlicher und vertrauenswürdiger Partner der Hyperscaler.

Als erfahrener Partner der drei relevanten Hyperscaler (Amazon Web Services (AWS), Google Cloud und Microsoft Cloud) hält PCG die höchsten Auszeichnungen der jeweiligen Anbieter und berät Sie als unsere Kunden in Ihrer Cloud Journey unabhängig.


Genutzte Services

Weiterlesen

Artikel
AWS Lambda: Vermeiden Sie diese Fallstricke

Ein großartiges Angebot, um schnell Ergebnisse zu erzielen, aber wie jedes gute Tool muss es richtig eingesetzt werden.

Mehr erfahren
Fallstudie
Finanzdienste
Cloud Migration
Die Cloud Journey der VHV Gruppe - Mit Strategie zum Erfolg

Wie meistert ein Versicherungskonzern mit über 4.000 Mitarbeitern den Spagat zwischen Compliance, Modernisierung und Kosteneffizienz?

Mehr erfahren
Fallstudie
Finanzdienste
DevOps
KYC – Archivsystem für die digitale Bank

Aufbau eines KYC-Cloud-Archivs für eine digitale Bank zur Speicherung von KYC-Kundendaten.

Mehr erfahren
Fallstudie
Software
DevOps
Mehr Tempo für die Buchhaltung

Was als Start-up im elterlichen Keller begann, hat sich innerhalb von wenigen Jahren zum führenden Anbieter cloudbasierter Buchhaltungs- und Finanzsoftware entwickelt: sevDesk.

Mehr erfahren
Alles sehen

Gemeinsam durchstarten

United Kingdom
Arrow Down