AWS hier. Ich habe einen einfachen App-Server, der auf EC2-Instanzen läuft, die sich in einer Autoscaling-Gruppe („Ziel“) befinden, denen ein Application Load Balancer (ALB) vorgeschaltet ist. Der Domänenname des ALB wird in DNS per CNAME meiner Dev-Subdomäne zugeordnet, sagen wir . Daher kann ich , , PostMan usw. dev.myapp.example.comverwenden, um HTTP-Anfragen abzuschicken und Antworten davon zu erhalten, und diese Anfragen werden über alle EC2-Instanzen verteilt, die sich hinter dem ALB (in der Autoscaling-Gruppe) befinden.curlwgethttp://dev.myapp.example.com
MyCloudDBDer auf diesen EC2-Instanzen ausgeführte App-Server muss eine Verbindung zu einer Datenbank-as-a-Service- Lösung eines Drittanbieters herstellen. Für diese Frage nennen wir diese Cloud-DB „ “.
Wenn ich eine EC2-Instanz manuell bereitstelle und meinen App-Server dort bereitstelle, MyCloudDBmuss ich mich bei der MyCloudDBWebkonsole anmelden und die öffentliche IP-Adresse der EC2-Instanz mit einem /32-Subnetz (ehrlich gesagt nicht sicher, warum im /32-Subnetz). Wenn AWS beispielsweise eine öffentliche IP für die Instanz als zuweist, 1.2.3.4muss ich mich anmelden MyCloudDBund einen Zugriffslisteneintrag für hinzufügen 1.2.3.4/32. Dann und nur dann kann der App-Server (der auf der neuen EC2-Instanz läuft) eine Verbindung zu herstellen MyCloudDB.
Ich versuche herauszufinden, wie ich diese Einrichtung der Zulassungs-/Zugriffsliste mit meinem ALB und seiner Autoscaling-Gruppe kompatibel machen kann. Natürlich sind die EC2-Instanzen in der Autoscaling-Gruppe flüchtig und werden je nach meinen Autoscaling-Regeln hoch- und heruntergefahren. Da dies dynamisch/elastisch sein muss, brauche ich eine Möglichkeit, um MyCloudDBallen Anfragen von EC2-Instanzen hinter meinem ALB „zu vertrauen“. Und natürlich darf ich die Sicherheit nicht so sehr lockern, dass ich mir selbst Kopfschmerzen bereite.
Es MyCloudDBwerden drei Arten von Netzwerkzugriffsoptionen angeboten:
- IP-Zugriffsliste (_was ich derzeit ausschließlich verwende)
- VPC-Peering
- Dadurch wird das Peering meiner App-VPC mit der
MyCloudDBVPC ermöglicht.
- Dadurch wird das Peering meiner App-VPC mit der
- Privater Endpunkt
- ermöglicht AWS PrivateLink die Verbindung zu
MyCloudDB
- ermöglicht AWS PrivateLink die Verbindung zu
- Verwaltungs-REST-API
- ermöglicht mir die Verwaltung der IP-Zugriffsliste, allerdings über die RESTful-API (Webdienst)
- so könnte ich einen EC2-Instanz-Lebenszyklus-Hook erstellen, um ein Skript auszuführen, das die IP-Adresse der Instanzen über oder ein anderes Tool zur
MyCloudDBIP-Zugriffsliste hinzufügtcurl
Aus Sicht der Automatisierung habe ich also drei Optionen: VPC-Peering, Private Endpoint (PrivateLink) oder API-Aufrufe. Ich kann die Vor- und Nachteile der API-Aufrufoption auseinanderhalten, aber ich habe Schwierigkeiten, „den Wald vor lauter Bäumen sehen" bei der Option „VPC-Peering vs. PrivateLink“.
Agroßer Aufrufhier ist: Irgendwann werde ich CloudFormation-Vorlagen haben, die den Rollout dieses ALB in neue (kurzlebige) Umgebungen verwalten. Ich brauche diese Verbindungslösung also nicht nur für EC2-Instanzen, die hinter ALB sitzen, sondern auch für ALBs, die über CloudFormation bereitgestellt werden.
Was sind angesichts meiner Situation, meines Kontexts und meiner Anforderungen die Vor-/Nachteile von VPC-Peering gegenüber PrivateLink?
Antwort1
Genau dafür wurde PrivateLink entwickelt. Sie fügen effektiv eine Netzwerkschnittstelle in Ihr VPC ein, auf die Sie zugreifen. Auf ihrer Seite trifft es auf einen NLB und geht dann zu ihrer Datenbank. Dies ist die Methode mit den geringsten Privilegien und das würde ich tun.
VPC-Peering öffnet einen größeren Teil Ihres Netzwerks für einen größeren Teil des Netzwerks anderer. Wenn Ihre IP-Bereiche kollidieren, wird es schwieriger. Ich sehe hier in dieser Situation keine Vorteile.
Wenn die IP-Zugriffsliste die einzige Option wäre, bräuchten Sie statische IPs für Ihre Autoscaling-Gruppe. Dies erreichen Sie, indem Sie in jedem Subnetz ein NAT-Gateway erstellen und die elastischen IPs auf die Whitelist setzen.