Gateway S3 o endpoint di interfaccia per un client locale?

Raggiungere S3 da una rete di ufficio tramite una VPN di sito non è un problema di routing che una rotta statica possa risolvere da sola. Un endpoint gateway è collegato alle tabelle di routing e serve le richieste che nascono all’interno della VPC. Un endpoint di interfaccia colloca interfacce di rete elastiche con indirizzi privati nelle tue subnet, e quegli indirizzi sono raggiungibili dalla sede tramite VPN o Direct Connect. Dove inizia la richiesta decide quale dei due ti serve davvero, e il lavoro su DNS, gruppo di sicurezza e policy deriva da quella risposta.

Separa i tipi di endpoint in base a dove inizia la richiesta

Un endpoint gateway appare come una voce della tabella di routing che punta a un elenco di prefissi gestito. Non ha interfaccia di rete, né gruppo di sicurezza, né indirizzo privato proprio, ed è proprio per questo che un host locale non può instradare verso di esso: dall’altra parte non c’è nulla verso cui instradare. Il traffico dall’interno della VPC raggiunge S3 perché la tabella di routing della subnet invia quel prefisso all’endpoint. Il traffico da qualsiasi altro luogo non ha una voce del genere da seguire.

Un endpoint di interfaccia è un insieme di interfacce di rete nelle subnet che scegli, ciascuna con un indirizzo privato da quella subnet e un gruppo di sicurezza collegato. È la forma che un client ibrido può usare, perché è una destinazione ordinaria verso cui il tuo tunnel può trasportare pacchetti. Significa anche che l’endpoint consuma indirizzi nella subnet e può esaurirli.

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

Leggi la colonna Type invece del nome. Una singola VPC di solito contiene entrambi i tipi per lo stesso servizio, e la voce che serve alla tua applicazione locale è quella di interfaccia.

Costruisci il percorso verso l’indirizzo di interfaccia prima di testare S3

Tre cose devono essere vere contemporaneamente: il router locale ha una rotta verso la subnet dell’endpoint, il percorso di ritorno da quella subnet raggiunge la rete del client, e il gruppo di sicurezza dell’endpoint ammette l’intervallo di origine del client. L’ACL di rete della subnet può comunque scartare il pacchetto dopo che tutte e tre sono soddisfatte, quindi controllala come quarto elemento e non come pensiero tardivo.

Una rotta funzionante verso un’istanza EC2 qualsiasi nella VPC non dimostra nulla di tutto ciò. Mostra solo che il tunnel è attivo, che è l’unica parte del percorso che già conoscevi. Dimostra l’indirizzo dell’endpoint separatamente, poi dimostra che il nome si risolve su di esso.

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

Il primo comando mostra quale interfaccia userebbe il client. Il secondo dimostra una stretta di mano TCP. Il terzo dimostra che TLS si completa con un certificato valido per il nome dell’endpoint, ed è il controllo che intercetta un indirizzo sbagliato prima che dai la colpa ai permessi.

Decidi quale risposta DNS riceve l’applicazione

L’esistenza di un endpoint di interfaccia nella VPC non reindirizza un SDK locale da sola. Il client usa o il nome specifico dell’endpoint che AWS pubblica per quel punto, o una zona ospitata privata che hai reso deliberatamente risolvibile dall’ufficio.

Per la risoluzione ibrida, il resolver locale ha bisogno di un percorso supportato verso la vista DNS della VPC, di solito tramite un endpoint in ingresso di Resolver. Abilitare il DNS privato senza capire quali sorgenti di query influenzi è il modo in cui una ricerca inizia a restituire un indirizzo che l’ufficio non può raggiungere. L’impostazione cambia le risposte per le query che arrivano dal resolver della VPC, non per ogni client ovunque.

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

Esegui entrambi sull’host dell’applicazione, non su una jump box dentro la VPC. Il resolver che risponde lì è quello che usa il tuo carico di lavoro, e una risposta diversa da un host diverso è la fonte di confusione più comune in questo progetto.

La raggiungibilità non è autorizzazione

Una richiesta che arriva all’endpoint ha ancora bisogno di un principale autorizzato e di un’autorizzazione di bucket applicabile. Una policy dell’endpoint può restringere ciò che l’endpoint consente, e una policy del bucket può restringerlo ancora. Raggiungere l’interfaccia non dice nulla sugli oggetti che il chiamante può leggere.

Prova entrambe le direzioni: una chiamata autorizzata e innocua verso il bucket previsto, e una chiamata che si prevede venga negata per un’identità o una risorsa fuori dalla policy. Conserva il nome dell’endpoint, l’indirizzo risolto e il contesto della policy con il risultato, così la persona successiva può riprodurlo. Un rifiuto che nomina il tipo di policy risparmia un’ora di congetture.

Infine, valuta il costo delle due opzioni prima di provisionare. Un endpoint di interfaccia viene fatturato per ora di interfaccia e per gigabyte, mentre un endpoint gateway no, e questa differenza decide la questione per molti carichi a basso volume che necessitano solo di accesso dal lato VPC.