Kriterien zur Bestimmung, wie viele AWS VPCs für Apps verwendet werden sollen? Inter-VPC vs. Intra-VPC-Verkehr

Kriterien zur Bestimmung, wie viele AWS VPCs für Apps verwendet werden sollen? Inter-VPC vs. Intra-VPC-Verkehr

Ich kann keine spezifischen Richtlinien dazu finden, was eine gute Vorgehensweise in Bezug auf die Verwendung eines VPCs im Vergleich zu mehreren für das Anwendungshosting darstellt. DiesVerknüpfungstreift das Thema, ist aber ziemlich alt und gibt keine wirkliche Antwort.

Ich arbeite derzeit an der Migration einer traditionell gehosteten Umgebung, die aus etwa 50 Apps plus zwei Datenbankfarmen (SQL Server und Oracle) besteht, zu AWS; der Gesamtbestand beträgt etwa 250 Windows-Server. Derzeit befindet sich jede App im Wesentlichen in ihrem eigenen /24-Subnetz.

Mir wurde empfohlen, dass jede App und jede Datenbankfarm sowohl in ihrem eigenen AWS-Konto als auch in ihrem eigenen VPC liegen sollte. Ich bin mir jedoch nicht sicher, ob dieser Ansatz sinnvoll ist, insbesondere was die Trennung der Apps von ihren Datenbanken betrifft.

Die Konten machen mir weniger Sorgen, da es sich hier eher um eine Abrechnungsfrage handelt. Aber was die VPCs betrifft, versuche ich den Unterschied zwischen beispielsweise Folgendem zu verstehen:

  1. Replizieren der gesamten Umgebung innerhalb von 1 VPC vs.
  2. Einführung von 50 VPCs zum Hosten der gleichen Anzahl an Apps/Servern.

Was sollte bei der Entscheidung zwischen (1) und (2) berücksichtigt werden, oder ein Kompromiss dazwischen? Ich habe mir die AWS-Dokumente angesehen und kann zu diesem Thema keinen wirklich klaren Rat finden.

Der Hauptunterschied besteht meines Erachtens darin, dass der Netzwerkverkehr ausschließlich innerhalb und außerhalb der VPC stattfindet. Das bedeutet:

  • Es entstehen jetzt zusätzliche Kosten, da für den Inter-VPC-Verkehr Kosten anfallen, für den Intra-VPC-Verkehr jedoch nicht.
  • Eine gewisse zusätzliche Komplexität entsteht dadurch, dass ein Inter-VPC-Mechanismus wie Peering oder Transit Gateways ausgewählt, eingerichtet und verwaltet werden muss.

Aber keiner der oben genannten Punkte ist ein klarer Grund, die Dinge auf die eine oder andere Weise zu handhaben. 50 VPCs sind zwar eine ganze Menge, aber die betreffenden Zahlen liegen durchaus innerhalb der Grenzen von beispielsweise Peering.

Gibt es sonst noch etwas, das ich berücksichtigen sollte?

  • Wie sieht es mit den Leistungsmerkmalen für Intra- vs. Inter-VPC-Verkehr usw. aus?

Weitere Überlegungen:

  • Um Konflikte zu vermeiden, müssen CIDR-Blöcke über die VPCs hinweg verwaltet werden.
  • Die maximale MTU des Peerings beträgt 1500 Bytes
  • Standardmäßig ist der Inter-VPC-Verkehr nicht verschlüsselt.
  • DNS-Komplikationen.

Vielen Dank für jede Hilfe.

Antwort1

AnsehenAWS-LandezoneUndAWS Kontrollturmfür bewährte Vorgehensweisen.

Ich habe einige AWS-Unternehmensnetzwerke entworfen. Hier sind meine allgemeinen Empfehlungen, wenn Sie viele Workloads für den gewünschten Bereich haben (die vollständigen Empfehlungen für die Gestaltung von Landing Zones sind in einem zweitägigen Workshop enthalten, den ich für Kunden durchführe).

  • Ein Konto pro Anwendung und Umgebung (z. B. hat App1 Konten für Entwicklung, Pre-Produktion und Produktion, App2 hat eigene Konten usw.)
  • Alle Ressourcen für jede Anwendung wie App-Server, Datenbankserver usw. gehen in dieses Konto. Die Aufteilung Ihres App-Servers und Ihrer Datenbank auf mehrere Konten erhöht die Kosten ohne wirklichen Nutzen.
  • Das Shared Services-Konto kann für die Dinge verwendet werden, die die meisten Anwendungen benötigen - AD,
  • Der Sicherheits-Account sollte Wachdienste, Sicherheitsgeräte usw. beherrschen
  • Transit-Gateway für die Kommunikation plus Konnektivität vor Ort (die Ihre Netzwerkfragen beantwortet)
  • Verbinden Sie sich mit einem Verzeichnisserver Ihrer Wahl – vor Ort, AD-Dienst, Azure AD usw.
  • Verwenden Sie AWS-Organisationen mit Service Control Policies für Berechtigungen auf hoher Ebene und IAM-Rollen, um Benutzern nur das zu erlauben, was Sie wollen. Lassen Sie sie also keine Sicherheitsdienste deaktivieren, keine Grenzen wie Internet-Gateway oder VPN ändern usw.
  • Erwägen Sie die Verwendunggemeinsam genutzte VPCsum die Bandbreitenkosten zu senken - aber seien Sie vorsichtig, es ist ein heikles Thema

Dies bietet Ihnen eine gute Isolierung und verringert Ihren Explosionsradius, aber Sie benötigen eine angemessene Automatisierung, da Sie 150 Konten haben würden. Ein Konto ist nur ein Container für Abrechnung und VPCs. Ja, Sie zahlen mehr für die Bandbreite.

Die Alternative zur Reduzierung der Bandbreitenkosten besteht darin, alles in einem VPC unterzubringen. Dies macht Isolierung, Kontrolle und Explosionsradius zu einem Problem.

Antwort2

Zusätzlich verwende ich für mein Produkt ein separates, stark abgeriegeltes Konto für Backups der Produktionsumgebung (RDS, S3 usw.) und in einer anderen Region, in der die Produktion ausgeführt wird. Disaster Recovery-Tests im abgeriegelten Konto werden alle 15 Tage durchgeführt, um sicherzustellen, dass die Backups funktionieren!

verwandte Informationen