Certificação AWS Solutions Architect Associate SAA-C03

Explicação: o Amazon S3 é o serviço de armazenamento mais econômico para coleções grandes e crescentes de arquivos de imagem, e o Amazon CloudFront é a maneira padrão de entregar esses objetos globalmente com baixa latência. A documentação da AWS afirma que o CloudFront pode usar um bucket S3 como origem e armazenar em cache os objetos em pontos de presença em todo o mundo. Isso reduz a latência para os visualizadores e reduz a carga repetida na origem. EBS, EFS e FSx não são os mais adequados para entrega de objetos voltados para a Internet em larga escala porque não são serviços de distribuição de objetos globais desenvolvidos especificamente. Portanto, S3 mais CloudFront é a arquitetura correta e mais econômica para entrega global de imagens em escala. ============

Explicação: SSE-KMS: a criptografia no lado do servidor com AWS Key Management Service (SSE-KMS) fornece criptografia robusta de dados em repouso, integrada ao AWS KMS para gerenciamento de chaves e auditoria. Rotação automática de chaves: ao permitir a rotação automática das chaves KMS, o sistema garante que as chaves sejam rotacionadas anualmente sem intervenção manual, atendendo aos requisitos de conformidade. Registro e auditoria: o AWS KMS registra automaticamente todas as principais ações de uso e gerenciamento no AWS CloudTrail, fornecendo os logs de auditoria necessários. Implementação: crie uma chave KMS com rotação automática habilitada. Configure o bucket S3 para usar SSE-KMS com a chave KMS criada. Certifique-se de que o CloudTrail esteja habilitado para registrar o uso da chave KMS. Eficiência operacional: esta solução fornece criptografia, gerenciamento automático de chaves e auditoria de maneira integrada e totalmente gerenciada, reduzindo a sobrecarga operacional. Referência: Rotação automática de chaves do AWS KMS Criptografia no lado do servidor do Amazon S3

Explicação: Para garantir alta disponibilidade e escalabilidade, o aplicativo Web deve ser executado em um grupo de Auto Scaling em duas zonas de disponibilidade atrás de um Application Load Balancer (ALB). O banco de dados deve ser migrado para Amazon RDS com implantação Multi-AZ, o que garante tolerância a falhas e failover automático em caso de falha de AZ. Essa configuração minimiza a sobrecarga administrativa e atende aos requisitos da empresa em termos de alta disponibilidade e escalabilidade. Opção A: réplicas de leitura normalmente são usadas para dimensionar operações de leitura, e o Multi-AZ fornece melhor disponibilidade para um banco de dados transacional. Opção B: replicar entre regiões da AWS adiciona complexidade desnecessária para um único aplicativo Web. Opção D: Instâncias EC2 em três zonas de disponibilidade adicionam complexidade desnecessária a este cenário. Referência da AWS: grupos de Auto Scaling Amazon RDS Multi-AZ

Explicação:

Explicação: Para autenticar usuários usando um Active Directory Federation Service (AD FS) local, a AWS fornece o AWS Directory Service AD ​​Connector. O AD Connector é um proxy que conecta aplicativos da AWS ao Microsoft Active Directory local sem exigir sincronização complexa de diretórios ou a necessidade de configurar um diretório separado na nuvem. Ao integrar o AD Connector ao Application Load Balancer (ALB), você pode autenticar e autorizar usuários usando suas credenciais locais existentes. Essa configuração permite que o ALB aproveite os recursos de autenticação do seu AD FS local, proporcionando uma experiência de usuário segura e contínua. Referência: como conectar seu Active Directory local à AWS usando o AD Connector AWS Directory Service AD ​​Connector

Explicação: Amazon Managed Service for Apache Flink (anteriormente Kinesis Data Analytics) é um serviço totalmente gerenciado e sem servidor para processamento em tempo real de dados de streaming. Você pode consumir dados do Kinesis Data Streams, realizar a detecção de anomalias e, em seguida, enviar os resultados para outro stream do Kinesis. Essa abordagem é fracamente acoplada, totalmente gerenciada e não requer modificação do código do aplicativo. Extrato de documentação da AWS: "O Amazon Managed Service para Apache Flink permite processar dados de streaming em tempo real, integrando-se ao Kinesis Data Streams como origem e coletor, e é totalmente gerenciado e sem servidor." (Fonte: Apache Flink na documentação da AWS) B: S3/Redshift não funciona em tempo real e adiciona complexidade. C, D: As soluções EC2/ECS não são sem servidor nem totalmente gerenciadas. Referência: Guia de estudo oficial do AWS Certified Solutions Architect, Real-Time Analytics.

