S3-gateway eller gränssnittsslutpunkt för en klient på plats?

Att nå S3 från ett kontorsnät över en site-VPN är inte ett routningsproblem som en statisk rutt kan lösa själv. En gateway-slutpunkt är kopplad till routningstabeller och betjänar förfrågningar som uppstår inne i VPC:n. En gränssnittsslutpunkt placerar elastiska nätverksgränssnitt med privata adresser i dina subnät, och dessa adresser går att nå från lokalnätet via VPN eller Direct Connect. Var förfrågan börjar avgör vilken av de två du faktiskt behöver, och arbetet med DNS, säkerhetsgrupp och policy följer av det svaret.

Skilj slutpunktstyperna åt efter var förfrågan börjar

En gateway-slutpunkt visas som en routningstabellpost som pekar på en hanterad prefixlista. Den har inget nätverksgränssnitt, ingen säkerhetsgrupp och ingen egen privat adress, och det är just därför en värd på plats inte kan routa till den: det finns ingenting på andra sidan att routa till. Trafik inifrån VPC:n når S3 eftersom subnätets routningstabell skickar det prefixet till slutpunkten. Trafik från alla andra håll har ingen sådan post att följa.

En gränssnittsslutpunkt är en uppsättning nätverksgränssnitt i de subnät du väljer, var och en med en privat adress från det subnätet och en kopplad säkerhetsgrupp. Det är den form en hybridklient kan använda, eftersom det är en vanlig destination som din tunnel kan bära paket till. Det betyder också att slutpunkten förbrukar adresser i subnätet och kan få slut på dem.

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

Läs Type-kolumnen i stället för namnet. En enda VPC innehåller ofta båda typerna för samma tjänst, och posten som din applikation på plats behöver är gränssnittsposten.

Bygg vägen till gränssnittsadressen innan du testar S3

Tre saker måste vara sanna samtidigt: routern på plats har en rutt till slutpunktens subnät, returvägen från det subnätet når klientnätet, och slutpunktens säkerhetsgrupp tillåter klientens källområde. Subnätets nätverks-ACL kan fortfarande kasta paketet efter att alla tre är uppfyllda, så kontrollera den som fjärde punkt och inte som en eftertanke.

En fungerande rutt till någon EC2-instans i VPC:n bevisar ingenting av detta. Den visar att tunneln är uppe, vilket är den enda delen av vägen du redan kände till. Bevisa slutpunktsadressen separat och bevisa sedan att namnet löses upp till den.

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

Det första kommandot visar vilket gränssnitt klienten skulle använda. Det andra bevisar ett TCP-handskakning. Det tredje bevisar att TLS slutförs med ett certifikat som är giltigt för slutpunktsnamnet, och det är kontrollen som fångar en fel adress innan du skyller på behörigheterna.

Bestäm vilket DNS-svar applikationen får

Att en gränssnittsslutpunkt finns i VPC:n omdirigerar inte ett SDK på plats av sig själv. Klienten använder antingen det slutpunktsspecifika namn som AWS publicerar för den slutpunkten, eller en privat värdbaserad zon som du medvetet gjort upplösbar från kontoret.

För hybrid upplösning behöver resolvern på plats en stödd väg in i VPC:ns DNS-vy, vanligtvis via en inkommande Resolver-slutpunkt. Att slå på privat DNS utan att förstå vilka frågekällor det påverkar är hur en uppslagning börjar returnera en adress som kontoret inte når. Inställningen ändrar svar för frågor som kommer via VPC-resolvern, inte för varje klient överallt.

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

Kör båda på applikationens värd, inte på en hopplåda i VPC:n. Resolvern som svarar där är den som din arbetsbelastning använder, och ett annat svar från en annan värd är den vanligaste källan till förvirring i den här designen.

Nåbarhet är inte auktorisering

En förfrågan som når slutpunkten behöver fortfarande ett auktoriserat principal och en tillämplig bucket-behörighet. En slutpunktspolicy kan begränsa vad slutpunkten tillåter, och en bucket-policy kan begränsa det ytterligare. Att nå gränssnittet säger ingenting om vilka objekt anroparen får läsa.

Testa båda riktningarna: ett ofarligt auktoriserat anrop mot den avsedda bucketen, och ett anrop som förväntas nekas för en identitet eller resurs utanför policyn. Spara slutpunktsnamnet, den upplösta adressen och policykontexten tillsammans med resultatet så att nästa person kan återskapa det. En nekad begäran som namnger policytypen sparar en timme av gissningar.

Prisa slutligen de två alternativen innan du provisionerar. En gränssnittsslutpunkt faktureras per gränssnittstimme och per gigabyte, medan en gateway-slutpunkt inte gör det, och den skillnaden avgör frågan för många arbetsbelastningar med låg volym som bara behöver åtkomst från VPC-sidan.