Um cliente nosso tentou ativar recentemente o S3 Transfer Acceleration, serviço criado para acelerar as transferências de dados de e para o Amazon Simple Storage Service (S3) em um bucket S3, e se deparou com um erro inesperado (Access Denied).
De início, achamos que fosse um problema de permissões do IAM, de Service Control Policy ou de bucket policy do S3, então fomos investigar esses pontos.
Ao começar a investigação, descobrimos que:
- Não havia nenhuma SCP de negação associada à conta, exceto a SCP Full AWS Access, que libera o acesso.
- Nenhuma bucket policy estava associada ao bucket S3. Ou seja, não havia nenhuma instrução de negação explícita no nível do bucket.
- A nomenclatura do bucket estava em conformidade com o exigido pelo S3 Transfer Acceleration.
- O usuário tinha privilégios de admin no IAM. Também testamos com o usuário root da conta AWS, mas o root recebeu a mesma mensagem de erro.
- O Amazon S3 Transfer Acceleration tinha suporte nas regiões do bucket.
Uma busca rápida no Google mostrou que o mesmo erro já tinha sido relatado em vários fóruns, mas sem nenhuma solução publicada.
Por sorte, conseguimos reproduzir o problema em algumas das nossas contas AWS pessoais. Fomos mais a fundo, mas mesmo assim não achamos a causa do erro. O que descobrimos foi:
- O erro era mais frequente em contas criadas via AWS Organizations.
- Não havia correlação específica com o tempo de existência das contas.
- Nada no AWS CloudTrail indicava a causa do erro.
- Também tentamos sair da AWS Organization e tornar a conta independente, mas precisamos de mais.
Indo mais a fundo na documentação da AWS, descobrimos que o Amazon S3 Transfer Acceleration tira proveito dos edge locations distribuídos globalmente do Amazon CloudFront.
Tentamos então criar uma nova distribuição do CloudFront, mas ela falhou com o erro abaixo.
A essa altura, quase desistimos achando que a única saída seria fazer upgrade do nosso AWS Support Plan. Só que, na era da otimização de custos, queríamos evitar qualquer despesa extra.
Foi aí que surgiu a hipótese de que isso poderia estar ligado ao Security Score da conta AWS (uma das vantagens de já ter trabalhado na AWS ;), e resolvemos testar.
Subimos algumas instâncias EC2 na região N. Virginia (us-east-1) — uma t2.micro já basta — e as deixamos rodando por 2 a 3 horas, até receber um e-mail parecido com o abaixo.
Assim que esse e-mail do screenshot acima chegou, tentamos ativar o Transfer Acceleration de novo — e funcionou!
A conclusão, portanto, é que a conta precisa ser verificada explicitamente na região N. Virginia (us-east-1) antes de você conseguir usar o Amazon S3 Transfer Acceleration. Não importa se já foi verificada em outra região.
A AWS pode melhorar a documentação e a mensagem de erro para deixar mais claro para o usuário o porquê desse comportamento, evitando que ele precise pagar pelo AWS Support sem necessidade.
Este post foi escrito em parceria com meu colega e guru de segurança
.
Senior Cloud Architect na DoiT International
Autor
Glad it helped you, i will add the error to the text .
--
Responder
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!!
--
Responder
por
[Configurando autenticação SAML para fazer streaming do Amazon Workspaces usando Auth0 como provedor de identidade.\ \
23 de nov. de 2023
por
[Construindo arquitetura AWS com MCP Servers e Strands Agents\ \
22 de set. de 2025
por
[Fingerprints JA3 e JA4 no AWS WAF e além\ \
10 de abr. de 2025
[AWS VPN Concentrators: simplificando a conectividade híbrida em larga escala\ \
22 de jan.
por
[Guia completo de redirecionamento de URL com AWS CloudFront, S3 e Route53\ \
1º de out. de 2025
[Migrando do Serverless Framework para o AWS SAM\ \
7 de out. de 2025
[S3\ \
4 de out. de 2025
[AWS S3 Bucket\ \
19 de dez. de 2025
[Aplicação web com EC2, S3, CloudFront e RDS\