Explicação: Quando uma função do AWS Lambda é invocada, especialmente após períodos de inatividade, ela pode sofrer inicializações a frio que atrasam a execução. À medida que a demanda aumenta, o comportamento de escalonamento e a latência do Lambda podem afetar o desempenho. Simultaneidade provisionada é um recurso da AWS projetado especificamente para resolver esse problema. Da documentação da AWS: "A simultaneidade provisionada mantém as funções inicializadas e hiperprontas para responder em milissegundos de dois dígitos." (Fonte: Guia do desenvolvedor do AWS Lambda Gerenciando simultaneidade) Por que a opção D está correta: A simultaneidade provisionada garante que um número especificado de instâncias de função Lambda estejam sempre quentes e prontas para atender solicitações, eliminando a latência de inicialização a frio. É econômico para cargas de trabalho com padrões de uso consistentes, como simulações em tempo real para um pequeno grupo de usuários. Mantém a escalabilidade e a baixa sobrecarga do Lambda sem migrar para contêineres gerenciados ou plataformas EC2. Por que as outras opções são menos ideais: Opção A (Fargate) e Opção B (EC2): introduzem mais infraestrutura e custos contínuos mais elevados para uma equipe pequena com uso provavelmente intermitente. Opção C (AWS Batch): Ideal para trabalhos em lote, não para simulações em tempo real; também incorre em maior latência devido ao enfileiramento de trabalhos. Referência: Guia do desenvolvedor do AWS Lambda "Simultaneidade e escalonamento" Pilar de eficiência de desempenho do AWS Well-Architected Framework Comparação de serviços de computação da AWS Lambda vs EC2 vs Fargate

Explicação: Para logs que são: Gravados e processados ​​em um curto período (24 horas) Acessados ​​rapidamente para computação/análise Com contagem e tamanho de objetos desconhecidos, o Amazon S3 Standard é o mais apropriado e econômico. O Intelligent-Tiering foi projetado para dados armazenados por períodos mais longos (normalmente mais de 30 dias) com padrões de acesso variáveis ​​e cobra uma taxa de monitoramento e automação por objeto que se torna ineficiente para objetos de vida muito curta. O S3 Glacier Deep Archive e o S3 One Zone-IA são otimizados para arquivamento de longo prazo ou dados acessados ​​com pouca frequência com tempo de recuperação ou restrições de disponibilidade que não são adequados para processamento ativo noturno.

Explicação: Os requisitos são suporte UDP, latência ultrabaixa e capacidade de lidar com milhões de solicitações por segundo de maneira econômica. Network Load Balancer (NLB) é o serviço da AWS projetado para balanceamento de carga de camada 4 de alto desempenho, incluindo TCP, TLS e UDP. O NLB pode ser dimensionado para taxas de transferência e conexão muito altas, mantendo baixa latência, o que é fundamental para o tráfego de jogos em tempo real. A opção C está correta porque o NLB oferece suporte a ouvintes UDP e encaminha o tráfego diretamente para destinos EC2 com sobrecarga mínima de processamento. Isso produz latência mais baixa do que as soluções da Camada 7 e é adequado para protocolos de jogos sensíveis à latência e que geralmente usam UDP para comunicação rápida e leve. O NLB também fornece endereços IP estáticos por zona de disponibilidade e integra-se perfeitamente aos grupos do Auto Scaling. A opção A está incorreta porque um Application Load Balancer opera na camada 7 (HTTP/HTTPS) e não processa tráfego UDP bruto; é otimizado para aplicativos da web, não para protocolos de jogos. A opção B está incorreta porque o Gateway Load Balancer se destina a implantar e dimensionar dispositivos virtuais de terceiros (como firewalls) e usa o encapsulamento Geneve; não se destina à distribuição do tráfego geral de jogos da Internet para servidores de jogos EC2. A Opção D adiciona custos e complexidade significativos ao implantar

Explicação: A opção A é a melhor resposta porque introduz tanto a dissociação como a escalabilidade horizontal com uma gestão mínima da infra-estrutura. O API Gateway fornece uma porta de entrada gerenciada para os microsserviços, o Lambda fornece computação sem servidor que se adapta ao volume de solicitações e o SQS fornece buffer durável entre estágios transacionais, como criação de pedidos e processamento de pagamentos. A AWS recomenda a dissociação baseada em filas quando produtores e consumidores operam em velocidades diferentes ou quando os picos precisam ser absorvidos sem perda de trabalho. As alternativas EKS e EC2 acrescentam significativamente mais carga operacional, e o cache não resolve o principal problema de dimensionamento do fluxo de trabalho. Portanto, uma arquitetura de microsserviços sem servidor usando API Gateway, Lambda e SQS é a melhor opção. ============