S3-gateway of interface-endpoint voor een client op locatie?

S3 bereiken vanaf een kantoornetwerk via een site-VPN is geen routeringsprobleem dat een statische route alleen kan oplossen. Een gateway-endpoint is gekoppeld aan routetabellen en bedient verzoeken die binnen de VPC ontstaan. Een interface-endpoint plaatst elastische netwerkinterfaces met privéadressen in je subnetten, en die adressen zijn vanaf de locatie bereikbaar via VPN of Direct Connect. Waar het verzoek begint, bepaalt welke van de twee je echt nodig hebt, en het werk aan DNS, beveiligingsgroep en beleid volgt uit dat antwoord.

Scheid de endpointtypen op waar het verzoek begint

Een gateway-endpoint verschijnt als een routetabelvermelding die naar een beheerde prefixlijst wijst. Het heeft geen netwerkinterface, geen beveiligingsgroep en geen eigen privéadres, en juist daarom kan een host op locatie er niet naartoe routeren: er is niets aan de andere kant om naartoe te routeren. Verkeer van binnen de VPC bereikt S3 omdat de routetabel van het subnet die prefix naar het endpoint stuurt. Verkeer van elders heeft geen dergelijke vermelding om te volgen.

Een interface-endpoint is een set netwerkinterfaces in subnetten die je kiest, elk met een privéadres uit dat subnet en een gekoppelde beveiligingsgroep. Dat is de vorm die een hybride client kan gebruiken, want het is een gewone bestemming waar je tunnel pakketten naartoe kan dragen. Het betekent ook dat het endpoint adressen in het subnet verbruikt en dat ze op kunnen raken.

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

Lees de kolom Type in plaats van de naam. Eén VPC bevat vaak beide soorten voor dezelfde dienst, en de vermelding die je applicatie op locatie nodig heeft, is de interface-vermelding.

Bouw het pad naar het interface-adres voordat je S3 test

Drie dingen moeten tegelijk waar zijn: de router op locatie heeft een route naar het subnet van het endpoint, het retourpad uit dat subnet bereikt het clientnetwerk, en de beveiligingsgroep van het endpoint staat het bronbereik van de client toe. De netwerk-ACL van het subnet kan het pakket nog steeds laten vallen nadat alle drie kloppen, dus controleer die als vierde punt en niet als een late gedachte.

Een werkende route naar een of andere EC2-instantie in de VPC bewijst hier niets van. Het laat zien dat de tunnel omhoog staat, wat het ene deel van het pad is dat je al wist. Bewijs het endpointadres apart en bewijs daarna dat de naam daarop oplost.

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

De eerste opdracht laat zien welke interface de client zou gebruiken. De tweede bewijst een TCP-handshake. De derde bewijst dat TLS wordt voltooid met een certificaat dat geldig is voor de endpointnaam, en dat is de controle die een verkeerd adres vangt voordat je de machtigingen de schuld geeft.

Bepaal welk DNS-antwoord de applicatie ontvangt

Het bestaan van een interface-endpoint in de VPC leidt een SDK op locatie niet vanzelf om. De client gebruikt ofwel de endpoint-specifieke naam die AWS voor dat endpoint publiceert, ofwel een privé-hosted zone die je bewust vanaf kantoor oplosbaar hebt gemaakt.

Voor hybride resolutie heeft de resolver op locatie een ondersteund pad nodig naar de DNS-weergave van de VPC, meestal via een inkomend Resolver-endpoint. Privé-DNS aanzetten zonder te begrijpen welke querybronnen het raakt, is hoe een opzoeking een adres gaat teruggeven dat kantoor niet kan bereiken. De instelling verandert antwoorden voor query’s die via de VPC-resolver binnenkomen, niet voor elke client overal.

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

Voer beide uit op de host van de applicatie, niet op een jumpbox in de VPC. De resolver die daar antwoordt is degene die je workload gebruikt, en een ander antwoord van een andere host is de meest voorkomende bron van verwarring in dit ontwerp.

Bereikbaarheid is geen autorisatie

Een verzoek dat bij het endpoint aankomt, heeft nog steeds een geautoriseerde principal en een toepasselijke bucketmachtiging nodig. Een endpointbeleid kan beperken wat het endpoint toestaat, en een bucketbeleid kan dat nog verder beperken. Het interface bereiken zegt niets over welke objecten de aanroeper mag lezen.

Test beide richtingen: één onschuldige geautoriseerde aanroep naar de bedoelde bucket, en één aanroep waarvan wordt verwacht dat die wordt geweigerd voor een identiteit of resource buiten het beleid. Bewaar de endpointnaam, het opgeloste adres en de beleidscontext bij het resultaat, zodat de volgende persoon het kan reproduceren. Een weigering die het beleidstype noemt, bespaart een uur gissen.

Prijs ten slotte de twee opties voordat je inricht. Een interface-endpoint factureert per interface-uur en per gigabyte, terwijl een gateway-endpoint dat niet doet, en dat verschil beslist de vraag voor veel workloads met een laag volume die alleen toegang vanaf de VPC-kant nodig hebben.