S3-gateway eller grensesnitt-endepunkt for ein klient på staden?

Å nå S3 frå eit kontornettverk over ein site-VPN er ikkje eit ruteproblem som ein statisk rute kan løyse åleine. Eit gateway-endepunkt er knytt til rutetabellar og tener førespurnader som oppstår inne i VPC-en. Eit grensesnitt-endepunkt plasserer elastiske nettverksgrensesnitt med private adresser i subnetta dine, og desse adressene er tilgjengelege frå lokalnettet over VPN eller Direct Connect. Kvar førespurnaden startar avgjer kva av dei to du faktisk treng, og arbeidet med DNS, tryggleiksgruppe og policy følgjer av det svaret.

Skil endepunkttypane etter kvar førespurnaden startar

Eit gateway-endepunkt viser seg som ei rutetabelloppføring som peikar på ei administrert prefiksliste. Det har ingen nettverksgrensesnitt, inga tryggleiksgruppe og inga eiga privat adresse, og det er nettopp difor ein vert på staden ikkje kan rute til det: det finst ingenting på hi sida å rute til. Trafikk frå inne i VPC-en når S3 fordi rutetabellen til subnettet sender prefikset til endepunktet. Trafikk frå alle andre stader har inga slik oppføring å fylgje.

Eit grensesnitt-endepunkt er eit sett med nettverksgrensesnitt i subnett du vel, kvart med ei privat adresse frå det subnettet og ei tilknytt tryggleiksgruppe. Det er forma ein hybrid klient kan bruke, fordi det er ein vanleg destinasjon som tunnelen din kan bera pakkar til. Det tyder òg at endepunktet brukar adresser i subnettet og kan gå tom for dei.

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

Les Type-kolonnen i staden for namnet. Eitt VPC inneheld ofte begge typane for same tenesta, og oppføringa applikasjonen din på staden treng, er grensesnitt-oppføringa.

Bygg vegen til grensesnittadressa før du testar S3

Tre ting må vere sanne samstundes: rutaren på staden har ei rute til subnettet til endepunktet, returvegen frå det subnettet når klientnettverket, og tryggleiksgruppa til endepunktet slepp gjennom kjeldeområdet til klienten. Nettverks-ACL-en til subnettet kan framleis kaste pakken etter at alle tre er oppfylte, så kontroller han som fjerde punkt og ikkje som ein ettertanke.

Ei fungerande rute til ein eller annan EC2-førekomst i VPC-en beviser ingenting av dette. Ho viser at tunnelen er oppe, som er den eine delen av vegen du alt visste om. Bevis endepunktadressa separat, og bevis deretter at namnet løysest til henne.

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 kva grensesnitt klienten ville bruke. Den andre beviser eit TCP-handtrykk. Den tredje beviser at TLS vert fullført med eit sertifikat som er gyldig for endepunktnamnet, og det er kontrollen som fangar ei feil adresse før du klandrar løyva.

Avgjer kva DNS-svar applikasjonen mottek

At eit grensesnitt-endepunkt finst i VPC-en, omdirigerer ikkje ein SDK på staden av seg sjølv. Klienten brukar anten det endepunktspesifikke namnet AWS publiserer for det endepunktet, eller ei privat verta sone som du med vilje har gjort løysbar frå kontoret.

For hybrid løysing treng resolvaren på staden ein støtta veg inn i DNS-visninga til VPC-en, vanlegvis via eit innkomande Resolver-endepunkt. Å slå på privat DNS utan å skjøne kva spørjingskjelder det påverkar, er korleis eit oppslag byrjar å returnere ei adresse kontoret ikkje når. Innstillinga endrar svar for spørjingar som kjem gjennom VPC-resolvaren, ikkje for kvar 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øyr begge på verten til applikasjonen, ikkje på ein hoppboks i VPC-en. Resolvaren som svarar der er den arbeidslasta di brukar, og eit anna svar frå ein annan vert er den vanlegaste kjelda til forvirring i dette designet.

Nåbarheit er ikkje autorisasjon

Ein førespurnad som kjem til endepunktet treng framleis ein autorisert principal og eit gjeldande bøtte-løyve. Ein endepunktpolicy kan snevre inn kva endepunktet tillèt, og ein bøttepolicy kan snevre det inn ytterlegare. Å nå grensesnittet seier ingenting om kva objekt den som ringer får lese.

Test begge retningar: eitt ufarleg autorisert kall mot den tiltenkte bøtta, og eitt kall som ein ventar vert avvist for ein identitet eller ressurs utanfor policyen. Ta vare på endepunktnamnet, den løyste adressa og policykonteksten saman med resultatet, slik at neste person kan gjenskape det. Ei avvising som namngjev policytypen sparar ein time med gissing.

Til slutt, prissett dei to alternativa før du provisjonerer. Eit grensesnitt-endepunkt vert fakturert per grensesnitt-time og per gigabyte, medan eit gateway-endepunkt ikkje gjer det, og den skilnaden avgjer spørsmålet for mange arbeidslaster med lågt volum som berre treng tilgang frå VPC-sida.