S3-gateway eller grensesnitt-endepunkt for en klient på stedet?

Å nå S3 fra et kontornettverk over en site-VPN er ikke et ruteproblem som en statisk rute kan løse alene. Et gateway-endepunkt er knyttet til rutetabeller og betjener forespørsler som oppstår inne i VPC-en. Et grensesnitt-endepunkt plasserer elastiske nettverksgrensesnitt med private adresser i subnettene dine, og disse adressene er tilgjengelige fra lokalnettet over VPN eller Direct Connect. Hvor forespørselen starter avgjør hvilken av de to du faktisk trenger, og arbeidet med DNS, sikkerhetsgruppe og policy følger av det svaret.

Skill endepunkttypene etter hvor forespørselen starter

Et gateway-endepunkt vises som en rutetabelloppføring som peker på en administrert prefiksliste. Det har ingen nettverksgrensesnitt, ingen sikkerhetsgruppe og ingen egen privat adresse, og det er nettopp derfor en vert på stedet ikke kan rute til det: det finnes ingenting på den andre siden å rute til. Trafikk fra inne i VPC-en når S3 fordi rutetabellen for subnettet sender prefikset til endepunktet. Trafikk fra alle andre steder har ingen slik oppføring å følge.

Et grensesnitt-endepunkt er et sett med nettverksgrensesnitt i subnettene du velger, hvert med en privat adresse fra det subnettet og en tilknyttet sikkerhetsgruppe. Det er formen en hybrid klient kan bruke, fordi det er en vanlig destinasjon som tunnelen din kan bære pakker til. Det betyr også at endepunktet bruker adresser i subnettet og kan gå tom for dem.

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

Les Type-kolonnen i stedet for navnet. En enkelt VPC inneholder ofte begge typene for samme tjeneste, og oppføringen applikasjonen din på stedet trenger, er grensesnitt-oppføringen.

Bygg veien til grensesnittadressen før du tester S3

Tre ting må være sanne samtidig: ruteren på stedet har en rute til endepunktets subnett, returveien fra det subnettet når klientnettverket, og endepunktets sikkerhetsgruppe slipper gjennom klientens kildeområde. Nettverks-ACL-en til subnettet kan fortsatt kaste pakken etter at alle tre er oppfylt, så kontroller den som fjerde punkt og ikke som en ettertanke.

En fungerende rute til en eller annen EC2-forekomst i VPC-en beviser ingenting av dette. Den viser at tunnelen er oppe, som er den ene delen av veien du allerede visste om. Bevis endepunktadressen separat, og bevis deretter at navnet lø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 kommandoen viser hvilket grensesnitt klienten ville brukt. Den andre beviser et TCP-håndtrykk. Den tredje beviser at TLS fullføres med et sertifikat som er gyldig for endepunktnavnet, og det er kontrollen som fanger en feil adresse før du klandrer tillatelsene.

Bestem hvilket DNS-svar applikasjonen mottar

At et grensesnitt-endepunkt finnes i VPC-en, omdirigerer ikke en SDK på stedet av seg selv. Klienten bruker enten det endepunktspesifikke navnet AWS publiserer for det endepunktet, eller en privat vertet sone som du bevisst har gjort oppløsbar fra kontoret.

For hybrid oppløsning trenger resolvereen på stedet en støttet vei inn i VPC-ens DNS-visning, vanligvis via et innkommende Resolver-endepunkt. Å slå på privat DNS uten å forstå hvilke spørringskilder det påvirker, er hvordan et oppslag begynner å returnere en adresse kontoret ikke når. Innstillingen endrer svar for spørringer som kommer gjennom VPC-resolveren, ikke for hver 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

Kjør begge på applikasjonens vert, ikke på en hoppboks i VPC-en. Resolveren som svarer der er den arbeidsbelastningen din bruker, og et annet svar fra en annen vert er den vanligste kilden til forvirring i dette designet.

Nåbarhet er ikke autorisasjon

En forespørsel som kommer til endepunktet trenger fortsatt en autorisert principal og en gjeldende bøtte-tillatelse. En endepunktpolicy kan innsnevre hva endepunktet tillater, og en bøttepolicy kan innsnevre det ytterligere. Å nå grensesnittet sier ingenting om hvilke objekter den som ringer får lese.

Test begge retninger: ett ufarlig autorisert kall mot den tiltenkte bøtta, og ett kall som forventes avvist for en identitet eller ressurs utenfor policyen. Ta vare på endepunktnavnet, den oppløste adressen og policykonteksten sammen med resultatet, slik at neste person kan gjenskape det. En avvisning som navngir policytypen sparer en time med gjetting.

Til slutt, prissett de to alternativene før du provisjonerer. Et grensesnitt-endepunkt faktureres per grensesnitt-time og per gigabyte, mens et gateway-endepunkt ikke gjør det, og den forskjellen avgjør spørsmålet for mange arbeidsbelastninger med lavt volum som bare trenger tilgang fra VPC-siden.