Guia Exaustivo para o Exame AWS Certified Solutions Architect – Professional (SAP-C02)

Este documento tem como objetivo fornecer um guia completo e detalhado para o exame AWS Certified Solutions Architect – Professional (SAP-C02), cobrindo todos os tópicos e subdomínios conforme o guia oficial da AWS. O conteúdo será estruturado para facilitar o estudo, a consulta rápida e a compreensão aprofundada dos conceitos necessários para a certificação.

Domínios do Exame e Pesos

O exame SAP-C02 é dividido em quatro domínios principais, cada um com um peso específico no conteúdo avaliado:

• Domínio 1: Design de Soluções para Complexidade Organizacional (26% do conteúdo)
• Domínio 2: Design para Novas Soluções (29% do conteúdo)
• Domínio 3: Melhoria Contínua para Soluções Existentes (25% do conteúdo)
• Domínio 4: Acelerar a Migração e Modernização de Workloads (20% do conteúdo)

Domínio 1: Design de Soluções para Complexidade Organizacional

Este domínio foca na capacidade de projetar soluções que abordem os desafios de ambientes complexos e em larga escala, incluindo estratégias de rede, segurança, governança e gerenciamento de contas.

Tópicos e Subtópicos:

1.1. Arquitetar estratégias de conectividade de rede.

• Conhecimento de:
  • Infraestrutura Global da AWS
  • Conceitos de rede AWS (por exemplo, Amazon Virtual Private Cloud [Amazon VPC], AWS Direct Connect, AWS VPN, roteamento transitivo, serviços de contêiner AWS)
  • Conceitos de DNS híbrido (por exemplo, Amazon Route 53 Resolver, integração de DNS on-premises)
  • Segmentação de rede (por exemplo, sub-redes, endereçamento IP, conectividade entre VPCs)
  • Monitoramento de tráfego de rede

1.2. Arquitetar estratégias de segurança para ambientes complexos.

• Conhecimento de:
  • AWS Organizations e Unidades Organizacionais (OUs)
  • Service Control Policies (SCPs)
  • AWS Identity and Access Management (IAM) avançado (por exemplo, permission boundaries, ABAC, roles cross-account)
  • AWS Security Hub, Amazon GuardDuty, Amazon Detective, AWS Config, AWS Inspector
  • Gerenciamento de chaves (por exemplo, AWS Key Management Service [AWS KMS] multi-região)
  • Segurança de dados (por exemplo, criptografia em trânsito e em repouso, tokenização, mascaramento de dados)
  • Gerenciamento de segredos (por exemplo, AWS Secrets Manager)
  • Auditoria e log (por exemplo, AWS CloudTrail, Amazon CloudWatch Logs)
  • Princípio do menor privilégio

1.3. Arquitetar estratégias de governança e conformidade.

• Conhecimento de:
  • AWS Control Tower
  • AWS Config e Conformance Packs
  • AWS Audit Manager
  • AWS License Manager
  • AWS Systems Manager
  • AWS Resource Access Manager (AWS RAM)
  • AWS Service Catalog
  • AWS Organizations e gerenciamento de contas
  • Tags e políticas de tagging

1.4. Arquitetar estratégias de gerenciamento de contas e multi-contas.

• Conhecimento de:
  • AWS Organizations e OUs
  • AWS Control Tower
  • AWS Single Sign-On (AWS SSO)
  • AWS IAM Identity Center
  • Landing Zones
  • AWS Resource Access Manager (AWS RAM)
  • Compartilhamento de recursos entre contas
  • Faturamento consolidado

Domínio 2: Design para Novas Soluções

Este domínio aborda a capacidade de projetar novas soluções na AWS, focando na escolha de serviços, padrões de arquitetura, resiliência, escalabilidade e otimização de performance.

Tópicos e Subtópicos:

2.1. Arquitetar soluções de computação.

• Conhecimento de:
  • Amazon EC2 (por exemplo, instâncias spot/mixed fleets, Auto Scaling)
  • AWS Lambda
  • Containers (por exemplo, Amazon Elastic Container Service [Amazon ECS], Amazon Elastic Kubernetes Service [Amazon EKS], AWS Fargate)
  • AWS Outposts
  • AWS Wavelength
  • AWS Local Zones
  • AWS Batch
  • AWS ParallelCluster
  • AWS Serverless Application Model (AWS SAM)
  • AWS Amplify

2.2. Arquitetar soluções de armazenamento.

• Conhecimento de:
  • Amazon S3 (por exemplo, classes de armazenamento, pontos de acesso, políticas de ciclo de vida)
  • Amazon Elastic File System (Amazon EFS)
  • Amazon FSx (por exemplo, FSx for Lustre, FSx for Windows File Server, FSx for NetApp ONTAP)
  • Amazon Elastic Block Store (Amazon EBS)
  • AWS Backup
  • Amazon Glacier
  • AWS Storage Gateway
  • AWS Snow Family

2.3. Arquitetar soluções de banco de dados.

• Conhecimento de:
  • Amazon Relational Database Service (Amazon RDS)
  • Amazon Aurora
  • Amazon DynamoDB
  • Amazon DocumentDB (com compatibilidade MongoDB)
  • Amazon Neptune
  • Amazon Redshift
  • Amazon ElastiCache
  • Amazon Quantum Ledger Database (Amazon QLDB)
  • Amazon Managed Blockchain
  • Amazon Keyspaces (para Apache Cassandra)
  • Amazon Timestream
  • Amazon Kinesis
  • AWS Database Migration Service (AWS DMS)
  • AWS Schema Conversion Tool (AWS SCT)

2.4. Arquitetar soluções de rede.

• Conhecimento de:
  • Amazon VPC (por exemplo, sub-redes, tabelas de rotas, gateways de internet, gateways NAT, endpoints de VPC)
  • AWS Transit Gateway
  • AWS PrivateLink
  • VPC Peering
  • AWS Direct Connect
  • AWS VPN
  • Amazon Route 53 (por exemplo, DNS multi-região, políticas de roteamento)
  • Amazon CloudFront (por exemplo, URLs assinadas, cookies assinados, geo-restrições)
  • AWS Global Accelerator
  • AWS App Mesh
  • AWS Cloud Map
  • VPC Lattice

2.5. Arquitetar soluções de mensageria e integração.

• Conhecimento de:
  • Amazon Simple Notification Service (Amazon SNS)
  • Amazon Simple Queue Service (Amazon SQS)
  • Amazon EventBridge
  • AWS Step Functions
  • Amazon Kinesis (por exemplo, Kinesis Data Streams, Kinesis Data Firehose, Kinesis Data Analytics)
  • Amazon Managed Streaming for Apache Kafka (Amazon MSK)
  • AWS AppSync
  • Amazon API Gateway
  • AWS IoT Core

Domínio 3: Melhoria Contínua para Soluções Existentes

Este domínio concentra-se na otimização e aprimoramento de arquiteturas existentes para melhorar a performance, resiliência, segurança e eficiência operacional.

Tópicos e Subtópicos:

3.1. Arquitetar soluções para alta disponibilidade e resiliência.

• Conhecimento de:
  • Estratégias de recuperação de desastres (por exemplo, RTO, RPO, padrões de DR: backup e restauração, piloto leve, multi-site ativo-ativo)
  • AWS Well-Architected Framework (Pilar de Confiabilidade)
  • Amazon Route 53 (por exemplo, failover, roteamento baseado em latência)
  • AWS Global Accelerator
  • Elastic Load Balancing (ELB)
  • Amazon EC2 Auto Scaling
  • Amazon CloudFront
  • AWS Shield, AWS WAF
  • Circuit Breaker pattern
  • Sagas pattern

3.2. Arquitetar soluções para otimização de performance.

• Conhecimento de:
  • AWS Well-Architected Framework (Pilar de Performance Efficiency)
  • Otimização de computação (por exemplo, escolha de instâncias, otimização de containers, Lambda provisioned concurrency)
  • Otimização de armazenamento (por exemplo, escolha de classes de S3, otimização de EBS, EFS, FSx)
  • Otimização de banco de dados (por exemplo, escolha de tipo de DB, otimização de consultas, caching com ElastiCache)
  • Otimização de rede (por exemplo, Direct Connect, Global Accelerator, CloudFront)
  • Caching (por exemplo, Amazon CloudFront, Amazon ElastiCache, AWS Global Accelerator)
  • Content Delivery Networks (CDNs)

3.3. Arquitetar soluções para monitoramento e observabilidade.

• Conhecimento de:
  • Amazon CloudWatch (por exemplo, métricas, logs, alarmes, dashboards)
  • AWS X-Ray
  • AWS CloudTrail
  • AWS Config
  • Amazon Kinesis (para ingestão de logs e métricas)
  • AWS Systems Manager (por exemplo, OpsCenter, Explorer)
  • AWS Health Dashboard
  • AWS Trusted Advisor
  • Feature flags com CloudWatch Evidently

3.4. Arquitetar soluções para segurança contínua.

• Conhecimento de:
  • AWS Security Hub, Amazon GuardDuty, Amazon Detective, AWS Inspector
  • AWS WAF, AWS Shield
  • AWS Firewall Manager
  • AWS Certificate Manager (ACM)
  • AWS Secrets Manager
  • AWS Systems Manager Parameter Store
  • AWS Single Sign-On (AWS SSO) / AWS IAM Identity Center
  • Princípio do menor privilégio
  • Automação de segurança (por exemplo, AWS Security Hub, AWS Config Rules)

Domínio 4: Acelerar a Migração e Modernização de Workloads

Este domínio aborda as estratégias e ferramentas para migrar e modernizar workloads para a AWS, incluindo a avaliação, planejamento e execução de migrações complexas.

Tópicos e Subtópicos:

4.1. Arquitetar estratégias de migração.

• Conhecimento de:
  • Estratégias de migração (por exemplo, 7 Rs: Rehost, Replatform, Refactor/Re-architect, Repurchase, Retain, Retire, Relocate)
  • AWS Migration Acceleration Program (MAP)
  • AWS Application Migration Service (AWS MGN)
  • AWS Database Migration Service (AWS DMS)
  • AWS Schema Conversion Tool (AWS SCT)
  • AWS DataSync
  • AWS Snow Family
  • AWS Transfer Family
  • AWS Direct Connect
  • AWS VPN
  • AWS CloudEndure Migration

4.2. Arquitetar estratégias de modernização.

• Conhecimento de:
  • Modernização de aplicações (por exemplo, microsserviços, serverless, containers)
  • Refatoração de código
  • Uso de serviços gerenciados (por exemplo, Amazon RDS, Amazon DynamoDB, AWS Lambda)
  • Integração de serviços (por exemplo, Amazon EventBridge, AWS Step Functions)
  • Padrões de modernização (por exemplo, Strangler Fig, Branch by Abstraction)
  • Ferramentas de modernização (por exemplo, AWS Migration Hub Refactor Spaces, AWS App2Container)

4.3. Arquitetar estratégias de otimização de custos.

• Conhecimento de:
  • AWS Well-Architected Framework (Pilar de Otimização de Custos)
  • Modelos de precificação da AWS (por exemplo, On-Demand, Reserved Instances [RIs], Savings Plans, Spot Instances)
  • Otimização de recursos (por exemplo, dimensionamento correto, desligamento de recursos ociosos)
  • AWS Cost Explorer, AWS Budgets, AWS Cost Anomaly Detection
  • AWS Compute Optimizer
  • AWS Trusted Advisor (Otimização de Custos)
  • Políticas de ciclo de vida do Amazon S3
  • Otimização de rede (por exemplo, uso de CloudFront, Direct Connect)

Novidades Relevantes (Exemplos)

• IAM Roles Anywhere
• VPC Lattice
• CloudFront Signed URLs
• Feature flags com CloudWatch Evidently

Tabelas Comparativas e Cenários Práticos

Esta seção será preenchida com tabelas comparativas detalhadas, exemplos de cenários práticos que caem na prova, decisões arquiteturais e armadilhas comuns, consolidando o aprendizado e facilitando a consulta rápida.

Este documento será continuamente expandido e detalhado em cada um dos tópicos e subtópicos listados, fornecendo um guia completo para a preparação do exame SAP-C02.

1.1. Arquitetar estratégias de conectividade de rede.

Conceitos Fundamentais e Avançados

A conectividade de rede em um ambiente AWS complexo é a espinha dorsal de qualquer arquitetura bem-sucedida. Ela abrange desde a conectividade básica dentro de uma VPC até topologias de rede híbridas e globais. O exame SAP-C02 espera que o candidato tenha um profundo conhecimento sobre como projetar, proteger e otimizar essas conexões.

Infraestrutura Global da AWS: A AWS possui uma infraestrutura global composta por Regiões, Zonas de Disponibilidade (AZs), Local Zones, Wavelength Zones e Pontos de Presença (PoPs). Compreender como esses componentes se interligam é fundamental. As Regiões são geograficamente isoladas, enquanto as AZs dentro de uma Região são conectadas com baixa latência. Local Zones e Wavelength Zones estendem os serviços da AWS para mais perto dos usuários finais ou de dispositivos 5G, respectivamente, para aplicações de latência ultrabaixa.

Amazon VPC: A VPC é o bloco de construção fundamental para a rede na AWS. Permite provisionar uma seção logicamente isolada da Nuvem AWS, onde você pode lançar recursos da AWS em uma rede virtual que você define. Você tem controle total sobre seu ambiente de rede virtual, incluindo a seleção de seu próprio intervalo de endereços IP, criação de sub-redes e configuração de tabelas de rotas e gateways de rede.

Conectividade Híbrida: A conectividade híbrida refere-se à conexão de sua rede on-premises com a sua VPC na AWS. As duas principais opções para isso são:

• AWS Direct Connect (DX): Fornece uma conexão de rede privada e dedicada de seu data center para a AWS. O Direct Connect pode reduzir os custos de rede, aumentar a largura de banda e fornecer uma experiência de rede mais consistente do que as conexões baseadas na Internet.
• AWS Site-to-Site VPN: Cria uma conexão segura entre sua rede on-premises e suas VPCs. As conexões VPN são estabelecidas através da Internet pública e são criptografadas com IPsec.

Roteamento Transitivo: Em uma topologia de rede complexa com múltiplas VPCs e conexões on-premises, o roteamento transitivo torna-se essencial. O AWS Transit Gateway (TGW) é um serviço gerenciado que atua como um hub central para conectar suas VPCs e redes on-premises. Ele simplifica a topologia de rede, eliminando a necessidade de conexões de emparelhamento de VPC (VPC Peering) complexas e full-mesh.

DNS Híbrido: O Amazon Route 53 Resolver permite a resolução de DNS bidirecional entre suas redes on-premises e a AWS. Você pode criar endpoints do Route 53 Resolver em suas VPCs que encaminham consultas de DNS de seus sistemas on-premises para o Route 53 e vice-versa. Isso é crucial para que os aplicativos em ambos os ambientes possam se comunicar usando nomes de domínio familiares.

Segmentação de Rede: A segmentação de rede é uma prática de segurança fundamental que envolve a divisão de uma rede em sub-redes menores e isoladas. Na AWS, isso é alcançado através do uso de VPCs, sub-redes, Network Access Control Lists (NACLs) e Security Groups. A segmentação ajuda a conter o impacto de uma violação de segurança e a aplicar políticas de segurança granulares.

Monitoramento de Tráfego de Rede: Para garantir a segurança e a performance de sua rede, é essencial monitorar o tráfego. A AWS oferece várias ferramentas para isso, incluindo:

