S3: punct final de gateway sau de interfață pentru accesul din rețeaua locală

Două tipuri de puncte finale S3 par interschimbabile într-o revizuire de proiectare și se comportă complet diferit imediat ce clientul se află în afara locației. Un punct final de gateway este o integrare cu tabelul de rutare în interiorul unui VPC, așa că o cerere dintr-un VPN al locației nu ajunge niciodată la el ca destinație privată. Un punct final de interfață plasează adrese private pe interfețe de rețea, iar o cale hibridă poate ajunge efectiv acolo. Tot ce urmează depinde de care dintre cele două ați ales.

Decideți după intrarea în rețea, nu după numele serviciului

Începeți de unde apare traficul, pentru că aceasta este întrebarea la care răspunde tipul de punct final. O încărcare de lucru într-un context VPC acceptat poate folosi un punct final de gateway și nu are niciodată nevoie de o adresă privată proprie. O încărcare de lucru la fața locului are nevoie de o adresă privată către care poate ruta, iar asta oferă un punct final de interfață. Dacă un proiect le amestecă pe ambele, ambele tipuri de puncte finale pot coexista într-un singur VPC, iar aceasta este o aranjare normală și nu o duplicare.

Amestecarea lor nu este problema. Problema este să presupunem că un tip îl acoperă pe celălalt.

Clasificați clientul înainte de a alege ceva. Un spațiu de lucru în interiorul VPC, un container în spatele unui gateway NAT și o aplicație într-un birou de sucursală sunt trei surse diferite, iar doar ultima impune intrarea hibridă. Scrieți această clasificare lângă inventarul punctelor finale, astfel încât următorul revizor să vadă de ce există fiecare punct final.

Ce cere calea de interfață de la un capăt la altul

Un punct final de interfață acordă accesibilitate la adrese private, iar accesibilitatea este doar una dintre cele patru cerințe. Rețeaua locală are nevoie de o rută către acele adrese, partea VPC are nevoie de o cale de întoarcere, grupul de securitate al punctului final trebuie să admită intervalul sursă, iar orice echipament de inspecție dintre ele trebuie să permită fluxul. O rută către orice instanță din VPC nu dovedește niciuna dintre cele patru.

Lucrați de la capătul îndepărtat înapoi. Confirmați că interfețele de rețea ale punctului final există în subrețelele așteptate, apoi confirmați că grupul său de securitate admite intervalul local real și nu un substituent. Apoi verificați dacă tunelul sau circuitul transportă calea de întoarcere în aceeași direcție. Inspecția este pasul pe care oamenii îl sar, pentru că un echipament intermediar care permite conexiunea poate totuși să arunce un corp de răspuns mai mare, iar asta arată ca o problemă de debit și nu de politică.

Testați cu cea mai mică operațiune autorizată disponibilă, nu cu o descărcare mare. Defecțiunea apare mai devreme și cu mai puțin trafic de explicat.

DNS urmează sursa interogării, nu VPC-ul

Un punct final care există nu redirecționează nimic de unul singur. Aplicația primește numele returnat de resolverul ei, iar resolverul răspunde conform vederii pe care are voie să o vadă. O instanță din interiorul VPC și un laptop din birou pun două întrebări diferite și amândouă pot primi răspunsuri corecte, dar diferite. Verificarea uneia și concluzia despre cealaltă este calea pe care un test reușit devine o implementare eșuată.

Citiți setarea DNS privată a punctului final ca parte a proiectării, nu ca o casetă de bifat care se activează după lansare.

Dacă resolverul biroului trebuie să vadă vederea VPC-ului, acea cale trebuie construită intenționat, de obicei printr-un punct final de resolver de intrare. Interogați din contextul propriu al aplicației și notați ce resolver a răspuns. Un rezultat colectat pe un host bastion din interiorul VPC descrie vederea bastionului și nimic altceva.

Permisiunea este separată de accesibilitate

Un punct final accesibil returnează erori pentru cererile pe care principalul nu are permisiunea să le facă, iar acea eroare înseamnă că sistemul funcționează conform proiectării. Politica de identitate, politica de bucket și orice politică de punct final sunt evaluate în propriile lor straturi. Accesul la rețea nu a acordat niciodată o permisiune.

Acceptați proiectarea pe baza a două rezultate: un apel autorizat inofensiv care reușește, și o refuzare așteptată pentru o identitate sau un bucket exclus.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Înregistrați numele punctului final, destinația rezolvată și contextul politicii lângă fiecare rezultat, pentru că o modificare ulterioară de DNS poate invalida întreaga concluzie. Comparați costul actual și greutatea operațională ale ambelor tipuri de puncte finale înainte de a proviziona ceva. Un punct final de interfață cumpără o intrare privată hibridă, nu este o cerință universală, iar calea de gateway rămâne adesea răspunsul mai bun pentru încărcările de lucru din interiorul VPC. Alegerea este per client și rămâne revizuibilă.