Tutti gli strumenti

VPC Routing Simulator

Verifica la raggiungibilità tra subnet VPC e analizza tabelle di routing per il debug di connettività cloud.

Verifica Raggiungibilità Subnet
Route Table Simulator
DestinazioneTargetPrefisso
VPC Peering Checklist

Verifica di aver completato tutti i passaggi necessari per un VPC Peering funzionante.

VPC Peering connection creata e accettata
Crea la richiesta dal VPC requester e accettala dal VPC accepter nella console AWS.
Route table VPC A: route verso CIDR di VPC B tramite pcx-xxx
Aggiungi una route con destinazione = CIDR VPC B e target = ID peering connection.
Route table VPC B: route verso CIDR di VPC A tramite pcx-xxx
Il peering non è transitivo: entrambe le route table devono essere aggiornate.
Security Group: permettono traffico dal CIDR del VPC peer
Aggiorna le regole inbound/outbound dei Security Group per accettare il CIDR del VPC remoto.
NACL: permettono traffico in entrambe le direzioni (incluse porte efemere)
Se usi NACL custom (non default), aggiungi regole inbound/outbound per porte 1024-65535.
Nessun range CIDR sovrapposto tra i due VPC
VPC Peering non è possibile se i CIDR si sovrappongono. Verifica con lo strumento Subnet Check sopra.
FAQ

Domande frequenti

Cos'è il "longest prefix match" nel routing?

Quando un router (o una route table AWS) ha più route che corrispondono a una destinazione, viene scelta quella con il prefisso più lungo (più specifico). Esempio: per la destinazione 10.0.1.50, la route 10.0.1.0/24 viene preferita a 10.0.0.0/8 perché /24 è più specifico di /8. La route 0.0.0.0/0 (default route) è la meno specifica e viene usata solo se nessun'altra route corrisponde. Questo principio si applica a tutte le routing table, da quelle AWS alle tabelle di routing dei router fisici.

Quando due VPC hanno range IP sovrapposti (es. entrambi usano 10.0.0.0/16), non è possibile creare un VPC Peering tra loro perché il router non saprebbe a quale VPC instradare il traffico verso un IP condiviso. Questo è un limite architetturale fondamentale: pianifica sempre gli spazi IP dei tuoi VPC in anticipo. La best practice è usare range /16 distinti per ogni VPC (es. 10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16). Il Transit Gateway allevia parzialmente questo problema ma la sovrapposizione rimane problematica.

VPC Peering è una connessione diretta point-to-point tra due VPC: è gratuita per traffico intra-AZ, non transitive (se A-B e B-C, A non può raggiungere C via B), e richiede route table entries separate per ogni peering. Transit Gateway è un hub centrale: tutti i VPC si connettono al TGW e possono comunicare tra loro senza connessioni point-to-point individuali. TGW supporta migliaia di VPC, è transitivo, supporta VPN e Direct Connect, ma ha un costo per ora e per GB. Usa Peering per connessioni semplici tra pochi VPC; TGW per architetture hub-and-spoke complesse.

No. Tutti gli strumenti LYNK TOOLS funzionano interamente nel browser, senza inviare file o dati a server esterni. L'elaborazione avviene localmente sul tuo dispositivo: i tuoi file restano privati e non vengono mai caricati online.