Blog

Aufbau eines stabilen öffentlichen Netzwerks auf AWS: Teil 2

Jaime Navarro Santapau

Jaime Navarro Santapau

Aktualisiert Oktober 15, 2025
16 Minuten

Sichere öffentliche Web-Endpunkte bereitstellen

Willkommen bei Building Resilient Public Networking on AWS - unserer umfassenden Blog-Serie über fortschrittliche Netzwerkstrategien, die auf regionale Evakuierung, Failover und robuste Notfallwiederherstellung zugeschnitten sind. Hier finden Sie eine Zusammenfassung dieser spannenden Reise:

  • Netzwerkkonzepte aus der Sicht des Kunden neu betrachten: Wenn Sie unsere Erkundung grundlegender Netzwerkkonzepte in der ersten Folge verpasst haben, können Sie das hier nachholen. Wir haben den Grundstein für das Verständnis der Grundlagen gelegt, die den folgenden Diskussionen zugrunde liegen.
  • Stellen Sie sichere öffentliche Web-Endpunkte bereit: In diesem Blogbeitrag gehen wir auf die Feinheiten der Bereitstellung eines Webservers und die Sicherung seines öffentlichen Endpunkts auf AWS ein. Außerdem entmystifizieren wir die Verwaltung einer DNS-gehosteten Zone mit Route 53, einschließlich der nahtlosen Integration mit DNS-Hosting-Anbietern von Drittanbietern.
  • Regionale Evakuierung mit DNS-Ansatz: An dieser Stelle werden wir die bisherige Webserver-Infrastruktur in mehreren Regionen bereitstellen und dann den DNS-basierten Ansatz zur regionalen Evakuierung prüfen, der die Leistungsfähigkeit von AWS Route 53 nutzt. Wir werden die Vorteile und Einschränkungen dieser Technik untersuchen.
  • Evakuierung von Regionen mit einem statischen Anycast-IP-Ansatz: Auch hier werden wir die Webserver-Infrastruktur in mehreren Regionen einrichten und dann das Konzept der Evakuierung von Regionen unter Verwendung des robusten Global Accelerator mit einem statischen Anycast-IP-Ansatz erkunden. Gewinnen Sie Einblicke in die Vorteile und Überlegungen zur Implementierung.
  • Persistente TCP-Verbindungen des Clients und warum dies ein Problem sein könnte: Zum Abschluss unserer Serie beleuchten wir die entscheidende Rolle der Behebung eines der häufigsten Verhaltensweisen von HTTP-Clients - persistente TCP-Verbindungen. Finden Sie heraus, warum die Vernachlässigung dieses Aspekts zum potenziellen Scheitern der zuvor besprochenen Ansätze führen kann.

Außerdem haben wir ein GitHub-Repository vorbereitet , um diese Blog-Serie zu ergänzen. Es bietet Infrastructure as Code (IaC) mit AWS Cloud Development Kit (CDK) und CloudFormation, so dass Sie die erforderliche Infrastruktur mühelos bereitstellen und verwalten können.

Einführung

In diesem zweiten Beitrag unserer Serie "Aufbau eines stabilen öffentlichen Netzwerks auf AWS", die sich an Leser mit Vorkenntnissen richtet, begeben wir uns auf eine geführte Reise zur Bereitstellung eines sicheren, mit HTTPS verstärkten öffentlichen Endpunkts. Es gibt zwar automatisierte Methoden für diesen Prozess, aber unser Ziel ist es, ihn für Leser, die sich in die Feinheiten vertiefen möchten, verständlich und zugänglich zu machen.

Um die notwendige Infrastruktur in der Cloud einzurichten, verwenden wir Infrastructure as Code (IaC) unter Verwendung von AWS CDK mit TypeScript zusammen mit CloudFormation. Den entsprechenden Code für diesen Blogbeitrag finden Sie hier.

Wenn Sie das AWS CDK noch nicht kennen, empfehle ich Ihnen,"Erste Schritte mit dem AWS CDK" zu lesen, um die Grundlagen zu verstehen.

Bereitstellungs- und Konfigurationsphasen

Wir gehen an die Bereitstellung und Konfiguration unserer Infrastruktur in verschiedenen Phasen heran, wobei wir verschiedene CDK-Stacks verwenden und einige manuelle Schritte für Ressourcen außerhalb von AWS einbeziehen. Hier finden Sie einen kurzen Überblick über jede Phase:

