Explique os tipos de controle de acesso no S3: IAM Policies, Bucket Policies, Bucket ACLs e Object ACLs
AWS S3 oferece várias camadas de segurança para controlar o acesso a buckets e objetos, sendo as principais IAM Policies, Bucket Policies e Access Control Lists (ACLs). Essas opções permitem gerenciar permissões de forma granular, priorizando políticas baseadas em JSON para maior flexibilidade e segurança. docs.aws.amazon
IAM Policies
As IAM Policies são políticas baseadas em identidade, anexadas a usuários, grupos ou roles no IAM, controlando o acesso a recursos S3 em toda a conta AWS. Elas funcionam definindo ações permitidas (como s3:GetObject), recursos (ARN do bucket ou objeto) e condições (ex: IP restrito), avaliadas pelo serviço IAM antes de qualquer requisição S3. Use-as para gerenciar acesso centralizado dentro da mesma conta, como permitir que um data engineer leia objetos de um bucket específico; por exemplo, uma policy permitindo s3:ListBucket em “arn:aws:s3:::meu-bucket” para um role usado em um ETL no Glue. docs.aws.amazon
Em comparação com Bucket Policies, IAM é melhor para controle intra-conta e integração com outros serviços AWS, mas não suporta cross-account nativamente sem trust policies. Desvantagem: requer gerenciamento no IAM, o que pode ser menos intuitivo para admins focados só em S3. Para certificação, memorize que são ideais para usuários/roles, evitando wildcards amplos como “*” para segurança. cybr
Cenário: Em um pipeline de dados, anexe uma IAM Policy a um role do Lambda para upload de arquivos processados no S3, limitando a um prefixo “/dados/2026/”.
Bucket Policies
Bucket Policies são políticas baseadas em recurso, aplicadas diretamente no bucket S3, permitindo regras de acesso JSON semelhantes às IAM, mas com suporte nativo a cross-account via Principal (ex: ARN de outra conta). Elas funcionam avaliando permissões no bucket antes de ações como PutObject, podendo permitir/denegar com condições como vpc endpoints ou MFA. Exemplo: Permita que a conta 123456789012 leia objetos com {“Principal”: {“AWS”: “arn:aws:iam::123456789012:root”}, “Action”: “s3:GetObject”, “Resource”: “arn:aws:s3:::meu-bucket/*”}. stackoverflow
Comparadas às IAM Policies, Bucket Policies são superiores para cross-account e regras de bucket como block public access, mas desvantagens incluem limite de 20 KB por policy e dificuldade em auditoria centralizada. Vs ACLs, são mais poderosas com condições avançadas. Use quando precisar compartilhar buckets entre contas, como logs centralizados de CloudTrail. msp360
Cenário: Em uma empresa com múltiplas contas, use Bucket Policy no bucket central para permitir que apps em outra conta escrevam logs, exigindo “s3:x-amz-acl”: “bucket-owner-full-control”.
Object ACLs
Object Access Control Lists (ACLs) controlam permissões em nível de objeto individual, usando XML para conceder acesso a contas/grupos como READ ou FULL_CONTROL, mas podem ser desabilitadas globalmente via Object Ownership “Bucket owner enforced”. Funcionam herdando do bucket ou definindo no upload (ex: –acl public-read via CLI), avaliadas junto com policies. AWS recomenda desabilitar ACLs em novos buckets, pois policies são mais seguras e escaláveis; exemplo: um objeto com ACL dando READ a uma conta externa. docs.aws.amazon
Vs Bucket ACLs (nível bucket, similar mas para metadados do bucket), Object ACLs são granulares mas legados; desvantagens: sem condições avançadas, propensos a erros de ownership cross-account. Prefira policies para tudo. Use raramente, só se migrando legacy ou necessidade específica de ACL por objeto. dev
Cenário: Upload de relatório sensível com Object ACL dando FULL_CONTROL só ao owner, mas desabilite ACLs para forçar policies.
Bucket ACLs
Bucket Access Control Lists (ACLs) definem permissões no nível do bucket inteiro, como READ para listar objetos ou WRITE para upload, aplicadas via console/CLI/API em XML. Similar aos Object ACLs, mas para o bucket; por padrão, só owner tem acesso, e podem ser editadas em Permissions > Access control list. Exemplo: Grant READ ao grupo “Authenticated Users” para listagem pública controlada. docs.aws.amazon
Comparadas a Bucket Policies, ACLs são simples mas limitadas (sem cross-account fácil, sem condições); desvantagens: legados, substituídos por policies para granularidade. Desabilite com Block Public Access. Use só para compatibilidade legacy. cybr
Cenário: Bucket de assets públicos com Bucket ACL READ para “All Users”, mas migre para Bucket Policy com condições para segurança.
Quando Utilizar Cada Um
Priorize IAM Policies para intra-conta e centralização; Bucket Policies para cross-account e regras bucket-level; evite ACLs (desabilite por default) a favor de policies para escalabilidade e auditoria no CloudTrail. Combine-as: IAM para roles + Bucket Policy para deny-all baseline. Para Data Engineer Associate, foque em exemplos JSON e avaliação de permissões (deny overrides allow). docs.aws.amazon
Explique no S3 Cross-Region Replication (CRR), Replicação de Objetos Existentes e Delete Markers
AWS S3 Replication permite copiar objetos de forma assíncrona entre buckets para resiliência, conformidade e baixa latência, com tipos como CRR (Cross-Region) e SRR (Same-Region). Ambas replicam novos objetos automaticamente, mas usam S3 Batch para existentes; delete markers são opcionais. docs.aws.amazon
CRR replica objetos assincronamente entre buckets em regiões diferentes, ajudando em disaster recovery, conformidade (dados distantes) e acesso rápido global. Configura-se no bucket fonte com regras por prefixo/tag, requer versioning habilitado e IAM role; destina a outro bucket (mesma ou conta diferente). Exemplo: Bucket em us-east-1 replica para eu-west-1 para baixa latência europeia. aws.amazon
Vs SRR, CRR é para multi-região (custo de egress mais alto), mas sem chain: Bucket1 -> Bucket2 não replica para Bucket3 de Bucket2. Delete markers replicam só se habilitado (padrão off), preservando versões; delete permanente não remove do destino. Use com S3 RTC para SLA de 15min em 99.99%. docs.aws.amazon
Cenário: App de e-commerce em sa-east-1 replica dados para us-east-1 para failover, com owner override no destino para proteção.
SRR replica dentro da mesma região (diferentes AZs ou contas), para agregação de logs, live dev/prod ou soberania de dados. Funciona igual CRR, mas intra-região (sem custo egress), com regras granulares e versioning. Exemplo: Logs de múltiplos buckets/accounts para um central na mesma região para Athena queries. dev
Vs CRR, SRR é mais barata e rápida para compliance local, mas não para DR global; mesmas limitações de chain/novos objetos. Ideal para multi-account sem sair da região. himanshublog.hashnode
Cenário: Equipe de dados replica raw data de prod para staging na mesma região us-west-2, alterando storage class no destino via lifecycle.
Replicação ativa só novos/atualizados; para arquivos antigos, use S3 Batch Replication (via Batch Operations), criando job com inventory do bucket fonte. Preserva metadados/version IDs, retry fails e replicas prévias. Exemplo: Após ativar CRR, rode Batch para copiar 1M objetos existentes para destino. aws.amazon
Vs replicação live, Batch é on-demand/paga por objeto; desvantagem: não automática. Use para migrações/backfills.
Cenário: Pós-merge de buckets legados, Batch replica históricos para novo bucket com CRR ativo.
Delete markers (marcam versão “deletada”) replicam se habilitado na regra (Status: Enabled), permitindo sync de deletes lógicos; delete permanente (versão específica) não afeta destino. Sem chain de replicação: alterações em réplicas não propagam adiante. Métricas CloudWatch monitoram status (Pending/Complete/Failed). veritas
Comparado a ferramentas como DMS, S3 Replication é serverless/específica para objetos; desvantagem: assíncrona sem SLA padrão (use RTC).
Cenário: Ambiente versionado com deleções frequentes; habilite delete markers para evitar orfãos no DR bucket. docs.aws.amazon
Explique as categorias de armazenamento do S3
Amazon S3 oferece classes de armazenamento otimizadas para diferentes padrões de acesso e custos, permitindo escolher a melhor opção via configuração de objeto ou Lifecycle Policies automáticas. Todas entregam 99.999999999% de durabilidade (11 9s), mas variam em latência, disponibilidade e retrieval fees. aws.amazon
S3 Standard
Classe general purpose para dados acessados frequentemente, com latência de milissegundos e throughput alto em qualquer volume. Ideal para apps operacionais, big data analytics ou conteúdo dinâmico; não tem mínimo de armazenamento nem retrieval fees. Exemplo: Arquivos de um data lake ativo em Athena queries diárias. aws.amazon
Vs IA classes, é mais cara para storage mas sem custos surpresa de leitura; use como padrão inicial antes de otimizar com Lifecycle.
Cenário: Pipeline ETL no Glue lendo/parando logs atuais.
S3 Standard-IA
Para dados pouco acessados mas com necessidade de ms latência (ex: backups acessados mensalmente), com storage ~40% mais barato que Standard, mas retrieval fee por GB + mínimo 30 dias. Transição automática via Lifecycle após 30 dias sem acesso. Exemplo: Backups de VMs ou datasets de relatórios trimestrais. aws.amazon
Vs One Zone-IA, tem redundância em >=3 AZs (99.9% availability); desvantagem: fees em acessos esporádicos podem somar. Prefira se RPO alto.
Cenário: Disaster recovery com acesso rápido ocasional.
S3 One Zone-IA
Similar ao Standard-IA mas em apenas 1 AZ (99.5% availability, menor custo), para dados recriáveis ou secundários com ms latência. Mínimo 30 dias, retrieval fees; risco de perda se AZ falhar (raro). Exemplo: Cache secundário ou thumbnails que podem regenerar. aws.amazon
Vs Standard-IA, economiza ~20% mas sem multi-AZ; desvantagem: não para dados críticos. Use com replicação para mitigar.
Cenário: Backup on-premise não crítico.
S3 Glacier Instant Retrieval
Recuperação em ms para dados raramente acessados (poucas vezes/ano), com mínimo 90 dias e retrieval fee. Mais barata que IA para long-term, archive instantâneo. Exemplo: Dados acessados trimestralmente em audits. aws.amazon
Vs Flexible Retrieval, zero tempo de espera mas custo retrieval maior; desvantagem: não para hot data. Transição via Lifecycle após 90 dias.
Cenário: Arquivos de compliance abertos esporadicamente.
S3 Glacier Flexible Retrieval
Tier Glacier com opções: Expedited (1-5 min), Standard (3-5h), Bulk (5-12h), mínimo 90 dias, retrieval fees escalonados. Para backups raramente acessados. Exemplo: Media archive ou logs antigos. aws.amazon
Vs Deep Archive, mais flexível mas retrieval mais caro/lento; desvantagem: planejamento para restauração. No Data Engineer, combine com Athena para queries archived.
Cenário: Disaster recovery de longo prazo.
S3 Glacier Deep Archive
Mais barata para archive raramente acessado (1-2x/década): Standard (12h), Bulk (48h), mínimo 180 dias, fees altas mas storage mínimo. Exemplo: Registros regulatórios de 7+ anos. aws.amazon
Vs Flexible, até 75% mais barata mas mais lenta; desvantagem: não para acesso frequente. Ideal para conformidade máxima.
Cenário: Dados retidos por lei por décadas.
S3 Intelligent-Tiering
Monitora acesso automaticamente (sem fee monitoramento <128KB) e move entre Frequent/Infrequent/Archive Instant/Archive/Deep Archive tiers, otimizando custo para padrões desconhecidos. Latência ms nos tiers hot, mínimo 30/90 dias por tier. Exemplo: Data lakes com acesso variável. aws.amazon
Vs manual, zero gerenciamento mas small monitoring fee; desvantagem: custo extra em objetos pequenos. Melhor para Data Engineer sem analytics de acesso.
Cenário: Logs analíticos com picos sazonais. aws.amazon
Amazon S3 Express One Zone
- Classe de armazenamento de alta performance que fica em apenas uma AZ
- Até 10x mais performance que o S3 standard (custo 50% menor)
- Desvantagem: estar em apenas uma AZ. As outras classes de armazenamento replicam os dados entre múltiplas AZs
- Casos de uso: apps sensíveis a latência, treinamento de modelos de ML, processamento de mídia, etc
S3 Lifecycle Rules
S3 Lifecycle Rules - Flashcards
Front: O que são S3 Lifecycle Rules?
Back: Conjunto de regras em um bucket S3 que definem ações automáticas para objetos, como transições para classes de armazenamento mais baratas (ex: Standard → Standard-IA após 30 dias) ou expiração/deleção. Aplica-se a objetos novos e existentes, otimizando custos ao longo do ciclo de vida dos dados. docs.aws.amazon
Front: Como criar uma Lifecycle Rule no S3?
Back: No Console S3: 1) Selecione o bucket > Management > Add lifecycle rule. 2) Defina ID, filtro (prefixo/tags), status (Enabled). 3) Adicione ações: Transition (dias para mudar classe, ex: 30 dias para IA) ou Expiration (dias para deletar). Via CLI/API: Use PutBucketLifecycleConfiguration. Regras até 1.000 por bucket. docs.aws.amazon
Front: Exemplo de regra para movimentação entre storage classes?
Back: Regra: Objetos com prefixo “logs/” → Transition para Standard-IA após 30 dias → Glacier após 90 dias → Expire após 365 dias. Economiza custos: Standard (frequente) → IA (infrequente) → Arquivamento. JSON exemplo: {“Transition”: [{“Days”: 30, “StorageClass”: “STANDARD_IA”}]}. github
Front: Como funciona a exclusão de arquivos após período?
Back: Ação “Expiration”: Define dias após criação para S3 deletar permanentemente (ex: 30 dias). Para buckets versionados, use NoncurrentVersionExpiration. Atenção: Em IA/Glacier, cobra mínimo (30/90 dias) mesmo se deletar cedo. S3 remove delete markers expirados automaticamente. stackoverflow
Front: O que é Amazon S3 Analytics (Storage Class Analysis)?
Back: Ferramenta para analisar padrões de acesso em objetos Standard (>128KB), recomendando quando mover para Standard-IA. Filtre por prefixo/tags, visualize gráficos no console (acesso por idade: 0-14 dias, 15-29, etc.). Leva 30+ dias para resultados; exporte CSV diário. Ajuda a otimizar Lifecycle Rules. docs.aws.amazon
Front: Cenários de uso para Lifecycle Rules?
Back: - Logs temporários: Delete após 7 dias.
- Backups: Standard → IA (30d) → Glacier (90d) → Delete (1 ano).
- Arquivos compliance: Archive após 1 ano, delete após 7 anos.
Ideal para dados com acesso decrescente, reduzindo custos em 75%+ em IA/Glacier. docs.aws.amazon
Front: Vantagens/Desvantagens vs serviços similares AWS?
Back: | Aspecto | S3 Lifecycle | S3 Intelligent-Tiering |
|———|————-|————————-|
| Automação | Regras fixas por dias | Automático por acesso |
| Custo | Baixo (transições pagas) | Monitoring fee + auto-tier |
| Controle | Alta (regras custom) | Baixa (automático) |
| Uso | Previsível/cíclico | Imprevisível |
Lifecycle é melhor para regras determinísticas; IT para sem monitoramento manual. docs.aws.amazon
Front: Quando usar S3 Lifecycle Rules (Data Engineer)?
Back: Sempre em workloads de dados com retenção definida (logs, ETL outputs, backups). Combine com Analytics para dados incertos. Evite em dados hot constantes. Custo-efetivo para TBs+; monitore via CloudWatch. docs.aws.amazon
O que é o S3 Event Notification?
S3 Event Notifications Flashcards
Front: O que é Amazon S3 Event Notifications? docs.aws.amazon
Back:
- Serviço do AWS S3 que envia notificações automáticas quando eventos específicos ocorrem em um bucket, como criação, remoção ou restauração de objetos. docs.aws.amazon
- Configurado no sub-recurso “notification” do bucket, identificando eventos e destinos. docs.aws.amazon
- Entregas “at least once”, geralmente em segundos, mas pode demorar até 1 minuto. docs.aws.amazon
Exemplo: Ao subir um arquivo, S3 publica uma mensagem JSON com detalhes (bucket, chave do objeto, timestamp). docs.aws.amazon
Front: Como funciona S3 Event Notifications? docs.aws.amazon
Back:
- Monitore eventos no bucket (ex: s3:ObjectCreated:* para criações via PUT, POST, COPY). docs.aws.amazon
- Configure via Console S3: Properties > Event Notifications > Create > Selecione eventos, prefixo/sufixo (opcional), destino (SNS, SQS, Lambda, EventBridge). docs.aws.amazon
- S3 publica mensagem para o destino especificado pelo ARN; precisa de permissões (policy no destino permitindo S3 publicar). docs.aws.amazon
Exemplo de setup: Crie SNS topic, adicione policy para S3, configure no bucket para “All object create events”. docs.aws.amazon
Front: Eventos suportados em S3 Event Notifications? docs.aws.amazon
Back:
- Criação de objetos (s3:ObjectCreated:Put, Post, Copy, CompleteMultipartUpload, *). docs.aws.amazon
- Remoção de objetos (s3:ObjectRemoved:Delete, DeleteMarkerCreated, *). docs.aws.amazon
- Outros: Restore, Replication, Lifecycle expiration/transition, Intelligent-Tiering archive, tagging, ACL PUT, RRS lost. docs.aws.amazon
Front: Destinos suportados em S3 Event Notifications? docs.aws.amazon
Back:
- Amazon SNS topics (fan-out para múltiplos assinantes, ex: email). docs.aws.amazon
- Amazon SQS queues (fila para processamento assíncrono; FIFO via EventBridge). docs.aws.amazon
- AWS Lambda functions (execução serverless direta). docs.aws.amazon
- Amazon EventBridge (roteamento avançado, cross-account). docs.aws.amazon
Front: Cenários de uso para S3 Event Notifications? falconcloud
Back:
- Processamento automático de uploads: Trigger Lambda para redimensionar imagens ou ETL em dados novos. falconcloud
- Alertas em tempo real: SNS para email/SMS quando arquivos críticos são adicionados/removidos. falconcloud
- Pipelines de data lake: SQS para fila de jobs de análise em objetos novos. runebook
- Monitoramento/auditoria: Notificações para compliance ou detecção de anomalias. runebook
Exemplo: Bucket de logs recebe arquivo > Event > Lambda indexa no OpenSearch. docs.aws.amazon
Front: Vantagens do S3 Event Notifications vs serviços similares? dev
Back:
- Vs S3 Replication: Notifications reagem a eventos (push, sem polling), Replication copia dados automaticamente; use Notifications para triggers customizados, Replication para DR/high availability. Vantagem: Gratuito para eventos, integra nativamente com serverless. Desvantagem: Pode loop se write no mesmo bucket (evite com prefixos). dev
- Vs EventBridge direto: S3 Notifications é mais simples/específico para S3 (até 100 configs/bucket), EventBridge adiciona roteamento/filtros avançados mas overhead. Vantagem: Direto no bucket. Desvantagem: Limitado a eventos S3/object-level (EventBridge faz bucket-level/cross-service). dev
- Vs Polling S3: Elimina custo/latência de LIST requests; event-driven é escalável. tutorialsdojo
Front: Quando usar S3 Event Notifications (Data Engineer Associate)? docs.aws.amazon
Back:
- Sempre em arquiteturas event-driven para data ingestion/processing (ex: S3 > Lambda > Glue). docs.aws.amazon
- Para workloads de streaming/ETL em tempo quase-real, evitando polling custoso. docs.aws.amazon
- Limites: 100 notificações por bucket; gerencie filtros (prefix/suffix) para eficiência. docs.aws.amazon
Dica certificação: Foque em permissões (S3 principal no policy destino) e idempotência (at-least-once). docs.aws.amazon
Quais são os tipos de upload que posso fazer no S3? existe uma forma de otimizar isso?
S3 Performance Flashcards
Front: O que é Multipart Upload no S3? docs.aws.amazon
Back:
- Permite upload de um objeto grande como partes independentes (mín. 5MB, máx. 5TB objeto, 10.000 partes). docs.aws.amazon
- Processo: Initiate (retorna Upload ID), UploadPart (paralelo, qualquer ordem), Complete (S3 junta partes). docs.aws.amazon
- Suporta checksums por parte e full-object; SDKs automatizam. docs.aws.amazon
Exemplo: Arquivo 100GB dividido em 1000 partes de 100MB, upload paralelo para throughput alto. docs.aws.amazon
Front: Como funciona Multipart Upload? docs.aws.amazon
Back:
- Inicie com CreateMultipartUpload (especifique checksum algo.); upload partes com UploadPart (part number 1-10k, ETag retornado). docs.aws.amazon
- CompleteMultipartUpload lista partes com ETAGs; S3 concatena em ordem ascendente. docs.aws.amazon
- Aborte para deletar partes incompletas (evite custos); lifecycle pode abortar auto após dias. docs.aws.amazon
Exemplo CLI: aws s3api create-multipart-upload –bucket mybucket –key largefile; upload parts; complete com JSON de partes. docs.aws.amazon
Front: Vantagens Multipart Upload vs upload simples? docs.aws.amazon
Back:
- Throughput melhorado: Paraleliza partes para multi-thread. docs.aws.amazon
- Resiliência: Retry só parte falha, pause/resume, inicia sem saber tamanho final. docs.aws.amazon
Vs simples: Obrigatório >5GB; para >100MB recomendado; custo storage partes até complete/abort. Desvantagem: Gerencie incomplete uploads via lifecycle. docs.aws.amazon
Front: O que é S3 Transfer Acceleration? aws.amazon
Back:
- Otimiza transfers long-distance: Roteia via CloudFront Edge Locations + backbone AWS para menor latência/variabilidade. docs.aws.amazon
- Ative no bucket; use endpoint acelerado (bucket.s3-accelerate.amazonaws.com). aws.amazon
- Paga só se acelerar (AWS compara); ideal GBs/TBs globais. aws.amazon
Exemplo: Upload de Ásia para US bucket reduz tempo 50% via edge próximo. notes.kodekloud
Front: Como funciona S3 Transfer Acceleration? docs.aws.amazon
Back:
- Cliente envia para edge location mais próximo; AWS roteia otimizado para bucket. aws.amazon
- Suporta multipart auto; testa velocidade no tool AWS. docs.aws.amazon
Vs direto: Melhor para distâncias longas; não sempre acelera (ex: same Region). Desvantagem: Custo extra se usado. stackoverflow
Front: O que é S3 Byte-Range Fetches? docs.aws.amazon
Back:
- Download paralelo de partes de objeto via header Range HTTP (ex: bytes=0-999). docs.aws.amazon
- Aumenta throughput aggregate; retry rápido em falhas; lê parcial (cabeçalho, linhas iniciais). docs.aws.amazon
- Alinhe com part sizes de multipart para best perf. docs.aws.amazon
Exemplo: Download 1GB em 10 ranges paralelas vs single GET. youtube
Front: Como usar Byte-Range Fetches? docs.aws.amazon
Back:
- GET Object com Range: bytes=start-end; múltiplas conexões para ranges diferentes. docs.aws.amazon
- SDKs/Transfer Manager automatizam. docs.aws.amazon
Vs Multipart (upload): Byte-range é “multipart reverso” para download. Desvantagem: App gerencia junção de partes. youtube
Front: Cenários de uso S3 Performance Features (Data Engineer)? aws.amazon
Back:
- Multipart: ETL data lakes grandes (>100MB), uploads resilientes spotty networks. docs.aws.amazon
- Transfer Accel: Ingestão global logs/videos para bucket central. aws.amazon
- Byte-Range: Análise preview (primeiras linhas CSV), downloads paralelos big data. docs.aws.amazon
Exemplo: Lambda baixa range de log > processa > S3 output via multipart. docs.aws.amazon
Front: Dicas Performance Geral S3 (Certificação)? docs.aws.amazon
Back:
- 3.5k PUT/5.5k GET/s por prefix; use prefixes aleatórios (ex: date/hash). docs.aws.amazon
- Retry 503s; multi-conexões; same Region EC2-S3. docs.aws.amazon
- Monitore 503s via CloudWatch/Storage Lens para throttle. docs.aws.amazon
Quais são as formas de criptografia de objetos no S3?
Formas de criptografar objetos no S3:
- Server-side encryption (SSE).
- Server Side Encryption with Amazon S3-Managed Keys (SSE-S3): AWS automaticamente criptografa os dados (criptografia padrão)
- Server-side encryption with KMS Keys Stored in AWS KMS (SSE-KMS): KMS gerencia as chaves de criptografia
- Server-side encryption with Customer-provided Keys (SSE-C): o proprio usuário gerencia as chaves de criptografia. Ele envia a chave no header da requisicao HTTP junto com o arquivo e o AWS faz a criptografia. A chave não é salva na AWS
- DSSE-KMS (Dual-Layer Server Side Encryption based on KMS) - NOVO! NAO DEVE CAIR NO EXAME
- Client-side encryption: O usuário criptografa os dados e salva no S3
O que é o Amazon EBS?
Amazon EBS Flashcards docs.aws.amazon
Front: O que é Amazon EBS? docs.aws.amazon
Back:
- Armazenamento em bloco persistente, escalável e de alto desempenho projetado para instâncias EC2. docs.aws.amazon
- Volumes replicados dentro de uma AZ para durabilidade 99.999%; attach como disco local. docs.aws.amazon
- Tipos SSD (transacional: gp3/gp2/io2) e HDD (throughput: st1/sc1). amazonaws
Exemplo: Attach EBS à EC2 como /dev/sdf > mkfs > mount para filesystem persistente. docs.aws.amazon
Front: Como funciona Amazon EBS? amazonaws
Back:
- Crie volume (tamanho, tipo, AZ específica); attach a EC2 na mesma AZ via Console/SDK/CLI. docs.aws.amazon
- Formate (ext4) e monte; detach/re-attach possível (exceto boot volume). docs.aws.amazon
- Elastic Volumes: Modifique size/IOPS/type online sem downtime (Nitro+). amazonaws
Exemplo CLI: aws ec2 create-volume –size 100 –type gp3 –availability-zone us-east-1a; attach com device /dev/xvdf. docs.aws.amazon
Front: Tipos de Volumes EBS? geeksforgeeks
Back:
- SSD: gp3 (até 16k IOPS, 1k baseline, custo-efetivo); io2 Block Express (256k IOPS, 99.999% durabilidade missão crítica). geeksforgeeks
- HDD: st1 (throughput otimizado, ex: logs); sc1 (cold infrequent). docs.aws.amazon
Escolha: Databases → io2; boot/general → gp3; big data → st1. amazonaws
Front: Principais Features EBS? geeksforgeeks
Back:
- Snapshots: Backup incremental no S3; copy cross-region/account; Fast Snapshot Restore (FSR). geeksforgeeks
- Multi-Attach: io1/io2 até 16 Nitro EC2 same AZ (app gerencia consistency). amazonaws
- Encryption: KMS at-rest/in-transit/snapshots automática. geeksforgeeks
Exemplo: DLM automatiza snapshots diários + retenção 30 dias. amazonaws
Front: Cenários de uso EBS (Data Engineer)? amazonaws
Back:
- Databases relacionais (RDS não cobre custom): EFS-like mas block-level performance. amazonaws
- Big Data: Hadoop/Spark clusters redimensionáveis (detach/reattach volumes). amazonaws
- Boot volumes EC2 para ETL jobs persistentes; temp storage ML training. geeksforgeeks
Exemplo: EC2 + EBS gp3 roda Spark > processa data lake > snapshot backup. amazonaws
Front: Vantagens EBS vs serviços similares AWS? geeksforgeeks
Back:
- Vs EFS: EBS é block-level (melhor IOPS latência baixa, single AZ); EFS shared filesystem (multi-AZ). Use EBS para DBs monolíticos, EFS para shared access múltiplas instâncias. Desvantagem: EBS preso à AZ da EC2. docs.aws.amazon
- Vs Instance Store: EBS persistente (sobrevive stop/terminate); Instance Store ephemeral (mais rápido mas dados perdidos). Vantagem EBS: Snapshots/DR. en.wikipedia
- Vs S3: EBS low-latency block access; S3 object storage (best throughput massivo). docs.aws.amazon
Front: Quando usar EBS (Data Engineer Associate)? docs.aws.amazon
Back:
- Sempre para workloads EC2 precisando block storage persistente (DBs, ETL custom). docs.aws.amazon
- Prefira gp3 baseline custo/performance; io2 para >16k IOPS mission critical. geeksforgeeks
- Limites: Volume size 64TiB max; monitor CloudWatch BurstBalance/VolumeThroughput. docs.aws.amazon
Dica certificação: Volumes criados em AZ específica; snapshots S3 são regionais (copy para multi-region DR). amazonaws
O que é o Amazon EFS?
Amazon EFS - Flashcard
O que é Amazon EFS?
- Amazon Elastic File System (EFS) é um serviço gerenciado de armazenamento de arquivos escalável e elástico para workloads Linux na AWS. aws.amazon
- Fornece um sistema de arquivos compatível com NFSv4, permitindo acesso simultâneo de milhares de conexões (EC2, Lambda, ECS, EKS, on-premises). en.wikipedia
- Escala automaticamente para petabytes sem provisionar capacidade, crescendo/encolhendo conforme arquivos são adicionados/removidos. amazonaws
Como funciona?
- Crie um filesystem via console/CLI/SDK; monte em instâncias EC2 usando NFS. docs.aws.amazon
- Dados distribuídos em múltiplos servidores de storage; suporta classes: Standard (alta performance SSD), Infrequent Access (IA, custo baixo para acesso raro), Archive (custo ainda menor). amazonaws
- Regional (multi-AZ, alta durabilidade) ou One Zone (mais barato, single-AZ); lifecycle management move arquivos automaticamente para classes mais baratas. amazonaws
- Throughput e IOPS escalam com tamanho do FS; criptografia em repouso/transito, POSIX permissions, IAM/VPC security. docs.aws.amazon
Comparação com serviços similares AWS (EBS e FSx):
- Vs EBS (block storage): EFS é compartilhado/multi-instância (NFS), elástico sem downtime; EBS é single-instance/low-latency, bom para DBs, mas não escala para multi-AZ compartilhado sem esforço extra. Vantagem EFS: acesso concurrente; desvantagem: latência maior (sub-ms vs single-digit ms EBS). bmc
- Vs FSx (managed filesystems): EFS é serverless/multi-protocolo simples; FSx é para Windows/Lustre/SMB com features específicas (ex: AD integration). Vantagem EFS: custo/escala automática; desvantagem: menos otimizado para HPC (use FSx for Lustre). bmc
Quando usar?
- Use quando precisar de storage compartilhado elástico para >1 instância, big data/ML, dev/test, CMS/web serving. aws.amazon
- Evite para workloads single-instance/high-IOPS (prefira EBS) ou Windows-specific (FSx). Pague só pelo usado (GB-mês + throughput provisionado). bmc
- Ideal para Data Engineer: analytics (Spark/Hadoop), backups, containers/serverless. aws.amazon
Exemplos de cenários:
- Big Data/ML: Compartilhe datasets entre clusters EMR/EC2 para training models; EFS escala com dados crescendo. aws.amazon
- Dev/Test: Repositório comum de código/binários para múltiplas instâncias EC2; duplique ambientes rapidamente. amazonaws
- CMS/Web: Armazene assets (imagens/vídeos) acessados por múltiplos servers; lifecycle reduz custo para arquivos antigos. aws.amazon
- Lift-and-shift: Migre apps on-premises que usam NFS compartilhado. amazonaws
O que é o AWS Backup?
AWS Backup - Flashcard
O que é AWS Backup?
- AWS Backup é um serviço totalmente gerenciado que centraliza e automatiza a proteção de dados em serviços AWS (como EBS, EFS, RDS, DynamoDB, EC2, FSx) e workloads híbridas/on-premises. aws.amazon
- Permite criar políticas unificadas de backup com agendamento, retenção, criptografia KMS e cópias cross-region/account para conformidade e DR. n2ws
Como funciona?
- Crie Backup Vaults (contêineres seguros para armazenar recovery points com Vault Lock para imutabilidade WORM contra ransomware). notes.kodekloud
- Defina Backup Plans (o quê, quando, retenção, lifecycle para cold storage) e atribua a recursos via tags ou listas. docs.aws.amazon
- Backups são point-in-time (snapshots criptografados), monitorados via console/CloudWatch/CloudTrail/SNS; suporta restore granular. kindatechnical
Comparação com serviços similares AWS (snapshots nativos e Storage Gateway):
- Vs Snapshots nativos (EBS/RDS): AWS Backup centraliza multi-serviço com políticas automáticas/cross-account; snapshots são service-specific/manuais. Vantagem Backup: automação/compliance; desvantagem: custo extra para gerenciamento unificado vs snapshots gratuitos em alguns casos. aws.amazon
- Vs Storage Gateway: Backup é nativo-cloud/policy-based; Gateway é para hybrid com VMs locais. Vantagem Backup: serverless/escala; desvantagem: menos foco em migração on-prem contínua (use Gateway para tape/iSCSI). n2ws
Quando usar?
- Use para ambientes multi-serviço com necessidade de políticas centralizadas, compliance (audit logs, Vault Lock), DR cross-region e automação em escala. docs.aws.amazon
- Ideal para Data Engineer: backups de EFS/S3/EMR/DynamoDB em pipelines ETL/analytics. Pague por GB armazenado + requests (otimize com lifecycle). Evite para workloads simples/single-service (use snapshots nativos). n2ws
Exemplos de cenários:
- Analytics/ETL: Backup automatizado de EFS (datasets compartilhados) e DynamoDB (tabelas operacionais) com retenção 30 dias e cópia para outra região. aws.amazon
- DR/Compliance: Proteja RDS/EC2 com Vault Lock imutável; restaure em nova conta após incidente. deployflow
- Hybrid Workloads: Backup de VMware on-prem via AWS Backup para conformidade regulatória. aws.amazon
- Cost Optimization: Lifecycle move backups antigos para cold tier em vaults de EBS volumes de EMR clusters. aws.amazon
O que é Amazon S3 Select?
Amazon S3 Select - Flashcard
O que é Amazon S3 Select?
- Amazon S3 Select é um recurso do S3 que permite executar consultas SQL simples diretamente em objetos armazenados no bucket, filtrando e recuperando apenas os dados necessários sem baixar o arquivo inteiro. docs.aws.amazon
- Funciona com formatos CSV, JSON ou Parquet (comprimidos em GZIP/BZIP2), suportando criptografia SSE e retornando resultados em CSV ou JSON. Nota: Não disponível para novos clientes desde recentemente; existentes podem continuar usando. msp360
Como funciona?
- Envie uma requisição via Console, CLI, SDK ou API com expressão SQL (ex: SELECT * FROM s3object s WHERE s._1 = ‘valor’), especificando serialização de input/output e range de bytes opcional para paralelismo. docs.aws.amazon
- O S3 processa no servidor, reduzindo dados transferidos em até 80% e acelerando performance em até 400%; limites incluem 1 objeto por query (até 5TB), SQL até 256KB, registros até 1MB. youtube
- Permissões: s3:GetObject; resultados são streamados para economia de tempo/custo. docs.aws.amazon
Comparação com serviços similares AWS (Amazon Athena e S3 Glacier Select):
- Vs Athena: S3 Select querya 1 objeto por vez (rápido, barato para simples filtros); Athena querya múltiplos objetos/buckets com joins/group by/complex SQL (serverless, mas mais caro/lento para escala). Vantagem Select: latência baixa/custo mínimo; desvantagem: sem joins/multi-objeto. scaler
- Vs Glacier Select: S3 Select é para S3 standard (instantâneo); Glacier Select é para arquivos em Glacier (jobs assíncronos, armazena resultados em S3). Vantagem Select: real-time; desvantagem: não para storage frio. msp360
Quando usar?
- Use para filtrar grandes arquivos estruturados no S3 antes de processar (ETL, analytics iniciais), apps interativos ou quando quer evitar download total para reduzir custos/latência. docs.aws.amazon
- Ideal para Data Engineer: pré-filtrar logs/CSV/JSON em pipelines Glue/EMR. Evite para queries complexas/multi-arquivo (use Athena) ou não-estruturado. Pague por dados escaneados + requests (muito mais barato que transferir tudo). scaler
Exemplos de cenários:
- Análise de Logs: Em um bucket com 1GB de logs CSV, query SELECT * FROM s3object s WHERE s.timestamp > '2025-01-01' para extrair só eventos recentes, sem baixar tudo para EC2. msp360
- App Web Interativa: Filtre dataset de crimes JSON por localização/tipo para mapa no browser, reduzindo tempo de carregamento. msp360
- ETL Pré-processamento: Em pipeline Glue, use S3 Select para selecionar linhas onde vendas > 1000 de um Parquet gigante antes de carregar em Redshift. portal.tutorialsdojo
- IoT/Data Streaming: Extraia sensores específicos de arquivos JSON diários comprimidos, alimentando Lambda para alertas em tempo real. docs.aws.amazon