• VPC Flow Logs: Captura informações sobre o tráfego IP que entra e sai das interfaces de rede em sua VPC.
• AWS CloudTrail: Registra todas as chamadas de API feitas em sua conta, incluindo as relacionadas a alterações na configuração da rede.
• Amazon CloudWatch: Coleta e monitora métricas de rede de vários serviços da AWS, permitindo que você crie alarmes e dashboards.

Comparações entre Serviços e Quando Usar Cada Um

AWS Transit Gateway vs. VPC Peering:

• VPC Peering: É uma conexão de rede entre duas VPCs que permite que elas se comuniquem como se estivessem na mesma rede. O VPC Peering é ideal para um número pequeno de VPCs. No entanto, ele não suporta roteamento transitivo (ou seja, se a VPC A está emparelhada com a VPC B e a VPC B está emparelhada com a VPC C, a VPC A não pode se comunicar com a VPC C através da VPC B). Isso leva a uma topologia de malha complexa à medida que o número de VPCs aumenta.
• AWS Transit Gateway: Atua como um hub central que conecta múltiplas VPCs e redes on-premises. Ele simplifica o gerenciamento da rede, pois cada VPC só precisa se conectar ao Transit Gateway. O TGW suporta roteamento transitivo e é a solução recomendada para arquiteturas com um grande número de VPCs.

AWS Direct Connect vs. AWS Site-to-Site VPN:

• AWS Site-to-Site VPN: É uma solução rápida e de baixo custo para estabelecer uma conexão segura entre sua rede on-premises e a AWS. No entanto, como a conexão é feita pela Internet pública, a performance pode ser inconsistente.
• AWS Direct Connect: Oferece uma conexão privada e dedicada com alta largura de banda e performance consistente. É a escolha ideal para workloads que exigem alta performance, baixa latência e segurança aprimorada. O custo inicial do Direct Connect é maior do que o da VPN.

Configurações, Limitações, Boas Práticas e Casos de Uso

AWS Transit Gateway:

• Configuração: Crie um Transit Gateway em sua conta e anexe suas VPCs e conexões VPN/Direct Connect a ele. Configure as tabelas de rotas do Transit Gateway para controlar o fluxo de tráfego.
• Limitações: Existem limites para o número de anexos, tabelas de rotas e rotas por tabela de rotas. Consulte a documentação da AWS para obter os limites mais recentes.
• Boas Práticas: Use uma conta de rede dedicada para hospedar o Transit Gateway. Use tabelas de rotas separadas para isolar diferentes ambientes (por exemplo, produção, desenvolvimento, teste). Monitore o tráfego do Transit Gateway usando o CloudWatch.
• Casos de Uso: Redes corporativas com múltiplas VPCs, conectividade híbrida em escala, compartilhamento de serviços centralizados.

AWS Direct Connect:

• Configuração: Solicite uma conexão Direct Connect através do Console da AWS. Trabalhe com um parceiro da AWS para estabelecer a conexão física entre seu data center e um local do Direct Connect. Configure as Virtual Interfaces (VIFs) para se conectar às suas VPCs.
• Limitações: A largura de banda é limitada pela porta que você provisiona (de 50 Mbps a 100 Gbps). A localização física de seu data center pode ser um fator limitante.
• Boas Práticas: Use conexões redundantes do Direct Connect para alta disponibilidade. Use o Link Aggregation Group (LAG) para combinar várias conexões em uma única conexão lógica de maior largura de banda. Monitore a utilização da conexão.
• Casos de Uso: Migração de grandes volumes de dados, workloads de baixa latência, aplicações que exigem alta largura de banda.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura de Rede Hub-and-Spoke com Transit Gateway: Este é o modelo de arquitetura mais comum para redes complexas na AWS. O Transit Gateway atua como o hub, e as VPCs e conexões on-premises são os spokes. Isso simplifica o gerenciamento da rede e melhora a escalabilidade.

Segurança: Use NACLs e Security Groups para controlar o tráfego em nível de sub-rede e de instância, respectivamente. Use o AWS Network Firewall para inspecionar e filtrar o tráfego em sua VPC. Use o AWS Shield para proteção contra ataques de DDoS.

Resiliência: Projete sua rede para ser altamente disponível, usando múltiplas AZs e Regiões. Use conexões redundantes de VPN e Direct Connect. Use o Route 53 para failover de DNS.

Governança: Use o AWS Organizations para gerenciar centralmente suas contas e políticas de rede. Use o AWS Control Tower para provisionar um ambiente de várias contas seguro e bem arquitetado. Use o AWS Resource Access Manager (RAM) para compartilhar recursos de rede, como o Transit Gateway, entre contas.

Estratégias de Migração e Modernização

Ao migrar para a AWS, comece com uma base de rede sólida. Use o Transit Gateway para conectar suas VPCs e sua rede on-premises. À medida que você moderniza suas aplicações, use serviços como o AWS PrivateLink para expor serviços de forma segura entre VPCs sem expô-los à Internet pública.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa possui 50 VPCs em uma única Região e precisa que todas elas se comuniquem entre si. Qual a solução mais escalável e gerenciável?

• Decisão Arquitetural: Usar o AWS Transit Gateway. O VPC Peering exigiria uma malha de quase 1225 conexões, o que seria impossível de gerenciar.

Armadilha Comum: Não entender as implicações de custo do tráfego de dados entre AZs. O tráfego de dados entre AZs incorre em custos, o que pode ser significativo em arquiteturas com alto volume de tráfego. Otimize a localização de seus recursos para minimizar o tráfego entre AZs.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura de Rede Hub-and-Spoke com Transit Gateway: Este é o modelo de arquitetura mais comum para redes complexas na AWS. O Transit Gateway atua como o hub, e as VPCs e conexões on-premises são os spokes. Isso simplifica o gerenciamento da rede e melhora a escalabilidade.

Segurança: Use NACLs e Security Groups para controlar o tráfego em nível de sub-rede e de instância, respectivamente. Use o AWS Network Firewall para inspecionar e filtrar o tráfego em sua VPC. Use o AWS Shield para proteção contra ataques de DDoS.

Resiliência: Projete sua rede para ser altamente disponível, usando múltiplas AZs e Regiões. Use conexões redundantes de VPN e Direct Connect. Use o Route 53 para failover de DNS.

Governança: Use o AWS Organizations para gerenciar centralmente suas contas e políticas de rede. Use o AWS Control Tower para provisionar um ambiente de várias contas seguro e bem arquitetado. Use o AWS Resource Access Manager (RAM) para compartilhar recursos de rede, como o Transit Gateway, entre contas.

Estratégias de Migração e Modernização

Ao migrar para a AWS, comece com uma base de rede sólida. Use o Transit Gateway para conectar suas VPCs e sua rede on-premises. À medida que você moderniza suas aplicações, use serviços como o AWS PrivateLink para expor serviços de forma segura entre VPCs sem expô-los à Internet pública.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa possui 50 VPCs em uma única Região e precisa que todas elas se comuniquem entre si. Qual a solução mais escalável e gerenciável?

• Decisão Arquitetural: Usar o AWS Transit Gateway. O VPC Peering exigiria uma malha de quase 1225 conexões, o que seria impossível de gerenciar.

Armadilha Comum: Não entender as implicações de custo do tráfego de dados entre AZs. O tráfego de dados entre AZs incorre em custos, o que pode ser significativo em arquiteturas com alto volume de tráfego. Otimize a localização de seus recursos para minimizar o tráfego entre AZs.

Detalhamento sobre políticas de IAM, SCPs, redes multi-VPC e multi-região, landing zones, observabilidade, custos e otimização

Estratégias Multi-Account e Landing Zones:

Uma estratégia multi-account é uma prática recomendada pela AWS para isolar workloads, gerenciar custos, aplicar segurança e governança de forma granular. O AWS Organizations permite que você gerencie centralmente várias contas AWS que você possui. Uma Landing Zone é um ambiente AWS bem arquitetado e multi-account que é escalável e seguro, servindo como um ponto de partida para a implantação de workloads. O AWS Control Tower é um serviço que automatiza a configuração de uma landing zone, aplicando as melhores práticas da AWS para identidade, acesso federado e estrutura de contas. Ele cria uma estrutura de Unidades Organizacionais (OUs) e contas pré-configuradas (como Log Archive e Audit), além de configurar guardrails (políticas de prevenção e detecção).

Service Control Policies (SCPs):

SCPs são um tipo de política que você pode usar para gerenciar permissões em sua organização no AWS Organizations. SCPs oferecem controle centralizado sobre as permissões máximas disponíveis para todas as contas em sua organização ou em OUs específicas. Eles não concedem permissões; em vez disso, eles definem os limites para as permissões que os usuários e funções do IAM podem ter. Por exemplo, você pode usar um SCP para impedir que qualquer conta em uma OU específica lance instâncias EC2 em uma região não aprovada. É uma boa prática testar SCPs em OUs de teste antes de aplicá-los em produção para evitar bloqueios acidentais.

IAM Avançado:

• Permission Boundaries: Uma permission boundary é uma política gerenciada pelo IAM que define as permissões máximas que uma política baseada em identidade pode conceder a uma entidade IAM (usuário ou função). Ela não concede permissões por si só, mas funciona como um filtro para as permissões efetivas. É útil para delegar a criação de funções e usuários sem conceder permissões excessivas.
• Attribute-Based Access Control (ABAC): ABAC é uma estratégia de autorização que define permissões com base em atributos. Na AWS, esses atributos são chamados de tags. Você pode projetar permissões que permitem ou negam acesso a recursos com base em tags anexadas a esses recursos, ou tags anexadas ao principal que faz a solicitação. Isso simplifica o gerenciamento de permissões em ambientes dinâmicos e em larga escala.
• Roles Cross-Account: Funções IAM podem ser usadas para conceder acesso seguro entre contas AWS. Em vez de compartilhar credenciais de acesso de longo prazo, uma função IAM permite que uma conta confie em outra conta para assumir essa função e acessar seus recursos. Isso é fundamental para cenários como implantação de CI/CD, acesso de auditoria ou compartilhamento de recursos.

Redes Multi-VPC e Multi-Região:

• AWS Transit Gateway: Conforme mencionado, o TGW é a solução preferencial para conectar múltiplas VPCs e redes on-premises, simplificando o roteamento e a conectividade em arquiteturas complexas. Ele suporta conectividade inter-regiões, permitindo que você crie uma rede global.
• AWS PrivateLink: Permite que você exponha serviços em sua VPC para outras VPCs (suas ou de outros clientes) ou para redes on-premises, sem expor o tráfego à Internet pública. Isso é ideal para criar conectividade privada e segura para serviços SaaS ou serviços internos compartilhados.
• VPC Peering: Embora útil para um número limitado de conexões ponto a ponto, não é escalável para redes complexas devido à sua natureza não transitiva.
• DNS Multi-Região com Amazon Route 53: O Route 53 oferece recursos avançados de roteamento de DNS, como roteamento baseado em latência, roteamento de failover e roteamento de geolocalização, que são cruciais para arquiteturas multi-região, garantindo alta disponibilidade e baixa latência para os usuários.

Observabilidade:

Em um ambiente multi-account e complexo, a observabilidade é vital. Ferramentas como Amazon CloudWatch (para métricas e logs centralizados), AWS X-Ray (para rastreamento de requisições distribuídas), AWS CloudTrail (para auditoria de API calls) e AWS Config (para monitoramento de conformidade da configuração dos recursos) são essenciais para ter uma visão unificada do comportamento e da saúde de suas aplicações e infraestrutura.

Custos e Otimização:

Gerenciar custos em um ambiente multi-account requer visibilidade e controle. O AWS Cost Explorer e o AWS Budgets ajudam a monitorar e controlar os gastos. A aplicação de tags consistentes em todos os recursos e contas é fundamental para alocar custos e identificar oportunidades de otimização. O AWS Compute Optimizer fornece recomendações para otimizar o uso de recursos de computação, enquanto o AWS Trusted Advisor oferece insights sobre otimização de custos, segurança, performance e tolerância a falhas.

Domínio 2: Design para Novas Soluções

Este domínio aborda a capacidade de projetar novas soluções na AWS, focando na escolha de serviços, padrões de arquitetura, resiliência, escalabilidade e otimização de performance. É crucial entender as características de cada serviço para tomar decisões arquiteturais informadas que atendam aos requisitos de negócios e técnicos.

Tópicos e Subtópicos:

2.1. Arquitetar soluções de computação.

Conceitos Fundamentais e Avançados

A AWS oferece uma vasta gama de serviços de computação, cada um otimizado para diferentes tipos de workloads. A escolha do serviço de computação correto é uma decisão arquitetural crítica que impacta diretamente a escalabilidade, performance, custo e gerenciamento da solução.

• Amazon EC2 (Elastic Compute Cloud): Fornece capacidade computacional segura e redimensionável na nuvem. É a base para muitas arquiteturas e oferece controle granular sobre as instâncias (tipo, sistema operacional, armazenamento, rede). O EC2 é ideal para workloads que exigem controle total sobre o ambiente de servidor, como aplicações legadas, bancos de dados específicos ou cargas de trabalho que precisam de GPUs.
  • Instâncias Spot/Mixed Fleets: Instâncias Spot permitem que você solicite capacidade EC2 não utilizada da AWS com grandes descontos. São ideais para workloads tolerantes a falhas, como processamento em lote, renderização ou testes. Mixed Fleets combinam instâncias On-Demand, Reserved Instances e Spot para otimizar custos e disponibilidade.
  • Auto Scaling: Permite escalar automaticamente a capacidade do EC2 para cima ou para baixo de acordo com a demanda. Garante alta disponibilidade e otimização de custos, lançando ou encerrando instâncias automaticamente.
• AWS Lambda: Um serviço de computação serverless que permite executar código sem provisionar ou gerenciar servidores. Você paga apenas pelo tempo de computação consumido. Ideal para funções de curta duração, orientadas a eventos, como processamento de dados em tempo real, backends de API ou automação de tarefas. Suporta várias linguagens de programação.
• Containers (Amazon ECS, Amazon EKS, AWS Fargate): A AWS oferece várias opções para executar workloads em contêineres:
  • Amazon Elastic Container Service (ECS): Um serviço de orquestração de contêineres totalmente gerenciado que facilita a execução, interrupção e gerenciamento de contêineres Docker em um cluster. É bem integrado com outros serviços AWS.
  • Amazon Elastic Kubernetes Service (EKS): Um serviço gerenciado de Kubernetes que facilita a execução de aplicações Kubernetes na AWS sem a necessidade de instalar, operar e manter seu próprio plano de controle Kubernetes. Ideal para quem já usa Kubernetes ou busca portabilidade.
  • AWS Fargate: Um mecanismo de computação serverless para contêineres que funciona com ECS e EKS. Com Fargate, você não precisa provisionar, configurar ou escalar clusters de máquinas virtuais. Você paga apenas pelos recursos de computação que seus contêineres usam. Ideal para simplificar a operação de contêineres.
• AWS Outposts, Wavelength, Local Zones: Estendem a infraestrutura e os serviços da AWS para locais on-premises (Outposts), para a borda da rede 5G (Wavelength) ou para áreas metropolitanas (Local Zones), permitindo que os clientes executem aplicações com baixa latência para usuários finais ou equipamentos locais.
• AWS Batch: Permite executar workloads de computação em lote em escala. Ele provisiona dinamicamente a quantidade ideal de recursos de computação (EC2, Spot) com base nos requisitos da workload.
• AWS ParallelCluster: Uma ferramenta de código aberto que facilita a implantação e o gerenciamento de clusters de computação de alto desempenho (HPC) na AWS.
• AWS Serverless Application Model (AWS SAM) e AWS Amplify: Ferramentas para simplificar o desenvolvimento e a implantação de aplicações serverless e web/mobile, respectivamente.

