APRENDER. PRATICAR. EVOLUIR.Duas escalas de distribuição
O traffic dial controla a parcela do tráfego já destinada a um endpoint group regional, não a percentagem global de todos os listeners. Se 600 ligações seriam destinadas ao grupo, um dial de 25% representa nominalmente 150. Dentro do grupo, pesos 40 e 120 dividem a parcela numa proporção de um para três. Estes cálculos ajudam a discutir uma release gradual, mas não garantem contagens exatas de pedidos, bytes ou carga. A documentação admite exceções aos pesos para preservar disponibilidade, incluindo colisões com IP preservado. No relatório, apresenta o denominador, a janela e o sinal medido. Não compare percentagem de ligações com percentagem de consumo sem considerar duração e custo diferentes por operação.
Drenagem e afinidade
Mudar o dial afeta novas ligações e não termina as que já existem. Uma sessão TCP longa pode continuar na versão anterior depois de o painel mostrar dial zero. Define um critério de drenagem com tempo, sessões ativas e trabalho em curso, além de um limite para decidir rollback. Source IP affinity também não replica estado de aplicação. Usa endereços para orientar a seleção, e mudanças de edge com outra Região preferida podem quebrar essa afinidade. Se o serviço guarda estado apenas na memória local, precisa de estratégia de recuperação para essa transição. Testa nova ligação e ligação persistente separadamente; o sucesso de uma não demonstra o comportamento da outra, nem garante que uma escrita anterior foi confirmada.
Failover não é uma regra de acesso
Quando não há endpoints saudáveis de peso positivo num grupo, o serviço procura alternativas. Durante esse mecanismo pode ignorar o traffic dial e considerar uma Região com dial zero. Se não encontrar um endpoint saudável elegível nos grupos tentados, existe comportamento fail open para um endpoint do grupo mais próximo. Logo, nem dial zero nem falha de health check são prova de isolamento. Uma release ainda não aprovada precisa de controlos explícitos que impeçam acesso, inclusive em falha regional. Documenta os destinos elegíveis e executa testes negativos com o owner de segurança. No comité, separa redução de tráfego, indisponibilidade operacional e bloqueio autorizado; são resultados diferentes e não devem partilhar uma única marca verde.
Saúde e portas são contratos separados
Para endpoints ALB/NLB, configura health checks em Elastic Load Balancing; os parâmetros de sonda de GA destinam-se a EC2 e Elastic IP. Um ALB precisa de pelo menos um target saudável em cada target group para a condição de saúde documentada. Para EC2 com listener UDP, confirma o servidor TCP e a porta exigidos pela sonda. Um override 443→8443 muda o tráfego do utilizador, não a porta de health check. Valida ambos os listeners e permissões. A porta endpoint do override não pode sobrepor gamas de listeners do accelerator nem ser reutilizada por outro override a partir de uma porta diferente. Estas dependências devem entrar no pipeline e no checklist funcional da janela, antes de o tráfego real ser alterado.
IP preservado e caminhos concorrentes
Preservar IP tem requisitos por tipo de endpoint. Elastic IP endpoints não suportam a funcionalidade; NLBs têm condições adicionais, incluindo security groups e restrições de listeners TLS. Confirma compatibilidade antes de desenhar regras com base no endereço do cliente. Quando a preservação está ativa, as allow lists devem considerar as origens autorizadas reais. Um endpoint privado pode receber tráfego por GA com IGW ligado à VPC sem exigir IP público ou rota IGW na subnet. Essa distinção evita expor um caminho direto desnecessário. Se o mesmo recurso recebe tráfego direto e por accelerators, podem ocorrer colisões de ligações. Portas finais distintas são uma mitigação documentada para certos cenários, mas devem ser configuradas e testadas em todo o percurso.
Ciclo de vida e compromisso com parceiros
Os IPs estáticos atribuídos pela AWS permanecem enquanto o accelerator existe, mesmo desativado. Desativar interrompe aceitação e encaminhamento, mas eliminar perde esses endereços. Recriar com o mesmo nome não constitui rollback que preserve allow lists de parceiros. Antes da janela, identifica os owners externos, prazos de alteração e a alternativa de recuperação que realmente restaura o acesso. As chamadas de gestão usam us-west-2, apesar de o serviço encaminhar para endpoints noutras Regiões; não confundas plano de gestão e localização dos dados. A aceitação deve juntar configuração, distribuição observada, sessões drenadas, saúde funcional e acesso dos parceiros. Guarda também a condição de interrupção da mudança quando essas provas não chegam dentro do tempo reservado.
def nominal_share(candidate_connections, dial, weights):
assert 0 <= dial <= 100 and all(w >= 0 for w in weights)
assert sum(weights) > 0
regional = candidate_connections * dial / 100
return [regional * w / sum(weights) for w in weights]
assert nominal_share(600, 25, [40, 120]) == [37.5, 112.5]
assert nominal_share(600, 100, [40, 120]) == [150, 450]
assert nominal_share(600, 0, [40, 120]) == [0, 0]
assert nominal_share(100, 100, [1, 3]) == [25, 75]
assert nominal_share(100, 100, [0, 3]) == [0, 100]
print("five nominal-share checks passed; failover and sessions are not modeled")
600 ligações candidatas à Região × dial 25% = 150 nominais; pesos 40/120 representam 37,5/112,5 em expectativa, não contagens garantidas nem drenagem de sessões antigas.
Armadilhas comuns
Usar dial zero como isolamento; aplicar override a health checks por inferência; recriar o accelerator como rollback com IP garantido.
Tópicos relacionados: Health checks e failover · Capacidade e continuidade
Uma mudança de distribuição precisa de provas de sessões, acesso e recuperação, além dos valores de configuração.
Referência: Traffic dials · ANS-C01