In meiner Rolle bei DoiT arbeite ich tagtäglich mit Startups, die gerade erst in die Cloud einsteigen.
Und mir begegnen immer wieder dieselben Fehler.
Einige davon teile ich hier – in der Hoffnung, dass Sie sie umgehen, bevor sie teuer, schmerzhaft oder kaum noch reparabel werden:
1\. Der AWS-Account läuft auf der privaten E-Mail eines Gründers
Sehr häufig wird der erste AWS-Account mit der privaten Gmail-Adresse eines Gründers angelegt.
Damit gehört der Account rechtlich und operativ einer Person – nicht dem Unternehmen.
Verlässt der Gründer das Unternehmen, kommt es zum Streit oder passiert ihm (im schlimmsten Fall) etwas, wird die Eigentumsfrage zum ernsthaften Geschäftsrisiko.
Hinzu kommt: Private E-Mail-Konten sind in der Regel weniger sicher als ein Firmenpostfach – keine erzwungene MFA, kein zentrales Auditing, eine schwächere Identity Governance und ein erhebliches Hindernis bei jedem Zertifizierungsaudit.
Wird die E-Mail des Gründers kompromittiert, bedeutet das oft die volle Kontrolle über die gesamte AWS-Umgebung des Unternehmens.
Außerdem entsteht so ein Single Point of Failure.
Best Practice:
Richten Sie ein gemeinsames Gruppenpostfach ein, zum Beispiel: [email protected]
Hinterlegen Sie mindestens zwei Teammitglieder (jemand ist immer krank, im Urlaub oder auf einer Konferenz) und nutzen Sie Plus-Adressierung, um Umgebungen in unterschiedlichen AWS-Accounts sauber zu trennen:
2\. Ressourcen im Management Account anlegen
Ein Startup beginnt mit einem einzigen AWS-Account, in dem alles läuft: Produktion, Entwicklung, Demos und die Spielwiese der Engineers.
Mit dem Wachstum des Unternehmens wird es nötig, Umgebungen voneinander zu trennen. Der naheliegendste Weg scheint zu sein, diesen einen Account in den Management Account in AWS Organizations umzuwandeln und neue Member Accounts über die Organisation anzulegen.
Das Problem: Der Management Account ist der einzige Account, der sich nicht über organisationsweite Kontrollen steuern lässt.
AWS Organizations Dokumentation zu Service Control Policies
Typische Richtlinien, die Sie durchsetzen wollen:
- Alle EC2-EBS-Volumes müssen verschlüsselt sein.
- Ressourcen dürfen nicht in nicht freigegebenen Regionen erstellt werden.
- Teure Instance-Typen (GPU) sind eingeschränkt.
- IAM-User sind verboten (es sind ausschließlich Rollen erlaubt).
Keine dieser Richtlinien greift im Management Account – der in diesem Fall zugleich der Produktions-Account ist.
Schlimmer noch: AWS lässt es nicht zu, einen Management Account in einen Member Account umzuwandeln.
Sobald der Produktions-Account auch der Management Account ist, bleibt nur eine vollständige Migration der Organisation: Neuaufbau der Organisation, Neuanlage der Policies, Neukonfiguration der Berechtigungen und erneutes Onboarding aller Mitarbeitenden auf einen neuen Single-Sign-On-Endpoint (SSO).
Wenn aktuell noch alles in einem einzigen AWS-Account läuft und Sie damit beginnen wollen, Umgebungen zu trennen, dann legen Sie einen neuen, eigenständigen AWS-Account an, definieren Sie ihn über AWS Organizations als Management Account und laden Sie den bestehenden Produktions-Account als Member Account in die neue Organisation ein.
3\. Compliance auf die lange Bank schieben
Wenn Sie an Enterprise-Kunden verkaufen wollen, werden Sie früher oder später nach Compliance gefragt:
- SOC 2 / ISO 27001 für B2B-SaaS
- HIPAA für den Gesundheitsbereich
- PCI DSS für Fintech und Payments
Ein bestehendes Produkt und eine gewachsene Organisation nachträglich an neue Compliance-Anforderungen anzupassen, ist extrem aufwendig.
Das betrifft nicht nur die Cloud-Architektur, sondern auch Entwicklungsprozesse, Zugriffssteuerung und sogar Arbeitsverträge (IP-Rechte, Vertraulichkeit, Geräteverwaltung etc.).
Die Cloud-Infrastruktur nachzubessern ist anspruchsvoll, aber machbar. Verträge und organisatorische Prozesse im Nachhinein zu ändern, ist ungleich schwieriger. Wer von der ersten Codezeile an einen Compliance-Beratungspartner einbindet, macht sich den Weg deutlich leichter.
4\. Alles auf eine Karte setzen
AWS lässt Sie Domain-Registrierung, -Verlängerung und DNS direkt in Route 53 verwalten – bequem und gefährlich zugleich.
Wird der AWS-Account gesperrt (wegen eines Abrechnungsproblems, eines Sicherheitsvorfalls oder eines geleakten IAM-Keys), kann auch Ihre Domain davon betroffen sein.
Funktioniert dann die E-Mail nicht mehr, wird es ausgesprochen schwierig, mit dem AWS Support in Kontakt zu treten und das Problem zu lösen.
Beiträge aus r/aws auf Reddit.com
Best Practice:
Halten Sie die Hauptdomain des Unternehmens außerhalb des produktiven AWS-Hauptaccounts – entweder bei einem separaten Anbieter wie GoDaddy oder NameCheap oder in einem dedizierten AWS-Account. Sind Sie einmal aus Ihrem Produktions-Account ausgesperrt, können Sie die DNS-Einträge weiterhin über den anderen Anbieter bzw. Account pflegen.
5\. Führen Sie einen Ablaufkalender, damit Ihnen keine kritischen Verlängerungstermine durchrutschen
Schon im ersten Jahr sammelt sich bei einem Startup einiges an:
- Verträge
- API-Keys
- Kreditkarten
Eine Gemeinsamkeit haben sie alle: ein Ablaufdatum.
Die unerwünschten Folgen sind meist:
- Gesperrte AWS-Accounts wegen ausbleibender Zahlung.
- Unerwartete Serviceausfälle wegen eines abgelaufenen API-Keys.
- Hektische Verhandlungen zur Vertragsverlängerung wegen verpasster oder unmittelbar bevorstehender Termine.
Ein gemeinsamer Kalender mit automatischen Erinnerungen ("Kreditkarte 3344 läuft in 30 Tagen ab", "Vertragsverlängerung mit MAP-Provider in 45 Tagen") hilft, solche Probleme zu vermeiden.
Fazit
Es gibt viele Herausforderungen zu meistern. Ich kann nur dringend empfehlen, sich einen Mentor zu suchen, der selbst schon gegründet und bereits mehrere Startups geführt hat. Erfahrener Rat ist Gold wert.
Wenn Sie Ihre Cloud von Tag eins an sauber aufbauen wollen: DoiT liefert die Technologie, die Expertise und jahrelange Erfahrung, mit der wir Startups ebenso wie global agierende Unternehmen dabei unterstützen, genau diese Fehler – und viele weitere – zu vermeiden.
Machen wir Ihre Cloud zum Wachstumsmotor statt zum Risikofaktor.