Brána S3 alebo koncový bod rozhrania pre klienta v miestnej sieti?

Dosiahnuť S3 z kancelárskej siete cez site VPN nie je problém smerovania, ktorý by statická trasa vyriešila sama. Koncový bod brány sa pripája k smerovacím tabuľkám a obsluhuje požiadavky, ktoré vznikajú vo vnútri VPC. Koncový bod rozhrania umiestňuje elastické sieťové rozhrania s privátnymi adresami do vašich podsietí a tieto adresy sú z miestnej siete dostupné cez VPN alebo Direct Connect. Kde požiadavka začína, rozhoduje o tom, ktorý z tých dvoch skutočne potrebujete, a práca s DNS, bezpečnostnou skupinou a politikou z tejto odpovede vyplýva.

Rozdeľte typy koncových bodov podľa toho, kde požiadavka začína

Koncový bod brány sa objavuje ako záznam v smerovacej tabuľke ukazujúci na spravovaný zoznam prefixov. Nemá sieťové rozhranie, bezpečnostnú skupinu ani vlastnú privátnu adresu, a práve preto naň host v miestnej sieti nemôže smerovať: na druhej strane nie je nič, kam smerovať. Prevádzka zvnútra VPC sa dostane na S3, pretože smerovacia tabuľka podsiete posiela tento prefix na koncový bod. Prevádzka z akéhokoľvek iného miesta nemá taký záznam, ktorý by mohla nasledovať.

Koncový bod rozhrania je sada sieťových rozhraní v podsietiach, ktoré si zvolíte, každé s privátnou adresou z tejto podsiete a pripojenou bezpečnostnou skupinou. To je tvar, ktorý môže použiť hybridný klient, pretože je to bežné cieľové miesto, kam váš tunel môže prenášať pakety. Znamená to tiež, že koncový bod spotrebúva adresy v podsieti a môže ich vyčerpať.

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

Čítajte stĺpec Type, nie názov. Jedna VPC zvyčajne obsahuje oba typy pre tú istú službu a záznam, ktorý vaša miestna aplikácia potrebuje, je ten rozhranový.

Pred testovaním S3 postavte cestu k adrese rozhrania

Tri veci musia platiť súčasne: smerovač v miestnej sieti má trasu do podsiete koncového bodu, spätná cesta z tejto podsiete dosiahne na sieť klienta a bezpečnostná skupina koncového bodu povoľuje rozsah zdroja klienta. Sieťový ACL podsiete môže paket stále zahodiť po tom, ako všetky tri prejdú, takže ho skontrolujte ako štvrtú položku, nie ako oneskorenú myšlienku.

Funkčná trasa k nejakej inštancii EC2 vo VPC nič z toho nedokazuje. Ukazuje len, že tunel je hore, čo je jediná časť cesty, ktorú ste už poznali. Dokážte adresu koncového bodu zvlášť a potom dokážte, že sa názov na ňu preloží.

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

Prvý príkaz ukazuje, ktoré rozhranie by klient použil. Druhý dokazuje TCP handshake. Tretí dokazuje, že TLS sa dokončí s certifikátom platným pre názov koncového bodu, a to je kontrola, ktorá zachytí zlú adresu skôr, než obviníte oprávnenia.

Rozhodnite, ktorú odpoveď DNS aplikácia dostane

Existencia koncového bodu rozhrania vo VPC sama osebe nepresmeruje miestne SDK. Klient buď používa názov špecifický pre koncový bod, ktorý AWS pre tento bod publikuje, alebo privátnu hostovanú zónu, ktorú ste zámerne urobili z kancelárie prekladateľnou.

Pre hybridný preklad potrebuje miestny resolver podporovanú cestu do zobrazenia DNS vašej VPC, zvyčajne cez prichádzajúci koncový bod Resolvera. Zapnutie privátneho DNS bez pochopenia toho, ktorých zdrojov dopytov sa týka, je spôsob, akým vyhľadávanie začne vracať adresu, na ktorú sa kancelária nedostane. Nastavenie mení odpovede pre dopyty, ktoré prichádzajú cez resolver VPC, nie pre každého klienta všade.

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

Spustite oba príkazy na hostiteľovi aplikácie, nie na jump boxe vo VPC. Resolver, ktorý tam odpovedá, je ten, ktorý vaša záťaž používa, a odlišná odpoveď z iného hostiteľa je najčastejší zdroj zmätku v tomto návrhu.

Dostupnosť nie je autorizácia

Požiadavka, ktorá dorazí na koncový bod, stále potrebuje autorizovaný principal a platné oprávnenie k bucketu. Politika koncového bodu môže zúžiť, čo koncový bod povoľuje, a politika bucketu to môže zúžiť znova. Dosiahnuť rozhranie nič nehovorí o tom, ktoré objekty smie volajúci čítať.

Otestujte oba smery: jedno neškodné autorizované volanie proti zamýšľanému bucketu a jedno volanie, pri ktorom sa očakáva odmietnutie pre identitu alebo prostriedok mimo politiky. Uložte názov koncového bodu, preloženú adresu a kontext politiky spolu s výsledkom, aby to ďalší človek mohol zopakovať. Odmietnutie, ktoré pomenuje typ politiky, ušetrí hodinu hádania.

Nakoniec pred zriadením prepočítajte cenu oboch možností. Koncový bod rozhrania sa účtuje za hodinu rozhrania a za gigabajt, kým koncový bod brány nie, a tento rozdiel rozhoduje otázku pri mnohých máloobjemových záťažiach, ktoré potrebujú len prístup zo strany VPC.