Arquiteturas de alto desempenho

Armazenamento por caso de uso: S3, EBS, EFS e FSx

Quase todo cenário de desempenho começa escolhendo onde o dado mora, e a prova monta as alternativas com os quatro serviços para ver se você sabe a diferença entre bloco, arquivo e objeto. Depois vem a segunda camada: qual classe do S3 e qual tipo de EBS, que é onde entra o custo.

Como cai: Várias instâncias precisam ler e gravar nos mesmos arquivos ao mesmo tempo. Qual serviço de armazenamento usar?

Erros comuns

• ×Propor EBS para compartilhar arquivos entre instâncias. Um volume EBS comum anexa a uma instância por vez; compartilhamento entre várias é EFS (Linux) ou FSx (Windows).
• ×Achar que S3 é sistema de arquivos. É armazenamento de objetos, acessado por API: não dá para montar e fazer a aplicação legada gravar nele como se fosse disco sem uma camada no meio.
• ×Escolher classe de arquivamento para dado acessado com frequência. Glacier cobra recuperação e tem tempo de espera; economia de armazenamento vira custo de acesso.
• ×Esquecer o mínimo de armazenamento das classes frias. Standard-IA e One Zone-IA cobram 30 dias mínimos e por objeto de 128 KB; para dado que muda toda hora, saem mais caras que a Standard.
• ×Usar One Zone-IA para dado que não pode ser perdido. Ela vive em uma única zona: se a zona se perde, o dado se perde.
• ×Trocar gp3 por io2 sem o enunciado pedir IOPS muito alta ou durabilidade de nível de banco crítico. gp3 já entrega IOPS e vazão configuráveis, e é mais barato.

Computação: famílias EC2, containers e serverless

É a escolha que aparece em cenário de desempenho e reaparece em custo. A prova testa duas coisas: ler o perfil da carga (CPU, memória, rede, GPU) para achar a família, e saber quando o serverless resolve — o que quase sempre é a resposta quando o enunciado diz 'menor esforço operacional' e a carga é intermitente.

Como cai: A carga é intermitente, dura poucos segundos por execução e a equipe não quer gerenciar servidores. Onde rodar?

Erros comuns

• ×Escolher Lambda para processamento longo. O tempo máximo de execução é de 15 minutos; carga que passa disso é container ou instância.
• ×Achar que EKS é sempre melhor que ECS. EKS traz Kubernetes e o ecossistema dele, com mais complexidade; ECS é mais simples e integrado. Sem exigência de Kubernetes no enunciado, ECS é a resposta de menor esforço.
• ×Confundir Fargate com ECS ou EKS. Fargate não é orquestrador: é o modo de execução sem gerenciar instâncias, que tanto ECS quanto EKS podem usar.
• ×Ignorar a família da instância. A letra indica o perfil: M para equilíbrio, C para computação, R e X para memória, T para carga intermitente com créditos, G e P para GPU, I e D para armazenamento local.
• ×Esquecer os créditos das instâncias da família T. Elas acumulam e gastam crédito de CPU; carga sustentada esgota o crédito e a instância passa a andar devagar ou a cobrar por excedente.
• ×Propor Lambda para carga constante e alta. Cobrança por invocação e duração compensa em carga intermitente; para carga previsível e contínua, instância com compromisso costuma sair mais barata.

Vocabulário

Fargate

— Modo de execução sem servidor para containers. Não é orquestrador: tanto o ECS quanto o EKS podem rodar suas tarefas em Fargate, deixando de gerenciar as instâncias que as hospedam.

Cache e entrega de conteúdo: CloudFront, ElastiCache e DAX

Cache é a resposta de desempenho mais barata, e por isso aparece muito. A prova testa se você põe o cache na camada certa: usuário distante reclamando de lentidão é borda; banco sobrecarregado com a mesma consulta é cache de dados. Trocar as duas é o erro que a questão procura.

Como cai: O mesmo conjunto de consultas está sobrecarregando o banco e a latência subiu. Qual a solução de MENOR esforço?

Erros comuns

• ×Usar CloudFront para aliviar consulta repetida ao banco vinda de dentro da aplicação. CloudFront é cache de borda para conteúdo entregue a clientes; consulta interna é ElastiCache ou DAX.
• ×Usar ElastiCache para conteúdo estático de site global. Funciona, e ignora que o CloudFront já resolve isso na borda, mais perto do usuário e com menos código.
• ×Escolher Memcached quando o enunciado pede persistência, réplicas, failover ou estruturas de dados. Isso é Redis; Memcached é cache simples, multithread e sem persistência.
• ×Achar que DAX serve para qualquer banco. DAX é específico do DynamoDB; para relacional, é ElastiCache.
• ×Esquecer que cache exige estratégia de invalidação. Dado que muda e cache sem TTL ou sem escrita explícita produz resposta velha, que é pior que resposta lenta.
• ×Ignorar que o CloudFront também acelera conteúdo dinâmico e requisição não cacheável, pela rede da AWS até a origem.

Vocabulário

DAX

— Cache em memória gerenciado, exclusivo do DynamoDB, compatível com a mesma API. Reduz leituras de milissegundos para microssegundos sem alterar o código da aplicação.

Qual banco para qual caso de uso

A AWS tem um banco para cada forma de dado, e a prova aposta que você vai escolher pelo nome conhecido em vez do caso de uso. Reconhecer a assinatura de cada um — 'relacionamentos entre entidades' é grafo, 'agregação sobre bilhões de linhas' é data warehouse — elimina três alternativas de imediato.