Comparações entre Serviços e Quando Usar Cada Um

EC2 vs. Lambda vs. Fargate:

• Use EC2 quando: Você precisa de controle total sobre o sistema operacional, tem aplicações legadas que não podem ser facilmente conteinerizadas ou refatoradas, ou precisa de tipos de instância específicos (GPUs, HPC).
• Use Lambda quando: Você tem workloads orientadas a eventos, funções de curta duração, precisa de escalabilidade instantânea e não quer gerenciar servidores. Ideal para backends de API, processamento de arquivos, automação.
• Use Fargate quando: Você quer executar contêineres sem gerenciar a infraestrutura subjacente. Ideal para microsserviços, aplicações web conteinerizadas, onde a portabilidade do contêiner é importante, mas o gerenciamento de VMs não é desejado.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon EC2:

• Configurações: Escolha o tipo de instância (família, tamanho), AMI (Amazon Machine Image), armazenamento (EBS), rede (VPC, sub-rede, Security Groups). Configure Auto Scaling Groups com políticas de escalabilidade.
• Limitações: Limites de serviço para o número de instâncias, vCPUs, volumes EBS por região. Custos podem escalar rapidamente se não forem otimizados.
• Boas Práticas: Use instâncias Spot para workloads flexíveis. Use Auto Scaling para resiliência e otimização de custos. Use User Data para automação de inicialização. Monitore com CloudWatch.
• Casos de Uso: Servidores web, servidores de aplicação, bancos de dados relacionais (com RDS ou self-managed), clusters de Big Data.

AWS Lambda:

• Configurações: Defina a função (código), runtime, memória, tempo limite, variáveis de ambiente, gatilhos (eventos). Configure VPC para acesso a recursos privados.
• Limitações: Tempo limite de execução (15 minutos), tamanho do pacote de implantação, memória máxima. Cold starts podem impactar a latência.
• Boas Práticas: Mantenha as funções pequenas e com uma única responsabilidade. Use Provisioned Concurrency para reduzir cold starts em workloads sensíveis à latência. Monitore com CloudWatch Logs e X-Ray.
• Casos de Uso: Processamento de eventos (S3, DynamoDB Streams), backends de API (com API Gateway), chatbots, automação de infraestrutura.

AWS Fargate (com ECS ou EKS):

• Configurações: Defina a definição da tarefa (imagem do contêiner, vCPU, memória), políticas de escalabilidade. Integre com Load Balancers e Service Discovery.
• Limitações: Não há acesso ao sistema operacional subjacente. Custos podem ser mais altos que EC2 para workloads de longa duração e alta utilização.
• Boas Práticas: Use imagens de contêiner otimizadas e pequenas. Implemente health checks para garantir a disponibilidade. Monitore com CloudWatch Container Insights.
• Casos de Uso: Microsserviços, APIs conteinerizadas, aplicações web, processamento de dados em contêineres.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura de Microsserviços: Frequentemente implementada com contêineres (ECS/EKS/Fargate) e Lambda para componentes serverless. Cada serviço é independente, escalável e resiliente.
• Padrões de Segurança: Use IAM Roles para conceder permissões mínimas aos serviços de computação. Isole recursos em sub-redes privadas. Use Security Groups para controlar o tráfego de rede. Criptografe dados em trânsito e em repouso.
• Resiliência: Distribua workloads por múltiplas AZs. Use Auto Scaling para lidar com picos de tráfego e falhas de instâncias. Implemente health checks e circuit breakers.
• Governança: Use AWS Config para monitorar a conformidade das configurações. Implemente políticas de tagging para rastreamento de custos e recursos.

Estratégias de Migração e Modernização

• Rehost (Lift-and-Shift): Migrar VMs on-premises para EC2. É a estratégia mais rápida, mas não aproveita totalmente os benefícios da nuvem.
• Replatform: Migrar aplicações para EC2 com algumas otimizações, como o uso de RDS para bancos de dados ou Auto Scaling. Pode envolver a conteinerização de aplicações para ECS/EKS.
• Refactor/Re-architect: Refatorar aplicações para usar serviços serverless (Lambda, Fargate) e microsserviços. Esta é a estratégia que mais aproveita os benefícios da nuvem, mas também a mais complexa e demorada.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação web tem picos de tráfego imprevisíveis e precisa de escalabilidade rápida e custos otimizados. A aplicação é composta por um frontend estático e um backend de API RESTful.

• Decisão Arquitetural: Hospedar o frontend estático no Amazon S3 e usar o Amazon CloudFront para entrega de conteúdo. Para o backend, usar AWS Lambda com Amazon API Gateway. Isso proporciona escalabilidade automática, alta disponibilidade e um modelo de custo pay-per-use.

Armadilha Comum: Usar EC2 para workloads que seriam mais adequadas para Lambda ou Fargate, resultando em custos mais altos e maior sobrecarga de gerenciamento. Por exemplo, executar um servidor web 24/7 em EC2 para uma aplicação que recebe tráfego apenas algumas horas por dia.

2.2. Arquitetar soluções de armazenamento.

Conceitos Fundamentais e Avançados

A AWS oferece uma ampla gama de serviços de armazenamento, cada um projetado para diferentes casos de uso, requisitos de performance, durabilidade e custo. A escolha do serviço de armazenamento adequado é crucial para a performance e a economia de uma solução.

• Amazon S3 (Simple Storage Service): Armazenamento de objetos altamente durável, disponível e escalável. Ideal para armazenar qualquer tipo de dado (imagens, vídeos, backups, logs, arquivos estáticos de sites). Oferece diferentes classes de armazenamento para otimização de custos com base na frequência de acesso.
  • Classes de Armazenamento: S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA (Infrequent Access), S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive. Cada classe tem um custo e um tempo de recuperação diferentes.
  • Pontos de Acesso (Access Points): Simplificam o gerenciamento de acesso a dados em S3 em escala, permitindo criar centenas de pontos de acesso com políticas de acesso distintas para diferentes aplicações ou usuários.
• Amazon Elastic File System (EFS): Um sistema de arquivos de rede (NFS) escalável e elástico para instâncias EC2 e on-premises (via Direct Connect ou VPN). Ideal para workloads que precisam de acesso compartilhado a arquivos, como aplicações web, sistemas de gerenciamento de conteúdo e ambientes de desenvolvimento.
• Amazon FSx: Oferece sistemas de arquivos totalmente gerenciados para workloads específicas:
  • FSx for Lustre: Para workloads de computação de alto desempenho (HPC) que exigem armazenamento de arquivos rápido.
  • FSx for Windows File Server: Para workloads que exigem compartilhamentos de arquivos baseados em Windows com suporte a SMB (Server Message Block).
  • FSx for NetApp ONTAP: Oferece recursos de gerenciamento de dados do ONTAP com a agilidade e escalabilidade da AWS.
• Amazon Elastic Block Store (EBS): Fornece volumes de armazenamento em bloco persistentes para uso com instâncias EC2. É como um disco rígido virtual que você pode anexar a uma instância. Ideal para bancos de dados, sistemas de arquivos e qualquer aplicação que precise de armazenamento de baixa latência e alta performance.
• AWS Backup: Um serviço de backup centralizado e gerenciado que facilita o backup de dados de vários serviços da AWS (EBS, RDS, DynamoDB, EFS, FSx, EC2, Storage Gateway) e on-premises.
• Amazon Glacier: Uma classe de armazenamento de S3 para arquivamento de dados de longo prazo e baixo custo. Ideal para dados que são acessados raramente, mas que precisam ser retidos por anos ou décadas.
• AWS Storage Gateway: Conecta ambientes on-premises com o armazenamento em nuvem da AWS, oferecendo gateways de arquivo, volume e fita para diferentes casos de uso de armazenamento híbrido.
• AWS Snow Family: Dispositivos físicos (Snowcone, Snowball, Snowmobile) para transferir grandes volumes de dados para dentro e para fora da AWS, ou para executar computação na borda em ambientes desconectados ou remotos.

Comparações entre Serviços e Quando Usar Cada Um

• S3 vs. EFS vs. FSx: A principal diferença está no modelo de acesso. S3 é para objetos (acesso via API), EFS e FSx são para arquivos (acesso via sistema de arquivos). A escolha entre EFS e FSx depende do tipo de sistema de arquivos e dos recursos específicos necessários (NFS genérico vs. Lustre/SMB/ONTAP).
• S3 vs. Glacier: Glacier é uma classe de armazenamento de S3, otimizada para arquivamento de longo prazo com custos muito baixos, mas com tempos de recuperação mais longos. S3 Standard é para acesso frequente, enquanto as classes IA são para acesso infrequente.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon S3:

• Configurações: Crie buckets, defina políticas de bucket, configure políticas de ciclo de vida para transição entre classes de armazenamento, configure versionamento, criptografia (SSE-S3, SSE-KMS, SSE-C).
• Limitações: Tamanho máximo de objeto (5 TB), limites de taxa de requisições por prefixo.
• Boas Práticas: Use políticas de ciclo de vida para otimizar custos. Habilite o versionamento para proteção contra exclusão acidental. Use Access Points para gerenciar o acesso em escala. Use criptografia por padrão.
• Casos de Uso: Data lakes, backups, hospedagem de sites estáticos, armazenamento de logs, distribuição de conteúdo.

Amazon EFS:

• Configurações: Crie um sistema de arquivos EFS, defina modos de performance (General Purpose, Max I/O), modos de throughput (Bursting, Provisioned), crie mount targets em suas VPCs.
• Limitações: Latência um pouco maior que EBS para acesso de bloco. Custo pode ser mais alto para workloads que não precisam de compartilhamento.
• Boas Práticas: Use o modo General Purpose para a maioria das workloads. Use o modo Max I/O para workloads com alta concorrência. Monitore o throughput e o uso de burst credits.
• Casos de Uso: Diretórios home de usuários, ambientes de desenvolvimento compartilhados, sistemas de gerenciamento de conteúdo (CMS), workloads de Big Data.

Amazon EBS:

• Configurações: Escolha o tipo de volume (gp2/gp3, io1/io2, st1, sc1), tamanho, IOPS/throughput. Crie snapshots para backup. Anexe a instâncias EC2.
• Limitações: Anexado a uma única instância EC2 por vez. Performance varia com o tipo de volume.
• Boas Práticas: Use gp3 para a maioria das workloads. Use io2 Block Express para workloads de alta performance. Crie snapshots regularmente para recuperação de desastres. Criptografe volumes EBS por padrão.
• Casos de Uso: Volumes de boot de instâncias EC2, bancos de dados, logs de aplicação, volumes de dados para aplicações que exigem armazenamento persistente e de baixa latência.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Data Lake no S3: Armazene dados brutos e processados no S3, usando diferentes classes de armazenamento para otimização de custos. Integre com serviços como AWS Glue, Amazon Athena e Amazon Redshift Spectrum para análise.
• Armazenamento Compartilhado para Aplicações Web: Use EFS para compartilhar arquivos de conteúdo entre múltiplos servidores web EC2 em um Auto Scaling Group.
• Padrões de Segurança: Use políticas de bucket S3, ACLs e políticas de ponto de acesso para controlar o acesso. Use IAM Roles para acesso a serviços de armazenamento. Criptografe dados em repouso (SSE-S3, SSE-KMS) e em trânsito (SSL/TLS). Use o AWS PrivateLink para acesso privado a S3 de dentro da VPC.
• Resiliência: S3, EFS e FSx for Windows/ONTAP são projetados para alta durabilidade e disponibilidade multi-AZ. Para EBS, use snapshots para backup e replicação entre AZs para recuperação de desastres.
• Governança: Use AWS Config para monitorar a conformidade das configurações de armazenamento. Implemente políticas de ciclo de vida para gerenciar o ciclo de vida dos dados e otimizar custos.

Estratégias de Migração e Modernização

• Migração de Dados: Use AWS DataSync para transferir grandes volumes de dados de on-premises para S3, EFS ou FSx. Use o AWS Snow Family para migrações offline de petabytes de dados.
• Modernização: Substitua servidores de arquivos on-premises por EFS ou FSx. Migre bancos de dados para RDS ou DynamoDB, que usam EBS e S3 internamente. Refatore aplicações para usar S3 para armazenamento de objetos em vez de sistemas de arquivos locais.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de análise de Big Data gera grandes volumes de dados que precisam ser armazenados de forma econômica e acessados ocasionalmente para relatórios históricos.

• Decisão Arquitetural: Armazenar os dados no Amazon S3 com políticas de ciclo de vida para transicionar dados mais antigos para S3 Intelligent-Tiering e, eventualmente, para S3 Glacier Deep Archive. Isso otimiza os custos de armazenamento enquanto mantém os dados acessíveis quando necessário.

Armadilha Comum: Usar S3 Standard para dados que são acessados raramente, resultando em custos de armazenamento desnecessariamente altos. Ou, inversamente, usar Glacier para dados que precisam de recuperação rápida, incorrendo em custos de recuperação elevados e atrasos.

2.3. Arquitetar soluções de banco de dados.

Conceitos Fundamentais e Avançados

A AWS oferece uma ampla variedade de serviços de banco de dados, cobrindo modelos relacionais, NoSQL, data warehousing, grafos, ledger, séries temporais e blockchain. A escolha do banco de dados certo é fundamental para a performance, escalabilidade, resiliência e custo de uma aplicação.

• Amazon Relational Database Service (RDS): Um serviço de banco de dados relacional gerenciado que facilita a configuração, operação e escalabilidade de bancos de dados relacionais na nuvem. Suporta vários motores de banco de dados (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB).
• Amazon Aurora: Um banco de dados relacional compatível com MySQL e PostgreSQL, construído para a nuvem. Combina a velocidade e a disponibilidade de bancos de dados comerciais de ponta com a simplicidade e a economia de bancos de dados de código aberto. Oferece até 5x o throughput do MySQL padrão e 3x o do PostgreSQL padrão.
• Amazon DynamoDB: Um serviço de banco de dados NoSQL de chave-valor e documento totalmente gerenciado que oferece performance de milissegundos de dígito único em qualquer escala. Ideal para aplicações que exigem baixa latência e alta taxa de transferência, como jogos, publicidade digital e IoT.
• Amazon DocumentDB (com compatibilidade MongoDB): Um serviço de banco de dados de documentos totalmente gerenciado que suporta workloads MongoDB. Compatível com as APIs do MongoDB, permitindo que você use o código, drivers e ferramentas do MongoDB existentes.
• Amazon Neptune: Um serviço de banco de dados de grafo rápido, confiável e totalmente gerenciado. Ideal para construir e executar aplicações que trabalham com conjuntos de dados altamente conectados, como redes sociais, motores de recomendação e detecção de fraudes.
• Amazon Redshift: Um serviço de data warehouse rápido e totalmente gerenciado em escala de petabytes. Ideal para análise de grandes volumes de dados estruturados e semi-estruturados, permitindo consultas complexas e relatórios.
• Amazon ElastiCache: Um serviço de cache na memória totalmente gerenciado que suporta Redis e Memcached. Usado para acelerar o desempenho de aplicações web e móveis, recuperando informações de caches na memória de alta velocidade em vez de depender de bancos de dados baseados em disco mais lentos.
• Amazon Quantum Ledger Database (QLDB): Um banco de dados de ledger totalmente gerenciado que fornece um log de transações transparente, imutável e criptograficamente verificável. Ideal para sistemas que precisam de um registro completo e verificável de todas as alterações de dados, como registros financeiros ou de supply chain.
• Amazon Managed Blockchain: Um serviço totalmente gerenciado para criar e gerenciar redes de blockchain escaláveis usando frameworks populares como Hyperledger Fabric e Ethereum.
• Amazon Keyspaces (para Apache Cassandra): Um serviço de banco de dados de tabela ampla, serverless, compatível com Apache Cassandra. Ideal para workloads Cassandra que precisam de escalabilidade e gerenciamento simplificados.
• Amazon Timestream: Um serviço de banco de dados de séries temporais rápido, escalável e serverless. Ideal para aplicações IoT e operacionais que coletam dados de séries temporais em alta velocidade.
• AWS Database Migration Service (DMS): Ajuda a migrar bancos de dados para a AWS de forma rápida e segura. Suporta migrações homogêneas (por exemplo, Oracle para Oracle) e heterogêneas (por exemplo, Oracle para PostgreSQL).
• AWS Schema Conversion Tool (SCT): Ajuda a converter o esquema do banco de dados e o código da aplicação de um banco de dados de origem para um banco de dados de destino diferente.

