Domande frequenti su Amazon VPC

Non sono previsti costi aggiuntivi per la creazione e l'uso di un cloud privato virtuale. Vengono invece addebitati i costi per gli altri servizi, ad esempio Amazon EC2, secondo le tariffe pubblicate (incluse quelle per il trasferimento dei dati). Se colleghi il tuo VPC al data center aziendale usando una connessione VPN hardware opzionale, il costo dipende dalle ore di connessione alla VPN (la quantità di tempo in cui la connessione è in stato "disponibile"). Le ore parziali saranno fatturate come ore complete. I dati trasferiti tramite connessioni VPN saranno fatturati secondo le tariffe standard di AWS. Per informazioni sui prezzi di VPC e VPN, visita la sezione dedicata nella pagina di Amazon VPC.

I costi di utilizzo per gli altri servizi, incluso Amazon EC2, vengono addebitati secondo le tariffe pubblicate per le risorse interessate. Il trasferimento dei dati non prevede alcun costo quando l'accesso ad Amazon Web Services (ad esempio ad Amazon S3) avviene tramite il gateway Internet del cloud privato virtuale.

Se accedi alle risorse AWS tramite la connessione VPN, vengono addebitati i costi di trasferimento dei dati su Internet.

Puoi connettere un cloud privato virtuale Amazon a:

• Internet (tramite un Internet gateway)
• Data center aziendale con una connessione VPN gestita da AWS (tramite un gateway virtuale privato)
• Internet e data center aziendale (tramite sia Internet gateway sia gateway virtuale privato)
• Altri servizi AWS (tramite Internet gateway, NAT, gateway virtuale privato o endpoint VPC)
• Altri VPC Amazon (tramite connessioni peer VPC)

Amazon VPC supporta la creazione di un Internet gateway. Questo gateway consente alle istanze EC2 nel cloud privato virtuale di accedere direttamente a Internet. Puoi anche utilizzare un Gateway Internet per traffico solo in uscita che è un gateway con stato che fornisce solo accesso in uscita per il traffico IPv6 dal VPC a Internet.

No. Un Internet gateway dispone di scalabilità orizzontale, è ridondante e offre disponibilità elevata. Non impone alcuna limitazione di banda.

Puoi utilizzare indirizzi IP pubblici, tra cui gli indirizzi IP elastici (EIP) e gli indirizzi globali unici IPv6 (GUA) per permettere alle istanze in un cloud privato virtuale di comunicare direttamente verso l'esterno e di ricevere traffico in entrata su Internet (ad es. con server Web). Puoi anche utilizzare le soluzioni proposte nella domanda successiva.

Tutti gli indirizzi IP che sono assegnati a un istanza o a un servizio in hosting in un VPC a cui è possibile accedere su Internet sono considerati indirizzi IP pubblici. Solo gli indirizzi IPv4 pubblici, compresi gli indirizzi IP elastici (EIP) e i GUA IPv6 possono essere instradati su Internet. Per farlo, dovresti prima connettere il VPC a Internet e poi aggiornare la tabella di routing per renderli raggiungibili da Internet.

Le istanze sprovviste di indirizzi IP pubblici possono accedere a Internet in due modi:

1. Le istanze prive di indirizzi IP pubblici possono instradare il traffico attraverso un gateway NAT oppure un'istanza NAT. Queste istanze usano l'indirizzo IP pubblico del gateway NAT o dell'istanza NAT per accedere a Internet. Il gateway NAT (o l'istanza NAT) consente le comunicazioni in uscita ma non permette alle macchine su Internet di avviare una connessione alle istanze con indirizzi privati.
2. Per i VPC con connessione VPN hardware o Direct Connect, le istanze possono instradare il traffico Internet all'interno del gateway virtuale privato fino al data center esistente. Da lì possono accedere a Internet tramite i punti di uscita esistenti e i dispositivi di protezione/monitoraggio della rete.

Sì. È possibile usare una VPN software di terze parti per creare una connessione VPN di accesso remoto o tra due siti con il VPC, utilizzando il gateway Internet.

No. Quando si utilizza lo spazio dell'indirizzo IP pubblico, tutte le comunicazioni tra le istanze e i servizi ospitati in AWS utilizzano la rete privata di AWS. I pacchetti che hanno origine dalla rete AWS con una destinazione sulla rete AWS rimangono sulla rete globale AWS, tranne il traffico verso o dalle Regioni AWS Cina.

Inoltre, tutti i dati che passano attraverso la rete globale AWS che collega i nostri centri dati e le nostre regioni vengono automaticamente crittografati a livello fisico prima di lasciare le nostre strutture sicure. Esistono anche ulteriori livelli di crittografia: ad esempio, tutto il traffico peer transregionale VPC e le connessioni Transport Layer Security (TLS, sicurezza del livello di trasporto) per i clienti o service-to-service. 

Una connessione VPN gestita da AWS collega il cloud privato virtuale al tuo data center. Amazon supporta le connessioni VPN IPSec (Internet Protocol security). I dati trasferiti tra il cloud privato virtuale e il data center vengono instradati su una connessione VPN crittografata per proteggere la riservatezza e l'integrità dei dati in transito. Per stabilire connessioni VPN hardware non è invece necessario disporre di una connessione VPN gestita da AWS.

Puoi usare qualsiasi intervallo di indirizzi IPv4, inclusi gli indirizzi IP previsti nella RFC 1918 o quelli che è possibile instradare pubblicamente per il blocco CIDR principale. Per i blocchi CIDR secondari sono previste alcune restrizioni. I blocchi IP instradabili pubblicamente sono raggiungibili solo tramite gateway virtuale privato e non è possibile accedervi da Internet tramite Internet gateway. AWS non pubblicizza in Internet i blocchi di indirizzi IP di proprietà dei clienti. Potrai allocare un massimo di 5 blocchi CIDR forniti da Amazon o GUA IPv6 BYOIP in un VPC richiamando la relativa API oppure tramite la Console di gestione AWS.

Puoi assegnare un singolo intervallo di indirizzi IP CIDR (Classless Internet Domain Routing) come blocco CIDR principale al momento della creazione del VPC; successivamente potrai aggiungere fino a quattro (4) blocchi CIDR secondari. Alle sottoreti interne al VPC potrai assegnare gli indirizzi compresi in questi intervalli CIDR. Anche se gli intervalli di indirizzi IP di diversi cloud privati virtuali possono sovrapporsi, non sarà possibile connettere i VPC a una comune rete domestica tramite una connessione VPN hardware. Per questo motivo, consigliamo di non utilizzare intervalli di indirizzi IP sovrapposti. Puoi allocare un massimo di 5 blocchi CIDR forniti da Amazon o IPv6 BYOIP al VPC.

Ai cloud privati virtuali di default viene assegnato l'intervallo CIDR 172.31.0.0/16. Le sottoreti di default all'interno di un cloud privato virtuale ricevono netblock /20 all'interno dell'intervallo CIDR del cloud privato virtuale. 