Manueller Schritt

  • Erstellen Sie eine kostenlose Domain in ClouDNS; wir müssen einen eindeutigen Namen wählen, der im öffentlichen Internet verfügbar ist

Erste CDK-Stufe - Grundlegende Infrastruktur

  • VPC-Erstellung: Erstreckt sich über die gesamte Region, wobei der bereitgestellte VPC-CIDR-Bereich automatisch aufgeteilt wird. Erstellt öffentliche und private Subnetze pro Availability Zone und stellt den ausgehenden Zugriff über ein Internet-Gateway und belastbare NAT-Gateways sicher.
  • Fargate Cluster: Richtet den Elastic Container Service (ECS) in AWS ein und bietet eine skalierbare und serverlose Container-Ausführungsumgebung.
  • Route53 DNS Public Zone: Richtet eine öffentliche DNS-Zone mit AWS Route53 ein und legt damit den Grundstein für die Verwaltung der DNS-Einträge unserer Domain.

Manueller Schritt

  • Sobald die grundlegende Infrastruktur eingerichtet ist, konfigurieren wir ClouDNS manuell mit den NS-Einträgen der in AWS Route53 erstellten öffentlichen Zone. Dadurch wird unsere in Route53 erstellte öffentliche Zone im Internet verfügbar.

Zweite CDK-Stufe - Bereitstellung von Webcontainern

  • Web-Container-Bereitstellung: Nutzt den Fargate-Cluster zur Bereitstellung von Web-Container-Aufgaben und gewährleistet so eine skalierbare und effiziente Ausführung.
  • SSL/TLS-Zertifikat erstellen: Erstellt ein öffentliches Zertifikat in AWS Certificate Manager (ACM), ein entscheidender Schritt zur Sicherung unseres öffentlichen Web-Endpunkts.
  • Öffentlicher Anwendungs-Load-Balancer (ALB): Richtet einen ALB ein und integriert das vorherige SSL/TLS-Zertifikat für mehr Sicherheit.
  • Route53 DNS-Einträge: Konfiguriert Route53 DNS-Einträge, um den Datenverkehr zum eingesetzten ALB zu leiten, der die Eingangstür des Webcontainers darstellt und die Erreichbarkeit sicherstellt.

Überblick über die Architektur

Das nebenstehende Diagramm veranschaulicht die Architektur der von uns bereitgestellten Infrastruktur und zeigt die Beziehungen zwischen den wichtigsten Komponenten. Während die CDK-Stacks die Infrastruktur innerhalb der AWS Cloud bereitstellen, müssen wir für externe Komponenten wie den DNS-Anbieter (ClouDNS) manuelle Schritte ausführen, die im folgenden Diagramm hervorgehoben sind.

 

Leitfaden für die Bereitstellung und Konfiguration

Nachdem wir nun ein klares Verständnis der Rolle der einzelnen Komponenten und AWS-Produkte in unserer Infrastruktur haben, können wir den Bereitstellungsprozess mithilfe der leistungsstarken Automatisierungstools von AWS - insbesondere AWS CDK und AWS CloudFormation- rationalisieren. Durch den Einsatz dieser Tools können Sie die Erstellung und Verwaltung Ihres sicheren öffentlichen Endpunkts automatisieren und so die Konsistenz und Skalierbarkeit Ihrer gesamten Infrastruktur sicherstellen.

In diesem Abschnitt führen wir Sie Schritt für Schritt durch die Aktionen, die für die Bereitstellung und Konfiguration der im vorherigen Bild dargestellten Infrastruktur erforderlich sind. Wir möchten für Klarheit sorgen, indem wir jeden Schritt im Detail erläutern. Es ist wichtig zu wissen, dass wir diese Aktionen der Übersichtlichkeit halber manuell durchführen werden. In einem realen Szenario sollte dieser Prozess jedoch automatisiert werden.

Um den Automatisierungsprozess umfassend zu verstehen und Verbesserungen für reale Szenarien einzuführen, werden wir uns im Abschnitt"Verbesserungen und Automatisierung" weiter unten in diesem Blogbeitrag mit den notwendigen Änderungen befassen. Beginnen wir mit der Ausführung und Erläuterung der einzelnen Schritte im Bereitstellungsprozess.

