„Wir trennen die Umgebungen später, wenn wir Nutzer haben.“ Diesen Satz haben wir von jedem kleinen Team gehört, mit dem wir gearbeitet haben, und wir haben ihn selbst gesagt. Er klingt nach Umsicht: bau keine Infrastruktur, die du noch nicht brauchst. Tatsächlich ist er ein Kredit, aufgenommen zum schlechtestmöglichen Zinssatz, und dieser Artikel ist der Tilgungsplan.
Wir haben die Anleitung geschrieben, wie man drei AWS-Konten aus einer CDK-Codebasis betreibt. Dies ist das Warum, gerichtet an das Team, das ein Konto mit allem darin hat und einen guten Grund, es noch ein Quartal so zu lassen.
Was „später“ kostet
Umgebungen am ersten Tag zu trennen ist ein Tag Arbeit. Sie im sechsten Monat zu trennen ist eine Woche. Sie im achtzehnten Monat zu trennen ist ein Monat, plus ein Risiko, das Sie nicht beziffern können. Die Kosten wachsen nicht linear; sie wachsen mit der Anzahl der Dinge, die Zustand und Namen angesammelt haben.
Im sechsten Monat hat die Datenbank echte Daten und einen echten Namen. Secrets wurden an drei Stellen kopiert. DNS zeigt auf Dinge. Auf jemandes Laptop gibt es ein Profil namens default, das in das einzige Konto deployt, das es gibt. Produktion aus diesem Konto herauszuziehen heißt, zustandsbehaftete Ressourcen in neue Stacks zu importieren, jeden Webhook und jede Integration umzuhängen, jedes geteilte Secret zu rotieren, und das ohne Ausfall. Wir haben es gemacht. Es ist ein Projekt mit Runbook, und das Runbook hat einen Rollback-Abschnitt, und den möchte man lieber nicht brauchen.
Die drei Dinge, die in einem Konto schiefgehen
Wir argumentieren nicht aus der Theorie. Jedes davon ist einem Team passiert, mit dem wir gearbeitet haben, und eines davon uns.
Testdaten in Produktion, oder Produktionsdaten im Test. Mit einem Konto ist „die Datenbank“ ein Cluster, und die Trennung ist ein Schemaname oder ein Tabellenpräfix. Ein Migrationsskript mit falschem search_path, ein Seed-Befehl in der falschen Shell, eine Analyseabfrage auf die falsche Tabelle: jedes ist ein Ein-Zeichen-Fehler, und jedes ist passiert. In getrennten Konten ist der Falsches-Konto-Fehler immer noch möglich, aber er erfordert das Annehmen einer anderen Rolle, und das Deploy-Tooling kann das ohne expliziten Flag verweigern.
Ein Deploy, der für Dev gedacht war. Unser Vorfall: ein cdk deploy von einem Laptop, mit falschem Kontext, löschte jeden App-Runner-Service in einer Umgebung. Es war die Dev-Umgebung, im Dev-Konto, und der Gesamtschaden war ein Nachmittag. Derselbe Befehl löscht in einem Ein-Konto-Setup die Produktion. Die Kontogrenze hat den Fehler nicht verhindert; sie hat ihn begrenzt. Das ist der ganze Wert.
Der Hotfix „nur dieses eine Mal“. Ein Konto ohne Staging bedeutet, dass der einzige Ort, an dem ein Fix getestet werden kann, die Produktion ist. Also geht der Fix nach Produktion, und er funktioniert, und der nächste auch, und irgendwann ist der Deploy-Prozess des Teams „auf main pushen und zuschauen“. Die Gewohnheit ist keine Dummheit. Sie ist die rationale Antwort darauf, nirgends sonst hinschauen zu können. Geben Sie den Leuten ein Staging-Konto für $20 im Monat, und sie nutzen es, weil es da ist.
Was „vom ersten Tag an“ tatsächlich heißt
Der Einwand gegen frühe Trennung ist meist das Bild einer Landing Zone: Control Tower, eine Organisation mit einem Dutzend OUs, Service Control Policies, ein Shared-Services-Konto, zentralisiertes Logging, ein Netzwerkkonto mit Transit Gateway. Das ist ein Monat Arbeit und das Richtige für ein Unternehmen mit fünfzig Engineers. Es ist das Falsche für drei, und es ist nicht das, was wir vorschlagen.
Das Minimum, das fast den gesamten Wert einfängt:
| Am ersten Tag tun | Überspringen, bis Sie es brauchen |
|---|---|
| Eine AWS Organization mit drei Mitgliedskonten: dev, staging, prod | Control Tower, Landing-Zone-Beschleuniger |
Eine config-Map in der CDK-Codebasis, nach Umgebung geschlüsselt |
Organisationseinheiten jenseits der Standard-OU |
| Eine OIDC-Deploy-Rolle pro Konto, nach Branch eingeschränkt | Service Control Policies |
RemovalPolicy.RETAIN und Löschschutz in Prod |
Shared-Services- oder Netzwerkkonten |
| Eine konsolidierte Abrechnungsansicht, nach Umgebung getaggt | Zentralisiertes CloudTrail in ein Sicherheitskonto |
Ein Deploy-Skript, das Prod ohne --env prod --yes verweigert |
Kontenübergreifendes VPC-Peering |
Das ist ein Tag. Der CDK-Diff von einer Umgebung auf drei ist die Config-Map und der env-Kontextwert; alles andere im Stack ist bereits parametrisiert oder sollte es sein. Und die drei Konten kosten in Minimalgröße, mit pausiertem Aurora und App Runner bei 0,25 vCPU, etwa $60 im Monat mehr als eines. Das ist der gesamte Aufpreis, und er ist weniger als eine Stunde des Engineers, der sonst die Migration im achtzehnten Monat machen würde.
Was Sie am zweiten Tag bekommen
Trennung ist nicht nur eine Sicherheitseigenschaft. Sie macht mehrere andere gute Dinge möglich, und die sind es, die sie bezahlen:
- Preview-Umgebungen pro Pull Request brauchen einen Ort, an dem jeder alles deployen kann, ohne zu fragen. Das ist das Dev-Konto, mit einer permissiven OIDC-Trust-Policy, die in Prod inakzeptabel wäre.
- Ein Produktions-Deploy, den ein Mensch freigibt, braucht ein GitHub-Environment mit Reviewern und eine Rolle, die nur dieses Environment annehmen kann. Das ist die Trust Policy des Prod-Kontos.
- Ehrliche Kostenverfolgung. „Was kostet Produktion?“ ist ein Filter auf die Konto-ID, kein archäologisches Projekt durch Tags.
- Explosionsradius für Zugangsdaten. Ein geleakter Dev-Schlüssel kann Prod-Daten nicht anfassen, weil er nicht in diesem Konto ist. Wir haben unsere langlebigen Schlüssel ohnehin gelöscht, aber die Grenze ist die Schicht darunter.
- Härtung, die sich pro Umgebung unterscheidet, ohne Verzweigung im Code. DESTROY in Dev, RETAIN in Prod, Point-in-Time-Recovery in Staging und Prod an, aus einer Tabelle in einer Datei.
Nichts davon ist in einem einzelnen Konto möglich, ohne die Isolation darin von Hand nachzubauen, mit IAM-Policies, die schwerer richtig hinzubekommen sind als die Kontogrenze, die sie nachahmen.
Der Ein-Konto-Fall, der tatsächlich in Ordnung ist
Wenn Sie einen Prototyp bauen, der in acht Wochen weggeworfen wird, ist ein Konto in Ordnung, und die Trennung wäre Verschwendung. Der Test ist, ob es eine Datenbank mit Daten gibt, deren Verlust Sie traurig machen würde. Der Tag, an dem die Antwort ja lautet, ist der Tag, an dem Sie über den Prototyp hinaus sind, und der kommt meist früher, als das Team denkt: das erste Mal, dass sich ein echter Nutzer registriert, das erste Mal, dass eine Rechnung erzeugt wird, das erste Mal, dass jemand sagt „lass das nicht gegen die echte laufen“.
Tun Sie es an diesem Tag, nicht am Tag des Vorfalls.
Wenn Sie ein Konto mit allem darin haben und das Tag-eins-Setup nachrüsten möchten, bevor es zum Monat-achtzehn-Projekt wird, sprechen Sie mit uns. Wir haben beides gemacht, und das erste ist viel günstiger.