Im Leben jedes Startups gibt es eine Phase namens „ClickOps“. Sie melden sich bei der AWS-Konsole an. Sie suchen nach EC2. Sie klicken auf „Instanz starten“. Sie nennen es „Legacy-Server-Do-Not-Touch“. Es funktioniert. Es fühlt sich produktiv an. Zwei Jahre später stürzt dieser Server ab. Der Ingenieur, der es gebaut hat, ist gegangen. Niemand weiß, welche Betriebssystemversion es lief. Niemand weiß, welche Sicherheitsgruppen geöffnet waren. Niemand weiß, wo die SSH-Schlüssel sind. Das Geschäft ist offline.

Bei Maison Code Paris setzen wir eine strenge Regel durch: Die Infrastruktur ist der Kodex. Wenn es nicht in Terraform (oder Pulumi/CDK) vorhanden ist, existiert es nicht. Dieser Leitfaden gibt einen tiefen Einblick in den Aufbau einer produktionstauglichen AWS-Infrastruktur, die belastbar und sicher ist und Sie nicht in den Bankrott treibt.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Warum Maison Code Infrastruktur diskutiert

Wir verwalten die Infrastruktur für Marken, die nicht scheitern können. Wenn ein Kunde eine Zusammenarbeit mit einem globalen Superstar startet, steigt der Datenverkehr innerhalb von 60 Sekunden um das Hundertfache. Wenn der Load Balancer nicht aufgewärmt ist und die Datenbank nicht skalierbar ist, stürzt die Site ab. Wir entwerfen für Elastizität. Wir nutzen AWS nicht als „Server-Host“, sondern als „programmierbares Dienstprogramm“. Wir helfen CTOs beim Übergang von spröden „Haustierservern“ zu widerstandsfähigen „Viehflotten“.

1. Die Kernphilosophie: Infrastructure as Code (IaC)

Warum schreiben wir Infrastruktur in HCL (HashiCorp Configuration Language)?

Reproduzierbarkeit: Sie können in 10 Minuten eine „Staging“-Umgebung einrichten, die ein exakter Klon von „Production“ ist.
Überprüfbarkeit: „Git Blame“ sagt Ihnen genau, wer wann Port 22 für die Öffentlichkeit geöffnet hat.
Notfallwiederherstellung: Wenn „us-east-1“ ausfällt, ändern Sie eine Variable „region = „eu-west-1““ und stellen sie erneut bereit.

Der Terraform-Stack

Wir verwalten den Staat nicht vor Ort. Wir verwenden ein Remote-Backend (S3 + DynamoDB zum Sperren).

„hcl

main.tf

Terraform { Backend „s3“ { Bucket = „maisoncode-terraform-state“ key = “prod/infrastructure.tfstate” Region = “us-east-1” dynamodb_table = “terraform-locks” verschlüsseln = wahr } }

Anbieter „aws“ { Region = “us-east-1” default_tags { Tags = { Umwelt = „Produktion“ Projekt = „E-Commerce“ ManagedBy = “Terraform” } } } „

2. Netzwerk: Die VPC-Falle

Der größte Fehler, den Entwickler machen, ist die Verwendung der „Standard-VPC“. Die Standard-VPC platziert alles in öffentlichen Subnetzen. Ihre Datenbank hat eine öffentliche IP. Das ist rücksichtslos. Wir entwerfen 3-Tier-Netzwerke.

„Meerjungfrau Diagramm TD Benutzer ->|HTTPS| ALB[Application Load Balancer] Untergraph VPC subgraph Öffentliches Subnetz ALB NAT[NAT-Gateway] Ende subgraph Privates Subnetz App[App-Server / Lambda] Ende subgraph Datenbank-Subnetz RDS[Postgres RDS] Ende Ende App ->|SQL| RDS App ->|Ausgehend| NAT „

Ebene 1: Öffentliches Subnetz

Enthält: Load Balancer (ALB), NAT-Gateways, Bastion Hosts.
Routing: Verfügt über ein Internet-Gateway (IGW). 0.0.0.0/0 -> IGW.

Tier 2: Privates Subnetz (App-Schicht)