Sì, puoi portare i tuoi indirizzi IPv4 pubblici e gli indirizzi GUA IPv6 in AWS VPC e allocarli staticamente a sottoreti e istanze EC2. Per accedere a questi indirizzi via Internet, devi pubblicizzarli su Internet dalla tua rete On-Premise. Devi anche reindirizzare il traffico su questi indirizzi tra il tuo VPC e la rete locale usando AWS DX o una connessione VPN AWS. Puoi reindirizzare il traffico dal tuo VPC usando il gateway virtuale privato. Allo stesso modo, puoi reindirizzare il traddico dalla tua rete casalinga al tuo VPC usando il tuo router.

Al momento, Amazon VPC supporta cinque (5) intervalli di indirizzi IP, uno (1) principale e quattro (4) secondari per IPv4. Le dimensioni di ciascuno di questi intervalli devono essere comprese tra /28 e /16 (secondo la notazione CIDR). Gli intervalli di indirizzi IP del cloud privato virtuale non devono però sovrapporsi a intervalli di reti esistenti.

Per il protocollo IPv6, il cloud privato virtuale ha una dimensione fissa di /56 (in notazione CIDR). Ad un cloud privato virtuale possono essere associati blocchi CIDR sia IPv4 sia IPv6.

Sì. È possibile espandere un cloud privato virtuale esistente aggiungendo fino a quattro (4) intervalli IPv4 secondari (CIDR). Per ridurne le dimensioni, è possibile eliminare i blocchi CIDR secondari che erano stati aggiunti.   Allo stesso modo, puoi aggiungere fino a cinque (5) intervalli IP (CIDR) IPv6 al tuo VPC.  Puoi ridurre il tuo VPC eliminando questi intervalli aggiuntivi.

Al momento è possibile creare fino a 200 sottoreti per cloud privato virtuale. Se desideri crearne un numero maggiore, inoltra una richiesta al centro assistenza.

La dimensione minima di una sottorete è /28 (o 14 indirizzi IP) per IPv4. Le sottoreti non possono avere dimensioni maggiori rispetto al cloud privato virtuale in cui sono create.

Per il protocollo IPv6, le sottoreti hanno una dimensione fissa di /64. A una sottorete può essere allocato un solo blocco CIDR IPv6.

Amazon riserva i primi quattro (4) e l'ultimo (1) indirizzo IP di ogni sottorete alla gestione della rete IP.

Quando avvii un'istanza Amazon EC2 all'interno di una sottorete che non è solo IPv6, puoi opzionalmente specificare l'indirizzo IPv4 privato primario per l'istanza. Se decidi di non specificare l'indirizzo IPv4 privato principale, AWS ne assegna automaticamente uno dall'intervallo di indirizzi IPv4 assegnati alla sottorete. Puoi assegnare indirizzi IPv4 privati secondari quando avvii un'istanza, quando crei un'interfaccia di rete elastica, o in qualsiasi momento dopo aver avviato l'istanza o creato l'interfaccia. Se avvii un istanza Amazon EC2 in una sottorete solo IPv6, AWS la indirizza automaticamente dall'indirizzo GUA IPv6 CIDR di quella sottorete fornito da Amazon. L'indirizzo GUA IPv6 dell'istanza rimarrà privato a meno che tu lo renda raggiungibile da Internet con la giusta configurazione del gruppo di sicurezza, del NACL e della tabella di routing.

Per un istanza avviata su una sottorete IPv4 o dual stack, l'indirizzo IPv4 privato principale è trattenuto per tutto il ciclo vitale dell'istanza o dell'interfaccia. Gli indirizzi IPv4 privati secondari possono essere assegnati, rimossi o riassegnati tra diverse istanze o interfacce in qualsiasi momento. Per un'istanza lanciata in una sottorete solo IPv6, l'indirizzo GUA IPv6 assegnato che è anche il primo indirizzo IP sull'interfaccia di rete primaria dell'istanza può essere modificato in qualsiasi momento associando un nuovo indirizzo GUA IPv6 e rimuovendo l'indirizzo GUA IPv6 esistente.

Un indirizzo IPv4 assegnato a un'istanza in esecuzione può essere riutilizzato da un'altra istanza solo se l'istanza originale è terminata. Tuttavia, l'indirizzo GUA IPv6 assegnato a un'istanza in esecuzione può essere utilizzato di nuovo da un'altra istanza dopo che è stato rimosso dala prima istanza.

Puoi specificare l'indirizzo IP di una sola istanza alla volta, al momento dell'avvio.

Puoi assegnare un indirizzo IP qualsiasi a un'istanza solo se l'indirizzo:

• È parte dell'intervallo di indirizzi IP della sottorete associata
• Non è riservato da Amazon a scopo di gestione della rete IP
• Non è assegnato a un'altra interfaccia

Sì. Puoi assegnare uno o più indirizzi IP privati secondari a un'interfaccia di rete elastica o a un'istanza EC2 in Amazon VPC. Il numero di indirizzi IP privati secondari che puoi assegnare dipende dal tipo di istanza. Consulta la Guida per l'utente EC2 per ulteriori informazioni sul numero di indirizzi IP privati secondari assegnabili per tipo di istanza.

Sì; gli indirizzi IP elastici, tuttavia, risulteranno raggiungibili solamente da Internet e non, quindi, dalla connessione VPN. Ogni indirizzo IP elastico deve essere associato a un indirizzo IP privato univoco sull'istanza. Gli indirizzi IP elastici dovrebbero essere usati solo su istanze in sottoreti configurate in modo che il loro traffico venga instradato direttamente verso Internet gateway. Gli indirizzi IP elastici non possono essere usati su istanze in sottoreti configurate per l'utilizzo di un gateway NAT o di un'istanza NAT con accesso a Internet. Questa regola si applica solo al protocollo IPv4. I cloud privati virtuali al momento non supportano indirizzi IP elastici per il protocollo IPv6.

La funzione Bring Your Own IP (BYOIP), ossia la possibilità di utilizzare il proprio IP, permette ai clienti di trasferire lo spazio esistente degli indirizzi IPv4 o IPv6 instradabili pubblicamente in AWS per utilizzarli con le proprie risorse AWS. L'intervallo di indirizzi IP continuerà a essere di proprietà del cliente. Inoltre, i clienti potranno creare indirizzi IP elastici dallo spazio IPv4 importato in AWS, utilizzandoli con istanze EC2, gateway NAT e Network Load Balancer. I clienti potranno inoltre associare un massimo di 5 CIDR ai propri VPC dallo spazio IPv6 importato in AWS. Continueranno comunque a disporre dell'accesso agli indirizzi IP forniti da Amazon e potranno scegliere di utilizzare gli indirizzi IP elastici creati con la funzione BYOIP, gli IP forniti da Amazon o entrambi.

Importare indirizzi IP esistenti in AWS può essere utile per diversi motivi:
Reputazione dell'IP: molti clienti considerano la reputazione dei propri indirizzi IP un asset strategico e desiderano utilizzarli in AWS con le proprie risorse. Ad esempio, clienti che operano servizi quali MTA di posta elettronica in uscita e dispongono di IP con reputazione elevata; ora potranno importare il proprio spazio degli indirizzi IP e conservare un'elevata efficacia del recapito.

Clienti di whitelist: BYOIP permette inoltre ai clienti di spostare workload che fanno affidamento su indirizzi IP whitelisting su AWS, senza necessità di ristabilire la whitelist con i nuvi indirizzi IP.

