Como criar seu primeiro bucket no Amazon S3 privado por padrão

Por que o primeiro bucket já nasce fechado

Toda vez que alguém cria um bucket do zero no Amazon S3, a primeira surpresa costuma ser positiva: por padrão, nada ali é público. As quatro configurações de Block Public Access vêm ligadas, o Object Ownership vem como Bucket owner enforced (ACLs desligadas) e a criptografia do lado do servidor (SSE-S3) já cobre todo objeto novo sem você configurar nada. Isso significa que, se você não mexer em nenhum controle avançado, o bucket que vai sair desse tutorial já nasce seguro o suficiente para guardar dado sensível, incluindo a primeira zona de pouso (landing zone) de um pipeline de analytics.

Esse é o roteiro que eu seguiria para criar, popular, organizar e depois limpar um bucket de testes, tanto pelo console quanto pela AWS CLI. Vale tanto para quem está estudando para a certificação quanto para quem só precisa de um lugar para guardar o CSV de amostra antes de apontar o Glue ou o Athena para ele.

Pré-requisitos

• Conta AWS ativa (a inscrição já habilita o S3 automaticamente, sem custo de ativação).
• Acesso ao console em https://console.aws.amazon.com/s3/, ou AWS CLI instalada e configurada com aws configure (credenciais de um usuário IAM com permissão de S3).
• Permissão mínima de s3:CreateBucket para criar com as configurações padrão. Para mexer em ACLs, Block Public Access ou versionamento, você também precisa de s3:PutBucketOwnershipControls, s3:PutBucketPublicAccessBlock e s3:PutBucketVersioning, respectivamente.
• Nenhum custo para criar o bucket. Você paga por armazenamento e por transferência de dado; seguindo este tutorial à risca, a cobrança fica abaixo de US$ 1, segundo a própria documentação da AWS.

Passo 1: criando o bucket

Antes de clicar em qualquer botão, escolha a região. Depois de criado, o bucket não muda de região nem de nome, então errar aqui custa recriar tudo. Para workload no Brasil, a escolha natural é sa-east-1 (São Paulo), que reduz latência e evita transferência entre regiões.

Pelo console:

1. Em https://console.aws.amazon.com/s3/, troque a região no topo para São Paulo.
2. No menu lateral, escolha General purpose buckets e depois Create bucket.
3. Em Bucket name, digite um nome exclusivo dentro da partição aws (a mesma partição vale para todas as contas comerciais do mundo, não só a sua).
4. Deixe o restante nas opções padrão e escolha Create bucket.

O nome do bucket segue regras fixas, e boa parte dos erros de "já existe" vem delas:

• entre 3 e 63 caracteres;
• só letras minúsculas, números, pontos (.) e hifens (-);
• começa e termina em letra ou número;
• único em toda a partição aws, não só na sua conta.

A documentação recomenda evitar ponto no nome, exceto quando o bucket serve para hospedagem estática.

Pela CLI, o mesmo bucket sai em uma linha:

aws s3 mb s3://meu-bucket-exemplo-2026 --region sa-east-1

O que fica pré-marcado (e por que eu deixaria assim)

Se escolher SSE-KMS ou DSSE-KMS, fique de olho na cota de requisições por segundo (RPS) do AWS KMS: cada leitura e escrita criptografada chama o KMS, e tráfego alto pode esbarrar na cota. O console já vem com S3 Bucket Keys ligado por padrão nesse caso, o que reduz essa chamada e o custo de KMS.

Tropeço: nome repetido e o ponto que some

Na prática, o erro mais comum nesse primeiro passo é BucketAlreadyExists: como o nome precisa ser único em toda a partição aws, alguém no mundo já pode ter pego o nome óbvio que você escolheu. A saída de sempre é incluir um sufixo com data, ambiente ou um hash curto no nome.

Outro tropeço menor aparece só na hora de baixar objeto pelo console: se a chave do objeto termina em ponto (.), o console remove esse ponto do nome do arquivo baixado. Para preservar o ponto final, é preciso usar a AWS CLI, um SDK ou a API REST, não o console.

Passo 2: subindo o primeiro objeto

Com o bucket criado, suba um arquivo de teste. Pelo console: entre no bucket, aba Objects, escolha Upload, depois Add files, selecione o arquivo e confirme em Upload.

Se o objetivo é alimentar um pipeline de dados, já vale subir direto num prefixo organizado, como se fosse uma pasta de landing zone:

aws s3 cp dados-vendas.csv s3://meu-bucket-exemplo-2026/landing/dados-vendas.csv

Esse prefixo landing/ não é uma pasta de verdade (o S3 não tem hierarquia real de diretórios), é só parte da chave do objeto. Mas o console e a CLI tratam prefixo como pasta, e isso já basta para organizar um bucket que vai alimentar um Glue Crawler ou uma consulta no Athena depois.

Passo 3: baixando e copiando entre pastas

Para baixar, selecione o objeto na lista e escolha Download, ou, pela CLI:

aws s3 cp s3://meu-bucket-exemplo-2026/landing/dados-vendas.csv ./dados-vendas.csv

Se o bucket tem versionamento ligado, o console mostra um botão Show versions ao lado da busca; marque a versão específica antes de baixar, senão você sempre pega a mais recente.

Para copiar um objeto para outro prefixo pelo console, use Create folder (dá pra desligar a criptografia específica da pasta, já que ela herda a do bucket), marque o objeto de origem, escolha Copy em Actions, aponte o destino em Browse S3 e confirme. Pela CLI, copiar é só repetir o cp com a chave de destino.

Passo 4: limpando para não pagar à toa

Criar bucket é grátis; o que gera custo é o que fica dentro dele e o tráfego de saída. Terminou o teste? Apague os objetos e depois o bucket:

aws s3 rm s3://meu-bucket-exemplo-2026/landing/dados-vendas.csv
aws s3 rb s3://meu-bucket-exemplo-2026

Dois detalhes importam aqui. Primeiro: o bucket precisa estar vazio para ser apagado, então aws s3 rb sozinho falha se ainda houver objeto dentro (use --force para esvaziar e apagar numa tacada, com cautela). Segundo: depois de apagado, o nome do bucket volta a ficar disponível para qualquer conta no mundo, inclusive a sua. Se pretende reaproveitar o nome, é mais seguro só esvaziar o bucket e manter ele existindo até decidir de vez.

O que olhar depois que o bucket está de pé

Esse roteiro cobre o básico que a própria AWS chama de getting started, e ele já entrega um bucket privado, criptografado e pronto para receber dado real. O que fica de fora, e vale investigar na sequência, é bucket policy (controle fino de quem acessa o quê), lifecycle rules (para mover objeto frio para uma classe mais barata) e replicação entre regiões. Nenhum desses três vem configurado neste primeiro bucket, e é normal que não venham: a ideia aqui era sair do zero com algo funcional e seguro, não entregar a arquitetura de produção pronta.

Fonte: Documentação do Amazon S3 — Getting started