S3-gateway eller interface-endpoint til en klient på stedet?
Gateway-endpoints lever i rutetabeller og betjener VPC-trafik. Interface-endpoints giver den lokale vej en privat adresse, plus DNS og politik.
At nå S3 fra et kontornetværk over en site-VPN er ikke et ruteproblem, som en statisk rute kan løse alene. Et gateway-endpoint er knyttet til rutetabeller og betjener forespørgsler, der opstår inde i VPC’en. Et interface-endpoint placerer elastiske netværksgrænseflader med private adresser i dine undernet, og disse adresser kan nås fra det lokale netværk over VPN eller Direct Connect. Hvor forespørgslen starter, afgør, hvilken af de to du faktisk har brug for, og arbejdet med DNS, sikkerhedsgruppe og politik følger af det svar.
Adskil endpoint-typerne efter, hvor forespørgslen starter
Et gateway-endpoint vises som en rutetabelpost, der peger på en administreret præfikseliste. Det har ingen netværksgrænseflade, ingen sikkerhedsgruppe og ingen egen privat adresse, og det er netop derfor, en vært på stedet ikke kan route til det: der er intet på den anden side at route til. Trafik inde fra VPC’en når S3, fordi undernettets rutetabel sender det præfiks til endpointet. Trafik fra alle andre steder har ingen sådan post at følge.
Et interface-endpoint er et sæt netværksgrænseflader i undernet, du vælger, hver med en privat adresse fra det undernet og en tilknyttet sikkerhedsgruppe. Det er den form, en hybrid klient kan bruge, fordi det er en almindelig destination, som din tunnel kan bære pakker til. Det betyder også, at endpointet bruger adresser i undernettet og kan løbe tør for dem.
aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table
Læs Type-kolonnen i stedet for navnet. En enkelt VPC indeholder ofte begge slags til samme tjeneste, og den post, din applikation på stedet har brug for, er interface-posten.
Byg vejen til interface-adressen, før du tester S3
Tre ting skal være sande på én gang: routeren på stedet har en rute til endpointets undernet, returvejen fra det undernet når klientnetværket, og endpointets sikkerhedsgruppe tillader klientens kildeområde. Undernettets netværks-ACL kan stadig kaste pakken, efter at alle tre er opfyldt, så kontroller den som fjerde punkt i stedet for som en eftertanke.
En fungerende rute til en eller anden EC2-instans i VPC’en beviser intet af dette. Den viser, at tunnelen er oppe, hvilket er den ene del af vejen, du allerede vidste. Bevis endpoint-adressen separat, og bevis derefter, at navnet opløses til den.
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
Den første kommando viser, hvilken grænseflade klienten ville bruge. Den anden beviser et TCP-håndtryk. Den tredje beviser, at TLS fuldføres med et certifikat, der er gyldigt for endpoint-navnet, og det er den kontrol, der fanger en forkert adresse, før du bebrejder tilladelserne.
Beslut, hvilket DNS-svar applikationen modtager
At et interface-endpoint findes i VPC’en, omdirigerer ikke en SDK på stedet af sig selv. Klienten bruger enten det endpointspecifikke navn, som AWS offentliggør for det pågældende endpoint, eller en privat hostet zone, som du bevidst har gjort opløselig fra kontoret.
Til hybrid opløsning har resolveren på stedet brug for en understøttet vej ind i VPC’ens DNS-visning, normalt via et indgående Resolver-endpoint. At slå privat DNS til uden at forstå, hvilke forespørgselkilder det påvirker, er hvordan et opslag begynder at returnere en adresse, kontoret ikke kan nå. Indstillingen ændrer svar for forespørgsler, der kommer gennem VPC-resolveren, ikke for enhver klient overalt.
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
Kør begge på applikationens vært, ikke på en jump box i VPC’en. Den resolver, der svarer der, er den, din arbejdsbelastning bruger, og et andet svar fra en anden vært er den mest almindelige kilde til forvirring i dette design.
Nåbarhed er ikke autorisation
En forespørgsel, der ankommer til endpointet, har stadig brug for en autoriseret principal og en gældende bucket-tilladelse. En endpoint-politik kan indsnævre, hvad endpointet tillader, og en bucket-politik kan indsnævre det igen. At nå grænsefladen siger intet om, hvilke objekter kalderen må læse.
Test begge retninger: ét harmløst autoriseret kald mod den tilsigtede bucket og ét kald, der forventes afvist for en identitet eller ressource uden for politikken. Gem endpoint-navnet, den opløste adresse og politik-konteksten sammen med resultatet, så den næste person kan genskabe det. En afvisning, der navngiver politiktypen, sparer en times gætteri.
Pris til sidst de to muligheder, før du klargør. Et interface-endpoint faktureres pr. grænsefladetime og pr. gigabyte, mens et gateway-endpoint ikke gør, og den forskel afgør spørgsmålet for mange arbejdsbelastninger med lav volumen, der kun har brug for adgang fra VPC-siden.