🏠Início 📚Certificações 📱Aplicativos Móveis

🎓Informações do exame

✍️Blog 📊Progresso 📅Calendário 💬Suporte

Política de Privacidade Termos de Uso Fale Conosco Política de Cookies Aviso Legal Acessibilidade DMCA / Direitos Autorais

Pular para o conteúdo

SAP-C02Guia

Guia

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.

Seções

Projetar Soluções para Complexidade Organizacional38 entradas
Projetar Novas Soluções41 entradas
Melhoria Contínua para Soluções Existentes35 entradas
Acelerar a Migração e Modernização de Cargas de Trabalho26 entradas

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.

Construir uma rede privada global em regiões + sites de filiais com roteamento baseado em política — além do TGW peering.

AWS Cloud WAN. A política da rede principal em JSON define declarativamente segmentos, regiões, anexos, compartilhamento.

Por quê: Cloud WAN substitui o design TGW hub-of-hubs por um backbone global gerenciado único. Os segmentos fornecem isolamento lógico entre regiões.

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.

Link Direct Connect como primário; precisa de failover automático de VPN.

VPN Site-to-Site anexada ao mesmo TGW que o DX gateway. A AWS prefere rotas BGP do DX; a VPN assume quando o BGP do DX se retira.

Por quê: A preferência de rota BGP torna o failover automático. A VPN pré-provisionada evita atraso de provisionamento durante a interrupção.

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.

Descoberta contínua de PII em todos os buckets S3 em 200 contas.

Macie com administrador delegado. Habilitação automática em toda a organização. Descobertas fluem para o Security Hub para revisão unificada.

Por quê: Macie não pode ler entre contas sem configuração explícita. A configuração em nível de organização garante que cada bucket esteja no escopo.

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.

Prevenir ações do usuário root em contas membro (requisito de conformidade).

SCP negando qualquer ação quando `aws:PrincipalArn` corresponde a `arn:aws:iam::*:root`.

Por quê: SCPs se aplicam mesmo ao root. IAM não pode negar o root. Ações do root nunca deveriam ser necessárias, exceto para recuperação de conta.

Impor planos do AWS Backup em todas as contas com retenção consistente.

Políticas de backup do Organizations anexadas a OUs. Definir planos + critérios de seleção; aplicar automaticamente a recursos no escopo.

Por quê: A duplicação de planos de backup por conta leva à divergência. As políticas da organização impõem uma única fonte da verdade.

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.

Serviços internos precisam de DNS resolúvel de várias VPCs em diferentes contas.

Zona hospedada privada do Route 53 associada a VPCs de várias contas via associação de VPC entre contas.

Por quê: Uma PHZ compartilhada via associação entre contas é melhor do que duplicatas por VPC que divergem.

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.

Aplicativos na AWS precisam autenticar contra um AD on-prem existente sem replicar identidades.

AD Connector. Atua como um proxy da VPC para o AD on-prem via DX/VPN.

Por quê: Nenhum dado de diretório sai do on-prem; as solicitações de autenticação passam. A latência depende do link.

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 aplicativo exige latência de um dígito de milissegundo para usuários móveis em 5G.

AWS Wavelength Zones em redes 5G de operadoras. Implantar EC2/EBS na borda da operadora; o tráfego permanece na rede da provedora de celular.

Por quê: Elimina completamente o salto da internet pública para casos de uso 5G como AR/VR, inferência em tempo real, jogos.

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.

Projetar Novas Soluções

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.

Reproduzir um banco de dados de produção para teste sem pagar por uma cópia completa.

Clonagem do Aurora. Copy-on-write — o clone inicial é gratuito; apenas as páginas alteradas são cobradas.

Por quê: Clones são pontuais, instantâneos, isolados. Snapshot+restaurar leva horas e fatura o armazenamento completo imediatamente.

Recuperar-se de um erro lógico (DROP TABLE em produção) em minutos, não horas.

Aurora MySQL Backtrack. Retorna o cluster no lugar para um ponto anterior no tempo sem restaurar do backup.

Por quê: Backtrack é in-place e rápido. Restaurações PITR criam um novo cluster — mais lento e requer corte de aplicativo.

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.

A frota de IoT emite 10M de pontos de dados de séries temporais/seg com retenção de frequência mista.

