Amazon S3: Compreendendo de forma rápida

O Amazon S3 (Simple Storage Service ) é um serviço de armazenamento em nuvem da AWS que permite armazenar, protegar e recuperar qualquer quantidade de dados (imagens, PDFs, vídeos, etc.) a qualquer momento, de forma escalável e segura.

Buckets

Um Bucket é o container principal de armazenamento no Amazon S3, todo arquivo (objeto) precisa estar dentro de um bucket. Funciona como uma pasta raiz, onde fica os dados e suas permissões.

Caraterísticas Principais: Bucket

Cada bucket tem um nome único em toda a AWS ( não pode repetir )

Ao criar o bucket, você escolhe em qual região da AWS os dados ficarão armazenados

Objetos são os arquivos armazenados dentro do bucket, cada objeto tem:

Key (chave): nome e caminho (e.x: imagens/perfil-img.png)
Value: o conteúdo do arquivo
Metadata: informações extras (ex: tipo do arquivo)

Cada objeto tem uma URL única, ex:

<https://nome-do-bucket.s3.amazonaws.com/imagens/perfil-img.png>

Você pode controlar o acesso dos objetos pelo Bucket Policies, ACLs (Access Control List) e IAM, assim pode definir quem pode ler, gravar, excluir ou listar arquivos.

O versionamento pode ser ativado para guardar todas as versões de um arquivo, isso ajuda a recuperar dados apagados ou substituidos.

As seguintes criptografias (SSE-S3, SSE-KMS, SSE-C) podem ser ativadas para proteger os dados em repouso (no S3).

Logs e Monitoramento podem ser registrados, assim mostrando acessos e atividades (útil para auditoria e segurança) é integrado com CloudWatch e CloudTrail

Bucket Storage Classes

A escolha da classe depende de quanto frequentemente os dados são acessados + quão rápido precisam estar disponíveis + custo que você está disposto a pagar.

Classes “IA” (infrequente access) e “Glacier” penalizam mais o acesso frequente ou remoção precoce, verifique requisitos de duração mínima / taxas de recuperação.

Pode-se usar regras de ciclo de vida para mover automaticamente objetos entre classes conforme o tempo ou padrão de acesso.

Classes para dados com acesso frequente

STANDARD: Classe padrão (default). Alta durabilidade ( $\approx 99,9999999\%)$ e alta disponibilidade, armazenamento em múltiplas Zonas de Disponibilidade. Ideal para dados acessados com requência, latência baixa.

INTELLIGENT_TIERING: Para dados com padrôes de acesso (acesso frequente ←→ infrequente ) para otimizar custos, sem que o usuário precise gerenciar manualmente.

EXPRESS_ONEZONE (menos comum): Classe mais agressiva para latência muito baixa, armazenando dados em apenas uma Zona de Disponibilidade, o que reduz custoe resiliência. ****

Classes para acesso infrequente

STANDARD_IA (”Infrequent Access”): Para dados que não são acessados frequentemente, mas quando acessados precisam de latência similar ao STANDARD.

ONEZONE_IA: Similar ao STANDARD_IA, porém armazena dados em apenas uma Zona de Disponibilidade (reduzida redundância geográfica) , mais barato, porém menor disponibilidade/resiliência.

Classes para Arquivamento / Acesso Rarefeito

GLACIER_INSTANT_RETRIEVAL: Para dados raramente acessados, mas que quando precisarem, quer acesso muito rápido (milissegundos).

GLACIER_FLEXIBLE_RETRIEVAL: Para arquivamento , os dados são acessados muito raramente e com tolerância para demora (minutos a horas). Custo de armazenamento muito baixo, mas há taxa/tempo de recuperação.

GLACIER_DEEP_ARCHIVE: O nível mais baixo de custo de armazenamento , para dados que praticamente não serão acessados, ou apenas por requisitos de retenção/compliance. Recuperação pode demorar horas.

Bucket Policy

Uma bucket policy (política de bucket ) é um documento JSON que você anexa diretamente a um bucket S3. Ela define quem (ou qual entidade) pode fazer o que com o conteúdo daquele bucket , ou seja, quais ações (”PutObject”, “GetObject”, “DeleteObject”, etc) são permitidas ou negadas para quais recursos e sob quais condições.

Importante: é um tipo de política baseada em recurso (resource-based policy) , o recurso é o bucket (e/ou objetos nele) , diferente de políticas ligadas a identidades (user/roles) que são “identity-based”.

Somente o proprietário do bucket pode associar ou modificar a bucket policy.

Principais elementos de uma Bucket Policy

Para o exame e para uso prático, as partes mais importantes da política são:

Version: Identifica a versão da linguagem de política da AWS (normalmente “2012–10–17”).
Statement: array de declarações. Cada declaração define permissões ou negações. Dentro de cada “Statement”:
Effect (”Allow” ou “Deny”): se a ação vai ser permitida ou negada.
Principal: quem esá sendo afetado pela política , pode ser uma conta AWS, um usuário, uma role, ou “*” (todos).
Action: quais operações do S3 estão sendo permitidas ou negadas (ex: “s3:GetObject”, “s3:PutObject”).
Resource: qual é o recurso sobre o qual a ação se aplica , o bucket (arn:aws:s3::bucket-name) ou objetos dentro dele (arn:aws:s3::bucket-name/*).
Condition (opcional): define condições adicionais para que a permissão ou negação se aplique , por ex., restrições de IP, uso de HTTPS, origem do pedido, etc.

Exemplos de uso comuns

Permitir que qualquer usuário faça download de arquivos públicos de um bucket (ex: hospedagem de site estático).
Restringir o upload de objetos apenas se estiverem encriptados ou se o pedido usar HTTPS
Permitir acesso de outra conta AWS (cross-account) a um bucket específico.
Bloqeuar acesso a partir de determindades intervalos de IP ou exigir MFA para certas ações

Observações

Entenda que “by default” um bucket e seus objetos são privados , precisam de política (ou IAM/ACL) para permitir acesso.
Sabendo a diferença entre políticas baseadas em recurso (bucket policy) e políticas baseadas em identidade (IAM policy) ajuda a responder questões de acesso/cenários.
Perceba que negar explicitamente (”Deny”) em uma bucket policy “override” permite em muitos casos , “Deny” > “Allow”
Lembre-se de que você pode combinar políticas: IAM + bucket policy + ACLs (embora AWS recomende minimizar o uso de ACLs).

Elementos fundamentais da estrutura do S3

Bucket

Um bucket é o recipiente ou “balde” lógico onde você armazena objetos.

Quando você cria um bucket, você escolhe uma região da AWS , os objetos desse bucket ficam nessa região, a menos que você configure replica ou outro recurso.

O nome do bucket deve ser globalmente único dentro da partição da AWS (por exemplo “aws”, “aws-cn”, etc).

Dentro de um bucket, você pode aplicar configurações como versionamento, criptografia, políticas, ciclo de vida, logs etc.

Objeto

O objeto é a unidade de armazenamento real: é o arquivo ou dado que você armazena, junto com metadados.

Cada objeto possui:

uma chave (key) , basicamente o “nome” ou identificador dentro do bucket.

2. um value , o conteúdo em bytes do objeto.

3. metadados , tanto do sistema (por exemplo data de criação, tipo de armazenamento) quanto definidos pelo usuário.

4. opcionalmente, uma versão (se o bucket tiver versionamento ativado) , então cada objeto pode ter múltiplas versões.

5. O tamanho máximo de um objeto pode chegar a 5 TB.

Estrutura “plana” e prefixos

Embora no console ou visualização você possa ver pastas (folders) dentro do bucket, internamente o S3 é estruturalmente plano , ou seja, não é hierarquia de diretórios real como num sistema de arquivos tradicional.

As “pastas” são na verdade prefixos na chave do objeto. Por exemplo, um objeto com chave photos/2017/image.jpg aparenta estar em “photos/2017”, mas na verdade isso é parte da chave.

Região, disponibilidade e durabilidade

Quando você escolhe uma região para o bucket, os dados ficam nessa região ( a menos que haja replicação configurada).

O S3 foi projetado para ser altamente durável e disponível, com redundância , por exemplo, objetos são armazenados em múltiplas Zonas de Disponibilidade.

Configurações extras importantes

Versioning: permite que você matenha múltiplas versões de um mesmo objeto, ajudando em recuperação de dados.
Ciclo de Vida (Lifecycle rules): você pode configurar políticas para mover objetos entre storange classes ou excluir objetos após certo tempo.
Controle de Acesso: por padrão, buckets e objetos são privados. Você gerencia acesso via políticas de bucket, ACLs, IAM etc.
Taggin, criptografia, logs: outros aspectos de governança e segurança que você pode aplicar.

Versionamento

O versionamento do S3 serve para manter várias versões do mesmo objeto dentro de um bucket.

Cada vez que você faz upload de um arquivo com o mesmo nome, o S3 cria uma nova versão, em vez de sobrescrever o antigo.

O versionamento vem desativo por padrão, então é necessário ativarmos manualmente se quisermos ele em atividade.

Antes, saiba que ele só pode ser ativado no nível do Bucket e que depois de ativado, não pode ser totalmente desativado, apenas suspenso.

Obs: Suspender = o bucket para de criar novas versões, mas mantém as existente.

Como funciona

Para saber como funciona iremo usar o exemplo do João.

João fez o uplaod de um novo arquivo, o S3 com versionamento ativado viu, recebeu e criou a versão inicial.

No outro dia, João realizou upload de outro arquivo com o mesmo nome, o S3 olho e falou: “Olha, desse aqui eu ja tenho, mas vou mantê-lo como uma segunda versão”.

João percebeu que fez o upload de dois arquivos com o mesmo nome, e por isso decidiu apagar um deles, o S3 como não é bobo falou o seguinte: “Amigo, tenho dois desses ai, você quer aClapagar uma, entretanto, isso pode ser necessário posteriormente. Então eu vou apenas parar de te mostrar esse resultado, marcando ele como deletado, certo?”

Depois de alguns dias, João percebeu que realmente precisava daquele arquivo, então ele chamou o seu amigo S3 para uma conversa de homem para máquina

João: “Mano, eu preciso daquele arquivo de volta.. Consegue remover a marca da maldição (deletação)?”

S3: “Claro, meu patrão. Ta na mesa já seu arquivo. Tamo junto, chefia!”

Termos Importantes

Version ID: identificador único gerado pelo S3 para cada versão.
Latest Version: a versão mais recente do objeto
Delete Marker: “Marca” indicando que o objeto foi excluido (pode ser removido para restaurar o arquivo)

As vantagens de ter isso ativado, é que podemos recuperar arquivos ou outros tipos de dados excluidos acidentalmente, restaurar versões antigas de um arquivo e isso protege contra erros humanos ou sobrescritas indevidas.

Todavia, vale ficar ligado em algumas coisas:

Cada versão ocupa espaço de armazenamento, ou seja, isso pode e vai aumentar os custos.
Excluir objetos em buckets versionados requer cuidado (é preciso excluir todas as versões para liberar espaço)

Replicação do S3 (Replicação de Objetos no Amazon S3)

O S3 Replication é um recurso que copia automaticamente objetos de um bucket para outro, após o upload.

Serve para garantir a disponibilidade e resuliência dos dados, reduzir a latência de acesso para usuários em outras regiôes, cumprir exigências legais.

Como funciona

Quando o replication está ativo, você envia um objeto para o bucket de origem, o S3 detecta o upload e copia o objeto para o bucket de destino, de forma assíncrona (leva apenas alguns segundos)

Para isso, temos dois tipos de replicação: CRR (Cross-Region Replication) e SRR (Same-Region Replication)

Antes de ativar, vale garantir quer o versionamento esteja ativo nos dois buckets (origem e destino), as permissões corretas (IAM Role) para o S3 replicar objetos e os buckets podem estar na mesma conta ou em contas diferentes.

Você também pode configurar algumas coisas a mais, como o filtro por prefixo ou tags (para que somente objetos específicos sejam clonados), replicação de metadados, ACLs e objetos criptografados, replicação bidirecional (pode gerar loops), e a replicação de Delete Markes.

Encriptação S3

A encriptação no Amazon S3 serve para proteger dados em repouso (at rest) e, opcionalmente em transito (in transit). Ela garante que, mesmo que alguém obtenha acesso físico ou lógico ao storage, não consiga ler os dados sem a chave correta.

Tipos de Encriptação no S3

O S3 oferece dois momentos diferentes onde a criptografia pode ser aplicada:

Criptografia em repouso (at rest): protege os dados quando armazenados nos servidores S3.
Criptografia em trânsito (in transit): protge os dados durenta o upload/download, via HTTPS (TLS).

Criptografia em Respouso (Server-Side Encryption — SSE)

Aqui, o S3 encripta os dados automaticamente quando você faz o upload e os desencripta quando faz o download.

Existem 3 formas principais de configurar isso:

SSE-S3 (Server-Side Encryption with S3 Managed Keys)

O S3 gerencia as chaves de criptografia.
Simples e automática.
Cada objeto recebe uma chave única (AES-256).
A AWS gira e protege essas chaves internamente, sem necessidade de configuração.

Header HTTP:

"x-amz-server-side-encryption": "AES256"

É bastante usada quando você quer criptografia simples, sem lidar com chaves, e é gratuito.

SSE-KMS (Server-Side Encryption with AWS KMS Keys)

Usa o AWS Key Management Service (KMS) para gerenciar chaves.
Você pode usar:
AWS managed key (aws/s3) ou
Customer managed key (CMK), criada por você no KMS.
Permite controle de acesso granular, auditoria (CloudTrail) e rotação de chaves.

Header HTTP:

"x-amz-server-side-encryption": "aws:kms"

É bastante usada quando há requisitos de compliance (LGPD, PCI-DSS, ISO, etc.) ou auditoria, é cobrado as requisições ao KMS (por criptografia/descriptografia).

SSE-C (Server-Side Encryption with Customer-Provided Keys)

Você fornece sua própria chave no momento do upload.
A AWS usa a chave apenas na operação (não armazena).
Você precisa enviar a mesma chave toda vez que quiser ler o objeto.

Headers HTTP:

"x-amz-server-side-encryption-customer-algorithm": "AES256"
"x-amz-server-side-encryption-customer-key": "<sua chave base64>"
"x-amz-server-side-encryption-customer-key-MD5": "<checksum>"

É bastante utilizada quado você não confia que a AWS armazene suas chaves, mas quer criptografia no servidor, é gratuito, porém é mais complexo.

Criptografia do Lado do Cliente (Client-Side Encryption)

Aqui, você criptografa os dados antes do upload. A AWS nunca vê o dado nem a chave, isso pode ser feito de duas formas:

Usando o SDK da AWS (que gerencia as chaves localmente).
Usando sua própria biblioteca de criptografia (OpenSSL, etc).

É bastante usada em aplicação que exigem sigilo absoluto (bancos, saúde, governo, etc), a depender da implementação pode custar algo, mas sem custo extra no S3.

Encriptsação Automática por Bucket

Você pode ativar criptografia padrão em um bucket, assim qualquer novo objeto é criptografado automaticamente, mesmo que o cliente não envie o header *x-amz-server-side-encryption*

Exemplo (AWS CLI):

aws s3api put-bucket-encryption \\
  --bucket meu-bucket \\
  --server-side-encryption-configuration '{
  "Rules": [{
  "ApplyServerSideEncryptionByDefault":{
          "SSEAlgorithm": "aws:kms"
          }
      }]
  }'

Storage Gateway

O AWS Storage Gateway é um dos serviços mais estratégicos da AWS, ele é o elo entre a infraestrutura local (on-premises) e a nuvem da AWS, permitindo que empresas integram o armazenamento da AWS com seus datacenter, servidores ou aplicações legadas, sem precisar migrar tudo de uma vez.

AWS Storage Gateway é um serviço hibrido de armazenamento.

Ele roda como uma VM (ou appliance físico) dentro do seu ambiente local ou em uma instância EC2, e faz a ponte entre o seu datacenter e o armazenamente da AWS (S3, EBS, FSx, Glacier, etc.)

Tipos de Storage Gateway

O serviço tem 3 modas principais, cada um voltado para um caso de uso diferente:

File Gateway

Feito para compartilhar arquivos (NFS/SMB) com backend no S3.

Você monta o Storage Gateway como um compartilhamente de rede (NFS ou SMB) em seus servidores locais
Ao gravar um arquivo nesse compartilhamente, o gateway o envia para o Amazon S3.
O arquivo é armazenado como objeto no S3, e os metadados são mantidos localmente (cache)

Ele pode ser acessado tanto localmente quanto via console S3 ou API.

É bastente utilizado para backups de arquivos locais para o S3, substituição de servidores de arquivos locais, acesso híbrido (on-prem + cloud), Machine Learning ou Big Data lendo dados de pastas locais, mas armazenados no S3.

Permite usar o S3 sem precisar reescrever aplicações, elas continuam usando SMB/NFS normalmente.

Volume Gateway

Utilizado para simular discos locais (iSCSI) que armazenam dados na nuvem.

Fornece volumes de bloco apresentados aos servidores via iSCSI, mas os dados são mantidos e protegidos no S3 (e snapshots no EBS/Glacier).

Existem dois modos:

Cached Volumes

Mantém dados recentes em cache local (SSD local) e envia o restante para o S3, ideal quando há muitos dados, mas você quer apenas o mais usado disponível localmente.

Stored Volumes

Armazena todos os dados localmente e envia backups (snapshots) periódicos para o S3. Ideal para ambientes com baixa concectividade, mas que ainda querem backup automático na nuvem.

Tape Gateway

Usado para substituir fitas de backup físicas por “fitas virtuais” (VTL — Virtual Tape Library)

Ele emula uma biblioteca de fitas físicas (VTL) compatível com softwares de backup legados (Veeam, Commvault, etc.), armazena os dados como objetos no Amazon S3 Glacier Deep Archive, seu software de bacup acha que esta gravando em fitas normais, mas, na verdade, é tudo na nuvem.

Utilizado geralmente para eliminar as fitas físicas e o custo de manutenção, o backup de longo prazo (compliance, auditoria) e recuperação rápida de fitas antigas sem precisar buscar fisicamente.