Enthält: EC2-Instanzen, Fargate-Container, Lambda ENIs.
Routing: Kein Internet-Gateway. 0.0.0.0/0 -> NAT Gateway (für ausgehende Updates).
Sicherheit: Nicht direkt aus dem Internet erreichbar.

Tier 3: Internes Subnetz (Datenschicht)

Enthält: RDS, ElastiCache, Redshift.
Routing: Überhaupt kein Internetzugang. Kein NAT.
Sicherheit: Vollständige Isolierung.

3. Die NAT-Gateway-Überraschung im Wert von 20.000 US-Dollar

Die Preise für die AWS-Bandbreite sind räuberisch. Ein NAT-Gateway berechnet Ihnen pro Stunde + pro verarbeitetem GB. Wenn Ihre Anwendung 10 TB Bilder von S3 herunterlädt und der Standard-S3-Verkehr über das NAT-Gateway läuft, zahlen Sie etwa 450 US-Dollar. Fix: S3-Gateway-Endpunkte. Dies ist ein virtuelles „Wurmloch“ von Ihrer VPC zu S3, das das NAT umgeht. Es ist Kostenlos.

„hcl Ressource „aws_vpc_endpoint“ „s3“ { vpc_id = aws_vpc.main.id service_name = “com.amazonaws.us-east-1.s3” } „ Stellen Sie immer Gateway-Endpunkte für S3 und DynamoDB bereit.

4. Berechnen: EC2 vs. Fargate vs. Lambda

Welche Rechenmaschine passt zum Luxus-E-Commerce?

EC2 (Virtuelle Maschinen)

Anwendungsfall: Legacy-Apps, Stateful-Dienste (WebSockets), Datenbanken (sofern selbst gehostet).
Urteil zum Maison Code: Vermeiden. Zu viel Wartung (OS-Patching).

ECS Fargate (Serverlose Container)

Anwendungsfall: Node.js/Docker-Apps mit langer Laufzeit.
Vorteile: Kein Betriebssystem-Patching. Sie definieren „CPU: 2, RAM: 4GB“. AWS führt es aus.
Maison-Code-Urteil: Standardauswahl für Next.js-Server, die HTML senden.

Lambda (Funktionen)

Anwendungsfall: Ereignisgesteuerte Aufgaben (Bildgrößenänderung, Auftragsabwicklung).
Vorteile: Auf Null skalierbar.
Urteil zum Maison Code: Hervorragend für „Glue Code“ und Hintergrundarbeiter.

5. Die Datenbank: RDS Aurora Serverless v2

Bei herkömmlichem RDS müssen Sie eine Instanzgröße auswählen („db.m5.large“). Wenn der Verkehr zunimmt, kommt es zu einem Unfall. Wenn der Verkehr sinkt, zahlen Sie zu viel. Aurora Serverless v2 skaliert die Rechenkapazität lokal in Millisekunden nach oben und unten. Es passt perfekt zum „Flash Sale“-Modell der Luxus-Tropfen.

