Guia - SAP-C02 AWS Certified Solutions Architect Professional
Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame SAP-C02 avalia. Leia de cima a baixo ou pule para uma seção.
Projetar Soluções para Complexidade Organizacional
Implementar um ambiente AWS com mais de 100 contas com guarda-corpos, registro e identidade consistentes desde o primeiro dia.
AWS Control Tower como zona de aterragem. O Account Factory provisiona contas; guarda-corpos obrigatórios + fortemente recomendados impõem linhas de base; arquivo de log centralizado + contas de auditoria criadas automaticamente.
Por quê: Control Tower codifica o padrão de multi-contas bem-arquitetado. Construir do zero apenas via Organizations reproduz o mesmo encanamento manualmente.
Precisa adicionar guarda-corpos e recursos personalizados além dos padrões do Control Tower em todas as contas.
Customizations for AWS Control Tower (CfCT). Pipeline de modelos do CloudFormation + SCPs implantados via StackSets para OUs.
Por quê: CfCT estende o Control Tower sem quebrar seu ciclo de vida. Regras personalizadas do Config, linhas de base de segurança, rede - tudo versionado e reproduzível.
Impor criptografia S3 KMS + remediar automaticamente buckets não conformes em 300 contas em <15 minutos.
Pacote de conformidade AWS Config em toda a organização via administrador delegado. Regra do Config + documento SSM Automation para remediação automática.
Por quê: Pacotes de conformidade implantam regras do Config + remediação em toda a organização a partir de uma conta. Abordagens por conta com Lambda ou apenas SCP perdem a detecção em tempo real ou a remediação.
Logs do CloudTrail à prova de adulteração em todas as contas retidos por 7 anos; apenas a equipe de segurança pode ler.
Trilha da organização entregando a um bucket S3 de conta de log dedicada. Object Lock no modo Compliance com retenção de 7 anos. SCP restringindo o acesso ao bucket a funções IAM de segurança.
Por quê: Object Lock no modo Compliance bloqueia a exclusão mesmo pelo usuário root. A trilha da organização coleta de todas as contas automaticamente. A conta de log dedicada isola o raio de explosão.
Federar 150 contas para o AD corporativo via SAML; atribuir permissões por grupo do AD.
IAM Identity Center com IdP SAML 2.0 externo. Conjuntos de permissões mapeados para grupos do AD via provisionamento SCIM. Atribuições de conta via grupos.
Por quê: Identity Center centraliza a federação em todas as contas da organização. Os conjuntos de permissões são reutilizáveis entre contas; SCIM mantém o estado de usuário/grupo sincronizado.
Conceder acesso a recursos marcados com o centro de custo do usuário, escalando para milhares de usuários.
Controle de acesso baseado em atributos (ABAC) no Identity Center. Passar atributos do AD via SAML; conjuntos de permissões referenciam `aws:PrincipalTag/CostCenter` contra `aws:ResourceTag/CostCenter`.
Por quê: ABAC escala sem alterações de política por usuário. Adicionar um novo centro de custo é apenas uma tag - sem reescrita de IAM.
A conta de CI/CD assume uma função de implantação em 50 contas de carga de trabalho para executar o CloudFormation.
Função IAM por conta de carga de trabalho com política de confiança permitindo o principal da conta de CI/CD. CI/CD assume via STS AssumeRole. Use external ID se uma ferramenta de terceiros iniciar.
Por quê: External ID previne o problema do confused deputy. O encadeamento de funções limita a sessão a 1 hora, mesmo que a função permita mais tempo.
A equipe de rede central possui a VPC; 30 contas spoke implantam cargas de trabalho em sub-redes compartilhadas.
O AWS RAM compartilha sub-redes com contas participantes. Os participantes lançam recursos sem possuir a VPC; a equipe central mantém o controle da tabela de rotas + NAT.
Por quê: VPCs compartilhadas eliminam a proliferação de VPCs por conta + IPAM duplicado. Os participantes não podem excluir a VPC ou alterar o roteamento.
Conectar VPCs em 5 regiões + on-prem com roteamento determinístico e inspeção central.
Transit Gateway em cada região. TGW peering para inter-região. VPC de inspeção com appliances acessíveis via tabelas de rotas do TGW.
Por quê: O TGW peering evita a malha completa de VPN/peering inter-regional. As tabelas de rotas por anexo permitem que a segurança inspecione fluxos específicos sem interromper outros.
O DC on-prem precisa de link de 10 Gbps para AWS com resiliência a falhas de link e sem exposição à internet.
Duas conexões Direct Connect em locais DX separados. Cada uma com uma VIF privada terminando em um Direct Connect Gateway → TGW. Failover BGP entre conexões.
Por quê: Um único DX é um ponto único de falha. Diferentes locais DX protegem contra interrupções em todo o site. O DX Gateway permite que uma VIF alcance várias regiões/VPCs.
O regulador exige criptografia de camada 2 entre on-prem e AWS sobre Direct Connect.
Direct Connect com MACsec em uma conexão dedicada de 10 Gbps ou 100 Gbps. Chave pré-compartilhada configurada em ambas as extremidades.
Por quê: IPsec funciona na camada 3; MACsec criptografa na camada 2 com taxa de linha, satisfazendo reguladores que exigem criptografia de link físico.
O tráfego leste-oeste entre VPCs deve passar por inspeção stateful.
VPC de inspeção centralizada com AWS Network Firewall. As tabelas de rotas do TGW direcionam o tráfego entre VPCs através da VPC do firewall antes de chegar ao destino.
Por quê: Network Firewall é o motor gerenciado de regras Suricata para inspeção stateful. A centralização evita a proliferação de firewalls por VPC.
Impor uma configuração de base WAF + Network Firewall em todas as contas da organização automaticamente.
AWS Firewall Manager com administrador delegado. Políticas para WAF, Shield Advanced, Network Firewall, security groups se aplicam em toda a organização.
Por quê: Firewall Manager anexa automaticamente políticas a novos recursos. Sem ele, cada conta se desvia da linha de base à medida que contas são adicionadas.
Centralizar descobertas do Security Hub de mais de 100 contas em um único painel.
Administrador delegado do Security Hub. A região de agregação coleta descobertas de todas as contas membro + todas as regiões habilitadas em um único console.
Por quê: Sem agregação, as descobertas permanecem por conta/região. O administrador delegado evita usar a conta de gerenciamento para operações de segurança.
Habilitar o GuardDuty em toda a organização com monitoramento central e visibilidade de faturamento por conta.
GuardDuty com administrador delegado. Habilitação automática em novas contas via integração da organização. Descobertas agregadas à conta do administrador.
Por quê: A habilitação automática fecha a lacuna em contas recém-criadas que, de outra forma, não seriam monitoradas.
Investigar uma descoberta do GuardDuty correlacionando CloudTrail + VPC Flow Logs entre contas.
Amazon Detective administrador delegado em uma conta de segurança dedicada. As contas membro contribuem para o gráfico de comportamento.
Por quê: Detective constrói automaticamente o gráfico de comportamento a partir de VPC Flow Logs, CloudTrail, GuardDuty. O administrador delegado (não o de gerenciamento) segue as melhores práticas da AWS.
Detectar quando qualquer recurso na organização é compartilhado com uma conta externa.
IAM Access Analyzer com a organização como zona de confiança, delegada à conta de segurança. Descobertas sobre acesso entre contas em S3, funções IAM, chaves KMS, Lambda, SQS, Secrets.
Por quê: Access Analyzer usa verificação formal, não correspondência de padrões. A zona de confiança em nível de organização trata contas irmãs como confiáveis.
Maximizar a utilização do Savings Plan em 50 contas com padrões de carga de trabalho incompatíveis.
Faturamento consolidado em Organizations com Savings Plans + compartilhamento de RI habilitado. Planos comprados na conta pagadora são compartilhados em toda a organização.
Por quê: O compartilhamento agrupa o uso para que a capacidade não utilizada em uma conta compense a demanda em outra. Desative o compartilhamento apenas para isolamento de alocação de custos.
Permitir que equipes de aplicativos se autoatendam com infraestrutura aprovada (VPCs, RDS) sem direitos de administrador IAM.
Portfólios do AWS Service Catalog. Produtos CloudFormation pré-aprovados com restrições. Compartilhar portfólios entre contas via Organizations.
Por quê: Fornece autoatendimento com guarda-corpos. As políticas de restrição ocultam a complexidade (tipos de instância, tags), enquanto os produtos carregam o escopo IAM para lançamento.
Impor tags `CostCenter` e `Environment` obrigatórias de forma consistente em toda a organização.
Políticas de tags do Organizations anexadas a OUs. Definir valores permitidos + capitalização. Combinar com a regra do Config `required-tags` para aplicação.
Por quê: As políticas de tags validam; as regras do Config detectam a não conformidade. SCPs podem negar a criação de recursos sem tags.
Mais de 100 VPCs, cada uma com NAT Gateway, está aumentando muito o custo. Deseja um único ponto de saída.
VPC de saída centralizada com NAT Gateway. VPCs spoke roteiam 0.0.0.0/0 → TGW → VPC de saída → NAT.
Por quê: Um NAT em vez de 100 corta o custo drasticamente. As regras de transferência de dados entre regiões do TGW se aplicam, então projete cuidadosamente para o tráfego inter-regional.
EC2 na VPC precisa resolver nomes de host on-prem; on-prem deve resolver DNS privado da VPC.
Endpoints de entrada + saída do Route 53 Resolver. As regras de encaminhamento enviam consultas `corp.local` para on-prem; o DNS on-prem encaminha `*.compute.internal` para o endpoint de entrada.
Por quê: Os endpoints do Resolver são ENIs HA em duas AZs. O encaminhamento condicional oferece resolução bidirecional sem expor o DNS à internet.
Cargas de trabalho Windows precisam de AD completo com confiança no forest on-prem.
AWS Managed Microsoft AD. Estabelecer confiança de forest bidirecional com AD on-prem via DX/VPN.
Por quê: Managed AD é um Microsoft AD real (DCs em duas AZs, esquema extensível). O AD Connector apenas atua como proxy; o Simple AD não suporta confiança.
Carga de trabalho sensível à latência deve ser executada em um datacenter específico, mas gerenciada via APIs da AWS.
AWS Outposts rack/server. As mesmas APIs da AWS (EC2, EBS, ECS, EKS, subconjunto RDS) são executadas on-prem. Conecta-se a uma região pai.
Por quê: Para latência local sub-milissegundo para sistemas on-prem ou residência de dados onde Local Zones não cobrem. Single-AZ - emparelhe dois Outposts para HA.
Reduzir a latência para usuários finais em uma metrópole que está longe da região principal.
AWS Local Zones. Implantar computação, armazenamento perto de centros populacionais; o plano de dados é roteado de volta para a região principal para o plano de controle.
Por quê: Local Zones hospedam EC2/EBS/RDS/ELB perto das principais cidades. Mais barato que Outposts quando a propriedade total do DC não é necessária.
O auditor de conformidade precisa da configuração atual de cada recurso em toda a organização.
Agregador do AWS Config na conta de auditoria, com escopo para toda a organização em todas as regiões.
Por quê: O agregador do Config é a visualização somente leitura em toda a organização. Os agregadores não habilitam o Config em contas membro - isso é separado.
Logs do CloudWatch de 50 contas precisam ir para um arquivo S3 para ingestão por SIEM.
Filtros de assinatura em cada conta → Kinesis Data Stream / Firehose entre contas → S3 na conta de log.
Por quê: Os filtros de assinatura permitem que os grupos de log enviem em tempo real. O Firehose lida com agrupamento, compactação, particionamento S3.
Gerar relatórios de evidências para SOC 2, PCI, HIPAA continuamente em toda a organização.
AWS Audit Manager. Frameworks pré-construídos mapeiam controles para evidências da AWS (Config, CloudTrail, Security Hub). Administrador delegado na conta de segurança.
Por quê: Audit Manager coleta automaticamente evidências por controle. Economiza centenas de horas de coleta manual de screenshots por ciclo de auditoria.
Implantar uma função IAM de base em todas as contas existentes + futuras na organização.
CloudFormation StackSets com permissões gerenciadas por serviço + implantação automática em novas contas. Direcionar para toda a organização ou OUs específicas.
Por quê: StackSets auto-gerenciados exigem IAM em cada conta. Os gerenciados por serviço aproveitam as permissões da organização e são o padrão para Organizations.
Após meses de execução de StackSets, suspeita-se que alterações manuais causaram drift.
Iniciar detecção de drift no StackSet. Revisar os resultados por instância de stack sem modificar recursos.
Por quê: A detecção de drift compara a configuração de recursos em tempo real com o modelo. Re-implantar StackSets para "corrigir" o drift pode causar alterações não intencionais.
Carga de trabalho de banco de dados variável e com picos - as necessidades de capacidade oscilam 10x em minutos.
Aurora Serverless v2. Definir min/max ACU; Aurora escala em segundos sem quedas de conexão.
Por quê: v2 escala adicionando capacidade à instância existente - sem failover. O Aurora provisionado não pode escalar tão rápido; o Serverless v1 escala mais lentamente e pausa as conexões.
Aplicativo global com RPO <1s e RTO <1min para failover de DB entre regiões.
Aurora Global Database. Replicação baseada em armazenamento, latência de replicação típica <1s. Promover secundário em segundos.
Por quê: O Global DB envia páginas, não transações - sub-segundo entre regiões. Réplicas de leitura entre regiões via replicação lógica não conseguem igualar isso.
Direcionar consultas de relatórios para instâncias de leitura específicas com mais memória.
Endpoints personalizados do Aurora. Definir endpoint apontando para um subconjunto de leitores (os maiores).
Por quê: O endpoint de leitura padrão distribui para todos os leitores de forma round-robin. Endpoints personalizados particionam o cluster por tipo de carga de trabalho.
Tabela DynamoDB experimenta picos de partição quente limitando algumas leituras/gravações.
Provisionado com auto-escalonamento + capacidade adaptativa (automático). Redesenhar a chave de partição se uma única chave for o hotspot.
Por quê: A capacidade adaptativa realoca o throughput entre partições sem ação. Mas se uma chave está quente, apenas o redesenho do esquema (chave composta, write sharding) ajuda.
Efeito colateral em cada gravação do DynamoDB - enviar para o OpenSearch para indexação de pesquisa.
DynamoDB Streams + Lambda trigger. Lambda agrupa registros do stream e grava no OpenSearch.
Por quê: Streams capturam alterações no nível do item por 24h. Modelo de trigger nativo - adaptador Kinesis Data Streams existe para retenção/análise mais longas.
Gravação em duas fases em múltiplos itens DynamoDB deve ser atômica.
TransactWriteItems / TransactGetItems. Semântica ACID em até 100 itens.
Por quê: Transações nativas evitam a complexidade da saga distribuída. O custo é 2x a capacidade normal por item - use apenas quando a atomicidade for necessária.
Migrar um cluster MongoDB auto-hospedado para um serviço gerenciado preservando a API.
Amazon DocumentDB. API compatível com MongoDB. Usar mongodump/mongorestore ou DMS para migração.
Por quê: DocumentDB é API-compatível com MongoDB 4.0/5.0 (maioria dos operadores, nem todos). Verificar compatibilidade de driver/recurso antes de se comprometer.
Mecanismo de recomendação precisa percorrer um grafo social de 100M de nós.
Amazon Neptune. Grafo de propriedades (Gremlin) ou RDF (SPARQL).
Por quê: DB de grafo construído para esse fim. Modelar relacionamentos no DynamoDB ou RDS é possível, mas o desempenho da consulta degrada com a profundidade do salto.
Por quê: Séries temporais construídas para esse fim - escalonamento DynamoDB/RDS é proibitivo a essa taxa. O escalonamento de retenção integrado reduz o custo de armazenamento.
Por quê: Sem dimensionamento de cluster ou gerenciamento de shard. Para cargas de trabalho previsíveis e sustentadas, domínios provisionados são mais baratos.
Análise em escala de petabytes com computação elástica e compartilhamento de dados entre equipes.
Nós Redshift RA3 com armazenamento gerenciado. Compartilhamento de dados entre clusters (sem cópia).
Por quê: RA3 separa computação de armazenamento - escala cada um independentemente. O compartilhamento de dados elimina o ETL entre os clusters das equipes.
Cluster Redshift existente + data lake S3 - consultar S3 do Redshift ou usar Athena?
Redshift Spectrum quando são necessárias junções entre tabelas do cluster e dados do S3. Athena quando totalmente serverless ad-hoc apenas em S3.
Por quê: Spectrum executa consultas S3 através da computação do Redshift. Athena paga por TB escaneado. Escolha com base em onde os dados dominantes residem.
Diferentes equipes precisam de diferentes visibilidades de linha/coluna nas mesmas tabelas do Glue Catalog.
AWS Lake Formation com filtros de nível de linha + nível de coluna + nível de célula. Conceder via tags LF.
Por quê: As políticas IAM/S3 não podem fazer em nível de linha. O Lake Formation impõe acesso granular via metadados do Glue Catalog + consumidores Athena/Redshift Spectrum/EMR.
Escolha Kafka gerenciado vs Kinesis Data Streams para streaming de eventos.
MSK quando clientes/ecossistema Kafka existentes. Kinesis para integração estreita com AWS (triggers Lambda, Firehose, KCL) e opção serverless.
Por quê: Ambos fazem streaming duravelmente com replay. MSK preserva a API e o ecossistema Kafka; Kinesis custa menos para streams pequenos e integra-se nativamente.
Replay de eventos da semana passada através de um novo consumidor sem re-emitir da origem.
EventBridge archive + replay. O arquivo captura eventos correspondentes; os reproduz para um destino mais tarde.
Por quê: O replay integrado evita a necessidade de um armazenamento de eventos separado. Útil para recuperação de incidentes e integração de novos consumidores.
Orquestração faturada em sub-segundos de fluxos de trabalho curtos de alto volume (>100k/seg).
Fluxos de trabalho Step Functions Express. Faturamento por ms de execução; máximo de 5 minutos.
Por quê: Fluxos de trabalho Standard são duráveis + com histórico rastreado, faturados por transição de estado. Express troca o registro de auditoria pelo custo em fluxos de vida curta.
Executar cargas de trabalho multi-tenant não confiáveis no EKS com forte isolamento.
Isolamento por pod EKS Fargate. Cada pod é executado em uma micro-VM dedicada.
Por quê: Os grupos de nós gerenciados compartilham o kernel - a escalada de privilégios cruza os tenants. O isolamento de kernel do Fargate é o mais forte no EKS.
O aplicativo de produção precisa de um endpoint LLM com baixa sobrecarga operacional.
Amazon Bedrock para modelos de fundação gerenciados (Claude, Llama, Titan). SageMaker apenas quando você precisa hospedar modelos personalizados ou pesos abertos finamente ajustados.
Por quê: Bedrock é apenas API - sem infraestrutura. SageMaker é uma plataforma ML completa - escolha quando você possui o ciclo de vida de treinamento/ajuste fino.
Escolher IA gerenciada para visão / NLP sem treinar um modelo.
Rekognition (rótulos de imagem/vídeo, rostos, moderação de conteúdo). Comprehend (sentimento, entidades, idiomas, detecção de PII). Translate. Polly. Transcribe.
Por quê: Os serviços de IA pré-treinados da AWS pulam todo o ciclo de vida de ML para tarefas comuns. Use SageMaker apenas quando o "pronto para usar" não se encaixa.
Aplicativo web suporta email/senha + Google + Apple + SAML enterprise SSO.
Cognito User Pool com UI hospedada. Configurar OIDC + IdPs SAML. O aplicativo recebe o JWT do Cognito.
Por quê: User Pool agrega IdPs em um único token. Identity Pool apenas troca tokens por credenciais da AWS - para acesso à API da AWS, não para autenticação.
DynamoDB Global Tables com gravações simultâneas na mesma chave em duas regiões.
Last-writer-wins por timestamp. O aplicativo projeta gravações idempotentes ou particiona gravações por região.
Por quê: A replicação GT é multi-master assíncrona. A resolução de conflitos é baseada em timestamp - os aplicativos devem tolerar consistência eventual.
Detectar picos de custo inesperados em horas, não no final do mês.
AWS Cost Anomaly Detection. ML monitora o gasto por serviço / por conta; alerta via SNS / email quando o limite é excedido.
Por quê: Os orçamentos disparam em limites planejados. A detecção de anomalias detecta surpresas (chave comprometida, job de treinamento descontrolado) dias/semanas antes.
Visibilidade em toda a organização sobre oportunidades de otimização de custos do S3.
S3 Storage Lens com métricas avançadas + escopo em toda a organização. Apresenta candidatos a camada fria, oportunidades de camada IT, uploads multipartes abandonados.
Por quê: O nível gratuito cobre métricas básicas; o nível avançado mostra replicação, atividade, recomendações de otimização. Centralizado na conta de auditoria/segurança.
Cortar o custo de saída do NAT Gateway para o tráfego S3 + DynamoDB.
Endpoints de gateway VPC para S3 + DynamoDB (grátis). Roteia o tráfego via endpoint, ignorando o NAT.
Por quê: O NAT cobra por GB; os endpoints de gateway são gratuitos. Para outros serviços da AWS, os endpoints de interface reduzem, mas não eliminam o custo.
Carga de trabalho "tagarela" entre AZs; custo de transferência de dados domina a fatura.
Co-localizar microsserviços na mesma AZ sempre que possível. Usar VPC Lattice ou service mesh com roteamento de afinidade AZ.
Por quê: Cross-AZ custa $0.01/GB em cada direção. A "tagarelice" dos microsserviços em escala soma. Troque um pouco de HA por custo onde 99.95% é suficiente.
Escolha entre Compute Savings Plan vs EC2 Instance Savings Plan vs Reserved Instances.
Compute SP: mais flexível (qualquer região, família, SO) - desconto ligeiramente menor. EC2 Instance SP: bloqueado por família de região - desconto mais profundo. RI: casos raros que precisam de reserva de capacidade.
Por quê: O Compute SP cobre Lambda + Fargate + EC2. As RIs só superam os SPs quando a reserva de capacidade importa; na maioria dos casos, os SPs vencem.
Frota de batch stateless executada em Spot - taxa de interrupção muito alta.
Spot Fleet com estratégia otimizada para capacidade em muitos tipos de instância + AZs.
Por quê: A estratégia de menor preço se concentra em um único pool - alta interrupção. A otimizada para capacidade escolhe pools com a capacidade disponível mais profunda.
Reduzir o custo de computação na camada web stateless em ~20% sem reescrever.
Migrar para Graviton (ARM) - `c7g`, `m7g`, Lambda ARM, Aurora Graviton. Testar compatibilidade para binários compilados.
Por quê: Graviton oferece ~20% melhor preço-desempenho para a maioria das cargas de trabalho. Java/Python/Node "simplesmente funcionam"; código nativo pode precisar de recompilação.
O custo de armazenamento do CloudWatch Logs está crescendo mês a mês.
Definir retenção por grupo de log (o padrão é para sempre). Para longo prazo, exportar para S3 + excluir no CW. Usar a classe Logs Infrequent Access.
Por quê: O CloudWatch Logs custa $0.03/GB de ingestão + armazenamento para sempre. O S3 Standard-IA a $0.0125/GB é mais barato para acesso de arquivamento.
Substituir monitoramento fragmentado por observabilidade unificada em todos os serviços.
CloudWatch ServiceLens para mapa de serviço; X-Ray para rastreamentos; CloudWatch Logs Insights para ad-hoc; Container Insights para ECS/EKS; RUM para navegador; Synthetics para canaries.
Por quê: A pilha nativa da AWS evita agentes por host. Emparelhe com o SDK OpenTelemetry para portabilidade.
Corrigir 5.000 instâncias EC2 em um cronograma sem scripts por instância.
SSM Patch Manager com linhas de base de patches + janelas de manutenção. Direcionamento baseado em tags; aprovar automaticamente patches de segurança após N dias.
Por quê: Patch Manager centraliza todo o ciclo de vida do patch. Scripts auto-gerenciados divergem e perdem novas instâncias.
Escaneamento contínuo de CVE em EC2 + imagens ECR + Lambda.
Amazon Inspector v2 com habilitação em toda a organização. Descobertas fluem para o Security Hub.
Por quê: O Inspector v2 cobre EC2 + imagens de contêiner + dependências Lambda em um único serviço. A correspondência manual de CVE é impossível em escala.
Failover multirregional - verificação de prontidão automatizada + evacuação zonal.
Route 53 Application Recovery Controller. Verificações de prontidão + controles de roteamento para failover baseado em célula.
Por quê: Verificações de saúde do Route 53 simples avaliam endpoints. ARC adiciona planos de controle ativo/standby para failover explícito e auditado.
Auditar quais caminhos da internet podem alcançar recursos internos.
VPC Network Access Analyzer. Expressões de escopo descrevem caminhos proibidos (por exemplo, internet → camada DB). Retorna os caminhos correspondentes.
Por quê: O Reachability Analyzer é ponto a ponto; o Network Access Analyzer é uma conformidade em todo o escopo.
Verificações de otimização de custo do Trusted Advisor (necessita de Suporte Business/Enterprise). ELBs ociosos, EC2 de baixa utilização, EIPs não utilizados, utilização de RI.
Por quê: A camada gratuita do TA é limitada; Business+ desbloqueia todas as verificações. A visualização da organização com administrador delegado mostra descobertas agregadas.
Containerizar monolitos legados Java/.NET sem reescrever.
CLI do AWS App2Container. Inspeciona o aplicativo em execução, gera artefatos de contêiner + manifestos ECS/EKS.
Por quê: A2C captura a configuração de tempo de execução (env, portas, dependências) em uma imagem funcional. A containerização manual perde dependências não óbvias.
Modernização de mainframe COBOL - converter para microsserviços Java.
Serviço AWS Mainframe Modernization com Blu Age (refactor) ou Micro Focus (replatform). Escolha com base na tolerância para emulação de tempo de execução.
Por quê: O refactor desbloqueia padrões nativos da nuvem; o replatform é mais rápido, mas emula o mainframe. Ambos reduzem o custo da licença do mainframe.
Decompor um monolito ao longo de 18 meses sem congelar o desenvolvimento.
Padrão Strangler Fig. Colocar o API Gateway/ALB na frente do monolito; rotear endpoints específicos para novos microsserviços à medida que são separados.
Por quê: Grandes reescritas geralmente falham. Strangler desacopla a transição por rota, mantém o monolito funcional durante a transição.
Deseja extrair microsserviços incrementalmente sem possuir o plano de roteamento.
AWS Migration Hub Refactor Spaces. Abstração gerenciada de aplicativo/rota/serviço sobre API Gateway + VPCs.
Por quê: Economiza a escrita do "encanamento" do Strangler Fig. Roteamento pré-construído + conectividade VPC para extração incremental.
O cutover baseado em DNS arrisca a persistência de caches DNS.
Cutover atrás do CloudFront / ALB / Global Accelerator. Trocar o backend sem alterar o DNS público.
Por quê: Os caches respeitam o TTL, mas clientes/firewalls armazenam em cache agressivamente. O endereço público estável isola de caches DNS persistentes.
Executar Kubernetes on-prem com as mesmas ferramentas do EKS durante a migração.
EKS Anywhere em hardware on-prem. Mesmas versões do Kubernetes + ECR + integração AWS Outposts.
Por quê: O plano de controle consistente reduz a divergência de habilidades do operador. A migração para EKS posteriormente é uma movimentação de carga de trabalho, não uma reescrita de ferramentas.