Amazon Timestream. Armazenamento em memória (recente), armazenamento magnético (histórico) — escalonamento automático.

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.

Livro-razão bancário precisa de verificação criptográfica de cada alteração de registro.

Amazon QLDB. Diário imutável e criptograficamente verificável. Usar exportação de digest SHA-256 para provas.

Por quê: QLDB é um ledger construído para esse fim. DynamoDB Streams fornecem histórico de alterações, mas sem encadeamento criptográfico integrado.

Carga de trabalho de análise de log com picos imprevisíveis e operações sem intervenção.

Amazon OpenSearch Serverless. Computação/armazenamento desacoplados; auto-escalona OCUs.

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.

O job diário do Glue processa dados incrementais; não deve reprocessar arquivos de ontem.

Glue job bookmarks. Rastrear chaves S3 / linhas DB processadas; retomar do último checkpoint bem-sucedido.

Por quê: Bookmarks evitam o processamento duplicado sem rastreamento manual de estado. Desabilitar para execuções de reprocessamento completo.

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.

Throughput Kafka variável; deseja gerenciamento de cluster sem intervenção.

MSK Serverless. Auto-escalona partições e throughput; paga por partição + dados.

Por quê: Sem dimensionamento de broker. Para throughput alto e sustentado, o MSK provisionado é mais barato.

Conectar SQS → filtro → Step Functions sem escrever Lambda de "cola".

EventBridge Pipes. Origem → filtro opcional → enriquecimento opcional → destino.

Por quê: Substitui um Lambda típico como "cola". Reduz código, custo e superfície operacional.

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.

Centenas de produtores emitem eventos; consumidores precisam de bindings tipados.

EventBridge Schema Registry com auto-descoberta. Gerar bindings de código fortemente tipados (Java, Python, TypeScript).

Por quê: A descoberta aprende esquemas a partir de eventos observados. Bindings oferecem segurança em tempo de compilação.

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.

Processar 10M de objetos S3 em paralelo através de uma Step Function.

Distributed Map state. Execuções filhas concorrentes de até 10.000 em paralelo; lê a origem diretamente do S3.

Por quê: O Inline Map tem um limite de 40 paralelos. O Distributed Map escala para jobs do tamanho de buckets S3 sem atingir cotas de serviço.

Fila FIFO requer >300 mensagens/seg.

SQS FIFO com modo de alto throughput habilitado. Até 70k msgs/seg por API por região; particionar por `MessageGroupId`.

Por quê: FIFO padrão tem um limite de 300 msg/seg sem agrupamento. O modo de alto throughput particiona a ordenação por ID de grupo.

Múltiplos consumidores precisam de throughput de leitura total no mesmo stream Kinesis.

Enhanced Fan-Out (EFO). Cada consumidor obtém um pipe dedicado de 2 MB/s/shard via push HTTP/2.

Por quê: O polling padrão compartilha o limite de 2 MB/s/shard entre os consumidores. O EFO elimina a contenção a um custo mais alto.

Firehose para S3; consultas de data lake escaneiam muito porque o particionamento é por tempo de ingestão, não por tempo de evento.

Particionamento dinâmico do Firehose. Extrair tempo do evento / ID do tenant do JSON; gravar para o prefixo S3 `year=YYYY/month=MM/tenant=X/`.

Por quê: A poda de partição Athena/Spectrum no tempo do evento reduz drasticamente o custo e a latência da varredura.

Cliente móvel/web precisa de atualizações em tempo real e busca seletiva de campos.

AWS AppSync (GraphQL) com assinaturas. Baseado em WebSocket.

Por quê: Clientes GraphQL buscam apenas os campos solicitados e assinam deltas. REST/HTTP API Gateway força a busca excessiva e o polling.

A API interna não deve ser acessível pela internet pública.

Endpoint privado do API Gateway via interface VPC endpoint. A política de recursos restringe a VPCs específicas.

Por quê: APIs privadas são acessíveis apenas da VPC + redes conectadas. APIs públicas exigem WAF + autenticação para serem seguras.

Proteger a origem S3 para que apenas o CloudFront possa lê-la.

Origin Access Control (OAC). Substitui o legado OAI; suporta SSE-KMS e todos os recursos S3.