Comparações entre Serviços e Quando Usar Cada Um

Amazon RDS vs. Amazon Aurora vs. Amazon DynamoDB:

• Use RDS quando: Você precisa de um banco de dados relacional tradicional e quer a conveniência de um serviço gerenciado sem se preocupar com a infraestrutura subjacente. Ideal para a maioria das aplicações web e empresariais que se beneficiam de um esquema fixo e transações ACID.
• Use Aurora quando: Você precisa de um banco de dados relacional com alta performance, escalabilidade e disponibilidade, superando o RDS padrão. É uma boa escolha para workloads OLTP (Online Transaction Processing) exigentes.
• Use DynamoDB quando: Você precisa de um banco de dados NoSQL com performance de milissegundos de dígito único em qualquer escala, sem se preocupar com o provisionamento de servidores. Ideal para aplicações com grandes volumes de dados e padrões de acesso flexíveis, como dados de sessão, perfis de usuário, IoT.

Outras Comparações:

• DocumentDB vs. DynamoDB: Ambos são NoSQL. DocumentDB é para workloads de documentos compatíveis com MongoDB, enquanto DynamoDB é mais flexível para chave-valor e documentos, com performance garantida em escala.
• Redshift vs. RDS/Aurora: Redshift é um data warehouse para análise (OLAP), enquanto RDS/Aurora são bancos de dados transacionais (OLTP). Não são substitutos, mas complementares.
• ElastiCache vs. Bancos de Dados: ElastiCache é um cache na memória para acelerar o acesso a dados frequentemente acessados, reduzindo a carga no banco de dados principal.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon RDS:

• Configurações: Escolha o motor, tipo de instância, armazenamento, Multi-AZ, réplicas de leitura, grupos de parâmetros e opções.
• Limitações: Escalabilidade vertical limitada pelo tipo de instância. Réplicas de leitura são assíncronas.
• Boas Práticas: Use Multi-AZ para alta disponibilidade. Use réplicas de leitura para escalar workloads de leitura. Monitore métricas de performance e otimize consultas.
• Casos de Uso: Aplicações web e móveis, sistemas de gerenciamento de conteúdo, CRMs, ERPs.

Amazon Aurora:

• Configurações: Escolha o motor (MySQL/PostgreSQL), tipo de instância, configure réplicas de leitura, Aurora Serverless para escalabilidade sob demanda.
• Limitações: Compatibilidade com MySQL/PostgreSQL, mas não 100% idêntico. Custos podem ser mais altos que RDS padrão para workloads de baixa utilização.
• Boas Práticas: Use o endpoint de leitura para distribuir o tráfego de leitura entre as réplicas. Use Aurora Serverless para workloads intermitentes ou imprevisíveis. Monitore com CloudWatch.
• Casos de Uso: Aplicações de alta performance, jogos, SaaS, e-commerce.

Amazon DynamoDB:

• Configurações: Defina tabelas, chaves primárias (partição e sort key), atributos, modos de capacidade (provisionado ou sob demanda), índices secundários globais/locais.
• Limitações: Não é um banco de dados relacional. Não suporta joins complexos ou transações multi-tabela nativamente (embora existam transações para múltiplos itens/tabelas no mesmo account/region).
• Boas Práticas: Projete bem as chaves primárias para distribuir a carga de trabalho. Use o modo sob demanda para workloads imprevisíveis. Use o DynamoDB Accelerator (DAX) para cache na memória. Habilite o DynamoDB Streams para processamento de eventos.
• Casos de Uso: Perfis de usuário, dados de sessão, carrinhos de compras, jogos, IoT, microsserviços sem estado.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura Orientada a Dados: Escolha o banco de dados certo para cada workload, combinando diferentes tipos (relacional para transações, NoSQL para dados flexíveis, data warehouse para análise).
• Padrões de Segurança: Use IAM Roles para acesso a bancos de dados. Criptografe dados em repouso (KMS) e em trânsito (SSL/TLS). Use Security Groups para controlar o acesso à rede. Implemente o princípio do menor privilégio.
• Resiliência: Use Multi-AZ para RDS e Aurora para alta disponibilidade. DynamoDB é inerentemente distribuído e resiliente. Use backups e snapshots regulares.
• Governança: Use AWS Config para monitorar a conformidade das configurações de banco de dados. Implemente políticas de tagging para rastreamento de custos e recursos.

Estratégias de Migração e Modernização

• Migração de Banco de Dados: Use AWS DMS para migrar bancos de dados existentes para a AWS, com suporte para migrações homogêneas e heterogêneas. Use AWS SCT para converter esquemas.
• Modernização: Refatore aplicações para usar bancos de dados serverless como DynamoDB ou Aurora Serverless. Migre de bancos de dados auto-gerenciados para serviços gerenciados como RDS ou Aurora para reduzir a sobrecarga operacional.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de e-commerce precisa de um banco de dados para armazenar informações de produtos e pedidos. A aplicação espera um alto volume de transações e precisa de alta disponibilidade e escalabilidade.

• Decisão Arquitetural: Para informações de produtos e pedidos que exigem um esquema relacional e transações ACID, o Amazon Aurora (compatível com MySQL ou PostgreSQL) com Multi-AZ e réplicas de leitura seria uma excelente escolha devido à sua alta performance e escalabilidade. Para dados de sessão de usuário ou carrinhos de compras (que podem ser mais flexíveis e de alta taxa de transferência), o Amazon DynamoDB seria uma boa opção.

Armadilha Comum: Tentar forçar um banco de dados relacional para um caso de uso NoSQL (ou vice-versa). Por exemplo, usar RDS para armazenar dados de IoT de alta taxa de ingestão, o que pode levar a problemas de performance e escalabilidade. Ou usar DynamoDB para dados que exigem joins complexos e transações multi-tabela, o que pode complicar o desenvolvimento e o gerenciamento.

2.4. Arquitetar soluções de rede.

Conceitos Fundamentais e Avançados

As soluções de rede na AWS são a base para a conectividade de todas as aplicações e serviços. O domínio 2 aprofunda os conceitos de rede, incluindo VPCs, conectividade global e serviços de entrega de conteúdo.

• Amazon VPC (Virtual Private Cloud): O serviço fundamental para criar sua rede virtual isolada na AWS. Permite definir sub-redes (públicas e privadas), tabelas de rotas, gateways de internet, gateways NAT e endpoints de VPC. É o alicerce para a segurança e o isolamento da rede.
  • Endpoints de VPC (Interface e Gateway): Permitem que você se conecte a serviços da AWS (como S3 e DynamoDB) e serviços de endpoint de VPC alimentados por PrivateLink sem usar um gateway de internet, um dispositivo NAT ou uma conexão VPN. Isso mantém o tráfego dentro da rede da AWS, aumentando a segurança e reduzindo a latência.
• AWS Transit Gateway: (Já abordado no Domínio 1) Atua como um hub central para conectar VPCs e redes on-premises, simplificando o roteamento e a conectividade em arquiteturas complexas e multi-contas.
• AWS PrivateLink: (Já abordado no Domínio 1) Permite que você exponha serviços em sua VPC para outras VPCs ou para redes on-premises de forma privada e segura, sem expor o tráfego à Internet pública.
• VPC Peering: (Já abordado no Domínio 1) Conecta duas VPCs diretamente, permitindo que elas se comuniquem como se estivessem na mesma rede. Ideal para um número limitado de conexões ponto a ponto.
• AWS Direct Connect e AWS VPN: (Já abordados no Domínio 1) Soluções para conectividade híbrida entre on-premises e AWS, oferecendo conexões privadas e seguras, respectivamente.
• Amazon Route 53: Um serviço de DNS (Domain Name System) web escalável e altamente disponível. Além da resolução de nomes, oferece recursos avançados de roteamento:
  • DNS Multi-Região: Permite rotear o tráfego para recursos em diferentes regiões com base em latência, geolocalização, ponderação ou saúde do recurso, crucial para alta disponibilidade e recuperação de desastres.
  • Políticas de Roteamento: Incluem roteamento simples, ponderado, baseado em latência, failover, geolocalização, multi-valor de resposta e baseado em proximidade (com Global Accelerator).
• Amazon CloudFront: Um serviço de rede de entrega de conteúdo (CDN) rápido que entrega dados, vídeos, aplicações e APIs com segurança globalmente, com baixa latência e altas velocidades de transferência. Ele armazena em cache o conteúdo em edge locations (Pontos de Presença) próximos aos usuários.
  • URLs Assinadas e Cookies Assinados: Permitem controlar o acesso ao conteúdo do CloudFront, concedendo acesso temporário a usuários específicos. Útil para conteúdo premium ou privado.
  • Geo-restrições: Permitem controlar quais países podem acessar seu conteúdo do CloudFront.
• AWS Global Accelerator: Um serviço de rede que melhora a disponibilidade e a performance de suas aplicações para usuários globais. Ele roteia o tráfego para o endpoint de aplicação mais saudável e mais próximo usando a rede global da AWS, otimizando a performance em comparação com a Internet pública.
• AWS App Mesh: Um service mesh que fornece visibilidade e controle de rede para suas aplicações baseadas em microsserviços. Ele padroniza como os microsserviços se comunicam, fornecendo recursos como roteamento de tráfego, retries, circuit breaking e métricas.
• AWS Cloud Map: Um serviço de descoberta de recursos que permite que suas aplicações descubram e se conectem a serviços de nuvem dinamicamente. Ele mantém um registro de todos os seus recursos de aplicação e seus locais, e os atualiza automaticamente.
• VPC Lattice: Um novo serviço que simplifica a conectividade, segurança e observabilidade entre serviços em uma arquitetura de microsserviços. Ele permite que você defina políticas de acesso e roteamento em um nível de serviço, independentemente da infraestrutura de rede subjacente. Facilita a comunicação entre serviços em diferentes VPCs e contas.

Comparações entre Serviços e Quando Usar Cada Um

AWS Transit Gateway vs. AWS PrivateLink vs. VPC Peering:

• CloudFront vs. Global Accelerator: Ambos melhoram a performance e a disponibilidade, mas em diferentes camadas. CloudFront é um CDN para conteúdo web (camada 7 - HTTP/HTTPS), otimizando a entrega de conteúdo estático e dinâmico. Global Accelerator opera na camada de rede (camada 4 - TCP/UDP), otimizando o roteamento do tráfego para aplicações, independentemente do protocolo. Use CloudFront para conteúdo web e Global Accelerator para aplicações que não são baseadas em HTTP/HTTPS ou que exigem endereços IP estáticos.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon VPC:

• Configurações: Defina blocos CIDR, crie sub-redes (públicas/privadas), configure tabelas de rotas, gateways de internet, NAT Gateways, Endpoints de VPC. Use Security Groups e NACLs para controle de tráfego.
• Limitações: Limites de blocos CIDR, número de VPCs, sub-redes, Security Groups por região/conta.
• Boas Práticas: Use um modelo de VPC com sub-redes públicas e privadas. Use NAT Gateways para acesso de saída de sub-redes privadas. Use Endpoints de VPC para acesso seguro a serviços AWS. Monitore Flow Logs para visibilidade do tráfego.
• Casos de Uso: Isolamento de ambientes (dev, test, prod), hospedagem de aplicações multi-tier, redes híbridas.

Amazon Route 53:

• Configurações: Crie zonas hospedadas, registros DNS (A, CNAME, MX, TXT, etc.), configure políticas de roteamento (simples, ponderado, latência, failover, geolocalização).
• Limitações: Limites de zonas hospedadas e registros por zona.
• Boas Práticas: Use políticas de roteamento de failover para alta disponibilidade. Use roteamento baseado em latência para otimizar a performance global. Use health checks para monitorar a saúde dos endpoints.
• Casos de Uso: Resolução de DNS para domínios, roteamento de tráfego global, failover de aplicações.

Amazon CloudFront:

• Configurações: Crie distribuições, defina origens (S3, EC2, Load Balancers), configure comportamentos de cache, SSL/TLS, URLs/Cookies assinados, geo-restrições.
• Limitações: Custos de transferência de dados podem ser significativos. Invalidações de cache podem levar tempo.
• Boas Práticas: Use para entregar conteúdo estático e dinâmico. Otimize as configurações de cache para melhorar a performance e reduzir custos. Use URLs/Cookies assinados para conteúdo restrito.
• Casos de Uso: Aceleração de sites e aplicações web, streaming de vídeo, distribuição de APIs, entrega de conteúdo de software.

AWS Global Accelerator:

• Configurações: Crie um acelerador, adicione ouvintes (listeners) e grupos de endpoints (com instâncias EC2, Load Balancers, Elastic IPs). O Global Accelerator fornece dois endereços IP estáticos.
• Limitações: Não é um CDN. Não armazena conteúdo em cache.
• Boas Práticas: Use para aplicações que exigem alta disponibilidade e performance global, especialmente para tráfego não-HTTP/HTTPS. Use com health checks para rotear para endpoints saudáveis.
• Casos de Uso: Jogos online, VoIP, aplicações financeiras, aplicações que exigem endereços IP estáticos globais.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura de Rede em Estrela (Hub-and-Spoke): Com o Transit Gateway como hub central, conectando VPCs de diferentes ambientes (produção, desenvolvimento, segurança) e redes on-premises.
• Padrões de Segurança: Implemente o princípio do menor privilégio para acesso à rede. Use Security Groups e NACLs. Use AWS WAF e Shield para proteção de aplicações web. Monitore o tráfego com VPC Flow Logs e CloudWatch.
• Resiliência: Projete redes multi-AZ e multi-região. Use Load Balancers para distribuir o tráfego. Implemente failover de DNS com Route 53.
• Governança: Use AWS Organizations para gerenciar contas de rede. Use AWS Config para monitorar a conformidade das configurações de rede. Use AWS Network Manager para gerenciar e monitorar sua rede global.

Estratégias de Migração e Modernização

• Migração de Rede: Migre redes on-premises para VPCs usando Direct Connect ou VPN. Consolide redes complexas com VPC Peering em uma arquitetura Transit Gateway.
• Modernização: Adote VPC Lattice para simplificar a conectividade e segurança de microsserviços. Use CloudFront e Global Accelerator para otimizar a entrega de aplicações globais. Refatore aplicações para usar Endpoints de VPC para acesso privado a serviços AWS.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa tem uma aplicação web global que precisa entregar conteúdo estático e dinâmico com baixa latência para usuários em todo o mundo, além de uma API backend que precisa de alta performance e disponibilidade.