Dipendenze scritte nel codice: molti clienti dispongono di IP utilizzati nel codice dei dispositivi o hanno basato dipendenze architetturali sui loro indirizzi IP. La funzione BYOIP permette ai clienti di eseguire la migrazione in AWS senza problemi.

Normative e conformità: molti clienti devono utilizzare IP specifici a causa di normative o standard di conformità. Anche loro potranno trarre enormi vantaggi dall'uso della funzione BYOIP.

Policy della rete IPv6 in locale: molti clienti possono instradare esclusivamente il proprio IPv6 nella rete in locale. Questi clienti possono trarre vantaggio dalla funzione BYOIP perché permette loro di assegnare il proprio intervallo IPv6 al VPC e di scegliere l'instradamento alla rete in locale utilizzando Internet o Direct Connect.

Quando viene rilasciato un indirizzo IP elastico creato con la funzione BYOIP, esso torna a far parte del pool di indirizzi IP da cui era stato allocato.

Consulta la nostra per i dettagli sulla disponibilità del BYOIP.

Sì. È possibile utilizzare un prefisso BYOIP con un qualsiasi numero di cloud privati virtuali nello stesso account.

È possibile importare fino a cinque intervalli di indirizzi IP in un account.

La specifica massima di un prefisso IPv4 importabile con la funzione BYOIP è un prefisso IPv4 /24 e un prefisso IPv6 /56. Se intendi pubblicizzare il tuo prefisso IPv6 su Internet, la specifica massima del prefisso IPv6 è /48.

È possibile utilizzare i prefissi registrati ARIN, RIPE e APNIC.

Al momento non sono accettati prefissi riassegnati o riallocati. Gli intervalli IP devono essere di rete e in allocazione o assegnazione diretta.

Sì. È possibile farlo attraverso il de-provisioning del prefisso BYOIP dalla regione attuale e il provisioning nella nuova regione.

Amazon VPC IP Address Manager (IPAM) è un servizio gestito che facilita la pianificazione, il rilevamento e il monitoraggio degli indirizzi IP per i carichi di lavoro AWS. Tramite IPAM, è possibile organizzare con facilità gli indirizzi IP sulla base delle esigenze di instradamento e sicurezza nonché impostare semplici regole aziendali per amministrare le assegnazioni degli indirizzi IP. Inoltre, è possibile automatizzare l'assegnazione degli indirizzi IP ai VPC, eliminando la necessità di utilizzare applicazioni di pianificazione degli indirizzi IP sviluppate internamente o basate su fogli di calcolo, la cui manutenzione può essere complicata e dispendiosa in termini di tempo. IPAM fornisce una singola vista operativa che può essere utilizzata come unica fonte di attendibilità, consentendo di eseguire in modo rapido ed efficiente attività di routine di gestione degli indirizzi IP come rilevamento dell'utilizzo IP, risoluzione dei problemi e verifica.

Utilizzando IPAM, potrai rendere più efficiente la gestione degli indirizzi IP. I meccanismi esistenti basati su fogli di calcolo o su strumenti sviluppati internamente richiedono operazioni manuali e sono soggetti a errori. Con IPAM, ad esempio, puoi velocizzare la distribuzione delle applicazioni perché gli sviluppatori non dovranno più attendere che il team di amministrazione centrale allochi un indirizzo IP. Puoi anche rilevare gli indirizzi IP sovrapposti e risolverli prima che si verifichino interruzioni di rete. Inoltre, puoi impostare degli allarmi affinché IPAM ti informi se i pool di indirizzi sono prossimi all'esaurimento o se le risorse non sono conformi alle regole di allocazione impostate per un pool. Queste sono alcune delle tante ragioni per cui dovresti utilizzare IPAM.

AWS IPAM offre le seguenti funzionalità:
 

• Allocazione degli indirizzi IP per reti su larga scala: IPAM è in grado di automatizzare le allocazioni degli indirizzi IP su centinaia di account e VPC in base a regole aziendali configurabili.
   
• Monitoraggio dell'utilizzo IP in tutta la rete: IPAM può monitorare gli indirizzi IP e consente di ricevere avvisi se vengono rilevati problemi potenziali come l'esaurimento degli indirizzi IP, che può bloccare la crescita della rete, oppure la sovrapposizione di indirizzi, con conseguenti errori di instradamento.
   
• Risoluzione dei problemi di rete: IPAM contribuisce a identificare rapidamente se i problemi di connettività sono dovuti a errate configurazioni degli indirizzi IP o ad altre cause.
   
• Verifica degli indirizzi IP: IPAM mantiene automaticamente i dati di monitoraggio degli indirizzi IP per un massimo di tre anni. Puoi utilizzare questi dati storici per condurre analisi retrospettive e verifiche sulla rete.

Questi sono i componenti principali di IPAM:

• Un ambito è il container di livello più alto all'interno di IPAM. Un IPAM contiene due ambiti predefiniti. Ciascun ambito rappresenta lo spazio IP per una singola rete. L'ambito privato è destinato a tutto lo spazio privato. L'ambito pubblico è destinato a tutto lo spazio pubblico. Gli ambiti consentono di riutilizzare gli indirizzi IP su più reti non connesse senza causare conflitti o sovrapposizioni degli indirizzi. All'interno di un ambito puoi creare dei pool IPAM.
   
• Un pool è una raccolta di intervalli di indirizzi IP contigui (o CIDR). I pool IPAM consentono di organizzare gli indirizzi IP sulla base delle tue esigenze di instradamento e sicurezza. All'interno di un pool di alto livello puoi avere diversi pool. Ad esempio, se hai necessità di sicurezza e instradamento distinte per le applicazioni di sviluppo e di produzione, puoi creare un pool per ciascuna di queste fasi. All'interno dei pool IPAM, puoi allocare i CIDR alle risorse AWS.
• Un'allocazione è un'assegnazione CIDR da un pool IPAM a un'altra risorsa o pool IPAM. Quando crei un VPC e scegli un pool IPAM per il CIDR del VPC, il CIDR viene allocato dal CIDR in provisioning al pool IPAM. Puoi monitorare e gestire l'allocazione tramite IPAM.

Sì. IPAM supporta indirizzi BYOIPv4 e BYOIPv6. BYOIP è una funzionalità EC2 che consente di portare gli indirizzi IP di tua proprietà in AWS. Con IPAM, puoi allocare e condividere direttamente i blocchi di indirizzi IP tra account e organizzazioni differenti. I clienti BYOIP esistenti che utilizzano IPv4 possono migrare i propri pool su IPAM per semplificare la gestione degli IP.

Sì, Amazon fornisce blocchi CIDR IPv6 contigui per l'allocazione VPC. I blocchi CIDR contigui consentono di aggregare i CIDR sotto un'unica voce su costrutti di rete e sicurezza come liste di controllo degli accessi, tabelle di instradamento, gruppi di sicurezza e firewall. Puoi eseguire il provisioning di CIDR IPv6 di Amazon in un pool di ambito pubblico e utilizzare tutte le funzionalità IPAM per gestire e monitorare l'utilizzo degli IP. L'allocazione di questi blocchi CIDR inizia a incrementi di /52; su richiesta sono disponibili blocchi di dimensioni maggiori. Ad esempio, è possibile allocare il CIDR /52 da Amazon e utilizzare IPAM per condividerlo tra account diversi e creare VPC al loro interno.