Por quê: OAI não suporta objetos SSE-KMS. A AWS recomenda OAC para todas as novas distribuições.

Limitar o tempo de acesso a vídeos pagos específicos no S3.

URLs assinadas do CloudFront (por URL) ou cookies assinados (múltiplos URLs). Grupo de chaves confiável assina as solicitações.

Por quê: URLs S3 pré-assinadas ignoram o cache do CloudFront. URLs assinadas do CloudFront armazenam em cache na borda E restringem o acesso.

Transformação leve de solicitação do visualizador: reescrita de cabeçalho, redirecionamento, roteamento A/B.

CloudFront Functions. JS, sub-milissegundo, todos os POPs de borda.

Por quê: Lambda@Edge é Node/Python completo na borda regional — mais pesado e caro. Functions são 10x mais baratas para manipulações simples.

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.

A latência do autoescalonamento do cluster EKS é muito lenta; a proliferação de tipos de instância dos grupos de nós.

Karpenter. O provisionador escolhe os tipos de instância just-in-time com base nos requisitos dos pods pendentes.

Por quê: O Cluster Autoscaler escala ASGs pré-definidos, lento e limitado. Karpenter escala EC2 arbitrários em segundos com diversificação.

O pod EKS precisa da função IAM de privilégio mínimo (evitar compartilhamento de função de instância de nó).

IAM Roles for Service Accounts (IRSA) via provedor OIDC. Anotar ServiceAccount com ARN da função.

Por quê: EKS Pod Identity é a alternativa mais recente — modelo de confiança mais simples. IRSA é maduro e funciona em todas as regiões.

As tarefas ECS-on-EC2 demoram de 5 a 7 minutos para iniciar durante o scale-out — precisam de <60s.

ECS Capacity Provider com alvo de escalonamento gerenciado ~80% em `CapacityProviderReservation`. Manter buffer ocioso.

Por quê: O buffer reservado significa que as novas tarefas aterrissam na capacidade existente instantaneamente enquanto o ASG lança substituições.

Lambda acionado por SQS, mas apenas 5% das mensagens correspondem — invocações desperdiçadas.

Mapeamento de fonte de evento com critérios de filtro. Lambda invocado apenas para mensagens correspondentes.

Por quê: O filtro pré-Lambda evita custos por invocação em mensagens irrelevantes. Filtragem suportada em SQS, Kinesis, DynamoDB, MQ, Kafka.

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.

Melhoria Contínua para Soluções Existentes

Frota EC2 superprovisionada em toda a organização; precisa de recomendações automatizadas de dimensionamento correto.

AWS Compute Optimizer habilitado em nível de organização. Revisar recomendações contra janelas de utilização; exportar para S3 para rastreamento.

Por quê: Compute Optimizer usa ML em métricas do CloudWatch. O dimensionamento manual perde sinais de forma da carga de trabalho.

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.

Quando a conta atinge 100% do orçamento mensal, interromper automaticamente recursos não essenciais.

Ações do AWS Budget. Aplicar política IAM restritiva + acionar Lambda via SNS para parar EC2/RDS não essenciais.

Por quê: As ações de orçamento mudam de "apenas alerta" para "impor". Combine com Cost Anomaly Detection para pegar gastos não orçados.

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.

A fatura do S3 continua crescendo apesar das operações de exclusão.

Regra de ciclo de vida aborta `uploads multipartes incompletos` após 7 dias. Inspecionar com `s3api list-multipart-uploads`.

Por quê: Uploads falhos deixam partes que são faturadas como armazenamento, mas são invisíveis na listagem do console. Vazamento de custo comum.

Dados de arquivo frios acessados no máximo uma vez por trimestre.

S3 Glacier Flexible Retrieval (restauração de 1 a 12 horas). Para "nunca acessados" use Deep Archive (recuperação de 12 horas, menor custo).

Por quê: Standard-IA mantém acesso em milissegundos; as camadas Glacier trocam o tempo de acesso por uma redução de custo de ~80 a 95%.

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.

O tráfego de saída para a internet é o item de linha mais caro.

Colocar tudo na frente do CloudFront. A saída do CloudFront para a internet é mais barata do que a saída direta do EC2/ALB.