„hcl Ressource „aws_rds_cluster“ „default“ { Cluster_Identifier = „Aurora-Cluster-Demo“ engine = “aurora-postgresql” engine_mode = “bereitgestellt” serverlessv2_scaling_configuration { min_capacity = 0,5 # 40 €/Monat max_capacity = 64.0 # Schwerlast } } „ Wenn der Drop endet, wird er auf 0,5 ACU (Aurora Capacity Units) reduziert. Sie zahlen für das, was Sie nutzen.

6. Inhaltsbereitstellung: CloudFront

Sie können den Benutzern keine Assets aus S3 direkt bereitstellen. S3 ist langsam (Zeit bis zum ersten Byte). CloudFront ist obligatorisch. Es ist ein globales CDN. Kritische Konfiguration: Cache-Richtlinien. Cachen Sie nicht einfach alles.

Bilder: Cache für 1 Jahr.
API-Antworten: Cache für 0 Sekunden (oder 60 Sekunden, wenn öffentlich).
HTML: Cache für 0 Sekunden (serverseitig gerendert).

Sicherheit: Verwenden Sie OAC (Origin Access Control), um Ihren S3-Bucket zu sperren, sodass nur CloudFront ihn lesen kann. Benutzer können das CDN nicht umgehen.

7. Das gut architektonische Framework (6 Säulen)

AWS stellt eine Checkliste namens „Well-Architected Framework“ bereit. Wir prüfen jeden Kunden darauf.

Operational Excellence: Alles automatisieren. Keine manuellen Änderungen.
Sicherheit: Alles verschlüsseln. Geringstes Privileg.
Zuverlässigkeit: Multi-AZ-Bereitstellungen. Selbstheilende Systeme.
Leistungseffizienz: Verwenden Sie Serverless/Spot, um Inhalte zu skalieren.
Kostenoptimierung: Analysieren Sie Rechnungen täglich. Markieren Sie jede Ressource.
Nachhaltigkeit: Verwenden Sie Graviton (ARM)-Prozessoren. Sie verbrauchen 60 % weniger Energie.

8. Disaster Recovery: RTO vs. RPO

Was passiert, wenn AWS „us-east-1“ abbrennt? Sie definieren zwei Metriken:

RTO (Recovery Time Objective): Wie lange dauert es, bis ich wieder online bin? (Ziel: < 1 Stunde).
RPO (Recovery Point Objective): Wie viele Daten können wir verlieren? (Ziel: < 5 Minuten). Strategie:
Datenbank: Regionsübergreifende Read Replicas (USA -> EU). Die Promotion dauert 5 Minuten.
Dateien: S3 Cross-Region Replication (CRR).
Code: Multiregionales Terraform anwenden.

9. Sicherheit: Das Prinzip der geringsten Privilegien

IAM (Identity Access Management) ist die Firewall für den Menschen. Niemals das Root-Konto verwenden. Schließen Sie es in einen Safe ein. Niemals einem Entwickler „Administratorzugriff“ gewähren.

Erstellen Sie detaillierte Richtlinien, die streng auf Ressourcen beschränkt sind.

„json { „Effekt“: „Zulassen“, „Aktion“: [“s3:PutObject“], „Ressource“: „arn:aws:s3:::maisoncode-uploads/images/*“ } „ Dieser Benutzer kann Bilder hochladen. Sie können den Bucket nicht löschen. Sie können die Finanzberichte nicht lesen.

8. Kostenoptimierung: Spot-Instanzen

Verwenden Sie für die Stapeldatenverarbeitung (z. B. Bildoptimierungsjobs, die nachts ausgeführt werden) keine On-Demand-Instanzen. Verwenden Sie Spot-Instanzen. Dabei handelt es sich um freie AWS-Kapazität, die mit einem Rabatt von 70–90 % verkauft wird. Der Haken: AWS kann sie mit einer 2-minütigen Vorwarnung beenden. Wenn Ihre App zustandslos ist (wie ein Warteschlangenarbeiter), spielt das keine Rolle. Es übernimmt die Beendigung und startet an anderer Stelle neu. Dies spart jeden Monat Tausende von Dollar für Hintergrundjobs.

9. Entwicklungsworkflow: Ephemere Umgebungen

Wie testen Sie Infrastrukturänderungen? Wir verwenden „Ephemere“. Wenn eine PR in GitHub geöffnet wird:

GitHub-Aktionen lösen Terraform aus.
Es wird ein neuer Arbeitsbereich „pr-123“ erstellt.
Es stellt einen vollständigen Stack bereit (VPC + Fargate + RDS).
Es führt E2E-Tests durch.
Es führt „Terraform Destroy“ aus.

Dies gibt absolute Sicherheit, dass Codeänderungen die Produktion nicht beeinträchtigen.

10. Fazit

AWS ist eine Kettensäge. Es ist stark genug, um einen Wald abzuholzen, aber gefährlich genug, um Ihnen ein Bein abzuschneiden. Durch Klicken auf die Konsole wird mit Spielzeug gespielt. Terraform zu schreiben ist Ingenieurskunst. Für 2026 bewegen wir uns in Richtung „Infrastruktur aus Code“ (unter Verwendung von SST oder Pulumi, um Infrastruktur aus Code abzuleiten), aber die Grundlagen von VPCs und IAM bleiben unveränderlich.

Ist Ihre Cloud ein Chaos?

Laufen bei Ihnen „Unbekannte Server“? Ist Ihre Rechnung ein Rätsel? Beauftragen Sie unsere Architekten.