Pasarel·la S3 o punt final d’interfície per a un client local?

Arribar a S3 des d’una xarxa d’oficina per una VPN de lloc no és un problema d’encaminament que una ruta estàtica pugui resoldre tot sol. Un punt final de pasarel·la s’adjunta a les taules de rutes i serveix les peticions que s’originen dins de la VPC. Un punt final d’interfície col·loca interfícies de xarxa elàstiques amb adreces privades a les vostres subxarxes, i aquestes adreces són accessibles des de les instal·lacions a través de VPN o Direct Connect. On comença la petició decideix quin dels dos necessiteu realment, i la feina de DNS, grup de seguretat i política en deriva d’aquesta resposta.

Separeu els tipus de punt final segons on comença la petició

Un punt final de pasarel·la apareix com una entrada a la taula de rutes que apunta a una llista de prefixos gestionada. No té interfície de xarxa, ni grup de seguretat, ni adreça privada pròpia, i és exactament per això que un amfitrió local no hi pot encaminar: a l’altre costat no hi ha res a què encaminar. El trànsit de dins de la VPC arriba a S3 perquè la taula de rutes de la subxarxa envia aquest prefix al punt final. El trànsit de qualsevol altre lloc no té cap entrada així per seguir.

Un punt final d’interfície és un conjunt d’interfícies de xarxa a les subxarxes que trieu, cadascuna amb una adreça privada d’aquesta subxarxa i un grup de seguretat adjunt. Aquesta és la forma que pot utilitzar un client híbrid, perquè és una destinació ordinària a la qual el vostre túnel pot portar paquets. També vol dir que el punt final consumeix adreces de la subxarxa i se’n pot quedar sense.

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

Llegiu la columna Type, no el nom. Una sola VPC sol contenir els dos tipus per al mateix servei, i l’entrada que necessita la vostra aplicació local és la d’interfície.

Construïu el camí fins a l’adreça d’interfície abans de provar S3

Tres coses han de ser certes alhora: l’encaminador local té una ruta cap a la subxarxa del punt final, el camí de tornada des d’aquesta subxarxa arriba a la xarxa del client, i el grup de seguretat del punt final admet el rang d’origen del client. La ACL de xarxa de la subxarxa encara pot descartar el paquet després que les tres es compleixin, així que comproveu-la com a quart element i no com a pensament posterior.

Una ruta que funciona cap a alguna instància EC2 dins de la VPC no demostra res d’això. Només mostra que el túnel està aixecat, que és l’única part del camí que ja sabíeu. Demostreu l’adreça del punt final per separat i després demostreu que el nom s’hi resol.

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

La primera ordre mostra quina interfície faria servir el client. La segona demostra un intercanvi de mans TCP. La tercera demostra que TLS es completa amb un certificat vàlid per al nom del punt final, i aquesta és la comprovació que atrapa una adreça incorrecta abans que culpeu els permisos.

Decidiu quina resposta DNS rep l’aplicació

Que existeixi un punt final d’interfície a la VPC no redirigeix cap SDK local per si sol. El client o bé fa servir el nom específic del punt final que AWS publica per a aquell punt, o bé una zona allotjada privada que hàgiu fet resoluble des de l’oficina de manera deliberada.

Per a la resolució híbrida, el resolutor local necessita un camí suportat cap a la vista DNS de la VPC, normalment a través d’un punt final d’entrada de Resolver. Activar el DNS privat sense entendre quines fonts de consulta afecta és com una cerca comença a retornar una adreça que l’oficina no pot assolir. El paràmetre canvia les respostes de les consultes que arriben pel resolutor de la VPC, no les de tots els clients a tot arreu.

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

Executeu les dues ordres a l’amfitrió de l’aplicació, no en una màquina de salt dins de la VPC. El resolutor que respon allà és el que fa servir la vostra càrrega de treball, i una resposta diferent des d’un altre amfitrió és la font de confusió més habitual en aquest disseny.

L’abastabilitat no és autorització

Una petició que arriba al punt final encara necessita un principal autoritzat i un permís de dipòsit aplicable. Una política de punt final pot restringir què permet el punt final, i una política de dipòsit ho pot restringir encara més. Arribar a la interfície no diu res sobre quins objectes pot llegir el sol·licitant.

Proveu les dues direccions: una crida autoritzada i innòcua contra el dipòsit previst, i una crida que s’espera denegada per a una identitat o un recurs fora de la política. Guardeu el nom del punt final, l’adreça resolta i el context de política amb el resultat perquè la persona següent ho pugui reproduir. Una denegació que anomena el tipus de política estalvia una hora de conjectures.

Finalment, valoreu el preu de les dues opcions abans d’aprovisionar. Un punt final d’interfície factura per hora d’interfície i per gigabyte, mentre que un de pasarel·la no, i aquesta diferència decideix la qüestió per a moltes càrregues de poc volum que només necessiten accés des del costat de la VPC.