Por quê: O preço de saída do CloudFront é escalonado e significativamente menor do que a saída regional. O cache reduz ainda mais a saída da origem.

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.

Reduzir o custo de um serviço Fargate de longa duração, mas tolerante a interrupções.

Fargate Spot via estratégia de provedor de capacidade. Misturar Spot + on-demand para tarefas HA.

Por quê: Fargate Spot ~70% mais barato. As tarefas recebem um aviso de 2 minutos antes da terminação — emparelhar com drenagem graciosa.

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.

Rastrear uma solicitação em serviços em 5 contas.

Observabilidade entre contas do X-Ray. As contas de origem compartilham rastreamentos com a conta de monitoramento central via OAM.

Por quê: Sem OAM, os rastreamentos fragmentam por conta. A agregação entre contas centraliza a visão do caminho da solicitação.

Visualizar métricas + logs + rastreamentos de várias contas em um único console do CloudWatch.

CloudWatch Observability Access Manager (OAM). As contas de origem se conectam a uma conta de monitoramento via sink + link.

Por quê: OAM é a estrutura canônica de observabilidade multi-conta. Elimina o salto de console por conta.

Lentidão do cluster Aurora — identificar o SQL principal por evento de espera.

Performance Insights habilitado no cluster. Top SQL por análise de carga + espera sem despejo de log de consulta.

Por quê: PI amostra eventos de espera com baixa sobrecarga. Métricas do CloudWatch informam que algo está lento, PI informa o quê.

Detectar automaticamente anomalias em DynamoDB / RDS / Lambda / ECS sem escrever limites de alarme.

Amazon DevOps Guru. Detecção de anomalias baseada em ML em métricas operacionais + eventos correlacionados.

Por quê: Limites estáticos perdem modos raros. DevOps Guru aprende linhas de base e alerta sobre desvios do normal.

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.

Remediar automaticamente falhas de regras do Config (por exemplo, SG aberto) sem aprovação humana.

Ação de remediação do Config invocando documento SSM Automation. `AWS-DisablePublicAccessForSecurityGroup` e outros pré-construídos.

Por quê: O Config detecta; o SSM Automation age. Ciclo mais apertado do que SNS → humano → ticket.

O pipeline dourado de AMI/imagem de contêiner deve ser reproduzível e atualizado com patches.

Pipeline do EC2 Image Builder. AMI de origem → receita (componentes) → teste → distribuir para regiões/contas.

Por quê: Substitui scripts Packer ad-hoc por um ciclo de vida gerenciado. Agende reconstruções para atualização mensal de patches.

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.

Validar que um aplicativo multicamadas pode atender a RTO de 1 hora / RPO de 15 minutos.

AWS Resilience Hub. Definir política → avaliar aplicativo → recomendações + runbooks automatizados.

Por quê: O Resilience Hub formaliza as reivindicações de RTO/RPO com testes concretos. Os runbooks de DR manuais divergem.

Testar se o autoescalonamento e o failover funcionam sob falhas reais, não as presumidas.

AWS Fault Injection Service (FIS). Experimentos modelados — derrubar instâncias, limitar APIs, injetar latência. Executar durante Game Days.

Por quê: Engenharia do caos como serviço. Falhas reais expõem suposições frágeis; ler runbooks não.

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.

Atualizar a versão principal do RDS com capacidade de rollback.

RDS Blue/Green Deployments. Criar clone verde com nova versão; reproduzir binlog; alternar em <1 min.

Por quê: A atualização principal in-place é irreversível. Blue/Green mantém o DB antigo ativo até que a transição seja bem-sucedida.

Reduzir o raio de explosão de implantações ruins com rollback automático.

CodeDeploy com configuração Canary (por exemplo, `CodeDeployDefault.ECSCanary10Percent5Minutes`). Alarme do CloudWatch aciona o rollback.

Por quê: Canary contém a quebra para 10% por 5 minutos. Tudo de uma vez maximiza a explosão; o rolling distribui, mas sem porta baseada em tráfego.

Funções Lambda superprovisionadas em memória.

Compute Optimizer para Lambda. Recomendações de ajuste de memória a partir de perfis de invocação.

Por quê: A máquina de estado AWS Lambda Power Tuning é a alternativa — o Compute Optimizer é sem intervenção.

