Accesso ai bucket S3 tra regioni AWS con VPC Peering

Una guida pratica per capire perché l'accesso S3 cross-region richiede qualcosa in più dei VPC Interface Endpoint con DNS privato

Contesto

Quello che AWS non dice è che questa configurazione non funzionerà senza una piccola aggiunta di connettività verso S3 nella regione che non ospita il bucket (nel mio esempio, us-west-2). Tornerò sul punto più avanti, allo step 6 dell'implementazione.

Scenario

Questa limitazione esiste perché i VPC endpoint di AWS sono progettati per fornire connettività privata ai servizi all'interno della stessa regione.

L'architettura della soluzione

Componenti:

VPC B: una VPC nuova o già esistente in us-east-1, dove andremo a collocare l'S3 Interface Endpoint
VPC Peering Connection: il ponte tra le due VPC
Private Hosted Zone: DNS Route53 per risolvere correttamente gli S3 Endpoint
S3 VPC Interface Endpoint: un Endpoint non è altro che un'Elastic Network Interface (ENI) in una VPC di destinazione, che fornisce connettività privata e sicura a S3 attraverso la rete backbone di AWS (nel nostro caso, in us-east-1)

Implementazione passo-passo

Prerequisiti

Step 1: mettere in sicurezza l'S3 Endpoint

Step 2: creare l'S3 VPC Interface Endpoint

Disabilitare il DNS privato
Associare il security group VPC_B_S3_SG creato in precedenza

Step 3: stabilire il VPC Peering

Step 4: configurare la risoluzione DNS con la PHZ

Associare la VPC A da us-west-2 alla nuova PHZ

All'interno di questa PHZ, creare due record Alias A che puntino al Regional DNS name* dell'S3 VPC Interface Endpoint:

1. Record root: lasciare vuoto il nome del record per crearne uno per

s3.us-east-1.amazonaws.com

Record root — lasciare vuoto il campo Record name

2. Record wildcard: usare * come nome del record per gestire

*.s3.us-east-1.amazonaws.com

Catch All — inserire "*" nel campo Record name

\* Un Regional DNS name è il nome privo della specifica della Availability Zone.

Si presenta così:

`*.vpce-0123456789abcdefg-dawd972fe.s3.us-east-1.vpce.amazonaws.com

e non us-east-1` a(che è invece un Zonal DNS name).

Uno Zonal DNS name è utile nelle architetture che isolano i workloads per Availability Zone. Può ad esempio aiutare a ridurre i costi di trasferimento dati regionali, mantenendo il traffico nella stessa AZ e regione dell'ENI dell'Interface Endpoint. Questo vantaggio, però, vale solo per accessi same-Region e same-AZ, condizione che non si verifica in uno scenario cross-Region.

Record risultanti:

Record risultanti nella nuova PHZ

Step 5: configurare il routing

VPC A: nella tabella di routing della subnet in cui gira l'istanza EC2, aggiungere una regola che instradi il traffico diretto al blocco CIDR della VPC B attraverso la peering connection
VPC B: nella route table della/e subnet in cui è stato collocato il VPC Interface Endpoint, aggiungere una regola che instradi il traffico diretto al blocco CIDR della VPC A attraverso la stessa peering connection

Step 6: abilitare l'accesso S3 regionale per il DNS locale

Si può ottenere questo risultato con uno dei seguenti metodi:

Un Internet Gateway o un NAT Gateway per l'accesso a Internet
Un S3 Gateway Endpoint nella VPC A (consigliato per i costi)
Un S3 VPC Interface Endpoint nella VPC A con DNS privato abilitato

L'approccio consigliato è quello di disporre di un S3 Gateway Endpoint in ciascuna VPC/regione in cui occorre accedere a S3, dato che è gratuito — sia come tariffa oraria sia come elaborazione del traffico — a differenza delle alternative.

Configurazione dell'AWS SDK per l'accesso S3 cross-region

Opzione 1: specificare gli endpoint regionali

Esempio per JavaScript SDK V2:

Opzione 2: abilitare l'accesso cross-region

JavaScript SDK v3: impostare followRegionRedirects: true nella configurazione del client S3 [8]

Esempio JavaScript SDK v3:

Nota: con il Java SDK V2 la prima richiesta verso un bucket in una regione diversa può presentare una latenza più elevata, ma le richieste successive beneficiano delle informazioni sulla regione memorizzate in cache.

Lo stesso non vale per il JavaScript SDK V3, che non memorizza in cache le informazioni sulla regione: ogni richiesta cross-region può quindi subire la latenza del redirect. Per ottenere prestazioni migliori con pattern di accesso cross-region noti, conviene specificare direttamente l'URL esatto dell'endpoint regionale.

L'AWS CLI sa gestire questi redirect in automatico e non ha bisogno della regione né dell'URL endpoint per un bucket, a patto di aver seguito lo step 6 sopra.

Come funziona il tutto

L'istanza interroga il proprio servizio S3 regionale per determinare la posizione del bucket
Una volta accertato che il bucket si trova in us-east-1, interroga un DNS per ottenerne gli IP in us-east-1
La Private Hosted Zone intercetta questa query DNS e la risolve nell'IP privato dell'S3 Interface Endpoint nella VPC B
L'IP privato dell'S3 Interface Endpoint viene restituito all'EC2
La regola aggiunta alla tabella di routing della subnet EC2 nella VPC A instrada il traffico verso quegli IP privati attraverso la VPC peering connection fino alla VPC B e, da lì, all'S3 VPC Interface Endpoint
L'endpoint fornisce un accesso sicuro e privato ai bucket S3 in us-east-1

Qualsiasi risposta da S3 (ad esempio quando si richiede un oggetto) percorrerà a ritroso la VPC Peering connection fino all'istanza EC2 nella VPC A.

Diagramma architetturale concettuale

Perché questo approccio funziona

Sfrutta il VPC peering per creare connettività cross-region
Usa la risoluzione DNS della PHZ privata per ottenere l'IP privato dell'endpoint S3 regionale corretto
Mantiene la sicurezza tramite VPC endpoint anziché instradamento su Internet
Nessuna modifica alle app client — le applicazioni non richiedono alcun intervento (non serve aggiungere una regione o un URL endpoint) e possono usare semplicemente il nome del bucket

Aspetti da tenere a mente

Impatto sulla latenza: il traffico cross-region avrà una latenza più alta rispetto all'accesso same-region. Se le prestazioni sono critiche, valutare in alternativa strategie di replica del bucket [6].

Trade-off di complessità: questa configurazione introduce complessità architetturale. Verificare se i vantaggi (costi e sicurezza intra-VPC) giustificano il maggiore carico operativo.

Invito all'azione

Riferimenti

Avete già implementato connettività VPC cross-region nel vostro ambiente AWS? Mi farebbe piacere conoscere le vostre esperienze e le eventuali varianti di questo approccio che avete sperimentato.