Amazon S3, S3 Tables e S3 Vectors chegam ao Marketplace da Vercel e ao v0

A AWS anunciou, no AWS News Blog, que o Amazon S3 passou a ser provisionado direto do Vercel Marketplace e do v0 by Vercel. Isso inclui não só o S3 "clássico" (general purpose buckets), mas também o S3 Tables (Apache Iceberg gerenciado) e o S3 Vectors (armazenamento vetorial para IA). Antes, colocar um bucket na frente de uma aplicação hospedada na Vercel significava abrir o console da AWS, criar a role, escrever a policy e configurar credenciais à mão. Agora esse caminho fica dentro do próprio fluxo de deploy.

A integração se junta às que já existiam para Amazon Aurora, Amazon DynamoDB e Amazon OpenSearch Serverless. Na prática, dá para montar um stack inteiro (banco relacional, NoSQL, busca, objeto, tabela analítica e vetor) dentro do Vercel, numa única conta AWS e numa única fatura. Para quem já roda tudo na Vercel e só queria um lugar para guardar upload de usuário ou embeddings de RAG, isso corta uma etapa inteira de setup manual.

Como fica o provisionamento

O fluxo é direto: no dashboard da Vercel, aba Storage, botão Create, escolher AWS, escolher o tipo de bucket (general purpose, Tables ou Vectors), escolher a região e criar. A AWS diz que o provisionamento leva segundos. Depois de conectar o bucket a um projeto, as variáveis de ambiente saem com os comandos de sempre:

vercel link
vercel env pull .env.local

Isso injeta AWS_REGION, AWS_ROLE_ARN, AWS_RESOURCE_ARN e um nome de bucket específico do tipo escolhido (S3_BUCKET_NAME, S3_TABLE_BUCKET_NAME ou S3_VECTOR_BUCKET_NAME). Não aparece AWS_ACCESS_KEY_ID nem AWS_SECRET_ACCESS_KEY em lugar nenhum, e isso é o ponto mais relevante da integração para quem trabalha com agente de código.

Nada de chave estática no .env

O erro mais comum de agente de código com AWS é exatamente esse: colar AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY direto no .env ou, pior, no código. Aqui o awsCredentialsProvider, importado de @vercel/functions/oidc, troca um token OIDC de curta duração por credenciais temporárias via AWS Security Token Service (STS), escopadas ao recurso específico daquele AWS_ROLE_ARN. Não tem chave fixa para vazar em commit nem para o agente reaproveitar em outro lugar sem querer.

Isso não dispensa checagem. A role criada automaticamente pela integração ainda é uma IAM role, com uma policy anexada, e vale abrir o console pelo menos uma vez para confirmar que ela está escopada ao AWS_RESOURCE_ARN do bucket e não tem Resource: "*" nem ações além do que a aplicação realmente usa (leitura e escrita no bucket, por exemplo, sem s3:DeleteBucket ou s3:PutBucketPolicy).

Três tipos de bucket, três workloads

A integração cobre casos bem diferentes, e o v0 já tenta adivinhar qual deles o prompt pede:

• S3 general purpose: armazenamento de objeto comum, para arquivo, imagem, vídeo e documento. A AWS promete 99,999999999% (11 noves) de durabilidade e 99,99% de disponibilidade por padrão.
• S3 Tables: tabelas Apache Iceberg totalmente gerenciadas, com manutenção e compactação automáticas, consultáveis por qualquer engine compatível com Iceberg REST Catalog, incluindo DuckDB.
• S3 Vectors: armazenamento vetorial para RAG e busca semântica, com redução de até 90% no custo de upload, armazenamento e consulta de vetores em relação a alternativas, segundo a AWS. Ele não gera embedding: isso continua sendo trabalho do seu modelo.

O exemplo mais comum: upload de arquivo

Para o general purpose bucket, o padrão é uma rota de API que recebe um FormData e sobe o arquivo com o SDK v3:

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { awsCredentialsProvider } from "@vercel/functions/oidc";

const s3 = new S3Client({
  region: process.env.AWS_REGION,
  credentials: awsCredentialsProvider({
    roleArn: process.env.AWS_ROLE_ARN,
  }),
});