Gerar política IAM de privilégio mínimo a partir da atividade observada no CloudTrail.

Geração de política do IAM Access Analyzer. Analisa o CloudTrail para a função; emite uma política apenas com as ações usadas.

Por quê: Supera a moagem manual de `iam:Get*` etc. Use a política gerada como ponto de partida, depois revise.

Conexão falhando de EC2 para RDS — descobrir o porquê sem capturas de pacote.

VPC Reachability Analyzer. Análise estática de tabelas de rotas, SGs, NACLs, NAT, peering. Retorna o bloqueador.

Por quê: Mais rápido que tcpdump. Identifica a configuração específica (qual regra SG, qual negação NACL).

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.

Ganhos rápidos em custo em toda a organização.

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.

Lambda → Tempestades de conexão RDS esgotam as conexões do DB.

RDS Proxy. Pool de conexões entre Lambda e RDS/Aurora. Failover mais rápido (~66% de redução).

Por quê: A concorrência do Lambda cria uma conexão por invocação no pior caso. O Proxy multiplexa para um pequeno pool.

A taxa de cache miss de conteúdo de cauda longa na origem é muito alta — origem sob carga.

CloudFront Origin Shield em uma região próxima à origem. Deduplica solicitações entre as bordas antes de atingir a origem.

Por quê: Sem o Origin Shield, cada POP perde independentemente para a origem. O Shield reduz a taxa de acertos na origem em ~70%.

Acelerar a Migração e Modernização de Cargas de Trabalho

Migrar 200 servidores on-prem para EC2 com tempo de inatividade mínimo.

AWS Application Migration Service (MGN). Replicação contínua em nível de bloco; transição por servidor em minutos.

Por quê: MGN é a ferramenta de rehost recomendada pela AWS (substituiu SMS + CloudEndure). A transição por servidor permite migração baseada em ondas.

Migrar Oracle on-prem para Aurora PostgreSQL com tempo de inatividade mínimo.

Schema Conversion Tool (SCT) para reescrita de esquema + procedimento. AWS DMS para carga completa + CDC.

Por quê: SCT aborda o código; DMS aborda os dados. CDC mantém a origem sincronizada até a transição.

Descobrir todos os bancos de dados on-prem e avaliar a complexidade da migração.

AWS DMS Fleet Advisor. Inventariar + avaliar frotas heterogêneas em escala.

Por quê: O Fleet Advisor consolida a descoberta + dimensionamento em um único fluxo de trabalho antes de lançar jobs DMS.

Categorizar 500 aplicativos para estratégia de migração.

Framework dos Sete Rs: Retire (descomissionar), Retain (manter on-prem), Relocate (VMware Cloud lift), Rehost (MGN), Replatform (RDS em vez de DB auto-gerenciado), Repurchase (descartar & SaaS), Refactor (microsserviços).

Por quê: Portfólios maiores misturam todos os 7. Mapear por aplicativo cedo evita dívidas de migração "tamanho único".

Construir o inventário de migração com dependências antes de iniciar as ondas.

AWS Application Discovery Service. Sem agente (varredura vCenter) ou baseado em agente (por servidor). Gera mapa de dependências.

Por quê: Sem mapeamento de dependências, o planejamento de ondas perde acoplamentos estreitos. Discovery os revela automaticamente.

Rastrear centenas de migrações de servidor + DB em andamento em MGN, DMS, manual.

AWS Migration Hub como painel único. Agrega status de MGN, DMS, Refactor Spaces.

Por quê: Os consoles por ferramenta fragmentam o status. O Migration Hub consolida e suporta relatórios de portfólio.

Mover 100 TB de um site remoto sem largura de banda WAN utilizável.

AWS Snowball Edge Storage Optimized. Enviar o dispositivo, copiar localmente, retornar para a AWS. Múltiplos dispositivos em paralelo para >80 TB.

Por quê: Snowmobile (45 PB) é para exabyte; Snowcone (8 TB) para pequeno. Edge é o cavalo de batalha em escala de petabytes.

Replicação contínua de dados on-prem NFS → S3 com limites de largura de banda.

Agente AWS DataSync. Tarefas agendadas; limitação de largura de banda por tarefa; modo de verificação para integridade.

Por quê: DataSync é construído para esse fim e 10x mais rápido que rsync auto-gerenciado via WAN. Snowball é offline; DataSync é online.