• Decisão Arquitetural: Usar Amazon CloudFront para entregar o conteúdo estático (imagens, CSS, JS) e dinâmico (HTML). Para a API backend, usar AWS Global Accelerator para rotear o tráfego para o endpoint de API mais próximo e saudável, garantindo baixa latência e alta disponibilidade. O CloudFront pode ser configurado para usar o Global Accelerator como origem para a API.

Armadilha Comum: Não otimizar o roteamento de DNS ou a entrega de conteúdo para usuários globais, resultando em alta latência e má experiência do usuário. Confundir o propósito de CloudFront e Global Accelerator e usar um onde o outro seria mais apropriado.

2.5. Arquitetar soluções de mensageria e integração.

Conceitos Fundamentais e Avançados

Serviços de mensageria e integração são cruciais para construir aplicações distribuídas, desacopladas e escaláveis. Eles permitem que diferentes componentes de uma aplicação se comuniquem de forma assíncrona, aumentando a resiliência e a flexibilidade.

• Amazon Simple Notification Service (SNS): Um serviço de mensagens pub/sub (publicar/assinar) totalmente gerenciado. Permite enviar mensagens para um grande número de assinantes (aplicações, usuários, outros serviços AWS) de forma assíncrona. Ideal para notificações, fanout de eventos e comunicação entre microsserviços.
• Amazon Simple Queue Service (SQS): Um serviço de fila de mensagens totalmente gerenciado que permite desacoplar e escalar microsserviços, sistemas distribuídos e aplicações serverless. As mensagens são armazenadas em uma fila até que um consumidor as processe. Suporta filas padrão (alta taxa de transferência, melhor esforço de ordenação) e filas FIFO (First-In, First-Out - garante ordenação e processamento

exatamente uma vez).

• Amazon EventBridge: Um barramento de eventos serverless que facilita a conexão de aplicações usando dados de seus próprios aplicativos, software como serviço (SaaS) e serviços da AWS. Ele permite rotear eventos de várias fontes para destinos como AWS Lambda, Amazon SQS, Amazon SNS e outros. Ideal para arquiteturas orientadas a eventos e integração entre sistemas.
• AWS Step Functions: Um serviço de fluxo de trabalho serverless que permite orquestrar funções Lambda e outros serviços AWS para construir aplicações complexas. Ele gerencia o estado, o tratamento de erros e as repetições, tornando a construção de fluxos de trabalho distribuídos mais fácil.
• Amazon Kinesis: Uma plataforma para streaming de dados em tempo real. Inclui:
  • Kinesis Data Streams: Para coletar e processar grandes fluxos de dados em tempo real.
  • Kinesis Data Firehose: Para entregar fluxos de dados para destinos como S3, Redshift, Splunk e outros.
  • Kinesis Data Analytics: Para processar e analisar dados de streaming em tempo real usando SQL ou Apache Flink.
• Amazon Managed Streaming for Apache Kafka (MSK): Um serviço totalmente gerenciado para Apache Kafka, facilitando a construção e execução de aplicações que usam Apache Kafka para processamento de dados em tempo real.
• AWS AppSync: Um serviço de GraphQL totalmente gerenciado que facilita o desenvolvimento de aplicações com dados em tempo real e offline. Ele lida com a conexão segura a fontes de dados, como DynamoDB, Lambda e bancos de dados relacionais.
• Amazon API Gateway: Um serviço totalmente gerenciado que facilita a criação, publicação, manutenção, monitoramento e proteção de APIs em qualquer escala. Atua como um

front-door para aplicações, permitindo que os clientes acessem dados, lógica de negócios ou funcionalidades de seus serviços de backend.

• AWS IoT Core: Um serviço gerenciado que permite que dispositivos conectados interajam de forma segura e fácil com aplicações em nuvem e outros dispositivos. Ideal para soluções de Internet das Coisas.

Comparações entre Serviços e Quando Usar Cada Um

SNS vs. SQS vs. EventBridge:

• Use SNS quando: Você precisa enviar a mesma mensagem para múltiplos assinantes de forma assíncrona. Ideal para notificações (SMS, e-mail, push), fanout de eventos para múltiplos sistemas downstream, ou para acionar várias funções Lambda em paralelo.
• Use SQS quando: Você precisa desacoplar componentes de uma aplicação, processar mensagens de forma assíncrona e garantir que cada mensagem seja processada uma vez (com filas FIFO). Ideal para filas de trabalho, processamento em lote, ou para lidar com picos de tráfego.
• Use EventBridge quando: Você precisa construir arquiteturas orientadas a eventos, integrar aplicações com serviços AWS ou SaaS, ou rotear eventos de forma inteligente com base em regras. É mais poderoso que SNS para roteamento de eventos complexos e filtragem.

Kinesis Data Streams vs. SQS:

• Kinesis Data Streams: Ideal para processamento de dados em tempo real, onde a ordem dos registros é importante e você precisa de múltiplos consumidores para processar o mesmo fluxo de dados. Ex: clickstreams, dados de IoT.
• SQS: Ideal para desacoplar componentes e processar mensagens de forma assíncrona, onde cada mensagem é processada por um único consumidor (ou um grupo de consumidores para filas padrão). Ex: filas de tarefas, processamento de pedidos.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon SNS:

• Configurações: Crie tópicos, adicione assinantes (Lambda, SQS, HTTP/S, e-mail, SMS), defina políticas de acesso. Configure filas de dead-letter (DLQ) para mensagens não entregues.
• Limitações: Tamanho máximo da mensagem (256 KB). Não garante a ordem de entrega para tópicos padrão.
• Boas Práticas: Use para fanout de eventos. Integre com SQS para durabilidade e processamento assíncrono. Use DLQs para lidar com falhas de entrega.
• Casos de Uso: Notificações de sistema, fanout de eventos de S3, acionamento de múltiplos microsserviços, alertas.

Amazon SQS:

• Configurações: Crie filas (padrão ou FIFO), configure visibilidade de mensagens, atraso, retenção, políticas de acesso. Configure DLQs.
• Limitações: Tamanho máximo da mensagem (256 KB). Filas FIFO têm menor throughput que filas padrão.
• Boas Práticas: Use filas FIFO para workloads que exigem ordenação e processamento exatamente uma vez. Use filas padrão para alta taxa de transferência. Monitore o número de mensagens visíveis e invisíveis.
• Casos de Uso: Filas de trabalho, processamento de pedidos, desacoplamento de microsserviços, processamento de dados em lote.

Amazon EventBridge:

• Configurações: Crie barramentos de eventos, defina regras com padrões de eventos e destinos. Use o Schema Registry para gerenciar esquemas de eventos.
• Limitações: Limites no número de regras e destinos por regra.
• Boas Práticas: Use para construir arquiteturas orientadas a eventos. Use regras para filtrar e rotear eventos para destinos específicos. Use o Schema Registry para garantir a compatibilidade de eventos.
• Casos de Uso: Integração entre serviços AWS, integração com SaaS, auditoria de eventos, automação de fluxos de trabalho.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura Orientada a Eventos: Use EventBridge como o hub central para eventos, com produtores publicando eventos e consumidores reagindo a eles. Isso promove o desacoplamento e a escalabilidade.
• Padrões de Segurança: Use IAM Roles para conceder permissões mínimas aos produtores e consumidores de mensagens. Criptografe mensagens em trânsito e em repouso. Use políticas de acesso para controlar quem pode publicar ou consumir mensagens.
• Resiliência: Use filas de mensagens (SQS) para absorver picos de tráfego e garantir a entrega de mensagens. Use DLQs para lidar com mensagens que não podem ser processadas. Implemente retries e backoff exponenciais.
• Governança: Use AWS CloudTrail para auditar as operações de API em serviços de mensageria. Use AWS Config para monitorar a conformidade das configurações.

Estratégias de Migração e Modernização

• Migração: Substitua sistemas de mensageria on-premises por SQS e SNS. Migre sistemas de integração legados para EventBridge para uma abordagem orientada a eventos.
• Modernização: Refatore aplicações monolíticas em microsserviços que se comunicam via eventos e filas. Adote Step Functions para orquestrar fluxos de trabalho complexos e de longa duração.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de e-commerce precisa processar pedidos de forma assíncrona. Após um pedido ser feito, várias ações precisam ser executadas: atualizar o estoque, enviar e-mail de confirmação, notificar o sistema de logística e atualizar o CRM.

• Decisão Arquitetural: O serviço de pedidos publica uma mensagem em uma fila SQS. Um consumidor (por exemplo, uma função Lambda) lê a mensagem da fila e orquestra as ações subsequentes usando AWS Step Functions. O Step Functions pode chamar funções Lambda para atualizar o estoque e o CRM, e publicar em um tópico SNS para enviar o e-mail de confirmação e notificar o sistema de logística. Isso garante que o processamento do pedido seja robusto, escalável e tolerante a falhas.

Armadilha Comum: Usar SNS para desacoplar componentes quando SQS seria mais apropriado, resultando em mensagens perdidas se os assinantes não estiverem disponíveis. Ou, inversamente, usar SQS para fanout de eventos, o que exigiria que cada consumidor fizesse polling da fila, em vez de receber a mensagem por push.

Domínio 3: Melhoria Contínua para Soluções Existentes

Este domínio concentra-se na otimização e aprimoramento de arquiteturas existentes para melhorar a performance, resiliência, segurança e eficiência operacional. O foco é garantir que as soluções AWS continuem a atender aos requisitos de negócios em evolução e às melhores práticas da indústria.

Tópicos e Subtópicos:

3.1. Arquitetar soluções para alta disponibilidade e resiliência.

Conceitos Fundamentais e Avançados

Alta disponibilidade e resiliência são pilares críticos de qualquer arquitetura de nuvem robusta. A AWS oferece uma série de serviços e padrões para garantir que as aplicações permaneçam operacionais mesmo diante de falhas.

• Estratégias de Recuperação de Desastres (DR): A recuperação de desastres envolve a preparação para a recuperação de um evento que interrompe as operações de negócios. As estratégias de DR são classificadas com base em dois objetivos principais:
  • Recovery Time Objective (RTO): O tempo máximo aceitável para restaurar o serviço após um desastre. Um RTO baixo significa que o serviço deve ser restaurado rapidamente.
  • Recovery Point Objective (RPO): A quantidade máxima aceitável de perda de dados medida em tempo. Um RPO baixo significa que pouca ou nenhuma perda de dados é tolerada. As estratégias de DR na AWS incluem:
    • Backup e Restauração: O método mais simples e de menor custo. Os dados são copiados para outra região ou conta e restaurados em caso de desastre. RTO e RPO são mais altos.
    • Piloto Leve (Pilot Light): Uma versão mínima da aplicação é mantida em execução em uma região de DR. Em caso de desastre, os recursos são escalados para restaurar a funcionalidade completa. RTO e RPO são menores que backup e restauração.
    • Warm Standby: Uma versão em escala reduzida da aplicação está sempre em execução na região de DR, pronta para assumir a carga. RTO e RPO são ainda menores.
    • Multi-Site Ativo-Ativo (Multi-Region Active-Active): A aplicação é executada simultaneamente em múltiplas regiões, com o tráfego roteado para ambas. Oferece o menor RTO e RPO (próximo de zero), mas é a estratégia mais cara e complexa.
• AWS Well-Architected Framework (Pilar de Confiabilidade): Este pilar fornece diretrizes para projetar sistemas que podem se recuperar de falhas e continuar a funcionar conforme o esperado. Abrange tópicos como recuperação de desastres, design para falhas, gerenciamento de mudanças e monitoramento.
• Amazon Route 53: Além de ser um serviço DNS, o Route 53 é fundamental para a resiliência, oferecendo:
  • Roteamento de Failover: Roteia o tráfego para um recurso alternativo se o recurso primário se tornar não saudável.
  • Roteamento Baseado em Latência: Roteia o tráfego para a região da AWS que oferece a menor latência para o usuário.
• AWS Global Accelerator: Melhora a disponibilidade e a performance de aplicações para usuários globais, roteando o tráfego para o endpoint mais saudável e mais próximo usando a rede global da AWS.
• Elastic Load Balancing (ELB): Distribui o tráfego de entrada entre múltiplas instâncias de destino em múltiplas Zonas de Disponibilidade, aumentando a disponibilidade e a tolerância a falhas.
• Amazon EC2 Auto Scaling: Ajusta automaticamente o número de instâncias EC2 em seu grupo de Auto Scaling em resposta a condições definidas, garantindo que a aplicação tenha a capacidade necessária para lidar com a demanda e se recupere de falhas de instâncias.
• Amazon CloudFront: Atua como um CDN, armazenando em cache o conteúdo em edge locations próximos aos usuários, o que melhora a performance e a resiliência ao reduzir a carga sobre os servidores de origem.
• AWS Shield e AWS WAF: Serviços de segurança que protegem contra ataques DDoS (Shield) e fornecem proteção em nível de aplicação contra exploits web comuns (WAF).
• Padrões de Resiliência:
  • Circuit Breaker: Impede que uma aplicação tente repetidamente uma operação que provavelmente falhará, protegendo o sistema de sobrecarga e permitindo que ele se recupere.
  • Sagas: Um padrão para gerenciar transações distribuídas, garantindo a consistência dos dados em um sistema de microsserviços, mesmo quando as operações falham.

Comparações entre Serviços e Quando Usar Cada Um

As estratégias de DR (Backup e Restauração, Piloto Leve, Warm Standby, Multi-Site Ativo-Ativo) são escolhas que dependem diretamente dos requisitos de RTO e RPO. Quanto menores os RTO e RPO desejados, mais complexa e cara será a estratégia.

Configurações, Limitações, Boas Práticas e Casos de Uso

Estratégias de DR:

• Configurações: Envolvem a replicação de dados (via S3 Cross-Region Replication, DynamoDB Global Tables, RDS Read Replicas ou DMS), o provisionamento de infraestrutura na região de DR e a configuração de roteamento de DNS (Route 53) para failover.
• Limitações: O custo e a complexidade aumentam significativamente à medida que RTO e RPO diminuem.
• Boas Práticas: Defina RTO e RPO claros para cada aplicação. Teste regularmente seu plano de DR. Automatize o processo de failover e recuperação sempre que possível.
• Casos de Uso:
  • Backup e Restauração: Dados de arquivos, backups de bancos de dados não críticos.
  • Piloto Leve/Warm Standby: Aplicações de negócios críticas que podem tolerar alguns minutos ou horas de inatividade.
  • Multi-Site Ativo-Ativo: Aplicações de missão crítica que exigem alta disponibilidade contínua (ex: serviços financeiros, e-commerce de alto volume).

Amazon EC2 Auto Scaling:

• Configurações: Defina um grupo de Auto Scaling, especifique o tamanho mínimo, desejado e máximo, configure políticas de escalabilidade (simples, baseada em etapas, de rastreamento de destino), e health checks.
• Limitações: A escalabilidade leva tempo para que novas instâncias sejam provisionadas e inicializadas.
• Boas Práticas: Use métricas de utilização de CPU ou requisições de Load Balancer para escalar. Use warm pools para reduzir o tempo de inicialização de novas instâncias. Monitore o grupo de Auto Scaling com CloudWatch.
• Casos de Uso: Aplicações web, microsserviços, qualquer workload que precise de escalabilidade elástica e resiliência a falhas de instâncias.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura Multi-AZ: Implante recursos em pelo menos duas Zonas de Disponibilidade dentro de uma região para proteger contra falhas de AZ. Use Load Balancers e Auto Scaling para distribuir o tráfego.
• Arquitetura Multi-Região: Para os requisitos mais rigorosos de RTO/RPO, implante a aplicação em múltiplas regiões. Use serviços como Route 53 e Global Accelerator para roteamento de tráfego e failover.
• Padrões de Segurança: Implemente o princípio do menor privilégio. Use Security Groups e NACLs. Criptografe dados em repouso e em trânsito. Use AWS Shield e WAF para proteção de borda.
• Resiliência: Projete para falhas. Implemente timeouts, retries e circuit breakers. Use filas e mensageria para desacoplar componentes. Teste a resiliência regularmente com Chaos Engineering.
• Governança: Use AWS Config para monitorar a conformidade das configurações de resiliência. Use AWS Resilience Hub para avaliar e gerenciar a resiliência de suas aplicações.

Estratégias de Migração e Modernização

• Modernização para Resiliência: Ao modernizar, refatore aplicações para serem stateless e use serviços gerenciados que são inerentemente resilientes (ex: DynamoDB Global Tables, Aurora Multi-Master). Adote padrões de microsserviços para isolar falhas.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de streaming de vídeo de missão crítica precisa de um RTO de segundos e um RPO de zero para seus dados de sessão de usuário.

• Decisão Arquitetural: Implementar uma estratégia de DR Multi-Site Ativo-Ativo usando DynamoDB Global Tables para os dados de sessão (que oferece replicação multi-região ativa-ativa com RPO próximo de zero) e Amazon Route 53 com roteamento de failover para direcionar o tráfego para a região saudável.

Armadilha Comum: Não testar o plano de recuperação de desastres regularmente. Um plano de DR não testado é um plano de DR que provavelmente falhará quando mais for necessário. Outra armadilha é superestimar a resiliência de um serviço sem entender suas limitações (ex: acreditar que Multi-AZ para RDS protege contra falhas de região inteira).

3.2. Arquitetar soluções para otimização de performance.

Conceitos Fundamentais e Avançados

A otimização de performance na AWS envolve a seleção e configuração de recursos para garantir que as aplicações respondam rapidamente e processem dados de forma eficiente, ao mesmo tempo em que se equilibra com os custos. O Pilar de Eficiência de Performance do AWS Well-Architected Framework fornece diretrizes para isso.

• AWS Well-Architected Framework (Pilar de Eficiência de Performance): Este pilar foca na capacidade de usar recursos de computação de forma eficiente para atender aos requisitos do sistema e manter essa eficiência à medida que a demanda muda. Abrange tópicos como seleção de recursos, monitoramento, otimização de rede e armazenamento.
• Otimização de Computação:
  • Escolha de Instâncias: Selecionar o tipo de instância EC2 correto (família, tamanho) para a workload. Instâncias otimizadas para computação, memória, armazenamento ou rede.
  • Otimização de Contêineres: Otimizar imagens de contêiner para serem pequenas e eficientes. Usar Fargate para abstrair o gerenciamento de servidores.
  • Lambda Provisioned Concurrency: Pre-inicializa instâncias de funções Lambda para reduzir cold starts, melhorando a latência para aplicações sensíveis ao tempo.
• Otimização de Armazenamento:
  • Escolha de Classes de S3: Usar a classe de armazenamento S3 apropriada (Standard, IA, Glacier) com base na frequência de acesso para otimizar custos e performance de recuperação.
  • Otimização de EBS: Selecionar o tipo de volume EBS correto (gp3, io2 Block Express) e provisionar IOPS/throughput adequados para a workload.
  • Otimização de EFS/FSx: Escolher os modos de performance e throughput corretos para EFS, e o tipo de FSx adequado para o caso de uso (Lustre para HPC, Windows para SMB).
• Otimização de Banco de Dados:
  • Escolha de Tipo de DB: Selecionar o tipo de banco de dados (relacional, NoSQL, etc.) que melhor se adapta aos padrões de acesso e requisitos de escalabilidade da aplicação.
  • Otimização de Consultas: Otimizar consultas SQL e NoSQL para reduzir o tempo de execução e o consumo de recursos.
  • Caching com ElastiCache: Usar Amazon ElastiCache (Redis ou Memcached) para armazenar em cache dados frequentemente acessados, reduzindo a carga sobre o banco de dados e melhorando a latência.
• Otimização de Rede:
  • Direct Connect: Para conexões on-premises de alta largura de banda e baixa latência.
  • Global Accelerator: Para roteamento de tráfego global otimizado para aplicações não-HTTP/HTTPS.
  • CloudFront: Para entrega de conteúdo com baixa latência e alta taxa de transferência via CDN.
• Caching: Implementar estratégias de cache em diferentes camadas da arquitetura (CDN com CloudFront, cache de aplicação com ElastiCache, cache de DNS com Route 53).
• Content Delivery Networks (CDNs): Redes de servidores distribuídos geograficamente que entregam conteúdo web e multimídia para usuários com base em sua localização, melhorando a velocidade de carregamento e reduzindo a carga sobre os servidores de origem.

Comparações entre Serviços e Quando Usar Cada Um

• ElastiCache (Redis vs. Memcached):
  • Redis: Mais rico em recursos, suporta estruturas de dados complexas (listas, sets, hashes), persistência de dados, replicação e clustering. Ideal para caching, leaderboards, contadores, filas de mensagens.
  • Memcached: Mais simples, focado em caching de objetos. Ideal para caching de dados simples e escalabilidade horizontal.

Configurações, Limitações, Boas Práticas e Casos de Uso

Otimização de Computação (EC2):

• Configurações: Monitore a utilização de CPU, memória e rede. Use o AWS Compute Optimizer para recomendações de dimensionamento correto.
• Limitações: A super-provisionamento leva a custos desnecessários; o sub-provisionamento leva a problemas de performance.
• Boas Práticas: Use o tipo de instância mais adequado para a workload. Use Auto Scaling para ajustar a capacidade dinamicamente. Considere instâncias com processadores otimizados (Graviton2/3) para melhor performance/custo.
• Casos de Uso: Aplicações web de alto tráfego, microsserviços, processamento de dados.

Amazon ElastiCache:

• Configurações: Escolha o motor (Redis/Memcached), tipo de nó, número de nós, Multi-AZ, grupos de segurança.
• Limitações: O cache é volátil (dados podem ser perdidos). Requer lógica de aplicação para gerenciar o cache.
• Boas Práticas: Armazene dados frequentemente acessados e que não mudam com frequência. Implemente estratégias de cache-aside ou write-through. Monitore as taxas de cache hit e miss.
• Casos de Uso: Caching de resultados de consultas de banco de dados, dados de sessão de usuário, rankings de jogos, feeds de notícias.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura de Caching em Camadas: Combine CDN (CloudFront) para cache de borda, ElastiCache para cache de aplicação/banco de dados e cache de objetos em S3 para dados estáticos.
• Padrões de Segurança: Use IAM Roles para acesso a serviços de cache. Criptografe dados em trânsito e em repouso no cache (Redis suporta criptografia).
• Resiliência: Use ElastiCache com Multi-AZ para alta disponibilidade. Implemente lógica de fallback na aplicação caso o cache não esteja disponível.
• Governança: Use AWS Config para monitorar a conformidade das configurações de performance. Use AWS Trusted Advisor para recomendações de otimização de performance.

Estratégias de Migração e Modernização

• Modernização para Performance: Refatore aplicações para serem stateless e usem cache extensivamente. Migre para serviços serverless e gerenciados que oferecem escalabilidade e performance otimizadas. Adote microsserviços para isolar e otimizar componentes individualmente.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de e-commerce sofre com alta latência nas consultas ao banco de dados durante picos de tráfego, impactando a experiência do usuário.

• Decisão Arquitetural: Implementar Amazon ElastiCache (Redis) para armazenar em cache os resultados de consultas frequentemente acessadas (ex: detalhes de produtos, categorias). A aplicação primeiro verifica o cache; se os dados não estiverem lá, consulta o banco de dados e armazena o resultado no cache para futuras requisições.

Armadilha Comum: Caching de dados que mudam com frequência, levando a dados desatualizados. Não invalidar o cache corretamente quando os dados de origem mudam. Não monitorar o cache hit ratio, o que pode indicar que o cache não está sendo eficaz.

3.3. Arquitetar soluções para monitoramento e observabilidade.

Conceitos Fundamentais e Avançados

Monitoramento e observabilidade são essenciais para entender o comportamento das aplicações, identificar problemas, otimizar performance e garantir a segurança. A AWS oferece um conjunto robusto de ferramentas para coletar, analisar e visualizar dados de telemetria.

• Amazon CloudWatch: Um serviço de monitoramento e gerenciamento que fornece dados e insights acionáveis para AWS, aplicações híbridas e on-premises. Ele coleta e rastreia métricas, coleta e monitora arquivos de log, e dispara alarmes com base em limites definidos.
  • Métricas: Pontos de dados que representam a performance de um recurso ao longo do tempo (ex: utilização de CPU, I/O de disco, requisições de Load Balancer).
  • Logs: Registros de eventos de aplicações e serviços (ex: logs de EC2, Lambda, VPC Flow Logs).
  • Alarmes: Acionam ações (ex: notificação SNS, Auto Scaling) quando uma métrica excede um limite.
  • Dashboards: Visualizações personalizadas de métricas e logs.
• AWS X-Ray: Ajuda desenvolvedores a analisar e depurar aplicações distribuídas, como as construídas usando uma arquitetura de microsserviços. Ele fornece uma visão de ponta a ponta das requisições à medida que elas viajam através dos componentes da aplicação, mostrando o desempenho da aplicação, gargalos e erros.
• AWS CloudTrail: Registra as chamadas de API da AWS feitas em sua conta, incluindo as feitas por usuários, funções e serviços da AWS. Esses logs de eventos podem ser usados para auditoria de segurança, rastreamento de alterações de recursos e solução de problemas operacionais.
• AWS Config: Permite avaliar, auditar e avaliar as configurações de seus recursos da AWS. Ele monitora continuamente as configurações dos recursos e as compara com as melhores práticas ou políticas definidas, alertando sobre não conformidades.
  • Conformance Packs: Coleções de regras e ações do AWS Config que podem ser implantadas como uma única entidade para ajudar a auditar e relatar a conformidade de um grupo de recursos.
• Amazon Kinesis (para ingestão de logs e métricas): Pode ser usado para coletar grandes volumes de logs e métricas em tempo real de várias fontes para processamento e análise downstream.
• AWS Systems Manager (OpsCenter, Explorer): Fornece uma visão centralizada de dados operacionais de seus recursos da AWS e permite automatizar a identificação e remediação de problemas.
• AWS Health Dashboard: Fornece uma visão personalizada da saúde dos serviços da AWS e dos eventos que podem afetar seus recursos.
• AWS Trusted Advisor: Um serviço que fornece recomendações para otimizar seus recursos da AWS em cinco categorias: otimização de custos, performance, segurança, tolerância a falhas e limites de serviço.
• Feature flags com CloudWatch Evidently: Permite que os desenvolvedores lancem novos recursos para um subconjunto de usuários, monitorem seu desempenho e impacto, e desativem ou ativem o recurso rapidamente com base em métricas em tempo real. Isso é parte de uma estratégia de observability-driven development.

Comparações entre Serviços e Quando Usar Cada Um

CloudWatch vs. X-Ray vs. CloudTrail:

• Use CloudWatch quando: Você precisa monitorar a saúde e a performance de seus recursos e aplicações, coletar logs e configurar alarmes. É a ferramenta central para monitoramento na AWS.
• Use X-Ray quando: Você precisa entender o fluxo de requisições através de uma aplicação distribuída, identificar gargalos de performance e depurar erros em microsserviços. Complementa o CloudWatch para observabilidade de aplicações.
• Use CloudTrail quando: Você precisa auditar as atividades em sua conta AWS para segurança, conformidade e solução de problemas. Ele registra todas as ações realizadas na conta.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon CloudWatch:

• Configurações: Crie alarmes com base em métricas, configure dashboards personalizados, envie logs de aplicações para CloudWatch Logs, use CloudWatch Events para automação.
• Limitações: Retenção de logs e métricas pode ter custos. Granularidade de métricas padrão (1 minuto).
• Boas Práticas: Defina alarmes para métricas críticas. Use logs estruturados (JSON) para facilitar a análise. Crie dashboards para visibilidade rápida. Use CloudWatch Agent para coletar métricas e logs de instâncias EC2 e on-premises.
• Casos de Uso: Monitoramento de utilização de recursos, detecção de erros de aplicação, alertas de segurança, escalabilidade automática.

AWS X-Ray:

• Configurações: Habilite o X-Ray para seus serviços (Lambda, EC2, ECS), configure o SDK do X-Ray em sua aplicação, use o X-Ray Daemon para enviar dados de trace.
• Limitações: Overhead de performance mínimo na aplicação. Requer instrumentação do código.
• Boas Práticas: Instrumente todos os componentes da aplicação. Use anotações e metadados para adicionar contexto aos traces. Monitore o mapa de serviço do X-Ray para identificar dependências e gargalos.
• Casos de Uso: Depuração de aplicações distribuídas, análise de latência de ponta a ponta, otimização de performance de microsserviços.

AWS Config:

• Configurações: Habilite o AWS Config para os tipos de recursos desejados, crie regras gerenciadas ou personalizadas, configure conformance packs.
• Limitações: Custos baseados no número de configurações gravadas e regras avaliadas.
• Boas Práticas: Use regras para impor padrões de segurança e conformidade. Use conformance packs para auditorias de conformidade em larga escala. Integre com AWS Security Hub para agregação de descobertas de segurança.
• Casos de Uso: Auditoria de conformidade, monitoramento de alterações de configuração, detecção de desvios de segurança.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura de Observabilidade Centralizada: Agregue logs e métricas de todas as contas e regiões em uma conta de log centralizada. Use CloudWatch, X-Ray e CloudTrail para uma visão unificada.
• Padrões de Segurança: Use CloudTrail para auditar todas as ações na conta. Use AWS Config para monitorar a conformidade de segurança. Integre com Security Hub para uma visão consolidada da postura de segurança.
• Resiliência: Use métricas e alarmes do CloudWatch para detectar problemas e acionar ações de recuperação automática (ex: Auto Scaling, Lambda).
• Governança: Use AWS Config para garantir que os recursos estejam configurados de acordo com as políticas da organização. Use CloudTrail para rastrear quem fez o quê e quando.

Estratégias de Migração e Modernização

• Modernização para Observabilidade: Ao modernizar, adote uma abordagem de observability-driven development. Instrumente aplicações com X-Ray. Use logs estruturados. Implemente feature flags com CloudWatch Evidently para lançamentos controlados e monitoramento de impacto.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de microsserviços está apresentando alta latência e erros intermitentes, mas é difícil identificar a causa raiz devido à complexidade da arquitetura distribuída.

• Decisão Arquitetural: Implementar AWS X-Ray para rastrear as requisições através de todos os microsserviços. O X-Ray fornecerá um mapa de serviço visual, mostrando as dependências, latências em cada etapa e quaisquer erros, permitindo identificar rapidamente o serviço ou componente que está causando o problema.

Armadilha Comum: Coletar muitos dados de monitoramento sem ter um plano para analisá-los ou agir sobre eles, resultando em