Como cai: A consulta precisa percorrer relacionamentos entre pessoas e contas a várias profundidades. Qual banco?

Erros comuns

• ×Usar Redshift para carga transacional. Ele é colunar e massivamente paralelo, desenhado para agregação analítica; transação frequente e pequena é RDS ou DynamoDB.
• ×Usar DynamoDB quando o enunciado exige consultas relacionais variadas e junções. DynamoDB brilha com padrões de acesso conhecidos e chave bem escolhida; consulta ad hoc arbitrária é relacional.
• ×Achar que OpenSearch é banco primário. Ele é motor de busca e análise de log; o dado costuma ter uma fonte de verdade em outro lugar.
• ×Propor um banco relacional para percorrer relacionamentos profundos. Cada nível vira uma junção; grafo (Neptune) foi feito para isso.
• ×Confundir DocumentDB com DynamoDB. DocumentDB é compatível com MongoDB, para documentos com consultas ricas; DynamoDB é chave-valor de escala massiva.
• ×Esquecer o Athena. Consultar dados que já estão no S3, sem carregar em banco nenhum, é Athena; propor Redshift nesse caso adiciona uma etapa que o enunciado não pediu.

Rede de alto desempenho e conectividade híbrida

Fecha o Domínio 3 e reaparece em custo e resiliência. A prova cobra três decisões: acelerar o trajeto de rede sem cache (Global Accelerator, que quase todo mundo confunde com CloudFront), ligar o data center à AWS (Direct Connect ou VPN, e a combinação dos dois), e conectar muitas VPCs sem virar uma teia.

Como cai: O tráfego é TCP, não pode ser cacheado, e usuários distantes reclamam de latência instável. O que usar?

Erros comuns

• ×Confundir Global Accelerator com CloudFront. CloudFront guarda conteúdo na borda; Global Accelerator não guarda nada, ele melhora o caminho até a aplicação e dá IPs anycast estáticos. Tráfego não HTTP ou não cacheável é Accelerator.
• ×Achar que Direct Connect é criptografado por padrão. É uma conexão dedicada e privada, mas sem criptografia; quando o enunciado exige criptografia em trânsito, a resposta acrescenta uma VPN por cima, ou MACsec.
• ×Propor Direct Connect para uma necessidade imediata. A provisão leva semanas ou meses; quando o enunciado diz 'rapidamente' ou 'em dias', a resposta é VPN, eventualmente como ponte até o Direct Connect ficar pronto.
• ×Usar peering de VPC para muitas VPCs. Peering não é transitivo e o número de conexões cresce ao quadrado; a partir de algumas VPCs, a resposta é Transit Gateway.
• ×Esquecer que uma única conexão Direct Connect é ponto único de falha. Alta disponibilidade exige duas conexões, idealmente em locais diferentes, ou uma VPN de contingência.
• ×Misturar grupo de posicionamento cluster com spread. Cluster aproxima para latência mínima; spread separa para reduzir falha correlacionada. São objetivos opostos.

Vocabulário

Direct Connect

— Conexão dedicada entre o data center e a AWS, sem passar pela internet, com banda consistente e latência previsível. Provisão leva semanas ou meses, e não é criptografada por padrão.

VPN site a site

— Túnel criptografado sobre a internet. Sobe em horas, custa pouco e herda a variabilidade da internet pública.

Ingestão e análise de dados: Kinesis, Glue, EMR e Lake Formation

O guia da SAA-C03 tem uma tarefa só para isto (3.5, ingestão e transformação de alto desempenho) e quem vem de infraestrutura costuma chutar. As questões seguem um roteiro fixo: a frequência do dado escolhe entre fluxo e lote, a palavra 'consumidor próprio' separa Data Streams de Firehose, 'converter CSV em Parquet' aponta Glue, e 'Spark ou Hadoop' aponta EMR.

Como cai: Sensores enviam eventos a cada segundo; a empresa quer guardá-los no S3 em Parquet com o MENOR esforço operacional. O que usar?

Erros comuns

• ×Propor Kinesis Data Streams quando o enunciado só quer entregar o fluxo no S3 ou no Redshift. Data Streams exige escrever e operar consumidores; se ninguém precisa processar registro a registro, Firehose entrega sozinho e é a resposta de menor esforço.
• ×Propor Firehose quando o enunciado pede vários consumidores lendo o mesmo fluxo em paralelo, ou reprocessar registros das últimas horas. Firehose entrega e esquece; retenção e leitura por aplicação própria são Data Streams.
• ×Escolher EMR para converter arquivos de formato. Glue é sem servidor e faz isso com um job; EMR só ganha quando o enunciado cita Spark, Hadoop, Hive ou controle do cluster.
• ×Usar SQS para ingestão de telemetria. Fila entrega cada mensagem a um consumidor e apaga; fluxo mantém a ordem por chave e permite vários leitores. 'Eventos por segundo, em ordem, para análise' é Kinesis.
• ×Resolver permissão por coluna com política de bucket. Política de bucket enxerga objeto, não coluna; permissão por tabela e coluna sobre o data lake é Lake Formation.
• ×Transferir terabytes de um servidor local com um script de cópia para o S3. Transferência recorrente e gerenciada entre local e AWS é DataSync; acesso contínuo de aplicação local a arquivos no S3 é Storage Gateway.