AWS SDK for Java 2.x passa a baixar objetos do S3 via URL pré-assinada nativamente

O que mudou

O AWS SDK for Java 2.x ganhou a capacidade de consumir uma URL pré-assinada do Amazon S3 direto pelo pipeline do próprio SDK, a partir da versão 2.48.0. Até então, o S3Presigner só sabia gerar a URL; para baixar o objeto com ela, o desenvolvedor precisava cair para um cliente HTTP de baixo nível (OkHttp, Apache HttpClient, o que estivesse à mão), perdendo retries automáticos, métricas e validação de checksum embutidos no SDK.

Agora isso acontece pelo S3AsyncClient.presignedUrlExtension() e também pelo S3 Transfer Manager. A diferença central: ao usar esse ponto de entrada, o SDK não assina a requisição de novo, só a envia; a autenticação já está na própria URL. É a situação clássica de quem serve mídia: um backend com credenciais AWS assina a URL e devolve para o cliente (app mobile, player de vídeo, frontend), que baixa o objeto do S3 sem jamais ter uma credencial própria.

S3AsyncClient s3AsyncClient = S3AsyncClient.create();

PresignedUrlDownloadRequest request = PresignedUrlDownloadRequest.builder()
 .presignedUrl(presignedUrl)
 .build();

CompletableFuture<GetObjectResponse> future =
 s3AsyncClient.presignedUrlExtension()
 .getObject(request, Paths.get("/tmp/my-object"));

O SDK também cobre o caso de objeto grande: com multipartEnabled(true) no cliente, o mesmo getObject() passa a dividir o download em partes com range e buscá-las em paralelo, sem o desenvolvedor escrever lógica de range manualmente. Por padrão, isso entra em ação para objetos acima de 8 MB.

Onde está disponível

A fonte não fala em regiões porque este é um recurso do cliente (biblioteca), não de infraestrutura: funciona contra qualquer bucket do Amazon S3, em qualquer região, incluindo São Paulo (sa-east-1), já que a URL pré-assinada carrega sua própria autenticação independentemente de onde o bucket mora.

Há um detalhe de assinatura que vale registrar: o post recomenda sempre Signature Version 4 (SigV4), que é o padrão do S3Presigner do Java e dos SDKs modernos. SigV2 está depreciada e só é aceita em regiões lançadas antes de 2014 (sa-east-1, lançada em 2011, é uma delas), mas os recursos de checksum descritos aqui exigem SigV4 de qualquer forma, então não há motivo prático para usar a versão antiga.

Quanto custa

O post não traz tabela de preço porque não é um serviço novo cobrado à parte: é mudança no SDK, que é open source e gratuito. Baixar um objeto via URL pré-assinada continua sendo, para efeito de cobrança, uma requisição GetObject normal no Amazon S3, seguindo o modelo de preço já existente do serviço (por requisição e por GB transferido). A novidade aqui é operacional, não financeira.

Como começar

Para usar os novos métodos, é preciso subir o SDK para a versão 2.48.0 ou mais recente e adicionar o módulo certo no pom.xml:

<dependency>
 <groupId>software.amazon.awssdk</groupId>
 <artifactId>s3</artifactId>
</dependency>
<!-- Opcional: só para downloads gerenciados com o Transfer Manager -->
<dependency>
 <groupId>software.amazon.awssdk</groupId>
 <artifactId>s3-transfer-manager</artifactId>
</dependency>

O ponto de partida é sempre uma URL pré-assinada já existente, gerada em algum backend com presigner.presignGetObject(presignRequest).url(). A partir daí, há três caminhos, na ordem que o post sugere:

1. Download de requisição única via s3AsyncClient.presignedUrlExtension().getObject(request, destino) - cobre a maioria dos casos, sem configuração extra.
2. Download multipart ligando multipartEnabled(true) no S3AsyncClient - mesma chamada, mas o SDK fatia o objeto grande em partes paralelas.
3. Transfer Manager com downloadFileWithPresignedUrl(...), para quem quer acompanhar progresso com addTransferListener(LoggingTransferListener.create()). Atenção aqui: o S3TransferManager precisa ser construído sobre o cliente padrão baseado em Netty, não com S3TransferManager.create(), que usa o cliente CRT quando ele está no classpath.

Para validar integridade, ative checksumMode(ChecksumMode.ENABLED) no GetObjectRequest antes de gerar a URL. O SDK então envia automaticamente o header x-amz-checksum-mode e confere o checksum que o S3 devolver: do objeto inteiro em downloads de requisição única, e por parte em downloads multipart, quando o range da parte coincidir com os limites originais do upload (um objeto que não foi enviado em múltiplas partes não recebe checksum por parte).

O que muda para quem já usa

Quem já tinha montado um fallback manual com HTTP client para consumir presigned URL de S3 ganha um caminho para simplificar esse código ao subir para 2.48.0: a troca é remover a camada própria de retry e checksum e passar a confiar no presignedUrlExtension(). Vale testar a troca aos poucos, porque há duas limitações explícitas no anúncio.

A primeira é que o cliente baseado em CRT não é suportado: chamar a extensão nele lança UnsupportedOperationException, então o download por URL pré-assinada só funciona no S3AsyncClient padrão (Netty) e no Transfer Manager construído sobre ele. A segunda é que, ao contrário de um FileDownload comum do Transfer Manager, um PresignedFileDownload não pode ser pausado e retomado. Para quem precisa dessa resiliência em downloads muito longos, o fallback antigo ainda pode fazer sentido num caso específico; para o resto, a recomendação da própria AWS é migrar.

Fonte: AWS Developer Tools Blog