export async function POST(request) {
  const formData = await request.formData();
  const file = formData.get("file");

  await s3.send(new PutObjectCommand({
    Bucket: process.env.S3_BUCKET_NAME,
    Key: file.name,
    Body: Buffer.from(await file.arrayBuffer()),
    ContentType: file.type,
  }));

  return Response.json({ success: true });
}

Para listar e ler os mesmos objetos, o material da AWS cita ListObjectsV2Command e GetObjectCommand usando o mesmo client. Vale notar que file.name como Key direto, sem sanitização, é outro ponto clássico de descuido de agente: dois uploads com o mesmo nome se sobrescrevem, e nome de arquivo controlado pelo usuário pode virar um Key com caminho inesperado.

Analytics com S3 Tables direto de uma função serverless

Para consulta analítica, o exemplo da AWS roda DuckDB dentro de uma Vercel Function, anexando o bucket de tabelas pelo AWS_RESOURCE_ARN como um catálogo Iceberg e rodando agregação SQL comum. O trecho carrega as extensões aws, httpfs e iceberg, cria um secret com as credenciais temporárias da sessão OIDC e faz ATTACH do bucket antes de consultar. Quem for reproduzir isso numa rota Next.js precisa adicionar @duckdb/node-api em serverExternalPackages, no next.config.mjs, para as bindings nativas não irem para o bundle.

Busca vetorial para RAG

Para S3 Vectors, o fluxo é gerar o embedding com o modelo de sua escolha e consultar o índice com QueryVectorsCommand, do pacote @aws-sdk/client-s3vectors, passando vectorBucketName, indexName e topK. É uma API simples, sem servidor de vetor separado para manter no ar, mas também sem os filtros e índices híbridos de um banco vetorial dedicado. Para um protótipo de busca semântica ou um bot que responde com base em PDF, é suficiente; para um caso de produção com filtro complexo por metadado, pode ficar curto.

O jeito v0 de pedir infraestrutura

No v0, a provisionamento sai de um prompt em linguagem natural. Pedir "a photo gallery where users upload images using AWS" gera um bucket general purpose; "a support bot that answers questions from my PDFs" gera S3 Vectors; "an analytics dashboard for my clickstream data" gera S3 Tables. O v0 configura a conexão e já entrega código funcional, o que reforça por que checar a IAM role gerada importa: o vibe coder aceita o diff sem necessariamente ler a policy.

Combinando com Aurora e DynamoDB

Como todo serviço AWS na Vercel compartilha a mesma conta e o mesmo modelo de autenticação, dá para misturar sem configuração extra: metadado de arquivo em Aurora com os arquivos em S3, ou texto de documento em DynamoDB com os embeddings em S3 Vectors para retrieval de RAG. É a composição mais natural para quem já usa essas outras integrações.

Conta nova ou conta existente: a pegadinha

Dá para criar uma conta AWS nova pelo próprio fluxo da Vercel, o que já libera os recursos de S3 para construir e testar, com $100 em créditos válidos por seis meses. Mas quem vincula uma conta AWS existente precisa saber de uma limitação: a Vercel só enxerga e gerencia buckets novos, criados através da própria plataforma. Buckets que já existiam na conta antes da integração ficam de fora do alcance dela.

Preço

Não há cobrança pela integração em si: o preço é o preço padrão do S3 pelos recursos consumidos, tudo na mesma fatura da conta AWS vinculada. A disponibilidade cobre v0 e Vercel Marketplace em todas as regiões comerciais da AWS que a Vercel já suporta; a lista exata de regiões não veio detalhada no anúncio, então vale conferir no próprio dashboard se sa-east-1 (São Paulo) está entre elas antes de assumir baixa latência para usuário no Brasil.

Quando vale e quando não

Para protótipo rápido, side project ou time pequeno sem infraestrutura dedicada, a integração corta etapa real de setup e tira a tentação de colar chave estática no código. Para quem já tem Terraform ou CDK consolidado, com múltiplas contas e processo de revisão de infraestrutura, provisionar bucket pelo clique da Vercel pode furar esse processo: o recurso nasce fora do pipeline de IaC e alguém vai precisar importá-lo depois, se quiser manter tudo versionado no mesmo lugar.

Fonte: AWS News Blog