S3-Endpunkt: Gateway oder Schnittstelle für den Zugriff aus dem lokalen Netz

Zwei S3-Endpunkttypen wirken in einem Design-Review austauschbar und verhalten sich völlig unterschiedlich, sobald der Client außerhalb des Standorts sitzt. Ein Gateway-Endpunkt ist eine Integration in die Routentabelle innerhalb einer VPC, daher erreicht eine Anfrage von einem Standort-VPN ihn nie als privates Ziel. Ein Schnittstellen-Endpunkt legt private Adressen auf Netzwerkschnittstellen, die ein hybrider Pfad tatsächlich erreichen kann. Alles Weitere hängt davon ab, welchen der beiden Sie gewählt haben.

Entscheiden nach dem Netzwerkzugang, nicht nach dem Dienstnamen

Beginnen Sie dort, wo der Datenverkehr entsteht, denn genau diese Frage beantwortet der Endpunkttyp. Eine Arbeitslast in einem unterstützten VPC-Kontext kann einen Gateway-Endpunkt nutzen und braucht nie eine eigene private Adresse. Eine Arbeitslast vor Ort braucht eine private Adresse, die sie erreichen kann, und genau das bietet ein Schnittstellen-Endpunkt. Mischt ein Design beides, können beide Endpunkttypen in einer VPC koexistieren, und das ist eine normale Anordnung und keine Doppelung.

Sie zu mischen ist nicht das Problem. Zu glauben, ein Typ decke den anderen ab, ist es.

Klassifizieren Sie den Client, bevor Sie etwas auswählen. Ein Arbeitsbereich innerhalb der VPC, ein Container hinter einem NAT-Gateway und eine Anwendung in einer Zweigstelle sind drei verschiedene Quellen, und nur die letzte erzwingt den hybriden Zugang. Schreiben Sie diese Klassifizierung neben das Endpunkt-Inventar, damit der nächste Prüfer sieht, warum jeder Endpunkt existiert.

Was der Schnittstellenpfad durchgängig erfordert

Ein Schnittstellen-Endpunkt gewährt Erreichbarkeit privater Adressen, und Erreichbarkeit ist nur eine von vier Anforderungen. Das lokale Netz braucht eine Route zu diesen Adressen, die VPC-Seite braucht einen Rückweg, die Sicherheitsgruppe des Endpunkts muss den Quellbereich zulassen, und jede Prüfvorrichtung dazwischen muss den Datenfluss erlauben. Eine Route zu irgendeiner Instanz in der VPC beweist keine dieser vier Anforderungen.

Arbeiten Sie vom fernen Ende rückwärts. Bestätigen Sie, dass die Netzwerkschnittstellen des Endpunkts in den erwarteten Subnetzen existieren, und prüfen Sie dann, ob seine Sicherheitsgruppe den echten lokalen Bereich statt eines Platzhalters zulässt. Prüfen Sie anschließend, ob der Tunnel oder die Leitung den Rückweg in derselben Richtung trägt. Die Prüfung ist der Schritt, den viele auslassen, denn eine Middlebox, die die Verbindung erlaubt, kann dennoch einen größeren Antwortkörper verwerfen, und das sieht dann wie ein Durchsatzproblem statt wie ein Richtlinienproblem aus.

Testen Sie mit der kleinsten zulässigen Operation statt mit einem großen Download. Der Fehler zeigt sich früher und mit weniger Verkehr, den man erklären muss.

DNS folgt der Abfragequelle, nicht der VPC

Ein Endpunkt, der existiert, leitet nicht von selbst etwas um. Die Anwendung erhält den Namen, den ihr Resolver zurückgegeben hat, und der Resolver antwortet je nach der Sicht, die er sehen darf. Eine Instanz in der VPC und ein Laptop im Büro stellen zwei verschiedene Fragen und können beide richtige, aber unterschiedliche Antworten erhalten. Das eine zu prüfen und auf das andere zu schließen, macht aus einem bestandenen Test eine gescheiterte Inbetriebnahme.

Lesen Sie die private DNS-Einstellung des Endpunkts als Teil des Designs, nicht als Kontrollkästchen, das nach dem Go-live aktiviert wird.

Wenn der Büro-Resolver die Sicht der VPC sehen muss, muss dieser Pfad absichtlich gebaut werden, üblicherweise über einen Resolver-Inbound-Endpunkt. Fragen Sie aus dem eigenen Kontext der Anwendung ab und notieren Sie, welcher Resolver geantwortet hat. Ein Ergebnis, das auf einem Bastion-Host in der VPC gesammelt wurde, beschreibt nur die Sicht des Bastion-Hosts und sonst nichts.

Berechtigung ist getrennt von Erreichbarkeit

Ein erreichbarer Endpunkt liefert Fehler für Anfragen, die der Principal nicht stellen darf, und dieser Fehler bedeutet, dass das System wie vorgesehen funktioniert. Identitätsrichtlinie, Bucket-Richtlinie und eine etwaige Endpunkt-Richtlinie werden in ihren eigenen Schichten ausgewertet. Netzwerkzugang hat noch nie eine Berechtigung erteilt.

Akzeptieren Sie das Design anhand von zwei Ergebnissen: ein harmloser autorisierter Aufruf, der gelingt, und eine erwartete Ablehnung für eine ausgeschlossene Identität oder einen ausgeschlossenen Bucket.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Notieren Sie den Endpunktnamen, das aufgelöste Ziel und den Richtlinienkontext neben jedem Ergebnis, denn eine spätere DNS-Änderung kann die gesamte Schlussfolgerung ungültig machen. Vergleichen Sie die aktuellen Kosten und den Betriebsaufwand beider Endpunkttypen, bevor Sie irgendetwas bereitstellen. Ein Schnittstellen-Endpunkt kauft einen hybriden privaten Zugang, er ist keine allgemeine Voraussetzung, und der Gateway-Pfad bleibt für Arbeitslasten innerhalb der VPC oft die bessere Antwort. Die Wahl ist pro Client und bleibt überprüfbar.