Certificação AWS Solutions Architect Associate SAA-C03

Explicação: A recuperação flexível do Amazon S3 Glacier foi projetada para dados de longa duração e acessados ​​com pouca frequência, onde tempos de recuperação de minutos a horas são aceitáveis. Ele oferece um custo de armazenamento muito baixo por GB, ao mesmo tempo em que oferece suporte para recuperação mais rápida do que camadas de arquivamento que podem levar muitas horas ou dias. O requisito estabelece que os dados raramente são acessados ​​e devem ser recuperáveis ​​dentro de 12 horas. O Glacier Flexible Retrieval atende a esse requisito de tempo de recuperação e é mais econômico por GB do que as classes de armazenamento Standard e Infrequent Access para dados de longo prazo raramente acessados. S3 Standard, S3 Standard-IA e S3 One Zone-IA são otimizados para acesso mais frequente ou de latência mais baixa e têm custo de armazenamento por GB mais alto em comparação com Glacier Flexible Retrieval.

Explicação: O requisito tem duas partes: (1) avaliar contínua ou regularmente a idade da chave de acesso IAM em relação a uma política de 90 dias e (2) corrigir chaves não conformes, desativando-as e excluindo-as. O menor esforço operacional geralmente vem do uso de avaliação de conformidade gerenciada e correção leve sem servidor. O AWS Config foi projetado para avaliar a conformidade da configuração de recursos ao longo do tempo. Usar uma regra do AWS Config para verificar a idade da chave de acesso se ajusta ao modelo de governança porque o Config mantém um histórico de conformidade, oferece suporte a relatórios centrais e pode avaliar chaves em uma conta (e geralmente em uma organização com padrões de agregação). Após a detecção, a correção deve ser automatizada com infraestrutura mínima, e o AWS Lambda é a ferramenta operacional mais leve para chamar diretamente APIs IAM (UpdateAccessKey para Inactive e depois DeleteAccessKey) de acordo com um cronograma. A opção C os combina adequadamente: o Config realiza avaliação de conformidade e uma regra agendada do EventBridge aciona uma função Lambda para corrigir chaves com mais de 90 dias. Isso evita executar e manter frotas de computação ou infraestrutura em lote. Ele também fornece uma separação clara de tarefas: Configuração para detecção e evidência, Lambda para ação corretiva. As opções A, B e D dependem do AWS Batch, que introduz sobrecarga operacional adicional (ambientes de computação, definições de trabalho, filas, escalabilidade e monitoramento) desnecessária para uma tarefa simples de manutenção do IAM. Além disso, o EventBridge por si só não é um serviço de avaliação de conformidade; ele pode agendar um trabalho, mas não rastreia inerentemente o estado de "idade da chave" ou a postura de conformidade da mesma forma que o Config faz. Portanto, C atende melhor ao requisito com o menor esforço operacional usando o Config para visibilidade contínua da conformidade e um Lambda programado para desativação e exclusão automatizada de chaves.

Explicação: Uma réplica de leitura é a melhor resposta porque o novo aplicativo precisa ler dados que mudam frequentemente enquanto minimiza a carga no gravador de produção. As réplicas de leitura do Amazon RDS são projetadas para descarregar o tráfego de leitura da instância de banco de dados primária, o que melhora o desempenho geral da carga de trabalho principal. O ElastiCache não é a melhor opção porque o aplicativo raramente repete a mesma consulta, portanto, um cache não proporcionaria grandes benefícios. Um ALB não está relacionado à consulta de banco de dados e os instantâneos não são apropriados para consultar dados quase atuais. Como o requisito é um novo acesso de leitura com impacto mínimo no banco de dados primário, usar uma réplica de leitura é a escolha arquitetural correta. ============

Explicação: Amazon RDS Proxy: o RDS Proxy é um proxy de banco de dados totalmente gerenciado e altamente disponível que torna os aplicativos mais resilientes a falhas de banco de dados agrupando e compartilhando conexões, e pode lidar automaticamente com failovers de banco de dados. Tempo de failover reduzido: ao usar o RDS Proxy, o gerenciamento da conexão entre o aplicativo e o banco de dados é aprimorado, reduzindo significativamente os tempos de failover. O RDS Proxy mantém conexões em um pool de conexões e reduz o tempo necessário para restabelecer conexões durante um failover. Configuração: crie uma instância do RDS Proxy. Configure o proxy para se conectar à instância de banco de dados do RDS for PostgreSQL. Modifique a configuração do aplicativo para usar o endpoint do RDS Proxy em vez do endpoint direto do banco de dados. Benefícios operacionais: Esta solução oferece alta disponibilidade e reduz o tempo limite do aplicativo durante failovers com alterações mínimas no código do aplicativo. Referência: Amazon RDS Proxy Configurando o RDS Proxy

