Scopes e conectividade futura
Antes de organizar pools, desenha as redes que podem comunicar. Dois ambientes isolados podem usar o mesmo espaço em scopes privados distintos. Isso representa a separação atual; não instala tradução nem resolve conflitos quando os ambientes passam a precisar de conectividade. Numa integração, começa pelos fluxos aprovados, owners e dependências de DNS. Decide se é necessário renumerar ou disponibilizar um serviço através de um padrão compatível com sobreposição. Não escolhas uma solução só para limpar o inventário. Regista o custo, prazo e risco da alternativa, e demonstra a operação de negócio antes do cutover. O scope é uma fronteira de gestão do espaço, não um controlo que torna endereços duplicados unívocos numa rede interligada.
Hierarquia, locale e regras
Provisionar um pool disponibiliza espaço para alocações; criar apenas o objeto sem CIDR não fornece capacidade. A hierarquia pode separar Regiões e ambientes, mas as regras do pool principal não são automaticamente regras dos recursos nos filhos. Aplica tags e limites no nível que aloca à VPC. Para uma VPC, o locale do pool deve corresponder à Região; uma escolha de locale existente não é editável. Distingue mínimo de netmask e mínimo de endereços: /22 permite um bloco maior do que /26. Uma necessidade de /21 não cabe numa regra de 22 a 26. Valida estes contratos no pipeline antes de reservar a janela; um default conveniente não satisfaz uma necessidade de capacidade diferente.
Descobrir não é corrigir
Auto-import incorpora recursos existentes e pode marcá-los noncompliant. Não acrescenta a tag em falta nem altera o CIDR para satisfazer regras. Ao descobrir blocos sobrepostos, seleciona o maior, mas não substitui uma alocação já existente com outro recurso sobreposto. A ausência de um segundo recurso entre as alocações não demonstra que deixou de existir. Compara descoberta, alocações e inventário operacional. Se dois CIDRs descobertos forem iguais, a escolha de um não constitui decisão de ownership. A equipa tem de resolver essa decisão e o possível conflito. Mantém uma lista de exceções com responsável, âmbito e próxima ação, evitando que uma importação parcialmente bem-sucedida seja apresentada ao comité como migração concluída.
Partilha e visibilidade
A partilha RAM é criada na home Region do IPAM, que pode diferir do locale do pool. O IPAM precisa da integração apropriada com Organizations e a partilha tem de estar ativada em RAM. Para uma conta externa, permissão para consumir um pool não equivale a visibilidade de todos os seus recursos: confirma a partilha de resource discovery com o administrador delegado. Num pool partilhado, o owner do recurso também tem de ser principal RAM, uma regra implícita adicional. Ao integrar uma aplicação de outra entidade, regista quem cria a partilha, quem aceita as responsabilidades e quem consegue observar os endereços. Testa alocação e cobertura separadamente; uma chamada bem-sucedida não comprova todo o modelo de governação.
Capacidade e cronologia
Um gráfico de PercentAllocated mede espaço entregue a outros pools; PercentAssigned mede espaço atribuído a recursos, incluindo reservas manuais. Nenhum é a percentagem de instâncias ocupadas. Apresenta o denominador e os recursos abrangidos antes de pedir expansão de capacidade. No histórico, sampled start e sampled end representam observações por snapshots periódicos. Uma associação pode ter começado antes de ser detetada. Ao investigar um incidente, junta o histórico à evidência de criação e à cronologia operacional, sem subtrair um atraso fixo inventado. Se o recurso mudar de scope, o registo anterior termina e inicia-se outro no destino. Conserva o contexto de ambos para que a transferência administrativa não pareça uma eliminação e recriação do serviço.
Libertar e descomissionar
ReleaseIpamPoolAllocation serve alocações manuais. Para um CIDR de recurso privado, segue o processo documentado de ignorar ou eliminar e confirma a libertação assíncrona antes de reutilizar o espaço. Um pedido de movimento entre scopes pode ter sucesso e continuar dependente dessa libertação. Ignored retira controlos de overlap e conformidade e não elimina cobrança de IPs ativos. O recurso pode continuar a usar o endereço. Do mesmo modo, cascade delete de IPAM não elimina VPCs nem renumera os seus CIDRs. Um plano de decommission precisa de provas distintas: recursos retirados, dependências removidas, custo reconciliado e gestão de endereços restante. Não uses um painel sem findings como substituto dessas provas.
from ipaddress import ip_network
def overlaps_after_join(rows):
return [(a[0], b[0]) for i, a in enumerate(rows)
for b in rows[i + 1:]
if ip_network(a[1]).overlaps(ip_network(b[1]))]
def permitted_size(cidr, minimum, maximum):
return minimum <= ip_network(cidr).prefixlen <= maximum
assert overlaps_after_join([("fund-a", "10.92.0.0/16"),
("fund-b", "10.92.4.0/24")]) == [("fund-a", "fund-b")]
assert overlaps_after_join([("a", "10.92.0.0/16"),
("b", "10.93.0.0/16")]) == []
assert not permitted_size("10.96.0.0/21", 22, 26)
assert permitted_size("10.96.0.0/22", 22, 26)
assert not permitted_size("10.96.0.0/27", 22, 26)
print("five local address checks passed; no IPAM changes made")
Dois /16 iguais pertencem a redes isoladas. Antes de autorizar a troca de ficheiros, documenta o fluxo, a solução para overlap e um teste com confirmação no destinatário.
Armadilhas comuns
Confundir ignored com eliminação; supor herança de regras; tratar uma alocação libertada como prova de espaço fisicamente livre.
Tópicos relacionados: Transit Gateway e sobreposição · FinOps e descomissionamento
A gestão do endereço e o estado do recurso precisam de evidência separada e reconciliada.
Referência: How IPAM works · ANS-C01