Telemetria: limites e aceitação de rede | AWS Advanced Networking: redes e produção

Escrever a pergunta de diagnóstico

Uma ferramenta só ajuda se a pergunta tiver origem, destino, família IP, protocolo, porta e instante de referência. Se o cliente falha por IPv6, um resultado sobre IPv4 não responde à pergunta. Reachability Analyzer constrói um modelo da configuração e não envia pacotes nem observa o data plane. Mesmo numa interface dual-stack, só inclui IPv4. Usa o modelo para identificar hipóteses de configuração, depois confirma o comportamento relevante por evidência apropriada. No ticket, separa o que foi analisado, o que foi observado e o que continua por confirmar. Isto permite que a próxima equipa continue a investigação sem repetir uma análise com filtros diferentes e comparar resultados que não têm o mesmo âmbito.

Percursos que o modelo não cobre

Para TCP através de uma route table TGW, Reachability Analyzer só analisa a ida. Um batch que não recebe confirmação ainda pode ter um problema de retorno. O percurso através de um endpoint GWLB também não inclui o load balancer e os targets: esse segmento precisa de análise separada. Regras Network Firewall 5-tuple são suportadas, mas listas de domínios e regras Suricata não ficam validadas por esse suporte. Lê as mensagens informativas e as limitações do componente. Se um filtro exige uma appliance e surge COMPONENT_FILTER_RESTRICTION, a conclusão é sobre o percurso filtrado. Retirar o filtro pode ajudar a investigar um bypass, mas não prova cumprimento do requisito de inspeção que acabaste de retirar.

Interpretar findings de exposição

Network Access Analyzer procura caminhos que correspondem ao scope definido; não é um ensaio funcional de todos os serviços. A análise é estática, limitada a IPv4 TCP/UDP e aos recursos da conta e Região analisadas. Não generalizes para toda a organização, para IPv6 ou para um circuito Direct Connect excluído do modelo. Os findings são unidirecionais. O serviço também não analisa regras Network Firewall, podendo reportar um caminho que uma regra efetiva bloqueia. Isso não permite fechar automaticamente como falso positivo, nem declarar uma intrusão. Reconcilia o percurso, a versão aplicada da política e um ensaio controlado. Documenta as lacunas para que o comité saiba exatamente que fronteiras receberam evidência e quais continuam em investigação.

O contrato dos Flow Logs

Um Flow Log tem âmbito, destino, filtros, formato e agregação. Não captura consultas de instâncias ao Amazon DNS server nem todo o tráfego de infraestrutura. Se precisares do destino original quando dstaddr representa o IPv4 primário da ENI, inclui pkt-dstaddr e conserva o contexto. O formato customizado tem ordem definida e a sua versão é a maior entre os campos selecionados. Não assumes a ordem default num parser de formato diferente. Alterar campos de um Flow Log existente exige uma transição para um recurso com a configuração necessária; uma query nova não cria informação histórica que nunca foi recolhida. Testa o consumidor com exemplos do novo formato e confirma entrega antes de retirar a configuração anterior.

Agregação e precisão temporal

tcp-flags é um bitmask de flags suportadas, não uma sequência de pacotes. O valor 3 pode resultar de SYN e FIN agregados e não demonstra um único pacote com ambas as flags. Zero pode ocorrer com tráfego ACK sem flags suportadas; não apaga a contagem packets. De forma semelhante, start e end têm limitações de precisão e não são timestamps de captura individual. Distingue tempo do fluxo de entrega ao destino: os prazos típicos de publicação não são garantias por registo. Quando faltam logs, verifica estado e DeliverLogsErrorMessage. Access error aponta para permissões ou trust de publicação. Evita alterar routing de produção só porque a telemetria atrasou; recolhe primeiro evidência que relacione a falha com o caminho.

Aceitação e passagem a RUN

Numa janela curta, prepara previamente os gates: configuração esperada, teste por família IP, retorno, política efetiva, entrega de logs e resultado funcional. Um caso de batch pode exigir confirmação no destinatário e controlo de duplicação antes de repetir. Associa cada gate a owner, prazo e evidência, e reserva tempo para rollback com validação. No handover, inclui filtros usados, IDs das interfaces, intervalo observado, limitações da ferramenta e hipótese ainda aberta. Uma ausência de findings só faz sentido com cobertura conhecida. O objetivo do relatório é permitir uma decisão defensável com a evidência disponível, não converter cada sinal verde numa promessa de disponibilidade. Depois da mudança, verifica se os novos recursos continuam incluídos nos mecanismos de observação.

from functools import reduce
from operator import or_

def aggregate_supported_flags(observed):
    # Inputs are already the supported values in this teaching model.
    return reduce(or_, observed, 0)

assert aggregate_supported_flags([2, 1]) == 3
assert aggregate_supported_flags([1, 2]) == 3
assert aggregate_supported_flags([18, 1]) == 19
assert aggregate_supported_flags([0, 0, 0]) == 0
assert aggregate_supported_flags([2, 4]) == 6
print("five aggregation checks passed; packet order cannot be recovered")

NA PRÁTICA

O caminho TCP por TGW aparece reachable, mas o batch não recebe confirmação. Analisa o retorno, correlaciona uma tentativa controlada e respeita o prazo de rollback.

Armadilhas comuns

Extrapolar IPv4 para IPv6; confundir bitmask com sequência; fechar findings sem testar o controlo não modelado.

Tópicos relacionados: Inspeção Network Firewall · Incidentes e critérios de aceitação

Leva esta ideia contigo

Uma conclusão só é tão abrangente como a evidência que a suporta.

Criar conta

Referência: How Reachability Analyzer works · ANS-C01