Schritt 0 - Installation der erforderlichen Tools

Um den Verteilungsprozess zu beginnen, müssen Sie die entsprechenden Tools auf dem Rechner installieren, auf dem Sie diese Schritte ausführen möchten. Folgen Sie den nachstehenden Anweisungen für Ihr Betriebssystem:

Schritt 1 - Bestätigen Sie die AWS-Anmeldedaten

Bevor Sie fortfahren, sollten Sie sicherstellen, dass Ihre AWS-Zugangsdaten korrekt konfiguriert sind und wie erwartet funktionieren. Führen Sie zur Bestätigung die folgenden Schritte aus:

  • AWS-Profile auflisten: Führen Sie den folgenden Befehl aus, um eine Liste der verfügbaren AWS-Profile anzuzeigen.
aws configure list-profiles
  • AWS-Standardprofil festlegen (Optional): Wenn Sie mehrere AWS-Profile haben und ein Standardprofil festlegen möchten, verwenden Sie den folgenden Befehl. Ersetzen Sie xxxxxxxxxx durch den von Ihnen gewünschten Profilnamen.
export AWS_DEFAULT_PROFILE=xxxxxxxxxx
  • AWS-Standardregion festlegen: Legen Sie die AWS-Standardregion fest.
export AWS_DEFAULT_REGION=us-east-1
  • Bestätigen Sie die AWS-Anmeldeinformationen: Überprüfen Sie, ob Ihre AWS-Anmeldeinformationen korrekt eingestellt sind, indem Sie die folgenden Befehle ausführen.
aws configure list
aws sts get-caller-identity

Schritt 2 - DNS-Konfiguration

In diesem Schritt müssen Sie einen eindeutigen Namen für Ihre kostenlose Domain wählen. Als Beispiel nehmen wir " subdomain-1.cloudns.ph" aber es ist wichtig, dass Sie einen anderen öffentlichen Domainnamen wählen, der für Sie verfügbar ist.

  • Create Free DNS Hosted Zone in ClouDNS:
    • Verwenden Sie die Vorlage "subdomain-xx.cloudns.ph", um eine kostenlose DNS-gehostete Zone in ClouDNS zu erstellen.
    • Folgen Sie der Anleitung, um Ihre kostenlose DNS-Zone einzurichten. Beachten Sie, dass Sie eine andere Subdomain auswählen müssen, wenn diese bereits in Gebrauch ist.
  • Update Configuration in GitHub Repository: 
    • Im GitHub-Repository finden Sie die Konfigurationsdatei unter ./infrastructure/config/environment.ts.
    • Aktualisieren Sie den Wert der Variable DNS_ZONE_NAME mit der gewählten Subdomain. Verwenden Sie die Vorlage"subdomain-2.subdomain-xx.cloudns.ph".

Schritt 3 - CDK-Projekt erstellen

Nun, da unser GitHub-Repository mit einem freien öffentlichen DNS-Domainnamen konfiguriert ist, können wir es erstellen und für die Bereitstellung vorbereiten.

  • Stellen Sie sicher, dass Sie sich im richtigen Ordner befinden
cd infrastruktur/blog_post_2
  • Installieren Sie JavaScript-Abhängigkeiten: Führen Sie den folgenden Befehl aus, um die erforderlichen JavaScript-Abhängigkeiten zu installieren:
npm install -dd
  • Erstellen Sie das Projekt: Führen Sie den folgenden Befehl aus, um das CDK-Projekt zu erstellen und es für die Bereitstellung vorzubereiten:
npm run build -dd

Schritt 4 - Bootstrap CDK und Überprüfung der Infrastruktur

Dieser Schritt umfasst die Einrichtung der erforderlichen AWS-Ressourcen und -Konfigurationen für die Bereitstellung Ihrer CDK Stacks mit CloudFormation.

  • Bootstrap CDK: Führen Sie den folgenden Befehl aus, um das CDK zu booten und es für die Bereitstellung vorzubereiten:
npx cdk bootstrap --region us-east-1
  • Überprüfen und Aktualisieren des anfänglichen Infrastrukturstatus: Um den anfänglichen Status der Infrastruktur in AWS, einschließlich der Verfügbarkeitszonen für die angegebene Region, zu überprüfen und zu aktualisieren, verwenden Sie die folgenden Befehle:
npx cdk context --clear
npx cdk synth --debug -vv

Schritt 5 - Bereitstellung der ersten CDK-Stufe (Basisinfrastruktur)

Führen Sie den folgenden Befehl aus, um die grundlegenden Infrastrukturanforderungen in der Region us-east-1 bereitzustellen:

npx cdk deploy stage-1/* --require-approval never

Die grundlegende Infrastruktur umfasst:

  • VPC Creation: 
    • Erstreckt sich über die gesamte Region und unterteilt den bereitgestellten VPC CIDR-Bereich (Classless Inter-Domain Routing).
    • Erzeugt öffentliche und private Subnetze pro Availability Zone.
    • Konfiguriert das Netzwerk-Routing für öffentliche Teilnetze, um den ausgehenden Zugriff über ein Internet-Gateway zu ermöglichen.
    • Konfiguriert das Netzwerk-Routing für private Subnetze, um den ausgehenden Zugriff über belastbare NAT-Gateways (eines pro AZ) zu ermöglichen.
  • Erstellen Sie einen Fargate-Cluster
  • Erstellen Sie eine Route53 DNS Public Zone

Nach der Ausführung dieses Befehls können Sie den Status Ihrer CDK-Bereitstellung in CloudFormation auch über die AWS-Konsole überprüfen.

Schritt 6 - Konfigurieren Sie ClouDNS mit den NS-Einträgen von AWS route53

Gehen Sie von der im vorherigen Schritt erstellten gehosteten Zone zum AWS Route 53 Dashboard. Wir erhalten die DNS-Einträge mit dem Typ NameSever (NS).

  • Retrieve NS Records from AWS Route 53:
    • Rufen Sie das AWS Route 53 Dashboard auf und suchen Sie die gehostete Zone, die Sie im vorherigen Schritt erstellt haben. (z.B. "subdomain-2.subdomain-1.cloudns.ph".)
    • Kopieren Sie die NS-Einträge, die sich auf die autoritativen DNS-Server beziehen. Beispielwerte:
ns-123.awsdns-00.com.
ns-123.awsdns-00.co.uk.
ns-123.awsdns-00.org.
ns-123.awsdns-00.net.
  • Configure ClouDNS:
    • Öffnen Sie Ihr ClouDNS-Konto und greifen Sie auf Ihre kostenlose DNS-Zone zu (z.B. subdomain-1.cloudns.ph).
    • Add four NS records, one for each authoritative DNS server:
      • Typ: NS-Eintrag
      • Host: subdomain-2.subdomain-1.cloudns.ph
      • Zeigt auf: ns-123.awsdns-00.com
  • Überprüfung: Bevor Sie mit dem nächsten Schritt fortfahren, stellen Sie sicher, dass die NS-Einträge korrekt konfiguriert sind und die Informationen im Internet weit verbreitet sind. Sie können dieses Online-Tool zur Überprüfung verwenden. Stellen Sie sicher, dass Sie die Beispiel-Domain durch Ihre eigene ersetzen.

Schritt 7 - Infrastrukturstatus löschen und aktualisieren

Nach der Erstellung der grundlegenden Infrastruktur in Schritt 5 ist es wichtig, den aktuellen Status der Infrastruktur in AWS in unserem CDK-Projekt zu überprüfen und zu aktualisieren, bevor wir den folgenden CDK-Stack bereitstellen. Führen Sie die folgenden Befehle aus:

npx cdk context --clear --debug -vv
npx cdk synth --debug -vv

Nach dem Ausführen dieser Befehle wird die Datei cdk.context.json wird aktualisiert. Diese Datei enthält alle Infrastrukturabhängigkeiten, die der nachfolgende CDK-Stack benötigt, um in Ihrem AWS-Konto bereitgestellt zu werden.

Schritt 8 - Bereitstellen der zweiten CDK-Stufe (zusätzliche Infrastruktur)

In diesem Schritt werden wir die verbleibende Infrastruktur in der Region us-east-1 einrichten.

npx cdk deploy stage-2/* --require-approval never

Dieser Befehl initiiert die Bereitstellung der folgenden Komponenten:

  • Web Container Aufgabe: Einsatz in dem zuvor erstellten Fargate-Cluster
  • Öffentliches Zertifikat in ACM: Erzeugt ein öffentliches Zertifikat in AWS Certificate Manager (ACM).
  • Public Application Load Balancer (ALB): 
    • Richtet ein ALB ein, das das vorherige Zertifikat integriert.
    • Die ALB dient als Einstiegspunkt für unseren Webcontainer.
  • Route53 DNS-Eintrag: Erstellt einen öffentlichen DNS-Eintrag, um den Datenverkehr zu dem mit dem Webcontainer verbundenen ALB zu leiten.

Nachdem Sie diesen Befehl ausgeführt haben, können Sie den Status Ihrer CDK-Bereitstellung in CloudFormation auch über die AWS-Konsole überprüfen.

Letzter Schritt - Erstellte Ressourcen entfernen

Sobald Sie alle Überprüfungen abgeschlossen haben, können Sie die gesamte Infrastruktur bereinigen, indem Sie die folgenden Schritte ausführen, um die bereitgestellten Ressourcen zu entfernen.

  • Zunächst müssen wir den DNS-Eintrag mit dem Typ CNAME entfernen, der von ACM in der öffentlichen gehosteten Zone in Route53 erstellt wurde. Stellen Sie sicher, dass dieser Schritt abgeschlossen ist, bevor Sie mit dem nächsten fortfahren
  • Im folgenden Schritt werden die zuvor erstellten Stapel in umgekehrter Reihenfolge entfernt, um Probleme mit Abhängigkeiten zwischen ihnen zu vermeiden.
npx cdk zerstören stufe-2/* stufe-1/*

Die Einhaltung dieser Reihenfolge gewährleistet eine reibungslose und vollständige Entfernung aller Ressourcen.

Testen und Prüfen

Nun, da die gesamte erforderliche Infrastruktur auf Ihrem AWS-Konto eingerichtet ist, ist es an der Zeit, das Verhalten der Infrastruktur zu untersuchen und zu bestätigen. Hier sind einige nützliche Tools für eine schnelle Überprüfung.

DNS-Verbreitungsprüfung

DNS Checker ist ein Online-Tool zur Überprüfung der DNS-Verbreitung im Internet. Denken Sie daran, die angegebene Domain mit der von Ihnen gewählten zu aktualisieren (z.B. "subdomain-2.subdomain-1.cloudns.ph").

SSL/TLS-Zertifikat prüfen

SSL Shopper ist ein Online-Tool zur Validierung von SSL/TLS-Zertifikaten. Denken Sie daran, die angegebene Domain durch die von Ihnen gewählte zu ersetzen (z.B. "subdomain-2.subdomain-1.cloudns.ph").

HTTP-Client-Überprüfung

Mit dem Befehlszeilentool cURL können wir schnell die Erreichbarkeit Ihres Webservers bestätigen und die verfügbaren HTTP-Protokolle (h2, http/1.1) überprüfen, um den öffentlichen ALB zu erreichen und ob die SSL-Verbindungen für die erstellte Domain ordnungsgemäß funktionieren.

curl -v https://web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph
* Versucht 35.173.227.251:443...
* Verbunden mit web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph (35.173.227.251) Port 443 (#0)
* ALPN: bietet h2,http/1.1
* (304) (OUT), TLS-Handshake, Client Hallo (1):
* CAfile: /etc/ssl/cert.pem
* CApath: keine
* (304) (IN), TLS-Handshake, Server-Hallo (2):
* TLSv1.2 (IN), TLS-Handshake, Zertifikat (11):
* TLSv1.2 (IN), TLS-Handshake, Server-Schlüsselaustausch (12):
* TLSv1.2 (IN), TLS-Handshake, Server beendet (14):
* TLSv1.2 (OUT), TLS-Handshake, Client-Schlüsselaustausch (16):
* TLSv1.2 (OUT), TLS-Chiffre ändern, Chiffre-Spezifikation ändern (1):
* TLSv1.2 (OUT), TLS-Handshake, Beendet (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS-Handshake, Beendet (20):
* SSL-Verbindung mit TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: Server akzeptiert h2
* Server-Zertifikat:
* Betreff: CN=*.subdomain-2.subdomain-1.cloudns.ph
* start date: Nov 27 00:00:00 2023 GMT
* expire date: Dec 25 23:59:59 2024 GMT
* subjectAltName: host "web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph" matched cert's "*.subdomain-2.subdomain-1.cloudns.ph"
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M03
* SSL certificate verify ok.
* mit HTTP/2
* h2 [:Methode: GET]
* h2 [:scheme: https]
* h2 [:authority: web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph]
* h2 [:Pfad: /]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* Verwendung der Stream ID: 1 (einfaches Handle 0x7fe9ef812c00)
> GET / HTTP/2
> Host: web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph
> Benutzer-Agent: curl/8.1.2
> Akzeptieren: */*
>
< HTTP/2 200
< Datum: Mon, 27 Nov 2023 15:51:13 GMT
< Inhaltstyp: application/json; charset=utf-8
< Inhalt-Länge: 456
< x-powered-by: Express
< etag: W/"1c8-5fXMveo7D3ZfVWsGIbMvSTgSbVQ"
<
* Verbindung #0 zum Host web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph intakt gelassen
{"MessageResponse": "Region: us-east-1. HTTP-Antwort-Code: 200. Verzögerte Antwort: 0 seconds.", "SocketRequest": "::ffff:10.0.2.105:41334", "HeadersRequest" :{ "x-forwarded-for": "79.116.196.168", "x-forwarded-proto": "https", "x-forwarded-port": "443", "host": "web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph", "x-amzn-trace-id": "Root=1-6564baf1-477d00c537a7da013a062f76", "user-agent": "curl/8.1.2", "accept": "*/*"}, "HeadersResponse" :{ "x-powered-by": "Express"}}