O aplicativo on-prem espera NFS/SMB, mas os dados devem ir para o S3.

File Gateway no Storage Gateway. Cache local + backend S3; objetos acessíveis via API S3 também.

Por quê: O Volume Gateway expõe iSCSI; o Tape Gateway emula VTL. O File Gateway é a ponte NAS-para-S3.

Loja pesada em VMware quer capacidade do lado da AWS sem reequipar vSphere/NSX.

VMware Cloud on AWS. Mesma pilha vSphere em hosts AWS bare-metal. Usar HCX para migração ao vivo.

Por quê: Preserva as ferramentas operacionais. Ponte antes do refactor. Depois, replataforma gradualmente para serviços nativos da AWS.

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.

PostgreSQL auto-gerenciado no EC2 → RDS para operações gerenciadas.

DMS para cutover com CDC. Use RDS Custom apenas se precisar de acesso ao SO ou extensões específicas do fornecedor.

Por quê: RDS lida com backups/patches/HA. RDS Custom é uma saída para necessidades legadas, mas reintroduz a carga operacional.

Mover de RDS MySQL para Aurora MySQL para desempenho + custo.

Réplica de leitura Aurora do RDS, depois promover. Ou DMS para tempo de inatividade zero quando as divergências de versão importam.

Por quê: O caminho da réplica de leitura é o mais simples no motor. DMS lida com diferenças de versão e movimentos heterogêneos.

Empresa quer financiamento de migração AWS + framework de melhores práticas.

AWS Migration Acceleration Program (MAP). Fases: Assess (MRA), Mobilize (parceiro MAP + ferramentas), Migrate & Modernize.

Por quê: MAP desbloqueia financiamento e metodologia estruturada. Pular o MAP perde ambos.

Estimativa de custo pré-migração para o patrocinador executivo.

AWS Pricing Calculator (configuração projetada) + Migration Evaluator (orientado a dados do inventário on-prem).

Por quê: O Pricing Calculator fornece preços "e se". O Migration Evaluator ingere dados vSphere/Hyper-V para projetar economias reais.

Descomissionar servidores SFTP auto-hospedados; parceiros fornecedores precisam continuar usando SFTP.

AWS Transfer Family (SFTP/FTPS/FTP) com backend S3 ou EFS.

Por quê: Serviço de protocolo gerenciado. Usuários mapeados para IAM; endpoints apenas VPC. Evita executar daemons SSH em EC2.

Lift-and-shift de compartilhamentos de arquivos Windows com integração AD.

Amazon FSx for Windows File Server. Adicionado ao AD; SMB; DataSync para sincronização online do on-prem; Snowball para volume.

Por quê: FSx for Windows é a zona de aterragem nativa do AD. EFS é apenas Linux; S3 carece de semântica SMB.

Migrar cargas de trabalho NetApp ONTAP mantendo todos os recursos NetApp (snapshots, FlexClone).

Amazon FSx for NetApp ONTAP. APIs ONTAP nativas; multi-protocolo NFS+SMB; replicação SnapMirror do on-prem.

Por quê: Outros sabores de FSx não expõem recursos específicos do ONTAP. Lift-and-shift NetApp sem re-arquitetar backups/replicação.

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.

Migração gradual de tráfego de on-prem para AWS para controle de risco.

Roteamento ponderado do Route 53. Começar 1% → AWS, aumentar gradualmente. Verificações de saúde para failback automático.

Por quê: O roteamento ponderado permite a migração estilo canary na camada DNS. ARC adiciona portas explícitas para cortes de maior risco.

Rastrear licenças BYOL de Windows / Oracle / SQL Server em cargas de trabalho migradas.

AWS License Manager. Definir regras; aplicar no lançamento; compartilhar via RAM em toda a organização.

Por quê: A não conformidade com BYOL é cara. O License Manager previne o super-provisionamento acidental.

Após a migração, as instâncias de desenvolvimento/teste do RDS são superprovisionadas durante a noite.

Migrar dev/test para Aurora Serverless v2 com baixo min ACU. Auto-escalar para baixo quando ocioso.

Por quê: Economiza custos ociosos noturnos sem a complexidade de um agendador de instâncias.

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.