No, attualmente i blocchi CIDR IPv6 contigui forniti da Amazon sono supportati soltanto in IPAM.

Puoi condividere i pool IPAM con altri account all'interno della tua organizzazione AWS tramite AWS Resource Access Manager (RAM). Inoltre, puoi condividere i pool IPAM con account esterni alla tua organizzazione AWS primaria. Ad esempio, questi account possono rappresentare un'altra linea di attività della tua azienda oppure un servizio gestito che un partner ospita per tuo conto in un'altra organizzazione AWS.

Sì. Puoi creare un instradamento di default per ogni sottorete. L'instradamento di default può indirizzare il traffico in uscita dal cloud privato virtuale tramite il gateway Internet, il gateway privato virtuale o il gateway NAT.

Per proteggere le istanze all'interno di Amazon VPC sono disponibili i gruppi di sicurezza di Amazon EC2. I gruppi di sicurezza in un cloud privato virtuale consentono di specificare il traffico ammesso in ingresso e in uscita per ogni istanza Amazon EC2. Il traffico che non viene espressamente consentito, sia in ingresso sia in uscita, viene automaticamente bloccato.

Oltre ai gruppi di sicurezza, per consentire o limitare il traffico in entrata e in uscita da ciascuna sottorete è possibile usare le liste di controllo degli accessi di rete (ACL).

In un cloud privato virtuale, i gruppi di sicurezza indicano il traffico che è consentito in ingresso e in uscita da un'istanza Amazon EC2. Le liste di controllo accessi di rete operano a livello di sottorete e analizzano il traffico in entrata e in uscita da una sottorete. Le liste possono essere usate per configurare regole che autorizzano e che bloccano il traffico. All'interno della stessa sottorete, le liste di controllo accessi di rete non possono essere usate per filtrare il traffico tra istanze. Infine, queste liste consentono un filtraggio stateless, mentre i gruppi di sicurezza eseguono un filtraggio stateful.

Il filtraggio di tipo stateful risale all'origine di una richiesta e può consentire l'inoltro automatico della risposta verso il computer da cui è stata inviata. Ad esempio, un filtro di tipo stateful che consente il traffico in entrata sulla porta TCP 80 di un server Web consentirà il traffico in risposta, di solito su un numero di porta elevato (ad esempio la porta TCP di destinazione 63, 912), attraverso il filtro di tipo stateful tra il client e il server Web. Il servizio di filtraggio conserva una tabella di stato che tiene nota dell'origine e della destinazione dei numeri di porta e degli indirizzi IP. Sul servizio di filtraggio è necessaria una sola regola, che consenta il traffico in entrata verso il server Web sulla porta TCP 80.

Il filtraggio di tipo stateless, invece, esamina esclusivamente l'indirizzo IP di origine o di destinazione e la porta di destinazione, senza tenere conto se il traffico proviene da una nuova richiesta o da una risposta a una richiesta. Nell'esempio illustrato in precedenza, sarebbe necessario implementare due regole nel servizio di filtraggio: una regola per consentire il traffico in entrata verso il server Web sulla porta TCP 80 e una per consentire il traffico in uscita dal server Web (porte TCP da 49.152 a 65.535).

Sì. Se è stato configurato un Internet gateway, il traffico di Amazon VPC destinato alle istanze Amazon EC2 esterne al cloud privato virtuale passerà attraverso Internet gateway ed entrerà poi nella rete pubblica di AWS per raggiungere l'istanza EC2. Se non è stato configurato un gateway Internet, oppure se l'istanza è in una sottorete configurata per l'instradamento attraverso il gateway privato virtuale, il traffico passerà attraverso la connessione VPN in uscita dal data center per rientrare nella rete pubblica di AWS.

Sì. Le istanze in una regione possono comunicare tra loro mediante connessioni VPC in peering tra più regioni, indirizzi IP pubblici, gateway NAT, istanze NAT, connessioni VPN e connessioni Direct Connect.

Sì. Le risorse in un cloud privato virtuale possono comunicare con Amazon S3 in diversi modi.  Puoi usare un endpoint VPC per S3, che fa sì che tutto il traffico rimanga nella rete di Amazon e consente di applicare policy di accesso aggiuntive al traffico di Amazon S3. Puoi usare un Internet gateway per abilitare l'accesso a Internet dal VPC, consentendo alle istanze in VPC di comunicare con Amazon S3. Puoi anche instradare tutto il traffico di Amazon S3 attraverso una connessione Direct Connect o VPN, facendolo uscire dal data center e rientrare nella rete AWS pubblica.

Sì. Per monitorare il traffico di rete nel tuo Amazon VPC, puoi utilizzare le funzionalità di traffic mirroring e i log di flusso di Amazon VPC.

I log di flusso sono una funzionalità che consente di acquisire informazioni sul traffico IP in entrata e in uscita dalle interfacce di rete nel tuo VPC. I dati dei log di flusso possono essere pubblicati su Amazon CloudWatch Logs o Amazon S3. È possibile monitorare i log di flusso del VPC per acquisire visibilità operativa delle dipendenze di rete e dei pattern di traffico, per rilevare anomalie e prevenire le perdite di dati, oppure per risolvere problemi di connettività e configurazione di rete. I metadati arricchiti dei log di flusso consentono di ottenere informazioni aggiuntive sul soggetto che ha avviato le connessioni TCP e sulle effettive sorgenti e destinazioni a livello di pacchetto del traffico che attraversa i livelli intermedi, come ad esempio il gateway NAT. Inoltre, è possibile archiviare i log di flusso per soddisfare determinati requisiti di conformità. Per ulteriori informazioni sui log di flusso di Amazon VPC, consulta la documentazione.

È possibile creare un log di flusso per un VPC, una sottorete o un'interfaccia di rete. Creando un log di flusso per una sottorete o un VPC, ogni interfaccia di rete in quella sottorete o in quel VPC viene monitorata. Durante la creazione di una registrazione dei log di flusso, è possibile scegliere i campi dei metadati che si desidera acquisire, l'intervallo massimo di aggregazione e la destinazione preferita del log. Si può anche scegliere di acquisire tutto il traffico o solo il traffico accettato o rifiutato. È possibile utilizzare strumenti come CloudWatch Log Insights o CloudWatch Contributor Insights per analizzare i log di flusso del VPC distribuiti in CloudWatch Logs. Puoi utilizzare strumenti come Amazon Athena o AWS QuickSight per interrogare e visualizzare i log di flusso del VPC distribuiti in Amazon S3. Puoi anche creare un'applicazione downstream personalizzata per analizzare i tuoi log o utilizzare soluzioni di partner come Splunk, Datadog, Sumo Logic, Cisco StealthWatch, Checkpoint CloudGuard, New Relic ecc.

Sì, puoi creare un log di flusso VPC per un gateway di transito o per un singolo collegamento del gateway di transito alla VPN. Con questa funzionalità, Transit Gateway può esportare informazioni dettagliate come IP di origine/destinazione, porte, protocollo, contatori del traffico, timestamp e vari metadati per i flussi di rete che attraversano tramite Transit Gateway. Per ulteriori informazioni sul supporto dei log di flusso per Transit Gateway, consulta la documentazione.

