Aggiornamento: a fine dicembre 2015, AWS ha annunciato una nuova funzionalità, un Managed NAT Gateway per VPC . Questo servizio facoltativo fornisce un meccanismo alternativo per le istanze VPC in una sottorete privata per accedere a Internet, dove in precedenza la soluzione comune era un'istanza EC2 su una sottorete pubblica all'interno del VPC, funzionante come "istanza NAT", che fornisce la traduzione dell'indirizzo di rete ( tecnicamente, traduzione dell'indirizzo di porta ) per istanze in altre sottoreti private, consentendo a tali macchine di utilizzare l'indirizzo IP pubblico dell'istanza NAT per l'accesso a Internet in uscita.
Il nuovo servizio NAT gestito non cambia sostanzialmente l'applicabilità delle seguenti informazioni, ma questa opzione non è trattata nel contenuto che segue. È comunque possibile utilizzare un'istanza NAT come descritto, oppure è possibile eseguire il provisioning del servizio Gateway NAT gestito. Sarà disponibile una versione estesa di questa risposta che integra ulteriori informazioni su NAT Gateway e su come si confronta con un'istanza NAT, poiché entrambe sono rilevanti per il paradigma della sottorete privata / pubblica in VPC.
Si noti che Internet Gateway e NAT Gateway sono due diverse funzionalità. Tutte le configurazioni VPC con accesso a Internet avranno un oggetto virtuale Internet Gateway.
Per comprendere la distinzione tra sottoreti "private" e "pubbliche" in Amazon VPC è necessario comprendere come funzionano in generale il routing IP e la traduzione degli indirizzi di rete (NAT) e come vengono specificamente implementati in VPC.
La differenziazione principale tra una sottorete pubblica e privata in VPC è definita da quale sia la route predefinita di quella sottorete, nelle tabelle di routing VPC.
Questa configurazione, a sua volta, determina la validità dell'utilizzo o meno di indirizzi IP pubblici su istanze su quella particolare sottorete.
Ogni subnet ha esattamente una route predefinita, che può essere solo una delle due cose:
- l'oggetto "Internet Gateway" del VPC, nel caso di una sottorete "pubblica", oppure
- un dispositivo NAT, ovvero un gateway NAT o un'istanza EC2, che svolge il ruolo di "istanza NAT", nel caso di una sottorete "privata".
Internet Gateway non esegue alcuna traduzione dell'indirizzo di rete per istanze senza indirizzi IP pubblici, quindi un'istanza senza un indirizzo IP pubblico non può connettersi a Internet verso l' esterno - per fare cose come il download di aggiornamenti software o l'accesso ad altre risorse AWS come S3 1 e SQS - se la route predefinita sulla sua sottorete VPC è l'oggetto Internet Gateway. Quindi, se sei un'istanza su una sottorete "pubblica", allora hai bisogno di un indirizzo IP pubblico per fare un numero significativo di cose che i server comunemente devono fare.
Per le istanze con solo un indirizzo IP privato, esiste un modo alternativo di accesso in uscita a Internet. Qui entra in gioco Network Address Translation² e un'istanza NAT.
Le macchine su una sottorete privata possono accedere a Internet perché il percorso predefinito su una sottorete privata non è l'oggetto "Internet Gateway" VPC - è un'istanza EC2 configurata come istanza NAT.
Un'istanza NAT è un'istanza su una sottorete pubblica con un IP pubblico e una configurazione specifica. Ci sono AMI pre-costruite per fare questo, o puoi costruirne una tua.
Quando le macchine private indirizzano il traffico verso l'esterno, il traffico viene inviato da VPC all'istanza NAT, che sostituisce l'indirizzo IP di origine sul pacchetto (l'indirizzo IP privato della macchina privata) con il proprio indirizzo IP pubblico, invia il traffico su Internet, accetta i pacchetti di risposta e li inoltra all'indirizzo privato della macchina di origine. (Può anche riscrivere la porta di origine e, in ogni caso, ricorda i mapping in modo da sapere quale macchina interna dovrebbe ricevere i pacchetti di risposta). Un'istanza NAT non consente a alcun traffico in ingresso "imprevisto" di raggiungere le istanze private, a meno che non sia stato specificamente configurato per farlo.
Pertanto, quando si accede a una risorsa Internet esterna da una sottorete privata, il traffico attraversa l'istanza NAT e sembra che la destinazione abbia avuto origine dall'indirizzo IP pubblico dell'istanza NAT ... quindi il traffico di risposta ritorna all'istanza NAT. Né il gruppo di sicurezza assegnato all'istanza NAT né il gruppo di sicurezza assegnato all'istanza privata devono essere configurati per "consentire" questo traffico di risposta, poiché i gruppi di sicurezza sono stateful. Si rendono conto che il traffico di risposta è correlato alle sessioni originate internamente, quindi è automaticamente consentito. Il traffico imprevisto viene ovviamente negato a meno che il gruppo di sicurezza non sia configurato per consentirlo.
A differenza del routing IP convenzionale, in cui il gateway predefinito si trova sulla stessa sottorete, il modo in cui funziona in VPC è diverso: l'istanza NAT per una determinata sottorete privata è sempre su una sottorete diversa e quell'altra sottorete è sempre una sottorete pubblica, perché l'istanza NAT deve avere un IP esterno pubblico e il suo gateway predefinito deve essere l'oggetto "Internet Gateway" VPC.
Allo stesso modo ... non è possibile distribuire un'istanza con un IP pubblico su una sottorete privata. Non funziona, perché il percorso predefinito su una sottorete privata è (per definizione) un'istanza NAT (che esegue NAT sul traffico) e non l'oggetto Internet Gateway (che non funziona). Il traffico in entrata da Internet colpirebbe l'IP pubblico dell'istanza, ma le risposte proverebbero a instradare verso l'esterno attraverso l'istanza NAT, il che eliminerebbe il traffico (poiché sarebbe composto da risposte a connessioni di cui non è a conoscenza, quindi sarebbe considerato non valido) o riscriverebbe il traffico di risposta per utilizzare il proprio indirizzo IP pubblico, che non funzionerebbe poiché l'origine esterna non avrebbe accettato risposte provenienti da un indirizzo IP diverso da quello con cui stavano tentando di avviare le comunicazioni .
In sostanza, quindi, le designazioni "private" e "pubbliche" non riguardano realmente l'accessibilità o l'inaccessibilità da Internet. Riguardano i tipi di indirizzi che verranno assegnati alle istanze su quella sottorete, il che è rilevante a causa della necessità di tradurre - o evitare di tradurre - quegli indirizzi IP per le interazioni Internet.
Poiché VPC ha route implicite da tutte le subnet VPC a tutte le altre subnet VPC, la route predefinita non ha un ruolo nel traffico VPC interno. Le istanze con indirizzi IP privati si collegheranno ad altri indirizzi IP privati nel VPC "dal" loro indirizzo IP privato, non "dal" loro indirizzo IP pubblico (se ne hanno uno) ... purché l'indirizzo di destinazione sia un altro indirizzo privato all'interno del VPC.
Se le tue istanze con indirizzi IP privati non devono mai, in nessun caso, originare traffico Internet in uscita, potrebbero tecnicamente essere distribuite su una sottorete "pubblica" e sarebbero comunque inaccessibili da Internet ... ma in una tale configurazione, è impossibile per loro originare il traffico in uscita verso Internet, che include ancora connessioni con altri servizi di infrastruttura AWS, come S3 1 o SQS.
1. Per quanto riguarda S3, in particolare, affermare che l'accesso a Internet è sempre necessario è una semplificazione eccessiva che probabilmente aumenterà nel tempo e si diffonderà ad altri servizi AWS, poiché le capacità di VPC continuano a crescere ed evolversi. Esiste un concetto relativamente nuovo chiamato endpoint VPCche consente alle tue istanze, comprese quelle con solo indirizzi IP privati, di accedere direttamente a S3 da sottoreti selezionate all'interno del VPC, senza toccare "Internet" e senza utilizzare un'istanza NAT o un gateway NAT, ma ciò richiede una configurazione aggiuntiva, ed è utilizzabile solo per accedere a bucket all'interno della stessa area AWS del VPC. Per impostazione predefinita, S3 - che è, al momento della stesura di questo documento, l'unico servizio che ha esposto la capacità di creare endpoint VPC - è accessibile solo dall'interno di VPC via Internet. Quando si crea un endpoint VPC, viene creato un elenco di prefissi (pl-xxxxxxxx) che è possibile utilizzare nelle tabelle di route VPC per inviare il traffico associato a quel particolare servizio AWS direttamente al servizio tramite l'oggetto virtuale "VPC Endpoint". Risolve anche un problema di limitazione dell'accesso in uscita a S3 per un'istanza particolare, poiché l'elenco dei prefissi può essere utilizzato in gruppi di sicurezza in uscita, al posto di un indirizzo IP o blocco di destinazione - e un endpoint VPC S3 può essere soggetto a ulteriori dichiarazioni di politica , limitando l'accesso alla benna dall'interno, come desiderato.
2. Come indicato nella documentazione, ciò che viene attualmente discusso è la porta e la traduzione dell'indirizzo di rete. È comune, anche se tecnicamente un po 'impreciso, fare riferimento all'operazione combinata come "NAT". Questo è in qualche modo simile al modo in cui molti di noi tendono a dire "SSL" quando in realtà intendiamo "TLS". Sappiamo di cosa stiamo parlando, ma non usiamo la parola più corretta per descriverlo. "Nota Usiamo il termine NAT in questa documentazione per seguire la pratica IT comune, sebbene il ruolo effettivo di un dispositivo NAT sia la traduzione dell'indirizzo che la traduzione dell'indirizzo della porta (PAT)."