ruído e dificultando a identificação de problemas reais. Outra armadilha é não configurar alarmes adequados, o que significa que os problemas só são descobertos quando já estão impactando os usuários.

3.4. Arquitetar soluções para segurança contínua.

Conceitos Fundamentais e Avançados

A segurança na AWS é uma responsabilidade compartilhada entre a AWS e o cliente. A AWS é responsável pela segurança da nuvem, enquanto o cliente é responsável pela segurança na nuvem. Este domínio foca em como arquitetar soluções para manter uma postura de segurança robusta e contínua, utilizando os serviços de segurança da AWS.

• AWS Security Hub: Fornece uma visão abrangente de alto nível da sua postura de segurança na AWS. Ele agrega, organiza e prioriza seus alertas de segurança (ou descobertas) de vários serviços da AWS (como GuardDuty, Inspector, Macie) e de produtos de parceiros da AWS. Permite que você execute verificações de segurança automatizadas em relação aos padrões da indústria e às melhores práticas.
• Amazon GuardDuty: Um serviço de detecção de ameaças que monitora continuamente atividades maliciosas e comportamentos não autorizados para proteger suas contas e workloads da AWS. Ele usa machine learning, detecção de anomalias e inteligência de ameaças para identificar ameaças como criptomineração, acesso não autorizado a dados e ataques de negação de serviço.
• Amazon Detective: Um serviço que facilita a análise, investigação e identificação da causa raiz de descobertas de segurança ou atividades suspeitas. Ele coleta automaticamente dados de log de seus recursos da AWS e usa machine learning, análise estatística e teoria dos grafos para construir um modelo unificado de suas atividades, tornando mais fácil conduzir investigações de segurança.
• AWS Inspector: Um serviço de avaliação de vulnerabilidades automatizado que ajuda a melhorar a segurança e a conformidade de aplicações implantadas na AWS. Ele descobre automaticamente e avalia continuamente instâncias EC2, imagens de contêiner no Amazon ECR e funções Lambda em busca de vulnerabilidades e desvios de melhores práticas.
• AWS WAF (Web Application Firewall): Ajuda a proteger suas aplicações web ou APIs contra exploits web comuns que podem afetar a disponibilidade, comprometer a segurança ou consumir recursos excessivos. Permite criar regras personalizadas para bloquear ou permitir tráfego com base em condições que você especifica.
• AWS Shield: Um serviço de proteção contra ataques de negação de serviço distribuída (DDoS) gerenciado que protege aplicações em execução na AWS. Oferece dois níveis: Standard (proteção automática para todos os clientes AWS) e Advanced (proteção aprimorada para aplicações críticas, com detecção e mitigação mais sofisticadas).
• AWS Firewall Manager: Um serviço de gerenciamento de segurança que permite configurar e gerenciar centralmente regras de firewall em suas contas e aplicações na AWS Organizations. Simplifica a implantação e a auditoria de regras de AWS WAF, AWS Shield Advanced, Security Groups, AWS Network Firewall e Route 53 Resolver DNS Firewall.
• AWS Certificate Manager (ACM): Facilita o provisionamento, gerenciamento e implantação de certificados SSL/TLS para uso com serviços AWS (como ELB, CloudFront, API Gateway). Ajuda a proteger a comunicação de rede e estabelecer a identidade de sites e aplicações.
• AWS Secrets Manager: Ajuda a proteger o acesso às suas aplicações, serviços e recursos de TI. Permite que você gire, gerencie e recupere credenciais de banco de dados, chaves de API e outros segredos durante seu ciclo de vida. Reduz a necessidade de codificar segredos em texto simples.
• AWS Systems Manager Parameter Store: Fornece armazenamento seguro e hierárquico para dados de configuração e gerenciamento de segredos. Pode ser usado para armazenar senhas, strings de conexão de banco de dados, códigos de licença e outros valores que precisam ser acessados por suas aplicações.
• AWS Single Sign-On (AWS SSO) / AWS IAM Identity Center: Um serviço de nuvem que facilita o gerenciamento centralizado do acesso a várias contas AWS e aplicações de negócios. Permite que os usuários façam login uma vez para acessar todos os seus recursos e aplicações atribuídos.
• Princípio do Menor Privilégio: Uma prática de segurança fundamental que afirma que cada usuário, programa ou processo deve ter apenas as permissões mínimas necessárias para executar sua função. Na AWS, isso é implementado através de políticas de IAM granulares.
• Automação de Segurança: Utilizar serviços como AWS Security Hub e AWS Config Rules para automatizar a detecção de não conformidades de segurança e, em alguns casos, a remediação.

Comparações entre Serviços e Quando Usar Cada Um

AWS Security Hub vs. Amazon GuardDuty vs. Amazon Detective vs. AWS Inspector:

• Esses serviços são complementares e devem ser usados em conjunto para uma postura de segurança abrangente. O Security Hub atua como um orquestrador e agregador, enquanto GuardDuty, Detective e Inspector fornecem insights específicos sobre ameaças, investigações e vulnerabilidades, respectivamente.

AWS WAF vs. AWS Shield:

• AWS WAF: Protege aplicações web contra ataques em nível de aplicação (Camada 7), como injeção de SQL, cross-site scripting (XSS). Você define as regras para permitir ou bloquear o tráfego.
• AWS Shield: Protege contra ataques DDoS (Distributed Denial of Service) em níveis de rede (Camada 3) e transporte (Camada 4), e também em nível de aplicação (Camada 7) com o Shield Advanced. É uma proteção mais ampla contra ataques de negação de serviço.

Configurações, Limitações, Boas Práticas e Casos de Uso

AWS Security Hub:

• Configurações: Habilite o Security Hub, integre com outros serviços AWS (GuardDuty, Config, Macie), configure padrões de segurança (AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark).
• Limitações: Requer a habilitação de outros serviços de segurança para coletar descobertas. Não é uma ferramenta de remediação direta.
• Boas Práticas: Use o Security Hub como seu painel central de segurança. Automatize a resposta a descobertas usando EventBridge e Lambda. Revise regularmente as descobertas e priorize a remediação.
• Casos de Uso: Gerenciamento centralizado de segurança, auditoria de conformidade, resposta a incidentes.

Amazon GuardDuty:

• Configurações: Habilite o GuardDuty em todas as regiões. Configure notificações para descobertas de alta severidade.
• Limitações: Não bloqueia o tráfego. Apenas detecta ameaças.
• Boas Práticas: Habilite o GuardDuty em todas as contas e regiões. Integre as descobertas com o Security Hub e sistemas de SIEM. Use para identificar atividades suspeitas em tempo real.
• Casos de Uso: Detecção de comprometimento de credenciais, acesso não autorizado a instâncias, uso de portas incomuns, criptomineração.

AWS KMS (Key Management Service):

• Configurações: Crie chaves KMS (chaves de cliente gerenciadas - CMKs), defina políticas de chave, configure rotação de chaves. Use chaves multi-região para replicação de chaves entre regiões.
• Limitações: Custos por chave e por requisição de API. Limites de taxa de requisições.
• Boas Práticas: Use KMS para criptografar dados em repouso em serviços AWS (S3, EBS, RDS, Lambda). Use chaves separadas para diferentes aplicações ou ambientes. Implemente o princípio do menor privilégio para acesso a chaves.
• Casos de Uso: Criptografia de dados em repouso, gerenciamento de chaves de criptografia, assinaturas digitais.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura de Segurança em Camadas (Defense in Depth): Implemente segurança em todas as camadas da arquitetura, desde a rede (VPC, Security Groups, NACLs, WAF, Shield) até a aplicação (IAM, Secrets Manager, KMS) e os dados (criptografia).
• Padrões de Segurança: Implemente o princípio do menor privilégio em todas as políticas de IAM. Use roles cross-account para acesso seguro entre contas. Automatize a detecção e resposta a incidentes de segurança.
• Resiliência: Use serviços de segurança gerenciados pela AWS que são inerentemente resilientes (ex: Shield, WAF). Projete para que as falhas de segurança não levem a uma interrupção completa do serviço.
• Governança: Use AWS Organizations e SCPs para impor políticas de segurança em toda a organização. Use AWS Config e Conformance Packs para monitorar a conformidade de segurança. Realize auditorias de segurança regulares.

Estratégias de Migração e Modernização

• Modernização para Segurança: Ao modernizar, adote uma abordagem de segurança shift-left, integrando a segurança no ciclo de vida de desenvolvimento. Use ferramentas de segurança automatizadas. Migre de gerenciamento de segredos manual para AWS Secrets Manager. Adote ABAC para gerenciamento de permissões escalável.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa precisa garantir que nenhuma instância EC2 seja lançada sem criptografia de volume EBS em sua conta de produção, e que todas as atividades suspeitas sejam detectadas e investigadas.

• Decisão Arquitetural: Usar AWS Config para criar uma regra que detecta instâncias EC2 com volumes EBS não criptografados e, opcionalmente, uma função Lambda para remediar automaticamente. Habilitar Amazon GuardDuty para detecção de ameaças e Amazon Detective para investigação de incidentes. As descobertas de GuardDuty e Config seriam agregadas no AWS Security Hub para uma visão centralizada.

Armadilha Comum: Conceder permissões excessivas (privilégio elevado) a usuários ou funções, violando o princípio do menor privilégio. Não revisar regularmente as políticas de IAM e as configurações de segurança. Confiar apenas em uma única camada de segurança, em vez de implementar uma defesa em profundidade.

Domínio 4: Otimização de Custos e Performance

Este domínio foca na capacidade de projetar soluções que sejam eficientes em termos de custo e performance. Isso envolve a seleção de serviços e recursos apropriados, a implementação de estratégias de otimização e o monitoramento contínuo para garantir que os gastos sejam controlados e que a performance atenda aos requisitos.

Tópicos e Subtópicos:

4.1. Arquitetar soluções para otimização de custos.

Conceitos Fundamentais e Avançados

A otimização de custos na AWS é um processo contínuo que visa maximizar o valor dos investimentos na nuvem. O Pilar de Otimização de Custos do AWS Well-Architected Framework fornece diretrizes para alcançar esse objetivo.

• AWS Well-Architected Framework (Pilar de Otimização de Custos): Este pilar foca na capacidade de executar sistemas para entregar valor de negócio ao menor preço. Abrange tópicos como adoção de um modelo de consumo, medição da eficiência geral, interrupção de gastos com trabalho indiferenciado e análise e atribuição de gastos.
• Modelos de Preços da AWS:
  • On-Demand: Pague por capacidade de computação por hora ou segundo, sem compromisso de longo prazo. Ideal para workloads imprevisíveis ou de curta duração.
  • Reserved Instances (RIs): Compromisso de uso de instâncias EC2, RDS, Redshift, ElastiCache por 1 ou 3 anos em troca de um desconto significativo (até 75% em comparação com On-Demand). Podem ser Standard (menos flexíveis) ou Convertible (mais flexíveis).
  • Savings Plans: Um modelo de precificação flexível que oferece preços mais baixos em troca de um compromisso de uso consistente (medido em USD/hora) por um período de 1 ou 3 anos. Abrangem EC2, Fargate e Lambda. Oferecem mais flexibilidade que RIs.
  • Spot Instances: Permitem que você solicite capacidade EC2 não utilizada da AWS com grandes descontos (até 90% em comparação com On-Demand). Ideal para workloads tolerantes a interrupções, como processamento em lote, renderização ou testes.
• Otimização de Recursos:
  • Dimensionamento Correto (Rightsizing): Ajustar o tamanho dos recursos (instâncias EC2, volumes EBS, etc.) para corresponder à demanda da workload, evitando o super-provisionamento.
  • Elasticidade: Usar Auto Scaling para escalar recursos para cima e para baixo automaticamente com base na demanda, garantindo que você pague apenas pela capacidade que realmente usa.
  • Desligamento de Recursos Ociosos: Identificar e desligar recursos que não estão sendo utilizados (ex: instâncias de desenvolvimento fora do horário comercial).
• Gerenciamento de Custos e Visibilidade:
  • AWS Cost Explorer: Uma ferramenta para visualizar, entender e gerenciar seus custos e uso da AWS ao longo do tempo. Permite analisar tendências, identificar áreas de alto custo e prever gastos futuros.
  • AWS Budgets: Permite definir orçamentos personalizados que o alertam quando seus custos ou uso excedem (ou estão previstos para exceder) seus limites orçamentários.
  • AWS Cost and Usage Report (CUR): Fornece um conjunto abrangente de dados sobre seus custos e uso da AWS, permitindo análises detalhadas e integração com ferramentas de BI.
  • AWS Compute Optimizer: Um serviço que usa machine learning para analisar a configuração e as métricas de utilização de seus recursos de computação da AWS (EC2, Auto Scaling Groups, Lambda, EBS, Fargate) e recomenda os recursos ideais para reduzir custos e melhorar a performance.
  • AWS Trusted Advisor: Oferece recomendações para otimização de custos, performance, segurança, tolerância a falhas e limites de serviço.
• Estratégias Multi-Conta para Otimização de Custos: Usar AWS Organizations para consolidação de faturamento e aplicação de políticas de custos em toda a organização.

Comparações entre Serviços e Quando Usar Cada Um

Reserved Instances (RIs) vs. Savings Plans:

• Use Savings Plans quando: Você tem um uso consistente de computação (EC2, Fargate, Lambda) e quer o maior desconto com flexibilidade para mudar tipos de instância ou regiões.
• Use Reserved Instances quando: Você tem um uso muito estável e previsível de um tipo de instância específico (especialmente para RDS, Redshift, ElastiCache, onde Savings Plans não se aplicam).

Configurações, Limitações, Boas Práticas e Casos de Uso

Otimização de Custos:

• Configurações: Habilite o AWS Cost Explorer e o AWS Budgets. Configure o AWS Compute Optimizer. Use políticas de ciclo de vida para S3. Configure Auto Scaling para escalar para baixo.
• Limitações: A otimização de custos é um processo contínuo e requer monitoramento e ajustes regulares. Nem todas as workloads são adequadas para Spot Instances.
• Boas Práticas: Comece com o dimensionamento correto. Use o modelo de consumo (pague pelo que usa). Aproveite os descontos por volume. Use instâncias Spot para workloads tolerantes a falhas. Use Savings Plans ou RIs para workloads de base. Monitore e analise os custos regularmente.
• Casos de Uso: Redução de custos em ambientes de desenvolvimento/teste, otimização de workloads de produção, planejamento orçamentário.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura Serverless: Frequentemente a mais eficiente em termos de custo, pois você paga apenas pelo uso real, sem provisionamento de servidores.
• Padrões de Segurança: Implemente o princípio do menor privilégio para evitar o provisionamento excessivo de recursos. Monitore o uso de recursos para identificar anomalias que possam indicar atividades maliciosas.
• Resiliência: A elasticidade (Auto Scaling) que otimiza custos também contribui para a resiliência, garantindo que a capacidade seja ajustada à demanda.
• Governança: Use tagging para atribuição de custos. Implemente políticas de orçamento. Use AWS Organizations para gerenciar custos em várias contas.

Estratégias de Migração e Modernização

• Migração para Otimização de Custos: Ao migrar, considere refatorar aplicações para usar serviços gerenciados e serverless que oferecem um modelo de custo mais granular e otimizado. Use o AWS Migration Hub para rastrear e otimizar o processo de migração.
• Modernização para Otimização de Custos: Adote microsserviços e conteinerização para otimizar o uso de recursos. Use serviços serverless sempre que possível. Implemente práticas de FinOps para gerenciar e otimizar continuamente os custos da nuvem.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa tem uma grande frota de instâncias EC2 para processamento de dados em lote que pode ser interrompido e reiniciado. Eles querem reduzir os custos de computação.