I dati dei log di flusso vengono raccolti al di fuori del percorso del tuo traffico di rete, quindi non influenzano il throughput o la latenza della rete. Puoi creare o eliminare i log di flusso senza alcun rischio di impatto sulle prestazioni della rete.

I costi di acquisizione e archiviazione dei dati per i vended log si applicano quando si pubblicano i log di flusso su CloudWatch Logs o su Amazon S3. Per ulteriori informazioni ed esempi, consulta la pagina dei prezzi di Amazon CloudWatch. Puoi anche tenere traccia degli addebiti dalla pubblicazione dei log di flusso usando i tag di allocazione dei costi.

La funzionalità di traffic mirroring di Amazon VPC permette di replicare in modo semplice il traffico di rete da e verso un’istanza di Amazon EC2 e inviarlo sui dispositivi di sicurezza e monitoraggio al di fuori della banda per casi d’uso quali l’ispezione dei contenuti, il monitoraggio delle minacce e la risoluzione dei problemi. Questi dispositivi possono essere implementati su una singola istanza EC2 o su una flotta di istanze in un sistema Network Load Balancer (NLB) con un listener UDP (User Datagram Protocol).

Il traffic mirroring supporta i pacchetti di rete catturati a livello dell'interfaccia di rete elastica (ENI) per le istanze EC2. Fai riferimento alla documentazione di mirroring del traffico per le istanze EC2 che supportano la funzionalità di mirroring del traffico Amazon VPC.

I clienti possono utilizzare strumenti open source o scegliere tra una vasta gamma di soluzioni di monitoraggio disponibili su AWS Marketplace. Il traffic mirroring permette ai clienti di trasmettere il traffico replicato a qualsiasi collettore o broker di pacchetti di rete o strumento di analisi, senza dover installare agenti specifici per fornitore.

I log di flusso di Amazon VPC permettono ai clienti di raccogliere, archiviare e analizzare i log di flusso della rete. Le informazioni catturate nei log di flusso includono dati sul traffico permesso e negato, la sorgente e la destinazione degli indirizzi IP, le porte, il numero di protocollo, il numero di pacchetti e byte, e un’azione (accettare o rifiutare). Puoi utilizzare questa funzionalità per risolvere i problemi di connettività e sicurezza, e assicurarti che le regole di accesso alla rete stiano funzionando come dovuto.

Il traffic mirroring di Amazon VPC, invece, fornisce una visione più accurata all’interno del traffico di rete, permettendoti di analizzare il contenuto effettivo del traffico, tra cui il payload, ed è mirato per casi d’utilizzo in cui hai bisogno di analizzare i pacchetti di rete per determinare la radice di un problema di prestazioni, applicare un processo di ingegneria inversa per un attacco di rete sofisticato, o rilevare e terminare violazioni interne o carichi di lavoro compromessi.

Amazon VPC è attualmente disponibile in diverse zone di disponibilità in tutte le regioni di Amazon EC2.

Sì. 

No. Una sottorete può occupare una sola zona di disponibilità.

Quando viene avviata un'istanza Amazon EC2, è necessario specificare la sottorete in cui avviarla. L'istanza verrà avviata nella zona di disponibilità associata alla sottorete scelta.

Quando crei una sottorete devi specificare la zona di disponibilità in cui collocarla. Quando usi lo strumento VPC Wizard, puoi selezionarla nella schermata di conferma. Quando usi l'API o l'interfaccia a riga di comando, puoi sceglierla durante la creazione della sottorete. Se non specifichi alcuna zona di disponibilità, viene selezionata l'opzione di default "No Preference" e la sottorete sarà creata in una zona di disponibilità qualsiasi della regione.

Se le istanze si trovano in sottoreti situate in zone di disponibilità differenti, verrà addebitato 0,01 USD per GB di dati trasferiti.

Sì. Il comando DescribeInstances() restituirà tutte le istanze Amazon EC2 in esecuzione. È possibile differenziare le istanze EC2-Classic da quelle EC2-VPC mediante una voce nel campo Subnet. Se viene elencato un ID sottorete, l'istanza sarà interna alla VPC.

Sì. Il comando DescribeVolumes() restituirà tutti i volumi EBS.

Per le istanze che richiedono un indirizzo IPv4, è possibile eseguire tutte le istanze Amazon EC2 che si desiderano dentro un VPC, ammesso che le dimensioni del cloud siano sufficienti e che a ogni istanza sia assegnato un indirizzo IPv4. Inizialmente, è possibile avviare solo 20 istanze Amazon EC2 alla volta, e le dimensioni massime di un VPC corrispondono a /16 (65.536 indirizzi IP). Se desideri aumentare questi limiti, compila questo modulo. Per le istanze solo IPv6, la dimensione del VPC di /56 ti permette di avviare un numero virtualmente illimitato di istanze Amazon EC2.

Puoi usare le AMI in Amazon VPC se sono registrate nella stessa regione del cloud privato virtuale. Ad esempio, puoi usare le AMI registrate in us-east-1 all'interno di un cloud privato virtuale situato nella regione us-east-1. Per ulteriori informazioni, consulta le domande frequenti sulla zona di disponibilità e la Regione Amazon EC2.

Sì, puoi usare gli snapshot Amazon EBS se si trovano nella stessa regione del cloud privato virtuale. Potrai trovare maggiori informazioni, nelle domande frequenti sulla zona di disponibilità e la Regione Amazon EC2.

Sì; tuttavia, un'istanza avviata in un cloud privato virtuale usando un'AMI basata su Amazon EBS conserverà lo stesso indirizzo IP quando interrotta e riavviata. Questa situazione è in contrasto con quanto accade con istanze simili avviate esternamente al cloud privato virtuale, che ricevono un nuovo indirizzo IP. Gli indirizzi IP delle istanze interrotte in una sottorete saranno considerati non disponibili.

Sì.

Sì. 

Sì. Le istanze cluster sono supportate in Amazon VPC, ma non tutti i tipi di istanza sono disponibili in tutte le regioni o zone di disponibilità.

Quando avvii un'istanza, le viene assegnato un nome host. Ci sono due possibilità: un nome basato sull'indirizzo IP o un nome basato sulla risorsa e questo parametro può essere configurato all'avvio dell'istanza. Il nome basato sull'indirizzo IP utilizza un modulo dell'indirizzo IPv4 privato mentre quello basato sulla risorsa utilizza un modulo dell'ID istanza.

Sì, puoi cambiare il nome host di un'istanza basato sull'IP con uno basato sulla risorsa e viceversa interrompendo l'istanza e quindi cambiando le opzioni di nome basate sulla risorsa.

Sì, il nome host dell'istanza può essere utilizzato come nome host DNS. Per le istanze lanciate in una sottorete solo IPv4 o dual-stack, il nome basato su IP risolve sempre all'indirizzo IPv4 privato sull'interfaccia di rete primaria dell'istanza e questo non può essere disattivato. Inoltre, il nome basato sulle risorse può essere configurato per risolvere all'indirizzo IPv4 privato sull'interfaccia di rete primaria, o al primo indirizzo GUA IPv6 sull'interfaccia di rete primaria, o entrambi. Per le istanze avviate in una sottorete solo IPv6, il nome basato sulle risorse sarà configurato per risolvere al primo indirizzo GUA IPv6 sull'interfaccia di rete primaria. 

