Accesso ai bucket S3 tra regioni AWS con (e senza! nov 2025) VPC Peering

Il 19 novembre 2025 AWS ha annunciato: "AWS PrivateLink now supports cross-region connectivity for AWS Services" [1].

Significa che non serve più passare per tutta la trafila di VPC Peering e Private Hosted Zone descritta in questo articolo. Ora il processo è molto più diretto (e semplice!).

Per la spiegazione completa, rimando al blog post di AWS [2].

Se vuole comunque vedere come si faceva prima, oppure approfondire le Private Hosted Zone per i servizi AWS, allora read on, Macduff (sì, lo so, la citazione corretta è "Lay on, Macduff"…)

AWS ci dice che, per usare un bucket S3 in un'altra regione (ad esempio un'istanza EC2 in us-west-2 che deve accedere a un bucket S3 in us-east-1), abbiamo a disposizione diverse opzioni [3]. Quella di cui mi occupo qui è "VPC interface endpoint (VPCE) con VPC peering".

Quello che AWS non ci dice è che questa soluzione non funziona senza una piccola aggiunta di connettività verso S3 nella regione in cui il bucket non si trova (nel mio esempio, us-west-2). Ne parlerò più avanti, al passo 6 dell'implementazione.

Un'istanza EC2 in esecuzione in us-west-2 deve accedere ai dati di un bucket S3 collocato in us-east-1. Il primo istinto potrebbe essere quello di creare un S3 Gateway Endpoint nella propria VPC, ma c'è un problema: gli S3 Gateway Endpoint non offrono accesso cross-region. (Nemmeno gli S3 VPC Interface Endpoint lo fanno per impostazione predefinita, ma sono proprio questi che useremo per risolvere il problema.)

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

La soluzione consiste nel costruire un ponte tra le regioni sfruttando il VPC peering e la risoluzione DNS per instradare il traffico in modo corretto. Ecco cosa andremo a costruire:

Componenti:

• VPC A: la VPC esistente in us-west-2, dove risiede l'istanza EC2
• VPC B: una VPC nuova o esistente in us-east-1 dove collocheremo il nostro 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 una Elastic Network Interface (ENI) in una VPC di destinazione, che fornisce connettività privata e sicura a S3 attraverso la backbone network di AWS (nel nostro caso in us-east-1)

Prerequisiti

Prima di iniziare, verifichi che le VPC non abbiano blocchi CIDR sovrapposti: AWS non consente il peering tra VPC con intervalli IP in conflitto. Si presuppone inoltre che l'istanza EC2 disponga di un instance role adeguato che le conceda i permessi per interagire con S3.

Passo 1: protegga il suo S3 Endpoint

Crei un security group nella VPC B (chiamiamolo VPC_B_S3_SG) che permetta il traffico HTTPS sulla porta 443 dal CIDR range della VPC A. Questo security group proteggerà l'S3 Interface Endpoint lasciando passare solo il traffico desiderato. Se in seguito si rendesse necessario consentire all'Interface Endpoint di ricevere traffico da altre VPC o blocchi CIDR, potrà sempre aggiungerli al SG.

Passo 2: crei l'S3 VPC Interface Endpoint

Nella VPC B (us-east-1), crei un S3 VPC Interface Endpoint con queste impostazioni specifiche [4]:

• Disabiliti il DNS privato
• Associ il security group VPC_B_S3_SG creato in precedenza

Passo 3: stabilisca il VPC Peering

Crei una VPC peering connection tra la VPC A e la VPC B. In questo modo viene creato un ponte di rete che permette al traffico di fluire tra le regioni [5].

Passo 4: configuri la risoluzione DNS con la PHZ

In Route53, crei una Private Hosted Zone (PHZ) per il dominio s3.us-east-1.amazonaws.com e la associ alla VPC A in us-west-2. Ripeta l'associazione con le altre VPC, nella stessa o in altre regioni, per cui prevede il peering verso us-east-1, così da consentire al traffico di raggiungere l'S3 VPC Interface Endpoint di us-east-1.

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

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

1. Record radice: lasci vuoto il nome del record per creare un record per

s3.us-east-1.amazonaws.com

Record radice: lasci vuoto il campo Record name

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

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

Catch All: inserisca "*" nel campo Record name

\* Un Regional DNS name è il nome senza la specifica della availability zone.

Si presenta così:

*.vpce-0123456789abcdefg-dawd972fe.s3.us-east-1.vpce.amazonaws.com e non come us-east-1a (che è invece un Zonal DNS name).

Lo Zonal DNS name è utile nelle architetture che isolano i workloads per Availability Zone. Ad esempio, può aiutare a contenere i costi di trasferimento dati regionali, garantendo che il traffico resti all'interno della stessa AZ e regione dell'ENI dell'Interface Endpoint. Il vantaggio, però, vale solo per l'accesso nella stessa regione e nella stessa AZ, e quindi non si applica in uno scenario cross-region.

Record risultanti:

Record risultanti nella nuova PHZ

Passo 5: configuri il routing

Aggiorni le tabelle di routing per consentire al traffico di fluire tra le VPC:

• VPC A: nella tabella di routing della subnet in cui è in esecuzione l'istanza EC2, aggiunga una regola che instradi il traffico verso il blocco CIDR della VPC B attraverso la peering connection
• VPC B: nella tabella di routing della/e subnet in cui ha collocato il VPC Interface Endpoint, aggiunga una regola che instradi il traffico verso il blocco CIDR della VPC A attraverso la stessa peering connection

Passo 6: abiliti l'accesso regionale a S3 per il DNS locale

Ecco un passaggio fondamentale che spesso viene trascurato: l'istanza EC2 nella VPC A deve poter raggiungere il proprio S3 endpoint regionale (s3.us-west-2.amazonaws.com) per determinare a quale regione appartiene un bucket. Senza questo, dovrà aggiungere "--region " ogni volta che accede a bucket residenti nella regione us-east-1.

Lo si può ottenere 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 ragioni di costo)
• Un S3 VPC Interface Endpoint nella VPC A con DNS privato abilitato

L'approccio consigliato è dotarsi di un S3 Gateway Endpoint in ogni VPC/regione in cui occorre accedere a S3, dato che è gratuito sia in termini di tariffa oraria sia di traffico elaborato, a differenza delle alternative.

Quando si accede a bucket S3 tra regioni diverse tramite VPC peering, configuri l'AWS SDK in modo che gestisca correttamente le richieste cross-region:

Opzione 1: specificare gli endpoint regionali

Definisca l'URL endpoint regionale specifico (ad esempio s3.us-east-1.amazonaws.com) per la regione del bucket di destinazione.

Esempio per JavaScript SDK V2:

const AWS = require('aws-sdk');

const s3 = new AWS.S3({
  endpoint: 's3.us-east-1.amazonaws.com'
});

Opzione 2: abilitare l'accesso cross-region

• Java SDK v2: usi crossRegionAccessEnabled(true) nel proprio S3 client builder [9]
• JavaScript SDK v3: imposti followRegionRedirects: true nella configurazione del proprio S3 client [10]

Esempio JavaScript SDK v3:

const { S3Client } = require('@aws-sdk/client-s3');

const s3Client = new S3Client({
});

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

Lo stesso non vale per il JavaScript SDK V3, che non mette in cache le informazioni di regione: ogni richiesta cross-region può subire la latenza dovuta al redirect. Se conosce in anticipo i pattern di accesso cross-region, per ottenere prestazioni migliori conviene specificare direttamente l'URL endpoint regionale esatto.

L'AWS CLI gestisce automaticamente questi redirect e non richiede né la regione del bucket né l'URL dell'endpoint, sempre a patto che abbia seguito il passo 6 sopra.

Quando l'istanza EC2 prova ad accedere a un bucket in us-east-1, il flusso è questo:

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

Qualsiasi risposta da S3 (ad esempio se ha richiesto un oggetto) tornerà tramite la VPC Peering connection all'istanza EC2 nella VPC A.

Diagramma architetturale concettuale

Questa soluzione aggira con eleganza i limiti regionali di AWS:

• Sfrutta il VPC peering per creare connettività cross-region
• Utilizza la risoluzione DNS della PHZ privata per ottenere l'IP privato dell'S3 endpoint regionale corretto
• Mantiene la sicurezza tramite VPC endpoint, evitando di passare per internet
• Non richiede modifiche alle applicazioni client: le applicazioni non necessitano di alcuna modifica (non serve indicare regione o URL endpoint) e possono semplicemente usare il nome del bucket

Considerazioni sui costi: il VPC peering comporta costi di trasferimento dati [6], mentre gli Interface Endpoint comportano un addebito orario più i costi di elaborazione dati [7]. Tenga conto di questi aspetti nelle decisioni architetturali.

Impatto sulla latenza: il traffico cross-region avrà una latenza più alta rispetto all'accesso nella stessa regione. Se le prestazioni sono critiche, valuti piuttosto strategie di replica dei bucket [8].

Trade-off in termini di complessità: questa configurazione aggiunge complessità architetturale. Valuti se i benefici (costi e sicurezza intra-VPC) giustifichino l'overhead operativo aggiuntivo.

Mi auguro che questo articolo le abbia offerto spunti utili. Se desidera saperne di più o è interessato ai nostri servizi, non esiti a contattarci. Può farlo qui.

1. https://aws.amazon.com/about-aws/whats-new/2025/11/aws-privatelink-cross-region-connectivity-aws-services/
2. https://aws.amazon.com/blogs/networking-and-content-delivery/aws-privatelink-extends-cross-region-connectivity-to-aws-services/
3. https://repost.aws/articles/ARjzluyMS8RbeOOK4MGXRG6Q/cost-effective-methods-for-accessing-s3-buckets-cross-region
4. https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws
5. https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html
6. https://aws.amazon.com/vpc/pricing/
7. https://aws.amazon.com/privatelink/pricing/
8. https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
9. https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/s3-cross-region.html
10. https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-middleware-sdk-s3/Interface/S3InputConfig/
11. What is VPC Peering
12. Gateway endpoints for Amazon S3
13. Working with Private Hosted Zones