Brána S3, nebo koncový bod rozhraní pro klienta v místní síti?

Dosáhnout na S3 z kancelářské sítě přes site VPN není problém směrování, který by statická trasa vyřešila sama. Koncový bod brány se připojuje k routovacím tabulkám a obsluhuje požadavky, které vznikají uvnitř VPC. Koncový bod rozhraní umísťuje elastická síťová rozhraní s privátními adresami do vašich podsítí a tyto adresy jsou z místní sítě dostupné přes VPN nebo Direct Connect. Kde požadavek začíná, rozhoduje o tom, který z těch dvou skutečně potřebujete, a práce s DNS, bezpečnostní skupinou a politikou z této odpovědi vyplývá.

Rozdělte typy koncových bodů podle toho, kde požadavek začíná

Koncový bod brány se objevuje jako záznam v routovací tabulce ukazující na spravovaný seznam prefixů. Nemá síťové rozhraní, bezpečnostní skupinu ani vlastní privátní adresu, a právě proto na něj host v místní síti nemůže směrovat: na druhé straně není nic, kam směrovat. Provoz zevnitř VPC se dostane na S3, protože routovací tabulka podsítě posílá tento prefix na koncový bod. Provoz z jakéhokoli jiného místa nemá takový záznam, který by mohl následovat.

Koncový bod rozhraní je sada síťových rozhraní v podsítích, které si zvolíte, každé s privátní adresou z této podsítě a připojenou bezpečnostní skupinou. To je tvar, který může hybridní klient použít, protože je to běžné cílové místo, kam váš tunel může přenášet pakety. Znamená to také, že koncový bod spotřebovává adresy v podsíti a může je vyčerpat.

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

Čtěte sloupec Type, ne název. Jedna VPC obvykle obsahuje oba typy pro stejnou službu a záznam, který vaše místní aplikace potřebuje, je ten rozhranový.

Než otestujete S3, postavte cestu k adrese rozhraní

Tři věci musí platit současně: směrovač v místní síti má trasu do podsítě koncového bodu, zpětná cesta z této podsítě dosáhne na síť klienta a bezpečnostní skupina koncového bodu povoluje rozsah zdroje klienta. Síťový ACL podsítě může paket stále zahodit poté, co všechny tři projdou, takže ho zkontrolujte jako čtvrtou položku, ne jako opožděnou myšlenku.

Funkční trasa k nějaké instanci EC2 ve VPC nic z toho nedokazuje. Ukazuje jen, že tunel je nahoře, což je jediná část cesty, kterou jste už znali. Dokažte adresu koncového bodu zvlášť a pak dokažte, že se název na ni přeloží.

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

První příkaz ukazuje, které rozhraní by klient použil. Druhý dokazuje TCP handshake. Třetí dokazuje, že TLS se dokončí s certifikátem platným pro název koncového bodu, a to je kontrola, která zachytí špatnou adresu dřív, než obviníte oprávnění.

Rozhodněte, kterou odpověď DNS aplikace dostane

Existence koncového bodu rozhraní ve VPC sama o sobě nepřesměruje místní SDK. Klient buď používá název specifický pro koncový bod, který AWS pro tento bod publikuje, nebo privátní hostovanou zónu, kterou jste záměrně učinili z kanceláře přeložitelnou.

Pro hybridní překlad potřebuje místní resolver podporovanou cestu do zobrazení DNS vaší VPC, obvykle přes příchozí koncový bod Resolveru. Zapnutí privátního DNS bez pochopení toho, kterých zdrojů dotazů se týká, je způsob, jakým vyhledávání začne vracet adresu, na kterou se kancelář nedostane. Nastavení mění odpovědi pro dotazy, které přicházejí přes resolver VPC, ne pro každého klienta všude.

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

Spusťte oba příkazy na hostiteli aplikace, ne na jump boxu ve VPC. Resolver, který tam odpovídá, je ten, který vaše zátěž používá, a odlišná odpověď z jiného hostitele je nejčastějším zdrojem zmatení v tomto návrhu.

Dostupnost není autorizace

Požadavek, který dorazí na koncový bod, stále potřebuje autorizovaný principal a platné oprávnění k bucketu. Politika koncového bodu může zúžit, co koncový bod povoluje, a politika bucketu to může zúžit znovu. Dosáhnout na rozhraní nic neříká o tom, které objekty smí volající číst.

Otestujte oba směry: jedno neškodné autorizované volání proti zamýšlenému bucketu a jedno volání, u kterého se očekává odmítnutí pro identitu nebo prostředek mimo politiku. Uchovejte název koncového bodu, přeloženou adresu a kontext politiky spolu s výsledkem, aby to další člověk mohl zopakovat. Odmítnutí, které pojmenuje typ politiky, ušetří hodinu hádání.

Nakonec před zřízením propočítejte cenu obou možností. Koncový bod rozhraní účtuje za hodinu rozhraní a za gigabyte, zatímco koncový bod brány ne, a tento rozdíl rozhoduje otázku u mnoha málo objemových úloh, které potřebují jen přístup ze strany VPC.