Gateway S3 sau punct final de interfață pentru un client local?

A ajunge la S3 dintr-o rețea de birou printr-un VPN de site nu este o problemă de rutare pe care o rută statică o poate rezolva singură. Un punct final de gateway este atașat tabelelor de rutare și deservește cererile care provin din interiorul VPC. Un punct final de interfață plasează interfețe de rețea elastice cu adrese private în subrețelele tale, iar acele adrese sunt accesibile din locație prin VPN sau Direct Connect. Locul unde începe cererea decide care dintre cele două îți trebuie cu adevărat, iar munca la DNS, grupul de securitate și politică decurge din acel răspuns.

Separă tipurile de punct final după locul unde începe cererea

Un punct final de gateway apare ca o intrare în tabela de rutare care indică o listă de prefixe administrată. Nu are interfață de rețea, nici grup de securitate, nici adresă privată proprie, și exact de aceea o gazdă din locație nu poate ruta către el: nu există nimic pe partea cealaltă către care să ruleze. Traficul din interiorul VPC ajunge la S3 pentru că tabela de rutare a subrețelei trimite acel prefix către punctul final. Traficul din orice alt loc nu are o astfel de intrare de urmat.

Un punct final de interfață este un set de interfețe de rețea în subrețelele pe care le alegi, fiecare cu o adresă privată din acea subrețea și un grup de securitate atașat. Aceasta este forma pe care o poate folosi un client hibrid, pentru că este o destinație obișnuită către care tunelul tău poate transporta pachete. Înseamnă și că punctul final consumă adrese din subrețea și le poate epuiza.

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

Citește coloana Type, nu numele. Un singur VPC conține adesea ambele tipuri pentru același serviciu, iar intrarea de care are nevoie aplicația ta locală este cea de interfață.

Construiește calea către adresa interfeței înainte de a testa S3

Trei lucruri trebuie să fie adevărate simultan: routerul din locație are o rută către subrețeaua punctului final, calea de întoarcere din acea subrețea ajunge la rețeaua clientului, iar grupul de securitate al punctului final admite intervalul sursă al clientului. ACL-ul de rețea al subrețelei poate încă să elimine pachetul după ce toate trei sunt îndeplinite, așa că verifică-l ca al patrulea element și nu ca gând ulterior.

O rută funcțională către vreo instanță EC2 din VPC nu dovedește nimic din toate acestea. Arată doar că tunelul este sus, ceea ce este singura parte a căii pe care o știai deja. Dovedește adresa punctului final separat, apoi dovedește că numele se rezolvă la ea.

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

Prima comandă arată ce interfață ar folosi clientul. A doua dovedește o strângere de mână TCP. A treia dovedește că TLS se finalizează cu un certificat valid pentru numele punctului final, și aceasta este verificarea care prinde o adresă greșită înainte să dai vina pe permisiuni.

Decide ce răspuns DNS primește aplicația

Existența unui punct final de interfață în VPC nu redirecționează un SDK local de la sine. Clientul folosește fie numele specific punctului final pe care AWS îl publică pentru acel punct, fie o zonă găzduită privată pe care ai făcut-o intenționat rezolvabilă din birou.

Pentru rezolvarea hibridă, rezolvatorul din locație are nevoie de o cale suportată în vizualizarea DNS a VPC, de obicei printr-un punct final de intrare Resolver. Activarea DNS privat fără a înțelege ce surse de interogare afectează este modul în care o căutare începe să returneze o adresă la care biroul nu poate ajunge. Setarea schimbă răspunsurile pentru interogările care vin prin rezolvatorul VPC, nu pentru fiecare client oriunde.

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

Rulează ambele pe gazda aplicației, nu pe o cutie de salt din VPC. Rezolvatorul care răspunde acolo este cel pe care îl folosește sarcina ta de lucru, iar un răspuns diferit de la altă gazdă este cea mai frecventă sursă de confuzie în acest design.

Accesibilitatea nu este autorizare

O cerere care ajunge la punctul final are în continuare nevoie de un principal autorizat și de o permisiune de bucket aplicabilă. O politică a punctului final poate restrânge ce permite punctul final, iar o politică de bucket o poate restrânge și mai mult. A ajunge la interfață nu spune nimic despre ce obiecte poate citi apelantul.

Testează ambele direcții: un apel autorizat și inofensiv către bucketul dorit, și un apel care se așteaptă să fie refuzat pentru o identitate sau o resursă din afara politicii. Păstrează numele punctului final, adresa rezolvată și contextul politicii împreună cu rezultatul, ca următoarea persoană să îl poată reproduce. Un refuz care numește tipul de politică economisește o oră de presupuneri.

În final, evaluează costul celor două opțiuni înainte de a proviziona. Un punct final de interfață este facturat pe oră de interfață și pe gigabyte, în timp ce un punct final de gateway nu este, iar această diferență decide întrebarea pentru multe sarcini de volum mic care au nevoie doar de acces din partea VPC.