• Decisão Arquitetural: Utilizar Spot Instances para a frota de processamento em lote. Isso pode reduzir os custos de computação em até 90% em comparação com as instâncias On-Demand. Para gerenciar a frota, pode-se usar o EC2 Fleet ou Auto Scaling Groups com uma estratégia de mixed instances que priorize Spot.

Armadilha Comum: Não considerar o custo total de propriedade (TCO) ao migrar para a nuvem, focando apenas nos custos de infraestrutura e ignorando os custos operacionais, de licenciamento ou de migração. Outra armadilha é comprar RIs ou Savings Plans sem uma análise cuidadosa do uso futuro, resultando em capacidade não utilizada e desperdício de dinheiro.

4.2. Arquitetar soluções para otimização de performance.

Conceitos Fundamentais e Avançados

A otimização de performance já foi abordada em detalhes no Domínio 3 (Seção 3.2). No contexto do Domínio 4, o foco é a intersecção entre performance e custo, buscando o equilíbrio ideal para entregar valor de negócio.

• AWS Well-Architected Framework (Pilar de Eficiência de Performance): Relembrando, este pilar foca na capacidade de usar recursos de computação de forma eficiente para atender aos requisitos do sistema e manter essa eficiência à medida que a demanda muda. A otimização de performance muitas vezes leva à otimização de custos, pois recursos mais eficientes podem significar menos recursos necessários.
• Serviços e Estratégias Chave (revisão e aprofundamento com foco em custo):
  • Dimensionamento Correto (Rightsizing): Usar o AWS Compute Optimizer para identificar e redimensionar recursos (EC2, EBS, Lambda, Fargate) para o tamanho ideal, o que otimiza tanto a performance quanto o custo.
  • Caching: Implementar estratégias de cache (CloudFront, ElastiCache) para reduzir a latência e a carga sobre os serviços de backend, o que pode levar a uma necessidade menor de recursos computacionais e, consequentemente, a custos mais baixos.
  • Elasticidade e Escalabilidade: Usar Auto Scaling e serviços serverless (Lambda, Fargate, DynamoDB) que escalam automaticamente com a demanda. Isso garante que você tenha a performance necessária nos picos, mas não pague por capacidade ociosa nos períodos de baixa demanda.
  • Otimização de Banco de Dados: Escolher o tipo de banco de dados correto para a workload (relacional, NoSQL, etc.) e otimizar consultas. O uso de DynamoDB com seu modelo de capacidade sob demanda, por exemplo, pode ser mais eficiente em custo para workloads com picos de tráfego do que um banco de dados relacional provisionado para o pico.
  • Otimização de Rede: Utilizar serviços como CloudFront e Global Accelerator para melhorar a performance de entrega de conteúdo e roteamento de tráfego, o que pode reduzir a necessidade de recursos de backend e, portanto, custos.
  • Armazenamento Inteligente: Usar classes de armazenamento S3 como Intelligent-Tiering, que movem automaticamente os dados para as classes de acesso infrequente ou arquivamento com base nos padrões de acesso, otimizando custos sem comprometer a performance de acesso quando necessário.

Comparações entre Serviços e Quando Usar Cada Um

• Compute Optimizer vs. Análise Manual: O Compute Optimizer automatiza a análise de performance e custo, fornecendo recomendações baseadas em machine learning, o que é mais eficiente e preciso do que a análise manual, especialmente em ambientes grandes e dinâmicos.

Configurações, Limitações, Boas Práticas e Casos de Uso

Otimização de Performance e Custo:

• Configurações: Habilite o AWS Compute Optimizer. Monitore métricas de performance e custo no CloudWatch e Cost Explorer. Configure políticas de ciclo de vida para S3 Intelligent-Tiering.
• Limitações: A otimização é um trade-off. Otimizar demais o custo pode impactar a performance, e vice-versa. É crucial encontrar o equilíbrio certo para os requisitos de negócio.
• Boas Práticas: Adote uma cultura de FinOps. Revise regularmente as recomendações do Compute Optimizer. Teste as otimizações em ambientes de não produção antes de aplicar em produção. Automatize o desligamento de recursos não utilizados.
• Casos de Uso: Redução de custos de infraestrutura, melhoria da experiência do usuário, garantia de que as aplicações atendam aos SLAs de performance.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

• Arquitetura Elástica e Serverless: Permite que a capacidade se ajuste à demanda, otimizando tanto a performance (capacidade suficiente nos picos) quanto o custo (não paga por capacidade ociosa).
• Padrões de Segurança: A otimização de recursos (rightsizng) também contribui para a segurança, pois menos recursos expostos significam uma superfície de ataque menor.
• Resiliência: A elasticidade é um componente chave da resiliência. A capacidade de escalar rapidamente para cima e para baixo ajuda a manter a performance e a disponibilidade sob carga variável.
• Governança: Use tags para rastrear o uso e o custo dos recursos. Implemente políticas de gerenciamento de recursos para garantir que os recursos sejam otimizados continuamente.

Estratégias de Migração e Modernização

• Modernização para Performance e Custo: Refatorar aplicações para usar serviços serverless e gerenciados que oferecem escalabilidade automática e um modelo de custo baseado no consumo. Isso geralmente resulta em melhor performance e custos mais baixos em comparação com a execução de workloads em VMs auto-gerenciadas.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação web de e-commerce tem um tráfego variável ao longo do dia, com picos significativos durante promoções. A empresa quer garantir a performance durante os picos e otimizar os custos nos períodos de baixa demanda.

• Decisão Arquitetural: Utilizar Amazon EC2 Auto Scaling para o backend da aplicação, configurado com políticas de escalabilidade baseadas na utilização da CPU ou no número de requisições do Load Balancer. Para o banco de dados, considerar Amazon Aurora Serverless ou DynamoDB On-Demand, que escalam automaticamente a capacidade e cobram apenas pelo uso real, eliminando a necessidade de provisionar para o pico.

Armadilha Comum: Não implementar Auto Scaling ou usar um modelo de provisionamento fixo para workloads com demanda variável, resultando em super-provisionamento (custo alto) ou sub-provisionamento (baixa performance). Ignorar as recomendações do Compute Optimizer ou não agir sobre elas.

Tabelas Comparativas e Resumos

Esta seção consolida informações importantes em tabelas para facilitar a consulta rápida e a tomada de decisões arquiteturais.

Estratégias de Recuperação de Desastres (DR)

Reserved Instances (RIs) vs. Savings Plans

Gatilhos Comuns de Auto Scaling

Comparação de Serviços de Mensageria: SNS vs. SQS vs. EventBridge

Detalhamento de Tópicos Obrigatórios

Esta seção aprofunda os tópicos mais críticos e frequentemente cobrados no exame, consolidando o conhecimento dos domínios anteriores.

1. Estratégias Multi-Account e AWS Organizations

• AWS Organizations: Permite gerenciar centralmente várias contas AWS. Facilita a aplicação de políticas, o faturamento consolidado e o gerenciamento de segurança.
• Landing Zone (via AWS Control Tower): Uma arquitetura de referência para configurar um ambiente multi-conta seguro e escalável. O Control Tower automatiza a criação da Landing Zone, estabelecendo uma linha de base com contas para log, auditoria e segurança, e aplicando guardrails (baseados em SCPs) para governança.
• Unidades Organizacionais (OUs): Permitem agrupar contas para aplicar políticas de forma hierárquica. Uma estrutura comum é ter OUs para Infraestrutura, Segurança, Workloads (separados por Prod, Dev, Test), etc.
• Service Control Policies (SCPs): Políticas de controle de serviço que definem as permissões máximas para as contas em uma OU. Elas não concedem permissões, mas atuam como um filtro, restringindo o que os administradores de contas podem delegar aos usuários e roles. Por exemplo, um SCP pode negar o acesso a regiões específicas ou impedir a desativação de serviços de segurança como CloudTrail e GuardDuty.

2. Networking Avançado

• Transit Gateway: Atua como um hub de rede central para conectar VPCs e redes on-premises. Simplifica a arquitetura de rede, elimina a necessidade de VPC Peering complexo e permite o roteamento centralizado.
• PrivateLink: Fornece conectividade privada entre VPCs, serviços AWS e suas redes on-premises sem expor o tráfego à internet pública. Cria um endpoint de interface em sua VPC que se conecta a um serviço de endpoint.
• Direct Connect: Uma conexão de rede dedicada e privada entre seu data center e a AWS. Oferece largura de banda consistente e baixa latência. O Direct Connect Gateway permite conectar a múltiplas VPCs em diferentes regiões com uma única conexão.
• DNS Multi-Região com Route 53: Essencial para alta disponibilidade e recuperação de desastres. Use políticas de roteamento como Failover (para DR ativo-passivo), Latency-based (para performance global) e Geolocation (para conformidade de dados) para direcionar o tráfego para a região mais apropriada.

3. IAM Avançado

• Permission Boundaries: Uma política de IAM gerenciada que define as permissões máximas que uma política de identidade pode conceder a uma entidade (usuário ou role). Útil para delegar a criação de roles a desenvolvedores, garantindo que eles não possam criar roles com mais permissões do que o limite definido.
• Attribute-Based Access Control (ABAC): Uma estratégia de autorização que define permissões com base em atributos (tags) anexados a usuários e recursos. É mais escalável que o RBAC (Role-Based Access Control) em ambientes com muitos recursos e políticas, pois você pode criar uma única política que se aplica a todos os recursos com uma determinada tag.
• Roles Cross-Account: Permitem que usuários ou serviços em uma conta (a conta confiável) assumam uma role em outra conta (a conta que confia) para acessar recursos. É a maneira padrão e segura de conceder acesso entre contas.
• IAM Roles Anywhere: Permite que workloads que rodam fora da AWS (como em seus data centers on-premises) usem certificados X.509 para obter credenciais de segurança temporárias e acessar recursos da AWS. Estende a segurança do IAM para fora da nuvem.

4. Observabilidade e Segurança Contínua

• CloudWatch: O serviço central para monitoramento de métricas e logs. Use CloudWatch Logs Insights para análises de log poderosas e CloudWatch Alarms para automação e alertas.
• CloudTrail: Audita todas as chamadas de API. Essencial para segurança e conformidade. Envie os logs para o S3 para retenção a longo prazo e para o CloudWatch Logs para análise em tempo real.
• AWS Config: Monitora a conformidade das configurações dos recursos. Use Conformance Packs para implantar um conjunto de regras de conformidade em sua organização.
• Security Hub: Agrega descobertas de segurança de GuardDuty, Inspector, Macie e outros serviços, fornecendo uma visão unificada da sua postura de segurança.
• GuardDuty: Detecção de ameaças baseada em machine learning. Monitora logs de CloudTrail, VPC Flow Logs e DNS para identificar atividades maliciosas.
• KMS Multi-Region Keys: Chaves KMS que podem ser replicadas para múltiplas regiões. Simplificam o gerenciamento de criptografia para dados que são replicados entre regiões, garantindo que você possa descriptografar os dados na região de DR.

5. Migração e Modernização (7Rs)

As 7 estratégias comuns de migração e modernização:

1. Retire (Aposentar): Descomissionar aplicações que não são mais necessárias.
2. Retain (Reter): Manter aplicações on-premises que não estão prontas para migrar.
3. Rehost (Lift-and-Shift): Migrar aplicações para a nuvem sem modificações. Rápido, mas com menos benefícios da nuvem. (Ex: usar Application Migration Service - MGN).
4. Replatform (Lift-and-Tinker): Migrar com algumas otimizações, como mover um banco de dados para RDS.
5. Repurchase (Comprar Novamente): Mover para um produto diferente, geralmente uma solução SaaS.
6. Refactor/Re-architect (Refatorar/Rearquitetar): Modificar a aplicação para aproveitar os recursos nativos da nuvem (ex: microsserviços, serverless). Maior benefício, mas maior esforço.
7. Relocate (Realocar): Mover infraestrutura de um ambiente de nuvem para outro (ex: VMware Cloud on AWS).

• AWS Migration Acceleration Program (MAP): Um programa que fornece consultoria, ferramentas e créditos de serviço para acelerar a migração para a AWS.

6. Novidades Relevantes

• VPC Lattice: Simplifica a conectividade, segurança e observabilidade entre serviços em diferentes VPCs e contas, sem a complexidade de gerenciar Transit Gateways ou VPC Peering para cada serviço.
• CloudFront Signed URLs/Cookies: Mecanismos para controlar o acesso a conteúdo privado no CloudFront. URLs assinadas são para acesso a arquivos individuais, enquanto cookies assinados podem conceder acesso a múltiplos arquivos.
• CloudWatch Evidently: Permite realizar experimentos e lançamentos de features (feature flags) para testar novas funcionalidades com um subconjunto de usuários e medir o impacto na performance e no negócio.

Cenários Práticos e Questões de Exemplo

Cenário 1: Otimização de Custos para Workload de Análise

• Situação: Uma empresa executa um cluster de análise de dados no Amazon EMR todas as noites. O trabalho leva cerca de 4 horas para ser concluído e pode ser reiniciado em caso de falha. O custo do cluster é alto.
• Decisão Arquitetural: Usar Spot Instances para os nós de tarefa (task nodes) do cluster EMR. Como os nós de tarefa não armazenam dados, a interrupção de uma instância Spot pode ser tolerada. Isso pode reduzir significativamente os custos de computação. Para os nós principais (master e core nodes), usar instâncias On-Demand ou Reserved Instances para garantir a estabilidade do cluster.

Cenário 2: Segurança de Acesso a Dados em Múltiplas Contas

• Situação: Uma aplicação em uma VPC na Conta A precisa acessar um bucket S3 na Conta B de forma segura, sem expor o tráfego à internet.
• Decisão Arquitetural: Criar um VPC Gateway Endpoint para o S3 na VPC da Conta A. Na Conta B, criar uma política de bucket S3 que permita o acesso a partir do VPC Endpoint da Conta A. Isso garante que o tráfego entre a VPC e o S3 permaneça na rede da AWS.

Cenário 3: Alta Disponibilidade para Aplicação Web Global

• Situação: Uma aplicação web com usuários em todo o mundo precisa de baixa latência e alta disponibilidade. A aplicação tem um backend de API e conteúdo estático.
• Decisão Arquitetural: Usar Amazon CloudFront para entregar o conteúdo estático e dinâmico. Configurar o CloudFront com múltiplas origens em diferentes regiões. Usar Amazon Route 53 com uma política de roteamento baseada em latência para direcionar os usuários para a região mais próxima. Implementar health checks do Route 53 para failover automático em caso de falha de uma região.

Cenário 4: Governança de Segurança em Larga Escala

• Situação: Uma empresa com dezenas de contas AWS quer garantir que ninguém possa desativar o AWS CloudTrail ou criar chaves de acesso IAM para o usuário root.
• Decisão Arquitetural: Usar AWS Organizations para gerenciar todas as contas. Criar uma Service Control Policy (SCP) e anexá-la à raiz da organização ou a uma OU específica. A SCP deve conter uma declaração de Deny explícita para as ações cloudtrail:StopLogging, cloudtrail:DeleteTrail e iam:CreateAccessKey quando o principal for o usuário root. Isso impõe a política em todas as contas afetadas, mesmo para os administradores dessas contas.