Erweiterungen und Automatisierung

Wenn wir über den in diesem Blogbeitrag beschriebenen Bereitstellungsprozess nachdenken, gibt es Möglichkeiten, verschiedene Aspekte zu verfeinern und zu automatisieren und so zu einem nahtloseren und effizienteren Arbeitsablauf beizutragen.

1. Modulare Bereitstellung mit separaten CDK-Apps

Ziehen Sie einen modularen Ansatz für die Bereitstellung in Erwägung, indem Sie die grundlegende Infrastruktur (VPC, Fargate Cluster, Route53 DNS Public Zone) von den Webcontainer-bezogenen Ressourcen trennen. Erstellen Sie verschiedene AWS CDK-Apps (oder sogar verschiedene GitHub-Repositories) für diese Komponenten, um unabhängige Updates und Änderungen zu ermöglichen. Diese modulare Struktur fördert die Flexibilität und passt besser zu den Praktiken der kontinuierlichen Integration und der kontinuierlichen Bereitstellung (CI/CD).

2. Automatisieren Sie die DNS-Registrierung mit AWS Route 53

Optimieren Sie den DNS-Registrierungsprozess, indem Sie AWS Route 53 als DNS-Registrator nutzen. Anstatt NS-Einträge bei externen Anbietern manuell zu konfigurieren, automatisieren Sie den Erwerb und die Verwaltung von DNS-Namen direkt innerhalb desselben Cloud-Anbieters. Dadurch werden manuelle Schritte überflüssig, was die Gesamtautomatisierung der Einrichtung der Infrastruktur verbessert.