Un cloud privato virtuale di default è una rete virtuale isolata logicamente nel cloud AWS, che viene automaticamente creata per il tuo account AWS la prima volta che effettui il provisioning di risorse Amazon EC2. Quando avvii un'istanze senza specificare il valore subnet-ID, l'istanza viene avviata nel cloud privato virtuale di default.

Quando avvii una risorsa in un cloud privato virtuale di default, puoi sfruttare le avanzate funzionalità di rete di Amazon VPC (EC2-VPC) con la facilità di utilizzo di Amazon EC2 (EC2-Classic). Potrai modificare in pochi istanti i membri dei gruppi di sicurezza e i relativi filtri in uscita, e sfruttare caratteristiche quali gli indirizzi IP multipli e le interfacce di rete multiple senza dover espressamente creare un cloud privato virtuale e avviare le istanze al suo interno.

Se il tuo account AWS è stato creato dopo il 18 marzo 2013, è possibile che tu sia in grado di avviare risorse in un VPC di default. Leggi questo annuncio sul forum per stabilire in quali regioni è possibile disporre di un VPC predefinito. Inoltre, gli account creati prima delle date elencate potranno utilizzare un VPC di default in qualsiasi regione in cui ciò sia consentito, a condizione che tu vi non abbia mai avviato istanze EC2 o effettuato il provisioning per risorse di Amazon Elastic Load Balancing, Amazon RDS, Amazon ElastiCache o Amazon Redshift.

No. Per avviare e gestire istanze EC2 e altre risorse AWS in un cloud privato virtuale di default puoi usare la Console di gestione AWS, l'interfaccia a riga di comando di Amazon EC2 o l'API AWS EC2. AWS creerà automaticamente un VPC di default, con una sottorete in ciascuna zona di disponibilità nella regione AWS. Il tuo cloud privato virtuale di default sarà connesso a un gateway Internet e le istanze riceveranno automaticamente indirizzi IP pubblici, come avviene per EC2-Classic.

Consulta Differenze tra EC2-Classic ed EC2-VPC nella Guida per l’utente di EC2.

I cloud privati virtuali di default sono collegati a Internet e tutte le istanze avviate nelle sue sottoreti di default ricevono automaticamente indirizzi IP pubblici. Se lo desideri, comunque, puoi aggiungere al tuo cloud una connessione VPN.

Sì. Per avviare un'istanza in cloud privati virtuali non di default è necessario specificare il valore subnet-ID al momento dell'avvio.

Sì. Per eseguire l'avvio in sottoreti non di default, è possibile scegliere la destinazione degli avvii usando la console oppure tramite l'opzione --subnet da interfaccia a riga di comando, API o kit SDK.

È possibile avere un solo VPC di default in ciascuna regione AWS in cui l'attributo Supported-Platforms è impostato su "EC2-VPC".

Viene creata una sottorete di default per ogni zona di disponibilità nel VPC di default.

No, al momento no.

No, al momento no.

Sì, un'istanza VPC di default può essere eliminata. Una volta completata l'operazione, è possibile creare una nuova istanza di default direttamente dalla console di VPC o dall'interfaccia a riga di comando. La nuova istanza VPC sarà quella predefinita all'interno della regione specificata. Questa operazione non consente il ripristino dell'istanza VPC precedentemente eliminata.

Sì, una sottorete di default può essere eliminata. Una volta eliminata, è possibile creare una nuova sottorete di default nella zona di disponibilità utilizzando l'interfaccia a riga di comando o SDK. La nuova sottorete di default sarà creata nella zona di disponibilità specificata. Questa operazione non consente il ripristino della sottorete precedentemente eliminata.

Il modo più semplice per ottenere un VPC di default è creare un nuovo account in una regione che ne permette l'utilizzo, oppure usare un account esistente in una regione che non hai mai utilizzato, a condizione che l'attributo Supported-Platforms per quell'account nella regione sia "EC2-VPC".

Sì; tuttavia possiamo configurare un account esistente per l'utilizzo di VPC di default solo se non hai risorse EC2-Classic per quell’account in quella regione. Inoltre, dovrai terminare tutte le risorse di Elastic Load Balancer, Amazon RDS, Amazon ElastiCache e Amazon Redshift non VPC di cui è stato eseguito il provisioning in quella regione. Una volta che il tuo account è configurato per l'utilizzo di un cloud privato virtuale, le risorse che avvierai in futuro, incluse le istanze avviate tramite Auto Scaling, saranno collocate in esso. Per richiedere la configurazione di un account esistente per l'utilizzo di un cloud privato virtuale, seleziona Account and Billing -> Service: Account -> Category: Convert EC2 Classic to VPC e inoltra una richiesta. Esamineremo la richiesta e i servizi AWS in uso e verificheremo la presenza di risorse EC2-Classic, inviando le istruzioni su come procedere.

Se il tuo account AWS dispone di un cloud privato virtuale di default, qualsiasi account IAM associato con il tuo account utilizzerà lo stesso cloud privato virtuale di default.

EC2-Classic è una rete flat che abbiamo avviato con EC2 nell'estate del 2006. Con EC2-Classic, le tue istanze vengono eseguite in un'unica rete flat che condividi con altri clienti. Nel corso del tempo, ispirati dalle esigenze in continua evoluzione dei nostri clienti, abbiamo avviato Amazon Virtual Private Cloud (VPC) nel 2009 per consentirti di eseguire istanze in un cloud privato virtuale logicamente isolato dal tuo account AWS. Oggi, mentre la maggior parte dei nostri clienti utilizza Amazon VPC, alcuni clienti utilizzano ancora EC2-Classic.

Ritireremo Amazon EC2-Classic il 15 agosto 2022 e abbiamo bisogno che tu migri tutte le istanze EC2 e altre risorse AWS in esecuzione su EC2-Classic ad Amazon VPC prima di questa data. La sezione seguente fornisce ulteriori informazioni sul ritiro della classe EC2, nonché strumenti e risorse per assisterti nella migrazione.

Sei interessato da questa modifica solo se hai abilitato EC2-Classic sul tuo account in una qualsiasi delle regioni AWS. Puoi usare la console o il comando description-account-attributes per verificare se EC2-Classic è abilitato per una Regione AWS; fai riferimento a questa documentazione per maggiori dettagli.

Se non disponi di risorse AWS attive in esecuzione su EC2-Classic in nessuna regione, ti chiediamo di disattivare EC2-Classic dal tuo account per quella regione. La disattivazione di EC2-Classic in una regione consente di avviare il VPC predefinito lì. Per farlo, passa al Centro supporto AWS all'indirizzo console.aws.amazon.com/support, scegli "Crea caso" e quindi "Account e supporto per la fatturazione", per "Tipo" scegli "Account", per "Categoria" scegli "Converti da EC2 Classic a VPC", inserisci gli altri dettagli come richiesto e scegli "Invia".

