Tópico

Solução de problemas de rede

Um método sistemático para problemas de conectividade de VPC, análise de logs de rede, depuração do CloudFront, links híbridos e monitoramento de rede do CloudWatch.

Todos os outros tópicos deste domínio construíram alguma coisa. Este desmonta quando ela para de funcionar. Uma conexão estoura o tempo e você tem 4 suspeitos plausíveis, uma taxa de cache hit despenca sem nenhum deploy, uma VPN reporta available enquanto nada a atravessa. O que separa uma correção de 20 minutos de uma queda de 3 horas não é conhecer mais serviços, é ter uma ordem de trabalho e saber qual fonte de evidência consegue enxergar o salto suspeito.

O que este tópico cobre

  • Um percurso ordenado de origem a destino que acha o componente que bloqueia em vez de chutar, mais o Reachability Analyzer e os explanation codes dele
  • Leitura de registros de VPC flow log campo por campo, e o padrão ACCEPT e depois REJECT que separa uma negativa de security group de uma de network ACL
  • O tráfego que os VPC Flow Logs nunca capturam, e quando a resposta são os Transit Gateway Flow Logs, os logs de acesso do ELB, os logs do WAF ou os query logs do Resolver
  • Consulta de logs em volume com o CloudWatch Logs Insights e o Amazon Athena
  • Diagnóstico do CloudFront a partir dos headers de resposta e dos campos de result type, as causas por trás de 403, 502 e 504, e como achar a dimensão da cache key que destrói a sua taxa de hit
  • Links híbridos diagnosticados de baixo para cima: Phase 1 contra Phase 2 contra BGP na VPN, e camada 1 contra camada 2 contra camada 3 no Direct Connect
  • As falhas de roteamento e de DNS que deixam um link perfeitamente saudável sem carregar tráfego
  • Internet Monitor, Network Flow Monitor e Network Synthetic Monitor, e as métricas por recurso que pegam falhas que ninguém reportou

Por que isso importa

A Task 5.3 da prova é inteiramente sobre diagnóstico, e as questões dela são montadas quebrando exatamente uma coisa em uma arquitetura correta no resto. Quem sofre são os candidatos que conhecem cada serviço isolado mas não têm método para reduzir 4 suspeitos a 1. Quem passa lê o sintoma primeiro: um timeout e uma conexão recusada apontam para camadas diferentes, um REJECT solitário e um par ACCEPT e REJECT apontam para firewalls diferentes, um 502 e um 504 apontam para metades diferentes da conexão com a origem.

A mesma disciplina é o que faz diferença no plantão. Nomear o salto suspeito antes de abrir um console já escolhe a sua ferramenta, e escolher direito é a maior parte do trabalho.

Lições deste tópico

  1. 1Solucionar problemas de conectividade na VPCGratuito
  2. 2Analisar logs de rede
  3. 3Solucionar problemas do CloudFront
  4. 4Solucionar problemas de conectividade híbrida e privada
  5. 5Monitoramento de rede do CloudWatch