3. CI/CD-Integration

Integrieren Sie Ihren Bereitstellungsprozess in eine CI/CD-Pipeline, um das Testen, Erstellen und Bereitstellen von Infrastrukturänderungen zu automatisieren. Nutzen Sie Tools wie GitHub Actions oder andere CI/CD-Dienste, um eine konsistente und zuverlässige Bereitstellungspipeline zu gewährleisten. Diese Integration automatisiert die Bereitstellungsschritte und erleichtert die Zusammenarbeit und Versionskontrolle.

4. Bewährte Praktiken für Infrastruktur als Code

Prüfen und übernehmen Sie bewährte Praktiken für Infrastructure as Code (IaC), um die Wartbarkeit und Skalierbarkeit des Codes zu verbessern. Ziehen Sie in Erwägung, Ihren IaC-Code zu versionieren, Code-Reviews durchzuführen und Änderungen zu dokumentieren. Dadurch wird sichergestellt, dass sich Ihre Infrastruktur systematisch weiterentwickelt, mit den Branchenstandards übereinstimmt und es für mehrere Teammitglieder einfacher wird, einen Beitrag zu leisten.

Cloud-Alternativen

Dieser Abschnitt bietet einen schnellen vergleichenden Überblick über die wichtigsten AWS-Services und ihre Gegenstücke in Azure und Google Cloud Platform (GCP). Wenn Sie ähnliche Implementierungen bei verschiedenen Cloud-Anbietern in Erwägung ziehen, könnte dieser Vergleich als Ausgangspunkt für den Leser dienen.

