APRENDER. PRATICAR. EVOLUIR.1. Desenhar relações antes de escrever a política
Num exercício fictício, três equipas gerem aplicações de fundos, desenvolvimento e serviços comuns. O requisito é permitir que produção e desenvolvimento consultem serviços comuns, mantendo a separação entre os dois ambientes. Começa por uma matriz de origens, destinos, protocolos e operações permitidas. Um segmento Cloud WAN representa um domínio de encaminhamento; não representa um papel de utilizador da aplicação. Partilhar attachments de serviços comuns com dois segmentos não cria, por transitividade, uma partilha entre estes. A matriz deve incluir tentativas proibidas e o caminho de retorno. Se ambos os ambientes conseguirem chegar a um servidor comum que funciona como proxy, a política de rotas não demonstra que esse servidor impede trânsito aplicacional entre ambientes. Esse controlo precisa de desenho e evidência próprios.
2. Ler associação, partilha e filtragem como decisões distintas
As regras de attachment policy avaliam o attachment, incluindo as suas tags e metadados. Não presumem as tags da VPC associada. A primeira regra correspondente, por ordem numérica crescente, decide a associação; uma regra genérica demasiado cedo pode impedir uma regra específica posterior. Sem correspondência, o attachment fica sem segmento. A aceitação manual acrescenta uma decisão à associação e deve ter um responsável com critérios claros. Na partilha de rotas, allow-filter restringe relações já criadas; sozinho não cria a partilha pretendida. O modo attachment-route não redistribui automaticamente rotas estáticas nem rotas recebidas de outro segmento. Escreve testes para a ausência de rotas e para associações inesperadas, incluindo uma tag mal escrita. A aplicação local no fim da aula demonstra apenas a precedência de regras simplificadas. As routing policies atuais exigem o esquema 2025.11. A associação destas políticas usa labels próprios, geridos pelo owner da core network, e não as tags usadas para escolher segmentos. Numa revisão de IaC, confirma primeiro a versão do esquema e depois os recursos e regras referenciados. Um ficheiro JSON válido pode continuar incompatível com a versão escolhida. A migração do esquema deve entrar na análise de impacto regional.
3. Separar criação, aplicação e aceitação operacional
Uma nova versão pode estar pronta para execução enquanto a política LIVE continua anterior. A aprovação do ficheiro JSON não aplica o change set. Compara valores antigos e novos, confirma as regiões afetadas e executa a alteração segundo a janela aprovada. Acompanha o progresso, mas reserva a aceitação operacional para testes de conectividade e isolamento. O âmbito regional depende dos campos alterados: mudar a versão do esquema afeta todos os core network edges, enquanto descrições não representam uma mudança equivalente. Restaurar uma versão antiga cria uma nova versão a partir dela; continua a ser necessário rever e aplicar a mudança. O rollback pode recuperar a configuração, mas não garante recuperação de sessões ou operações de negócio em curso. Regista como reconciliar instruções cujo resultado ficou incerto.
4. Inserir inspeção com um caminho verificável
Um network function group identifica attachments onde existe uma função de rede ou segurança. A ação send-via encaminha tráfego entre VPCs através dessa função e de volta à core network. Send-to representa um caminho de saída através da função. A seleção exige conhecer origem, destino, região da inspeção e percurso de retorno. No modo dual-hop, a arquitetura precisa dos attachments de inspeção nas duas regiões envolvidas; não basta duplicar nomes na política. A restrição de um attachment por grupo e região também não limita o número de appliances que podem existir dentro da VPC de inspeção. Antes de aceitar o desenho, demonstra que tráfego permitido chega ao serviço, tráfego proibido é bloqueado e os registos permitem atribuir o resultado à função correta. Evita converter sucesso de deployment em prova de inspeção efetiva.
5. Atribuir trabalho ao owner correto numa VPC partilhada
Partilhar uma subnet não transfere a administração de todas as suas dependências. O owner mantém route tables, NACLs e attachments de Transit Gateway; o participante gere recursos seus, como interfaces e security groups. Durante um incidente, a equipa participante pode ver a route table sem a poder alterar. Dar-lhe mais permissões IAM não elimina essa fronteira do modelo de partilha. Define previamente como escalar uma alteração de rede ao owner, com destino, porta, evidência e prazo. Para observabilidade, distingue os flow logs da subnet dos logs de interfaces pertencentes ao participante. O owner pode criar os seus registos, mas não deve presumir que consegue descrever ou apagar flow logs criados pelo participante. A matriz de responsabilidades deve acompanhar a aplicação quando muda de equipa ou de conta.
6. Planear retirada e passagem a RUN
Retirar a partilha de uma subnet impede novos recursos do participante, mas os existentes podem continuar a funcionar. Isso não demonstra que autoscaling ou substituição de nós continuam possíveis: workflows geridos podem precisar da partilha contínua. Num descomissionamento, inventaria recursos, dependências de recuperação e responsáveis pela eliminação antes de fechar o projeto. O owner não consegue apagar a subnet enquanto restarem recursos do participante. O documento de entrega deve identificar versão LIVE, associações aprovadas, fluxos testados, alertas, contactos e critérios de reversão. No exercício local, altera a prioridade da regra genérica e observa a mudança de segmento selecionado. Discute depois o que falta para aceitar uma rede real: aprovação, propagação, rotas, controlos de tráfego e resultado aplicacional. O código não substitui esses testes nem contacta serviços AWS.
def select_segment(rules, attachment_tags):
for priority, key, value, segment in sorted(rules):
if key == "*" or attachment_tags.get(key) == value:
return segment
return None
rules = [(20, "env", "prod", "production"), (90, "*", "", "sandbox")]
assert select_segment(rules, {"env": "prod"}) == "production"
assert select_segment(rules, {"env": "prodd"}) == "sandbox"
assert select_segment(rules[:1], {"env": "prodd"}) is None
assert select_segment(rules, {}) == "sandbox" # VPC tags are not an input
broad_first = [(10, "*", "", "sandbox"), rules[0]]
assert select_segment(broad_first, {"env": "prod"}) == "sandbox"
print("five precedence checks passed; no AWS policy evaluated or changed")
Caso fictício: uma equipa declara a migração concluída porque a versão 12 está Ready to execute. A versão 11 permanece LIVE e um teste proibido ainda passa. A equipa revê o change set, aplica a versão aprovada e repete testes positivos e negativos antes da aceitação.
Armadilhas comuns
Confundir LATEST com LIVE; usar tags da VPC no lugar das do attachment; presumir partilha transitiva; retirar uma subnet sem testar substituição de recursos.
Tópicos relacionados: Inspeção centralizada · Arquitetura entre contas · Mudança e descomissionamento
A política define intenção; a execução, os testes de fluxos e a atribuição de responsabilidades demonstram a entrega.
Referência: Core network policy version parameters · ANS-C01