Explicação: O Amazon API Gateway fornece uma solução escalável e reutilizável para interagir com o DynamoDB sem exigir acesso direto dos desenvolvedores. Ao configurar uma API REST com um método POST que se integra à ação PutItem do DynamoDB, os desenvolvedores podem enviar dados (como classificações de usuários) para a tabela do DynamoDB por meio do API Gateway, sem precisar interagir diretamente com o banco de dados. Esta solução não tem servidor e minimiza a sobrecarga operacional. Opção A: Usar ALB com Lambda adiciona complexidade e é menos eficiente para este caso de uso. Opção B: embora seja possível usar o Lambda, o API Gateway fornece uma interface mais escalonável e reutilizável. Opção C: SQS com Lambda introduz componentes desnecessários para uma operação simples de venda. Referência da AWS: Amazon API Gateway com DynamoDB

Explicação:

Explicação: A implantação do aplicativo Web em instâncias do EC2 em sub-redes privadas atrás de um ALB interno garante que o aplicativo não seja acessível diretamente pela Internet. Ao configurar uma conexão VPN site a site, o aplicativo pode ser acessado com segurança a partir da rede do escritório da empresa. A implantação de gateways NAT em sub-redes públicas permite que instâncias em sub-redes privadas iniciem conexões de saída com a Internet para baixar patches de segurança. Referência: Exemplo: VPC com servidores em sub-redes privadas e documentação NATAWS

Explicação: O Amazon Aurora PostgreSQL com Babelfish permite que aplicativos SQL Server sejam executados diretamente no Aurora PostgreSQL com alterações mínimas de código. O Babelfish adiciona um endpoint compatível com SQL Server, reduzindo significativamente os custos em comparação com a execução de instâncias licenciadas do SQL Server em RDS ou EC2. Extrato de documentação da AWS: "O Babelfish para Aurora PostgreSQL permite que o Aurora entenda o protocolo de conexão T-SQL e SQL Server, permitindo que você execute aplicativos SQL Server no Amazon Aurora PostgreSQL com custos mais baixos." (Fonte: documentação do Babelfish para Aurora PostgreSQL) A, D: SQL Server em EC2 ou RDS incorre em altos custos de licenciamento da Microsoft. C: O PostgreSQL simples exigiria mais refatoração de código do que o Babelfish. Referência: Guia de estudo oficial do AWS Certified Solutions Architect, Babelfish e otimização de custos.

Explicação: A solução mais econômica e de baixa manutenção para agregar dados S3 de várias contas na mesma região da AWS é usar a replicação na mesma região (SRR) do Amazon S3. Da documentação do AWS S3: "S3 Same-Region Replication (SRR) replica automaticamente novos objetos entre buckets na mesma região da AWS. O SRR é comumente usado para agregar logs em um único bucket, simplificar a agregação de dados e atender aos requisitos de conformidade." (Fonte: Visão geral da replicação do guia do usuário do Amazon S3) Principais benefícios do uso de SRR para este caso de uso: Zero sobrecarga operacional Sem Lambda, scripts ou código personalizado Totalmente gerenciado AWS lida com toda a replicação automaticamente Seguro e eficiente Nenhum dado sai da região us-west-2 Suporta replicação entre contas Com funções e permissões de IAM adequadas Baixo custo Em comparação com pipelines ETL personalizados ou soluções Lambda Em contraste: a opção A (políticas de ciclo de vida) não suporta cópia, apenas expiração, transições ou exclusões. A opção C (scripts) requer agendamento e manutenção personalizados, aumentando a sobrecarga operacional. A opção D (Lambda) acrescenta complexidade e custo e não é tão escalonável ou independente quanto o SRR. Referência: Guia do usuário do Amazon S3 "Usando replicação na mesma região (SRR)" Pilar de otimização de custos do AWS Well-Architected Framework Práticas recomendadas da AWS para agregação de dados e replicação S3

Explicação: O AWS Key Management Service (AWS KMS) oferece suporte a chaves multirregionais, que são chaves mestras gerenciadas do cliente que podem ser replicadas para várias regiões e tratadas como uma única chave lógica. Isso permite que aplicativos em diferentes regiões criptografem e descriptografem dados usando chaves equivalentes, enquanto a AWS cuida da replicação, durabilidade e disponibilidade de chaves. O KMS é um serviço de chaves totalmente gerenciado, portanto a empresa não precisa operar hardware ou gerenciar armazenamento de chaves de baixo nível. As tags combinadas com o controle de acesso baseado em atributos (ABAC) permitem impor acesso refinado às chaves usando políticas e chaves de condição do IAM, proporcionando controle de acesso centralizado e flexível com baixa sobrecarga operacional. O CloudHSM (opções C e D) requer gerenciamento de clusters HSM, escalabilidade, backups e operações manuais de chaves, o que aumenta significativamente a carga operacional. A importação de material de chave no KMS (Opção B) adiciona complexidade ao ciclo de vida e é desnecessária quando existem chaves nativas de várias regiões.