Das folgende, aus Praxiserfahrungen erstellte Dokument stellt Organisationen ein Rahmengerüst für die Erstellung eines eigenen Nutzungskonzepts der Amazon Webservices (AWS) zur Verfügung. Das Konzept fokussiert dabei auf die Business-Seite des Themas, namentlich Umgang mit Kosten und die Zusammenarbeit mit anderen Abteilungen.
1. Ausgangslage
Die Nutzung der Cloud-basierten Amazon Webservices (AWS) im Unternehmen kann im Wesentlichen drei Verbesserungen realisieren:
- Verschnellerte Entwicklungs- und Release-Prozesse durch das Zusammenwachsen der traditionell getrennten Bereiche Entwicklung und Systemadministration (Stichwort: DevOps)
- Förderung von Innovation durch radikale Vereinfachung des Test neuer Server-Infrastrukturen
- Parallelisierung von Entwicklungsaufgaben durch Nutzung von parallel zur Spezifikation der Systemarchitektur bereits fertig konfigurierten AWS-Services (Stichwort: Microservice-Architektur)
Diesen Verbesserungen stehen ein Vielzahl von Problemen und Risiken gegenüber. Beispielhaft genannt seien an dieser Stelle:
- Kosteneinsparungen durch dynamisches Autoscaling der Server sind häufig nur mit sehr hohem Aufwand zu erreichen – im Regelfall erzeugt eine Server-Migration aus dem klassischen Hosting erst einmal wesentlich höhere Kosten. (Achtung: Business-Problem für die IT)
- Einmal für Tests konfigurierte und später „vergessene“ Server verursachen z.T. erhebliche und ggf. nicht budgetierte Kosten. (Stichwort: zeitnahes Kosten-Controlling notwendig)
- Die lokale Entwicklung für AWS Services und das Deployment in die Amazon-Cloud funktionieren wesentlich anders als in klassischen Umgebungen gewohnt – hier sind erhebliche Aufwendungen für die Erarbeitung und Umsetzung einer Entwicklungs- und Deployment-Strategie zu erwarten (Stichwort: hoher Technologie-Sprung)
- Vendor-Lock-in: bei der Verwendung AWS-spezifischer Services ist der Einsatz von Abstraktions-Layern ein Muss, will man sich die Möglichkeit der späteren Migration zu einem anderen Hosting-Anbieter offenhalten (Stichwort: Lock-out-Strategie)
- Widerstand der Systemadministration gegen den mit der AWS-Einführung notwendig einhergehenden Verlust der „Alleinherrschaft“ über die Server-Infrastruktur (Achtung: der kulturelle Wandel des Zusammenrückens von Entwicklung und Systemadministration ist eine notwendige Bedingung).
2. Ziele des Konzepts
- Wahrnehmung der Hosting-Kostenverantwortung durch den IT-Entwickler-Bereich ermöglichen
- Sicherstellung der Kostentransparenz
- Sicherstellung einer kostenoptimierenden Hosting-Strategie
- Unterstützung von Innovation im Bereich AWS-Nutzung
3. Scope des Konzepts
Das Konzept betrachtet folgende Themen:
- Anforderungen an das AWS-Rechtemanagement, soweit es für die Sicherung der Hosting-Kostenverantwortung und Innovationssicherung (siehe Abschnitt „Ziele des Konzepts“) notwendig ist
- Prozessbeschreibungen für die Sicherstellung der Hosting-Kostenverantwortung durch die Leitung des Entwickler-Bereichs
- VPC-Containerstrategie für die Sicherstellung eines Basis-Sicherheitskonzepts
- Abgrenzung und Zusammenarbeit mit den Systemadministratoren
Nicht betrachtet werden in diesem Konzept u.a. folgende Themen:
- Detaillierte AWS- Rechte- und Rollenkonzepte für den Zugriff auf AWS-Resourcen – insbesondere auch für den Zugriff auf AWS-Produktivsysteme
- AWS-IT-Sicherheitsthemen
- Datenschutz
- AWS-Best-Practises für Entwickler und Systemadministratoren
- Hosting-Migrations-Szenarien
- Hosting-Migrationspläne
- Betrachtung der AWS-Eignung von Anwendungen
4. Business Relevanz
- Mit Umsetzung des Konzepts sammelt der Entwickler-Bereich praktische Erfahrungen im Umgang mit der AWS. Diese Erfahrungen können sowohl an interne und externe Entwickler-Teams als auch an Mitarbeiter der Systemadministration weitergegeben werden.
- Die Umsetzung des Konzepts ist notwendig, um AWS-kostenoptimierende Maßnahmen auf geeignete Weise testen zu können.
5. Grobplanung (Vorschlag)
- Fertigstellung einer ersten Version des Konzepts: Tag x
- Abstimmung des Konzepts innerhalb des Unternehmens: x+30
- Schaffung der technischen Rahmenbedingungen für die Umsetzung des Konzepts: x+60
- Workshops und Schulungen mit Amazon-Mitarbeitern, Systemadministratoren und anderen interessierten Beteiligten: zwischen x+45 und x+75
- Umsetzung des Konzepts im Entwickler-Bereich (Inkrafttreten der entsprechenden bereichs-internen Regelungen): x+75
6. Ergebnisse der Konzepterarbeitung
- Guideline AWS-Basis-Setup für das AWS-Hosting des Entwickler-Bereichs (zur Abstimmung mit den Systemadministratoren und als Vorlage für andere Bereiche)
- Guideline notwendige Prozesse zum Schutz vor der Entstehung ungeplanter Kosten
- Guideline Zusammenarbeit Entwickler, Systemadministratoren, andere Entwickler-Teams (z.B. QA)
6.1 Guideline AWS-Basis-Setup für das AWS-Hosting des Entwickler-Bereichs
Diese Guideline dient zur Abstimmung mit den Systemadministratoren und als Vorlage für das mandatierte AWS-Hosting anderer
Entwickler-Bereiche.
6.1.1 AWS Root-Accounts
- Es gibt genau einen AWS-Root-Account für den Bereich Entwickler-Bereich. AWS-Accountname: entwicklerbereichsname.head@newgmbh.de Dieser Account konfiguriert eine eigene Login-Konsole unter https://entwicklerbereichsname.signin.aws.amazon.com/console
- Der Root-Account ist ggf. mit einem zentralen Payer-Account des Unternehmens verlinkt (falls existent)
- Der Root-Account legt die Accounts aller Mitarbeiter des Bereichs an
- Der Root-Account vergibt Role-based Lese-Credentials für die Mitarbeiter anderer Bereiche (insbesondere Systemadministratoren, Controlling)
6.1.2 AWS-Benutzergruppen
Basis-Idee: Klare Trennung separater AWS-Root-Account je Bereich + die Definition organisatorischer Prozesse
6.1.2.1. Benutzergruppe Administrators
- Administratoren haben alle Rechte innerhalb der vom Root-Account angelegten VPCs.
- Die Gruppe Administrators basiert auf der AWS-Standard-Policy „AdministratorAccess“. Ihre Arbeit wird organisatorisch eingeschränkt durch im Entwickler-Bereich gültige Regelungen zum Umgang mit der AWS.
- Administratoren stellen sicher, dass das Konfigurieren von AWS-Resourcen so dokumentiert wird, dass sowohl die Leitung des Entwickler-Bereichs als auch die Teams der Systemadministration sowie das IT-Controlling auf geeignete Art und Weise davon Kenntnis erlangen.
- Kostenrelevante Aktivitäten sind in jedem Fall per Genehmigungsanfrage durch die Leitung des Entwickler-Bereichs zu bestätigen.
- Administratoren erhalten per IAM-Konfiguration Zugriff auf den zum Root-Account gehörenden Cost-Explorer. (wenn notwendig)
Im ersten Schritt werden folgende Personen als Administratoren benannt: Robert Müller, Heinz Schmidt, Torsten Schulze (3-4 Personen)
6.1.2.2 Benutzergruppe Developers
Developers haben beschränkte Rechte. Sie können in der Regel keine neuen AWS-Resourcen anlegen.
Zu Beginn haben Developers lediglich folgende Rechte:
- Arbeiten mit EC2-Instanzen
- Start / Stop von RDS Services (Datenbanken)
6.1.2.3 Benutzergruppe Managers
- Managers haben Lesezugriff auf alle AWS-Resourcen.
- Managers können sowohl Mitarbeiter des Entwickler-Bereichs als auch – per Rollendefinition – Mitarbeiter anderer Bereiche sein. Im typischen Anwendungsfall eines Web-Portals würde die Manager-Rolle den Mitarbeitern des jeweiligen Portalmanagement (daher der Name der Gruppe) zufallen.
- Die Gruppe Managers basiert auf der AWS-Standard-Policy „ReadOnlyAccess“.
6.2 Guideline AWS-Prozesse im Entwickler-Bereich
Diese Guideline definiert die notwendigen AWS-Nutzungs-Prozesse zum Schutz vor der Entstehung ungeplanter Kosten sowie der Einhaltung einer Basis-IT-Sicherheit.
6.2.1 Genehmigungsanfrage für das Anlegen neuer AWS-Resourcen
Die Genehmigungsanfrage für das Anlegen neuer Ressourcen wird per Ticket-System (z.B. Jira-Desktop) an eine fachlich kompetente Personengruppe gestellt. Im idealen Fall (nämlich eine enge Zusammenarbeit zwischen den Entwicklern und den Systemadministratoren) ist die „fachlich kompetente Personengruppe“ ein Team der Systemadministration.
Im Ticket ist eine detaillierte Beschreibung des geplanten Dienstes zu leisten.Das entsprechende Vorhaben gilt genau dann als genehmigt wenn folgende Bedingungen erfüllt sind:
- Positive Stellungnahme der fachlich kompetente Personengruppe (bevorzugt) oder (im Ausnahmefall) Leitung des Entwickler-Bereichs
- Auf geeignete Weise Bestätigung der Kenntnisnahme durch die Leitung des Entwickler-Bereichs
Ohne Genehmigungsanfrage ist kein Anlegen neuer Ressourcen erlaubt.
6.2.2 Anlegen neuer Benutzer, Rechtemanagement bestehender Benutzer
Das Anlegen neuer Benutzer sowie das Rechtemanagement bestehender Benutzer darf nur durch die Leitung des Entwickler-Bereichs erfolgen. Den Mitarbeitern des Entwickler-Bereichs ist bekannt, dass die entsprechenden Aktivitäten im AWS-Log nachvollziehbar sind.
6.2.3 Laufende Kostenkontrolle
Die laufende Kostenkontrolle erfolgt durch den AWS-Cost-Explorer. Zum jeweils 3. Werktag eines Monats wird durch das IT-Controlling eine detaillierte Kostenauswertungen des Vormonats erstellt.
6.2.4 Tagging von AWS-Ressourcen
Jede Resource erhält zwingend ein Tag „Product“ mit dem Wert des offiziellen Produktkürzels. Die Einhaltung dieser Regel ist im Rahmen der Erstellung der Monatsabrechnung zu überprüfen
6.3 Guideline Zusammenarbeit Entwickler-Bereich, Systemadministratoren, andere IT-Teams
Diese Guideline beschreibt Mindest-Anforderungen an die Zusammenarbeit zwischen Entwicklern, Systemadministratoren und ggf. anderen Entwickler-Bereichen. Dieser Abschnitt hat in erster Linie Empfehlungscharakter und sollte weiterentwickelt und aktualisiert werden.
6.3.1 Sicherstellung der Informationskette
Mit Umsetzung dieses Konzepts sind alle mit der Administrator-Rolle ausgestattete Mitarbeiter Entwickler-Bereichs in der Lage, neue AWS-Entities anzulegen. Diese Mitarbeiter stellen untereinander den regelmäßigen Informationsaustausch auf geeignete Weise sicher (mindestens 1x wöchentlich).
Durch den Prozess „6.2.1 Genehmigungsanfrage für das Anlegen neuer AWS-Resourcen“ wird der Informationsaustausch mit der Systemadministration und ggf. anderen fachlich kompetenten Personen systemisch sicher gestellt.
6.3.2 Gemeinsame Durchführung von Weiterbildungsmaßnahmen
Dieses Konzept geht von regelmäßigen Weiterbildungsmaßnahmen für IT-Entwicklungsteams aus. Im Rahmen der Vorbereitung und Durchführung dieser Veranstaltungen erfolgt eine enge Zusammenarbeit zwischen den wissenstragenden Kollegen.
6.3.3 Gemeinsamer Besuch von externen Weiterbildungsmaßnahmen
Die Mitarbeiter der verschiedenen Teams besuchen gemeinsam AWS-Weiterbildungs-Veranstaltungen., Falls dies nicht möglich ist, werden wichtige Inhalte im Nachgang in einem Info-Meeting vorgestellt.