S3: endpoint gateway o endpoint di interfaccia per l’accesso dalla rete locale

Due tipi di endpoint S3 sembrano intercambiabili in una revisione di progettazione e si comportano in modo del tutto diverso non appena il client si trova fuori sede. Un endpoint gateway è un’integrazione con la tabella di routing all’interno di un VPC, quindi una richiesta proveniente da una VPN di sede non arriva mai ad esso come destinazione privata. Un endpoint di interfaccia colloca indirizzi privati sulle interfacce di rete, che un percorso ibrido può davvero raggiungere. Tutto ciò che segue dipende da quale dei due avete scelto.

Decidete dall’ingresso di rete, non dal nome del servizio

Partite da dove nasce il traffico, perché è questa la domanda a cui risponde il tipo di endpoint. Un carico di lavoro in un contesto VPC supportato può usare un endpoint gateway e non ha mai bisogno di un proprio indirizzo privato. Un carico di lavoro on-premise ha bisogno di un indirizzo privato verso cui poter instradare, ed è ciò che fornisce un endpoint di interfaccia. Se un progetto mescola entrambi, i due tipi di endpoint possono coesistere nello stesso VPC, e questa è una disposizione normale e non una duplicazione.

Mescolarli non è il problema. Presumere che un tipo copra l’altro lo è.

Classificate il client prima di scegliere qualsiasi cosa. Uno spazio di lavoro dentro il VPC, un container dietro un gateway NAT e un’applicazione in una filiale sono tre origini diverse, e solo l’ultima impone l’ingresso ibrido. Scrivete questa classificazione accanto all’inventario degli endpoint, così il prossimo revisore vede perché ogni endpoint esiste.

Che cosa richiede il percorso di interfaccia da un capo all’altro

Un endpoint di interfaccia concede la raggiungibilità agli indirizzi privati, e la raggiungibilità è solo uno dei quattro requisiti. La rete locale ha bisogno di una rotta verso quegli indirizzi, il lato VPC ha bisogno di un percorso di ritorno, il gruppo di sicurezza dell’endpoint deve ammettere l’intervallo di origine, e qualsiasi appliance di ispezione tra i due deve consentire il flusso. Una rotta verso una qualsiasi istanza del VPC non dimostra nessuno dei quattro.

Lavorate dall’estremità lontana all’indietro. Confermate che le interfacce di rete dell’endpoint esistono nelle sottoreti attese, poi confermate che il suo gruppo di sicurezza ammette l’intervallo locale reale e non un segnaposto. Poi verificate se il tunnel o il circuito trasporta il percorso di ritorno nella stessa direzione. L’ispezione è il passo che le persone saltano, perché un dispositivo intermedio che consente la connessione può comunque scartare un corpo di risposta più grande, e questo sembra un problema di throughput e non di policy.

Provate con l’operazione autorizzata più piccola disponibile invece che con un download grande. Il guasto compare prima e con meno traffico da giustificare.

Il DNS segue l’origine della query, non il VPC

Un endpoint che esiste non reindirizza nulla da solo. L’applicazione riceve il nome che il suo resolver ha restituito, e il resolver risponde secondo la vista che gli è consentito vedere. Un’istanza dentro il VPC e un portatile in ufficio pongono due domande diverse e possono entrambi ottenere risposte corrette ma diverse. Verificare l’una e concludere sull’altra è il modo in cui un test superato diventa un deployment fallito.

Leggete l’impostazione DNS privata dell’endpoint come parte della progettazione, non come una casella da attivare dopo il go-live.

Se il resolver dell’ufficio deve vedere la vista del VPC, quel percorso va costruito di proposito, di solito tramite un endpoint resolver in ingresso. Interrogate dal contesto proprio dell’applicazione e annotate quale resolver ha risposto. Un risultato raccolto su un host bastion dentro il VPC descrive la vista del bastion e nient’altro.

L’autorizzazione è separata dalla raggiungibilità

Un endpoint raggiungibile restituisce errori per le richieste che il principal non è autorizzato a fare, e quell’errore significa che il sistema funziona come progettato. La policy di identità, la policy del bucket e qualsiasi policy dell’endpoint vengono valutate nei rispettivi livelli. L’accesso di rete non ha mai concesso un’autorizzazione.

Accettate il progetto su due risultati: una chiamata autorizzata innocua che riesce e un rifiuto atteso per un’identità o un bucket escluso.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Registrate il nome dell’endpoint, la destinazione risolta e il contesto della policy accanto a ogni risultato, perché un cambiamento DNS successivo può invalidare l’intera conclusione. Confrontate il costo attuale e il peso operativo di entrambi i tipi di endpoint prima di predisporre qualsiasi cosa. Un endpoint di interfaccia compra un ingresso privato ibrido, non è un requisito universale, e il percorso gateway resta spesso la risposta migliore per i carichi di lavoro dentro il VPC. La scelta è per cliente e resta rivedibile.