S3-Gateway oder Interface-Endpoint für einen lokalen Client?

S3 aus einem Büronetz über ein Site-VPN zu erreichen, ist kein Routingproblem, das eine statische Route allein lösen kann. Ein Gateway-Endpunkt hängt an Routingtabellen und bedient Anfragen, die innerhalb der VPC entstehen. Ein Interface-Endpunkt platziert elastische Netzwerkschnittstellen mit privaten Adressen in Ihren Subnetzen, und diese Adressen sind vom lokalen Standort über VPN oder Direct Connect erreichbar. Wo die Anfrage beginnt, entscheidet, welchen der beiden Sie tatsächlich brauchen, und die Arbeit an DNS, Sicherheitsgruppe und Richtlinie folgt aus dieser Antwort.

Trennen Sie die Endpunkttypen danach, wo die Anfrage beginnt

Ein Gateway-Endpunkt erscheint als Routentabelleneintrag, der auf eine verwaltete Präfixliste zeigt. Er hat keine Netzwerkschnittstelle, keine Sicherheitsgruppe und keine eigene private Adresse, und genau deshalb kann ein Host vor Ort nicht dorthin routen: Auf der anderen Seite gibt es nichts, wohin geroutet werden könnte. Verkehr von innerhalb der VPC erreicht S3, weil die Routentabelle des Subnetzes dieses Präfix an den Endpunkt schickt. Verkehr von überall sonst hat keinen solchen Eintrag, dem er folgen könnte.

Ein Interface-Endpunkt ist eine Menge von Netzwerkschnittstellen in Subnetzen, die Sie auswählen, jeweils mit einer privaten Adresse aus diesem Subnetz und einer angehängten Sicherheitsgruppe. Das ist die Form, die ein hybrider Client nutzen kann, denn es ist ein gewöhnliches Ziel, an das Ihr Tunnel Pakete tragen kann. Es bedeutet auch, dass der Endpunkt Adressen im Subnetz verbraucht und sie ihm ausgehen können.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Lesen Sie die Spalte Type statt des Namens. Eine einzelne VPC enthält häufig beide Arten für denselben Dienst, und der Eintrag, den Ihre Anwendung vor Ort braucht, ist der Interface-Eintrag.

Bauen Sie den Pfad zur Interface-Adresse, bevor Sie S3 testen

Drei Dinge müssen gleichzeitig zutreffen: Der Router vor Ort hat eine Route zum Subnetz des Endpunkts, der Rückweg aus diesem Subnetz erreicht das Clientnetz, und die Sicherheitsgruppe des Endpunkts lässt den Quellbereich des Clients zu. Die Netzwerk-ACL des Subnetzes kann das Paket trotzdem verwerfen, nachdem alle drei erfüllt sind, prüfen Sie sie daher als vierten Punkt und nicht als nachträglichen Gedanken.

Eine funktionierende Route zu irgendeiner EC2-Instanz in der VPC beweist nichts davon. Sie zeigt, dass das Tunnel steht, was der eine Teil des Pfades ist, den Sie ohnehin kannten. Beweisen Sie die Endpunktadresse getrennt und beweisen Sie dann, dass der Name darauf auflöst.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

Der erste Befehl zeigt, welche Schnittstelle der Client verwenden würde. Der zweite beweist einen TCP-Handshake. Der dritte beweist, dass TLS mit einem für den Endpunktnamen gültigen Zertifikat abgeschlossen wird, und das ist die Prüfung, die eine falsche Adresse abfängt, bevor Sie die Berechtigungen beschuldigen.

Entscheiden Sie, welche DNS-Antwort die Anwendung erhält

Ein Interface-Endpunkt in der VPC leitet ein SDK vor Ort nicht von selbst um. Der Client nutzt entweder den endpointspezifischen Namen, den AWS für diesen Endpunkt veröffentlicht, oder eine private gehostete Zone, die Sie bewusst vom Büro aus auflösbar gemacht haben.

Für die hybride Auflösung braucht der Resolver vor Ort einen unterstützten Pfad in die DNS-Ansicht der VPC, meist über einen eingehenden Resolver-Endpunkt. Privates DNS einzuschalten, ohne zu verstehen, welche Abfragequellen es betrifft, führt dazu, dass eine Suche eine Adresse zurückgibt, die das Büro nicht erreichen kann. Die Einstellung ändert Antworten für Abfragen, die über den VPC-Resolver eintreffen, nicht für jeden Client überall.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

Führen Sie beide auf dem Anwendungshost aus, nicht auf einer Jump-Box in der VPC. Der Resolver, der dort antwortet, ist der, den Ihre Arbeitslast nutzt, und eine andere Antwort von einem anderen Host ist die häufigste Verwechslungsquelle in diesem Design.

Erreichbarkeit ist keine Autorisierung

Eine Anfrage, die am Endpunkt ankommt, braucht weiterhin einen autorisierten Principal und eine zutreffende Bucket-Berechtigung. Eine Endpunkt-Richtlinie kann einengen, was der Endpunkt zulässt, und eine Bucket-Richtlinie kann es erneut einengen. Die Schnittstelle zu erreichen sagt nichts darüber, welche Objekte der Aufrufer lesen darf.

Testen Sie beide Richtungen: einen harmlosen autorisierten Aufruf gegen den vorgesehenen Bucket und einen Aufruf, der für eine Identität oder Ressource außerhalb der Richtlinie abgelehnt werden soll. Halten Sie Endpunktnamen, aufgelöste Adresse und Richtlinienkontext zusammen mit dem Ergebnis fest, damit die nächste Person es reproduzieren kann. Eine Ablehnung, die den Richtlinientyp nennt, spart eine Stunde Raten.

Kalkulieren Sie schließlich die beiden Optionen vor der Bereitstellung. Ein Interface-Endpunkt wird pro Schnittstellenstunde und pro Gigabyte abgerechnet, ein Gateway-Endpunkt nicht, und dieser Unterschied entscheidet die Frage für viele Arbeitslasten mit geringem Volumen, die nur Zugriff von der VPC-Seite brauchen.