AWS Azurblau GCP
IaC (Infrastruktur als Code) AWS CDK Pulumi,
Terraform CDK
Pulumi,
Terraform CDK
Networking Amazon VPC Azure Virtuelles Netzwerk Google Virtuelle Private Cloud (VPC)
Containerdienst ECS mit Fargate Azure Container-Instanzen (ACI) Google Kubernetes Engine (GKE)
Anwendungslastausgleicher Anwendungslastausgleicher (ALB) Azure Load Balancer Google Cloud Lastausgleich
DNS (Domain Name System) Amazonas Route 53 Azure DNS Google Cloud DNS
Zertifikat Manager AWS-Zertifikatsverwaltung (ACM) Azure Schlüssel Tresor Google Cloud Certificate Manager

Fazit und nächste Schritte in unserer Serie "Aufbau stabiler öffentlicher Netzwerke auf AWS".

Herzlichen Glückwunsch! Sie haben die Feinheiten der Erstellung eines sicheren öffentlichen Endpunkts auf AWS mit ACM und Route53 erfolgreich gemeistert. Sie beherrschen die Verwaltung einer DNS-gehosteten Zone mit AWS Route 53 und die nahtlose Integration mit DNS-Hosting-Anbietern von Drittanbietern wie ClouDNS.

Wenn Sie diesen Meilenstein erreicht haben, ist unsere Reise noch lange nicht zu Ende. Nach der Möglichkeit, einen Webserver in einer Region bereitzustellen, bereiten wir uns nun auf eine bedeutende Verbesserung vor - die Bereitstellung in mehreren Regionen. Dieser Fortschritt ebnet uns den Weg für die Erforschung von Lösungen für die Evakuierung von Regionen.

In den kommenden Artikeln werden wir uns mit wichtigen Themen wie regionale Evakuierung, Failover und Notfallwiederherstellung befassen und dabei verschiedene Ansätze und AWS-Produkte einsetzen. Hier ein kleiner Spoiler:

  • Wir werden die Evakuierung der Region mithilfe des DNS-Ansatzes mit AWS Route53 überprüfen.
  • Wir werden die Evakuierung von Regionen mit Hilfe des Anycast IP-Ansatzes mit Global Accelerator überprüfen.

Wir werden auch die Vor- und Nachteile der bisherigen Ansätze besprechen und zum Abschluss unserer Blog-Post-Serie erklären, warum die bisherigen Ansätze völlig scheitern können, wenn wir eines der häufigsten Verhaltensweisen von HTTP-Clients (dauerhafte TCP-Verbindungen) nicht berücksichtigen.

Bleiben Sie dran für einen tieferen Einblick in den Aufbau von stabilen und hochverfügbaren Anwendungen in der Cloud.

Zusätzliche Ressourcen

  1. AWS CDK Getting Started: This guide introduces essential AWS CDK concepts and outlines the installation and configuration process.
  2. AWS ACM Documentation (ACM) Documentation: Access the official AWS documentation for AWS Certificate Manager to explore features, use cases, and best practices. 
  3. AWS Route 53 Documentation: Delve into the intricacies of AWS Route 53 with the official documentation, covering DNS management and domain registration.
  4. ClouDNS Documentation: Refer to the official ClouDNS documentation for detailed insights into their DNS hosting services and configurations. 
  5. GitHub Repository for Practical Examples: Explore the GitHub repository used in this blog post series to access practical examples and infrastructure as code (IaC) configurations. 

Verfasst von

Jaime Navarro Santapau

I'm a Senior DevOps Engineer with over 18 years of experience starting as a Software Engineer followed by Backend Software Development Lead. Currently, I manage complex infrastructure and deliver scalable solutions. Proficient in cloud platforms like AWS and Azure, containerization technologies (Docker, Kubernetes), and automation tools. Proven track record in driving successful DevOps implementations, streamlining workflows, and improving team collaboration. Strong expertise in CI/CD pipelines, monitoring, and scripting languages.

Contact

Let’s discuss how we can support your journey.