Disattiveremo automaticamente EC2-Classic dal tuo account il 30 ottobre 2021 per qualsiasi regione AWS in cui non disponi di risorse AWS (istanze EC2, database relazionale Amazon, AWS Elastic Beanstalk, Amazon Redshift, AWS Data Pipeline, Amazon EMR, AWS OpsWorks) su EC2-Classic dal 1° gennaio 2021.

D'altra parte, se disponi di risorse AWS in esecuzione su EC2-Classic, ti chiediamo di pianificare la loro migrazione ad Amazon VPC il prima possibile. Non potrai avviare istanze o servizi AWS sulla piattaforma EC2-Classic oltre il 15 agosto 2022. Eventuali carichi di lavoro o servizi in stato di esecuzione perderanno gradualmente l'accesso a tutti i servizi AWS su EC2-Classic man mano che verranno ritirati a partire dal 16 agosto 2022.

Puoi trovare le guide alla migrazione per le tue risorse AWS nella domanda successiva.

Amazon VPC ti offre il controllo completo sul tuo ambiente di rete virtuale su AWS, isolato logicamente dal tuo account AWS. Nell'ambiente EC2-Classic, i tuoi carichi di lavoro condividono un'unica rete flat con altri clienti. L'ambiente Amazon VPC offre molti altri vantaggi rispetto all'ambiente EC2-Classic, inclusa la possibilità di selezionare il proprio spazio di indirizzi IP, la configurazione di sottoreti pubbliche e private e la gestione di tabelle di routing e gateway di rete. Tutti i servizi e le istanze attualmente disponibili in EC2-Classic hanno servizi comparabili disponibili nell'ambiente Amazon VPC. Amazon VPC offre anche una generazione di istanze molto più ampia e di ultima generazione rispetto a EC2-Classic. Ulteriori informazioni su Amazon VPC sono disponibili a questo link.

Per aiutarti a migrare le tue risorse, abbiamo pubblicato playbook e soluzioni create che troverai di seguito. Per eseguire la migrazione, devi ricreare le tue risorse EC2-Classic nel tuo VPC. Innanzitutto, puoi utilizzare questo script per identificare tutte le risorse fornite in EC2-Classic in tutte le regioni in un account. Puoi quindi utilizzare la guida alla migrazione per le risorse AWS pertinenti di seguito:

• Istanze e gruppi di sicurezza
• Classic Load Balancer
• Amazon Relational Database Service
• AWS Elastic Beanstalk
• Amazon Redshift per la migrazione di cluster DC1 e per altri tipi di nodi
• AWS Data Pipeline 
• Amazon EMR 
• AWS OpsWorks

Oltre alle guide alla migrazione di cui sopra, offriamo anche una soluzione lift-and-shift (alza e sposta) altamente automatizzata, AWS Application Migration Service (AWS MGN), che semplifica, accelera e riduce i costi di migrazione delle applicazioni. Puoi trovare risorse pertinenti su AWS MGN qui:

• Introduzione a AWS Application Migration Service 
• Formazione tecnica su richiesta di AWS Application Migration Service
• Documentazione per approfondire le caratteristiche e le funzionalità di AWS Application Migration Service
• Video sull'architettura dei servizi e sull'architettura di rete

Per semplici migrazioni di singole istanze EC2 da EC2-Classic a VPC, oltre ad AWS MGN o alla Guida alla migrazione delle Istanze, puoi anche utilizzare il runbook "AWSSupport-MigrateEC2 ClassicToVPC" da "AWS Systems Manager > Automazione". Questo runbook automatizza i passaggi necessari per migrare un'istanza da EC2-Classic a VPC creando un'AMI dell'istanza in EC2-Classic, creando una nuova istanza dall'AMI in VPC e, facoltativamente, terminando l'istanza EC2-Classic.

In caso di domande o dubbi, puoi contattare il team di supporto AWS tramite il supporto AWS Premium.

Nota: se disponi di risorse AWS in esecuzione su EC2-Classic in più regioni AWS, ti consigliamo di disattivare EC2-Classic per ciascuna di tali regioni non appena hai migrato tutte le tue risorse a VPC in esse.

Intraprenderemo le seguenti due azioni prima della data di ritiro del 15 agosto 2022:

• Non emetteremo più istanze riservate (RI) di 3 anni e RI di 1 anno per l'ambiente EC2-Classic il 30 ottobre 2021. Le istanze riservate già in atto nell'ambiente EC2-Classic non saranno interessate in questo momento. Le istanze riservate che scadranno dopo il 15/08/2022 dovranno essere modificate per utilizzare l'ambiente Amazon VPC per il periodo rimanente del contratto di locazione. Per informazioni su come modificare le istanze riservate, visita la nostra documentazione.
• Il 15 agosto 2022, non consentiremo più la creazione di nuove istanze (Spot o on demand) o altri servizi AWS nell'ambiente EC2-Classic. Eventuali carichi di lavoro o servizi in stato di esecuzione perderanno gradualmente l'accesso a tutti i servizi AWS su EC2-Classic man mano che verranno ritirati a partire dal 16 agosto 2022.

Sì.

Le interfacce di rete possono essere collegate esclusivamente a istanze che si trovano nella stessa zona di disponibilità.

Le interfacce di rete possono essere collegate esclusivamente a istanze che si trovano nello stesso cloud privato virtuale.

Sì; tuttavia non si tratta di un caso d'uso ideale per usare più interfacce. Ti consigliamo di assegnare più indirizzi IP privati all'istanza, associando quindi indirizzi IP elastici agli IP privati secondo necessità.

È possibile collegare e scollegare interfacce secondarie (eth1-ethn) su un'istanza EC2, ma non è possibile scollegare l'interfaccia eth0.

Sì. È possibile creare connessioni in peering tra cloud privati virtuali in regioni differenti. La connessione peer VPC tra regioni è disponibile a livello globale in tutte le regioni commerciali (escluso la Cina).

Sì, se il proprietario dell'altro cloud privato virtuale accetta la tua richiesta di connessione peer.

Per la creazione di connessioni peer di cloud privati virtuali non viene addebitato alcun costo; tuttavia verrà fatturato il trasferimento di dati tra connessioni peer. Per informazioni sulle tariffe di trasferimento dei dati, consulta la relativa sezione nella pagina dei prezzi di EC2.

No. Le connessioni peer di cloud privati virtuali non necessitano di Internet gateway.

Il traffico tra istanze in cloud privati virtuali in peering è privato e isolato, come il traffico tra due istanze nello stesso cloud privato virtuale.

No. Una connessione peer può essere interrotta da una delle due parti in qualsiasi momento. In seguito all'interruzione, il traffico tra i due cloud privati virtuali viene bloccato.

No. La proprietà transitiva delle connessioni peer non è supportata.

Per creare una connessione peer tra cloud privati virtuali AWS impiega la sua infrastruttura; non impiega un gateway o una connessione VPN, né dipende da un singolo apparato hardware fisico. Non prevede alcun singolo punto di errore né colli di bottiglia.

Una connessione peer tra istanze VPC in regioni diverse opera avvalendosi della stessa tecnologia ridondante a scalabilità orizzontale ed elevata disponibilità su cui si basa VPC. Il traffico per queste connessioni passa dalla dorsale di AWS, che offre ridondanza di design e assegna la larghezza di banda in modo dinamico. Non esiste un singolo punto di errore nella comunicazione.

