%3F.png)
Ich suche nach guten Mustern und Anti-Mustern für die Bereitstellung gespiegelter Umgebungen (der Einfachheit halber sagen wir eine EC2-Instanz und einen RDS- und S3-Bucket, was eine ziemlich gängige Konfiguration ist). Nehmen wir an, wir müssen dies Hunderte oder sogar Tausende Male tun. Ich habe einige Ideen in Betracht gezogen, wie zum Beispiel
Mehrere Konten - Ein Zweck - Alle Regionen nutzen
- Wir stellen eine Instanz eines VPC pro Region bereit und stellen unsere Services in dieser Region bereit.
- Gut, garantiert Isolation und keine
noisy neighbors, TF-Module oder CloudFormation-Vorlagen werden nicht kompliziert - Schlecht, ein verdammter Management-Albtraum
Ein Konto – Mehrzweck
- Wir teilen unser VPC in mehrere Subnetze auf und stellen Ressourcen pro Subnetzgruppierung bereit.
- Gut, einfacher zu verwalten, mehr für weniger
- Schlecht, Sie sind auf 20 Subnetze pro Region beschränkt (16 Regionen * 20), die Möglichkeit lauter Nachbarn, das Networking könnte zu Spaghetti werden
Ich suche nach weiteren Möglichkeiten, dies zu tun, und warum diese schlecht (technische Schulden, nicht wartbar) oder gut (leicht wiederverwendbar usw.) wären.
Tausend Dank
Antwort1
Zu diesem recht komplexen Thema gibt es einige allgemeine Anmerkungen: Es hängt stark davon ab, was Sie wirklich erreichen möchten.
Sie haben drei Möglichkeiten:
Einzelnes VPC – einzelner Satz großer Subnetze – in Ihrem Beispiel wären das 4 – 2 „öffentliche“ Subnetze und 2 „private“ Subnetze. Verwenden Sie dann Sicherheitsgruppen, um „Bereitstellungen“ zu isolieren – ich sehe keinen Vorteil darin, Subnetze zur Trennung zu verwenden, außer dass Sie dann den IP-Adressraum und viele Subnetze verwalten müssen. Letztendlich ist der einzige Unterschied zwischen einem Subnetz normalerweise: AZ/Routentabelle/NACL/DHCP-Optionen – verwenden Sie nur dann ein neues Subnetz, wenn sich eines davon ändert. Ein Subnetz selbst verursacht keine „Noisy Neighbor“-Probleme. Es ist keine Layer-2-Domäne im klassischen „VLAN“-Sinne und das Upstream-Internet-Gateway ist horizontal ohne Einschränkungen skalierbar, wie folgt:Häufig gestellte Fragen zu Amazon VPC
Mehrere VPC – wenn Sie ein einzelnes Konto hätten, könnten Sie mehrere VPCs in einer Region haben. Das weiche Limit liegt bei 5 VPCs, das harte Maximum jedoch bei:
Die Anzahl der VPCs in der Region multipliziert mit der Anzahl der Sicherheitsgruppen pro VPC darf 10.000 nicht überschreiten.
Das ist ziemlich viel. In Ihrem Beispiel könnten Sie sagen, dass es möglicherweise 4 Sicherheitsgruppen gibt (ELB, EC2 ASG, RDS, Administratorzugriff), was theoretisch 2.500 VPCs bedeutet. Ich habe noch nie gehört, dass jemand so etwas hat, aber es könnte eine Option sein.
Allerdings sollten Sie je nach der automatischen Skalierbarkeit Ihrer Plattform auch bedenken, dass manche Limits kontoweit gelten und dass, wenn Sie sie bei einer Bereitstellung erreichen, dies Auswirkungen auf eine andere haben kann – z. B. einfach die Anzahl der Instanzen eines bestimmten Typs – oder die Limits für gleichzeitige Lambda-Ausführungen. Das führt uns zur dritten Option …
Mehrere Konten – Dank der AWS Organizations API können Sie jetzt neue Konten per API erstellen. Die Seite „Limits“ ist jedoch leider vage, was das Limit hinsichtlich der Anzahl der Konten angeht. Ich habe jedoch von größeren Unternehmen gehört, die Tausende von Konten haben. Siehe:Grenzen von AWS OrganizationsUndSo verwenden Sie AWS Organizations zur Automatisierung der End-to-End-Kontoerstellung
Insgesamt werden Sie für Ihren Anwendungsfall einen sauberen CloudFormation-Stack wollen, der mit minimalen Abweichungen vollständig wiederverwendet werden kann – einfach aus Gründen der Konsistenz von Bereitstellung, Betrieb und Support. Für mich deutet das entweder auf VPC als Bereitstellungseinheit oder Account als Bereitstellungseinheit hin. Sie müssen in beiden Fällen auf die Grenzen achten. Wenn Sie es innerhalb eines VPC tun, entweder mit großen Subnetzen oder aufgeteilt nach Subnetz, wird die Wartung letztendlich kompliziert – meine subjektive Ansicht.