S3 não é só uma pasta gigante na internet

Tratar o S3 como uma pasta gigante na internet funciona bem o suficiente para justificar um upload de imagem e seguir em frente. O problema é que o serviço resolve uma quantidade de coisa bem maior do que isso, e parte dela só aparece quando o uso deixa de ser básico.

Bucket, key e object: o vocabulário mínimo

Um bucket é o contêiner de nível mais alto no S3, com nome globalmente único dentro da AWS. Dentro dele, cada arquivo armazenado é um object, identificado por uma key, que é essencialmente o caminho completo daquele objeto dentro do bucket. Não existe uma estrutura real de pastas por trás disso: o que parece uma pasta é, na prática, apenas um prefixo comum entre keys, exibido de forma hierárquica pela interface e pelas ferramentas, sem existir como diretório de fato dentro do armazenamento.

Presigned URLs: acesso temporário sem expor credencial

Uma presigned URL é uma URL gerada com uma assinatura temporária, que concede acesso limitado a uma ação específica (normalmente GetObject ou PutObject) sobre um objeto específico, por um tempo determinado, sem que quem recebe essa URL precise ter credencial nenhuma da AWS.

Isso resolve um problema comum: permitir que um cliente (navegador, aplicativo móvel) faça upload direto para o S3, sem que a aplicação backend precise atuar como intermediária carregando o arquivo inteiro, e sem expor nenhuma credencial da AWS no lado do cliente.

var request = new GetPreSignedUrlRequest
{
    BucketName = "meu-bucket",
    Key = "uploads/documento.pdf",
    Verb = HttpVerb.PUT,
    Expires = DateTime.UtcNow.AddMinutes(15)
};

string url = s3Client.GetPreSignedURL(request);

Essa URL, válida por 15 minutos nesse exemplo, permite que quem a receber execute exatamente aquele upload, para aquela key específica, dentro da janela de tempo definida.

Storage classes: nem todo dado precisa do mesmo custo

O S3 oferece diferentes classes de armazenamento, com trade-off entre custo e latência de acesso. S3 Standard é a classe padrão, para dado acessado com frequência. S3 Standard-IA (Infrequent Access) reduz custo de armazenamento em troca de custo de recuperação quando o dado é de fato acessado, adequado para dado acessado raramente mas que ainda precisa de acesso rápido quando necessário. Nas classes de arquivamento (a família Glacier), o custo de armazenamento cai bastante, em troca de tempo de recuperação maior, variando conforme a classe específica escolhida.

Escolher a classe errada não é erro fatal, mas costuma significar pagar mais por armazenamento que não precisava daquele nível de disponibilidade, ou aceitar latência de recuperação inadequada para o uso real do dado.

Lifecycle policies: mover e expirar dado sem intervenção manual

Uma lifecycle policy automatiza duas coisas: transição de um objeto entre storage classes conforme ele envelhece, e expiração (exclusão automática) depois de um período definido. Um exemplo comum é mover log para uma classe mais barata depois de um tempo, e excluí-lo definitivamente depois de um período maior, sem que ninguém precise rodar esse processo manualmente.

Isso importa especialmente para dado que perde relevância com o tempo, como log, backup temporário ou artefato de build, onde manter tudo indefinidamente na classe mais cara não traz benefício real.

Controle de acesso: IAM Policy, Bucket Policy e a diferença entre elas

Existem duas formas principais de controlar quem pode acessar o quê num bucket. Uma IAM Policy é anexada a um usuário, papel (role) ou grupo, e define o que aquela identidade pode fazer, independentemente do recurso. Uma Bucket Policy é anexada diretamente ao bucket, e define quem, inclusive identidade de outra conta AWS, pode acessar aquele bucket específico, funcionando como política baseada em recurso em vez de baseada em identidade.

As duas podem coexistir, e a AWS avalia ambas: acesso só é permitido quando não existe negação explícita em nenhuma das duas e existe permissão explícita em pelo menos uma delas aplicável ao caso.

Além de guardar arquivo

Nenhum desses recursos aparece na primeira vez que alguém sobe uma imagem para um bucket e configura acesso público básico. Eles aparecem quando o uso amadurece: quando segurança de upload direto do cliente importa, quando custo de armazenamento em escala começa a doer, ou quando dado antigo precisa sair de circulação sem alguém lembrando de apagar manualmente. Tratar o S3 só como pasta de arquivo esconde a maior parte do que o serviço realmente resolve.