Se si verifica un errore su una connessione tra regioni diverse, il traffico non verrà inoltrato su Internet.

La larghezza di banda tra le istanze in cloud privati virtuali peer non è diversa da quella tra istanze all'interno dello stesso cloud privato virtuale. Nota:: un gruppo di posizionamento può coprire più VPC in peering, all'interno dei quali non sarà tuttavia disponibile la bisezione completa della larghezza di banda tra istanze. Scopri di più sui gruppi di posizionamento.

Il traffico viene crittografato utilizzando i moderni algoritmi AEAD (Authenticated Encryption with Associated Data). Accordo e gestione della chiave sono gestiti da AWS.

Di default, una query per un nome host pubblico di un'istanza in un cloud privato virtuale in peering in una regione differente viene risolta con un indirizzo IP pubblico. È possibile utilizzare il DNS privato di Route 53 per risolvere il nome con un indirizzo IP privato con connessioni peer tra istanze VPC in regioni diverse.

No. Non è possibile fare riferimento a gruppi di sicurezza su una connessione peer tra istanze VPC in regioni diverse.

Sì. Le connessioni peer tra istanze VPC in regioni diverse supportano IPv6.

No. Le connessioni peer tra istanze VPC in regioni diverse non possono essere usate con EC2-ClassicLink.

ClassicLink di Amazon Virtual Private Cloud (VPC) consente alle istanze EC2 nella piattaforma EC2-Classic di comunicare con le istanze in un cloud privato virtuale usando indirizzi IP privati. Per usare ClassicLink, attiva la funzione in un cloud privato virtuale nel tuo account e associa un gruppo di sicurezza al suo interno con un'istanza in EC2-Classic. Nelle comunicazioni tra le istanze in EC2-Classic e quelle nel cloud privato virtuale saranno applicate le regole del gruppo di sicurezza di quest'ultimo. 

Non sono previsti costi aggiuntivi per l'utilizzo di ClassicLink; tuttavia saranno applicate le tariffe di trasferimento dei dati tra diverse zone di disponibilità. Per ulteriori informazioni, consulta la pagina dei prezzi di EC2.

Per poterlo usare, è necessario configurare almeno un cloud privato virtuale per l'utilizzo di ClassicLink. Quindi devi associare un gruppo di sicurezza del cloud privato virtuale con un'istanza EC2-Classic. Questa istanza è così collegata al VPC e fa parte del gruppo di sicurezza selezionato nel VPC.  Un'istanza EC2-Classic non può essere collegata a più di un VPC alla volta.

No, l'istanza EC2-Classic non entra a far parte del cloud privato virtuale. Diventa membro del gruppo di sicurezza del cloud associato con essa. Nelle comunicazioni tra le istanze in EC2-Classic e le risorse nel cloud privato virtuale saranno applicate tutte le regole e i riferimenti al gruppo di sicurezza del cloud.

Il nome host DNS pubblico di EC2 non risolve l'indirizzo IP privato dell'istanza EC2-VPC quando riceve una query proveniente da un'istanza EC2-Classic, né viceversa.

Sì. ClassicLink non può essere abilitato per cloud privati virtuali con CIDR (Classless Inter-Domain Routing) nell'intervallo 10.0.0.0/8, ad eccezione di 10.0.0.0/16 e 10.1.0.0/16. Inoltre, ClassicLink non può essere abilitato per cloud privati virtuali con una voce nella tabella di routing che indirizza verso lo spazio CIDR 10.0.0.0/8 con un'impostazione di destinazione diversa da "local".

Il traffico proveniente da un'istanza EC2-Classic può essere instradato solo verso indirizzi IP privati all'interno del cloud privato virtuale. Non potrà essere instradato verso destinazioni esterne al cloud, inclusi gateway Internet, gateway virtuali o cloud privati virtuali peer.

ClassicLink non modifica in alcun modo il controllo degli accessi definito per un'istanza EC2-Classic tramite i gruppi di sicurezza esistenti nella piattaforma EC2-Classic.

La connessione ClassicLink viene interrotta quando l'istanza EC2-Classic viene arrestata e riavviata. L'istanza EC2-Classic dovrà pertanto essere nuovamente collegata al cloud privato virtuale. La connessione ClassicLink, tuttavia, rimane valida anche in seguito al riavvio dell'istanza.

ClassicLink non consente alle regole del gruppo di sicurezza di EC2-Classic di usare come riferimento i gruppi di sicurezza del cloud privato virtuale né viceversa.

AWS PrivateLink è una soluzione che permette di accedere ai servizi in hosting in AWS in modo scalabile e con elevata disponibilità mantenendo tutto il traffico di rete nell'ambito della rete AWS. I clienti che usano questa tecnologia possono accedere ai servizi compatibili con PrivateLink privatamente dal loro Amazon Virtual Private Cloud (VPC) o dal loro ambiente locale senza utilizzare IP pubblici e senza inviare traffico su Internet. I proprietari di servizi possono registrare i loro Network Load Balancer a PrivateLink e offrire i loro prodotti ad altri clienti AWS.

Gli utenti di un servizio dovranno creare endpoint VPC di tipo interfaccia per i servizi abilitati da PrivateLink. Questi endpoint saranno visualizzati come interfacce di rete elastiche (ENI, Elastic Network Interface) con indirizzi IP privati all'interno del cloud privato virtuale. Una volta creati gli endpoint, il traffico destinato agli indirizzi IP in questione sarà instradato in modo privato ai servizi AWS corrispondenti.

I proprietari di un servizio dovranno instradarlo in AWS PrivateLink; per farlo devono configurare un Network Load Balancer e creare un servizio PrivateLink che si registri ad esso. I clienti potranno stabilire endpoint all'interno del loro cloud privato virtuale per connettersi al servizio, previa inclusione del loro account in whitelist e ruoli di IAM.

Questa caratteristica supporta i seguenti servizi AWS: Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Kinesis Streams, Service Catalog, EC2 Systems Manager e Amazon SNS. Anche molte soluzioni SaaS supportano questa caratteristica. Visita Marketplace AWS per navigare tra i prodotti SaaS abilitati da AWS PrivateLink.

Sì. L'applicazione in locale può connettersi agli endpoint del servizio in Amazon VPC tramite AWS Direct Connect. Gli endpoint instraderanno automaticamente il traffico verso i servizi AWS basati su AWS PrivateLink.

Sì. Puoi usare la Console di gestione AWS per gestire oggetti Amazon VPC quali cloud privati virtuali, tabelle di routing, Internet gateway e connessioni VPN IPsec. Inoltre, è disponibile una procedura guidata per creare cloud privati virtuali.

Per ulteriori informazioni sui limiti VPC, consulta la guida per l'utente di Amazon VPC.

Sì. Per ulteriori informazioni sul Supporto AWS, fai clic qui.

ElasticFox non è più ufficialmente supportato per la gestione di Amazon VPC. Il supporto per Amazon VPC è disponibile tramite le API di AWS, gli strumenti a riga di comando, la Console di gestione AWS e una serie di utility di terze parti.