Un nostro cliente ha provato di recente ad attivare S3 Transfer Acceleration, il servizio pensato per accelerare i trasferimenti di dati da e verso Amazon Simple Storage Service (S3) su un bucket S3, imbattendosi in un errore inatteso (Access Denied).
All'inizio abbiamo ipotizzato un problema di permessi IAM, di Service Control Policy o di policy del bucket S3, e abbiamo iniziato a verificare proprio questi aspetti.
Dalle prime analisi è emerso che:
- All'account non era associata alcuna SCP di tipo deny, fatta eccezione per la Full AWS access SCP, che invece consente l'accesso.
- Al bucket S3 non era associata alcuna policy: nessuna istruzione di deny esplicita a livello di bucket.
- La nomenclatura del bucket era conforme ai requisiti di S3 Transfer Acceleration.
- L'utente disponeva di privilegi IAM admin. Abbiamo provato anche con l'utente root dell'account AWS, ma anche al root l'accesso veniva negato con lo stesso messaggio di errore.
- Amazon S3 Transfer Acceleration risultava supportato nella regione del bucket S3.
Una rapida ricerca su Google ha rivelato che lo stesso errore era già stato segnalato in diversi forum, ma senza alcuna soluzione pubblicata.
Per fortuna siamo riusciti a riprodurre il problema su alcuni nostri account AWS personali e abbiamo potuto approfondire, senza però individuare la causa dell'errore. Quello che abbiamo notato è:
- L'errore era più ricorrente sugli account creati tramite AWS Organizations.
- Non emergeva alcuna correlazione specifica con l'anzianità degli account.
- In AWS CloudTrail non c'era alcuna traccia utile a spiegare l'origine dell'errore.
- Abbiamo provato anche a uscire dall'AWS Organization e a rendere l'account stand-alone, ma non è bastato.
Approfondendo la documentazione AWS, abbiamo scoperto che Amazon S3 Transfer Acceleration sfrutta le edge location distribuite a livello globale di Amazon CloudFront.
Abbiamo quindi provato a creare una nuova distribuzione CloudFront, ma l'operazione è fallita con l'errore mostrato qui sotto.
A quel punto eravamo quasi sul punto di mollare, convinti che l'unica via fosse fare l'upgrade del nostro AWS Support Plan; ma in piena era di cost optimization volevamo a tutti i costi evitare spese aggiuntive.
Ci è venuta allora un'intuizione: il problema poteva essere legato al Security Score dell'account AWS (qualche vantaggio nell'aver lavorato in AWS si vede ancora ;), e così abbiamo deciso di fare una prova.
Abbiamo avviato un paio di istanze EC2 nella regione N. Virginia (us-east-1) — un t2.micro va più che bene — lasciandole in esecuzione per 2-3 ore, finché non abbiamo ricevuto un'email come quella qui sotto.
Ricevuta l'email mostrata nello screenshot, abbiamo riprovato ad attivare Transfer Acceleration: ha funzionato!
La conclusione è quindi che l'account deve essere esplicitamente verificato nella regione N. Virginia (us-east-1) prima di poter utilizzare Amazon S3 Transfer Acceleration. Non conta se è già stato verificato in un'altra regione.
AWS dovrebbe migliorare la documentazione e il messaggio di errore, in modo che gli utenti capiscano subito il motivo del blocco senza dover pagare inutilmente per AWS Support.
Questo articolo è stato scritto a quattro mani con il mio collega e guru della security
.
Senior Cloud Architect in DoiT International
Autore
Glad it helped you, i will add the error to the text .
--
Rispondi
Wish google indexed this page. Can you add the error in the page as text so people can find this?
Thanks for saving the day!!
--
Rispondi
di
[Configurare l'autenticazione SAML per Amazon Workspaces con Auth0 come identity provider.\ \
23 nov 2023
di
[Costruire architetture AWS con MCP Server e Strands Agents\ \
22 set 2025
di
[Fingerprint JA3 e JA4 in AWS WAF e oltre\ \
10 apr 2025
[AWS VPN Concentrator: connettività ibrida su larga scala, semplificata\ \
22 gen
di
[Guida completa al redirect di URL con AWS CloudFront, S3 e Route53\ \
1 ott 2025
[Migrare da Serverless Framework a AWS SAM\ \
7 ott 2025
[S3\ \
4 ott 2025
[AWS S3 Bucket\ \
19 dic 2025
[Applicazione web con EC2, S3, CloudFront e RDS\