Domande frequenti su Amazon VPC

Amazon VPC consente di eseguire il provisioning di una sezione logicamente isolata del cloud di Amazon Web Services (AWS) dove puoi avviare risorse AWS in una rete virtuale da te definita. Hai il controllo completo sul tuo ambiente virtuale di rete, incluse la selezione degli intervalli di indirizzi IP, la creazione di sottoreti e la configurazione di tabelle di routing e di gateway di rete. Inoltre, potrai creare una connessione VPN hardware tra il tuo data center aziendale e la VPC per utilizzare il cloud AWS come estensione del data center aziendale.

Puoi personalizzare la configurazione di rete di Amazon VPC con estrema facilità. Ad esempio, puoi creare una sottorete pubblica per i server Web dotata di accesso a Internet e collocare sistemi back-end quali database o server di applicazioni in una sottorete privata senza accesso a Internet. Grazie ai vari livelli di sicurezza disponibili, inclusi i gruppi di sicurezza e le liste di controllo degli accessi di rete, è possibile controllare l'accesso alle istanze di Amazon EC2 in ciascuna sottorete.

Amazon VPC è composto da una serie di oggetti già noti ai clienti con reti esistenti:

• Un cloud privato virtuale: una rete virtuale isolata logicamente nel cloud AWS. Potrai scegliere manualmente gli intervalli dello spazio degli indirizzi IP del VPC.
• Sottorete: un segmento di un intervallo di indirizzi IP del VPC in cui collocare gruppi di risorse isolate.
• Gateway Internet: una connessione pubblica a Internet, lato Amazon VPC.
• Gateway NAT: un servizio gestito di Network Address Translation (NAT) ad elevata disponibilità per consentire l'accesso a Internet alle risorse in sottoreti private.
• Gateway virtuale privato: una connessione VPN, lato Amazon VPC.
• Connessione peer: una connessione peering consente di instradare il traffico attraverso indirizzi IP privati tra due VPC in peering.
• Endpoint VPC: permettono connessioni private ai servizi in hosting in AWS direttamente dal cloud privato virtuale, senza dover utilizzare un gateway Internet, una VPN, dei dispositivi Network Address Translation (NAT) o dei proxy firewall.
• Internet gateway per traffico solo in uscita: un gateway stateful che fornisce solo accesso in uscita per il traffico IPv6.

Le tue risorse AWS vengono automaticamente assegnate in un cloud privato virtuale di default pronto all'uso. Puoi scegliere di creare ulteriori VPC accedendo alla pagina di Amazon VPC della Console di gestione AWS e facendo clic sul pulsante "Start VPC Wizard".

Avrai a tua disposizione quattro opzioni di base per creare l'architettura di rete. Dopo aver selezionato un'opzione, puoi modificare le dimensioni e l'intervallo di indirizzi IP del cloud privato virtuale e delle relative sottoreti. Se selezioni un'opzione che prevede l'accesso a una VPN hardware, dovrai specificare l'indirizzo IP della VPN hardware nella tua rete. Puoi modificare il cloud privato virtuale aggiungendo o rimuovendo gateway e intervalli IP secondari oppure aggiungendo altre sottoreti agli intervalli IP.

Le quattro opzioni sono:

1. Un VPC con una sottorete pubblica singola, esclusivamente
2. Un VPC con sottoreti pubbliche e privati
3. Un VPC Amazon con sottoreti pubbliche e private e accesso a un VPN gestito da AWS
4. Un VPC Amazon con solo una sottorete privata e accesso a VPN sito-sito AWS

Gli endpoint VPC consentono di connettere in modo privato un cloud privato virtuale ai servizi in hosting in AWS senza utilizzare Internet gateway, dispositivi NAT, VPN o proxy firewall. Gli endpoint sono dispositivi virtuali con scalabilità orizzontale e disponibilità elevata che permettono la comunicazione tra le istanze in un cloud privato virtuale e i servizi AWS. Amazon VPC offre due diversi tipi di endpoint: gli endpoint di tipo gateway e gli endpoint di tipo interfaccia.

Gli endpoint di tipo gateway sono disponibili solo per i servizi AWS, ad esempio S3 e DynamoDB. Questi endpoint aggiungono un elemento alla tabella di routing selezionata e instradano il traffico ai servizi supportati tramite la rete privata di Amazon.

Gli endpoint di tipo interfaccia forniscono connettività privata ai servizi compatibili con PrivateLink, che siano servizi AWS, aziendali o soluzioni SaaS e supportano le connessioni su Direct Connect. In futuro, questo tipo di endpoint supporterà anche altre soluzioni AWS e SaaS. Consulta la pagina relativa ai prezzi di VPC per informazioni sulle tariffe degli endpoint di tipo interfaccia.

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 prodotto 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 Internet gateway 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 peering VPC)

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.

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) per i clienti o service-to-service. 

Puoi usare qualsiasi intervallo di indirizzi IPv4, inclusi gli indirizzi IP previsti nella RFC 1918 o quelli che è possibile instradare pubblicamente per l’intervallo CIDR principale. Per gli intervalli 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 intervalli 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 intervallo CIDR principale al momento della creazione del VPC; successivamente potrai aggiungere fino a quattro (4) intervalli 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 intervalli CIDR forniti da Amazon o IPv6 BYOIP al VPC.

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 intervalli CIDR sia IPv4 sia IPv6.

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 intervallo CIDR IPv6.

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.

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.

Consulta la nostra documentazione informativa sulla disponibilità del BYOIP.

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.

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).

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).

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.

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 costi di importazione 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.

Il mirroring del traffico 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 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 mirroring del traffico 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.

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.

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.

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

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.

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.

Le interfacce di rete possono essere collegate esclusivamente a istanze in VPC nello stesso account.

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.

Per creare una connessione peering VPC 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.

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.

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, Amazon SNS e AWS DataSync. Anche molte soluzioni SaaS supportano questa caratteristica. Visita AWS Marketplace per navigare tra i prodotti SaaS abilitati da AWS PrivateLink.

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.

Una funzionalità di sicurezza e conformità che fornisce un controllo centralizzato per monitorare e applicare la crittografia dei flussi di traffico all'interno e tra i VPC in una regione. Per ulteriori informazioni, leggi la documentazione qui.

Modalità monitor (per visibilità, valutazione e avvio della migrazione) e modalità di applicazione (per prevenire il traffico non crittografato).

Amministratori della sicurezza e architetti cloud, in particolare nei settori che richiedono la conformità a standard come HIPAA, FedRamp e PCI DSS.

Utilizzano sia la crittografia a livello di applicazione che le funzionalità di crittografia integrate dell'hardware di AWS Nitro System per garantire l'applicazione della crittografia.

La modalità monitor fornisce visibilità sullo stato di crittografia dei flussi di traffico, aiuta a identificare le risorse non conformi e compila i log dei flussi VPC con le informazioni sullo stato della crittografia. Risorse come Network Load Balancer, Application Load Balancer, Fargate Clusters e il piano di controllo EKS migreranno automaticamente e gradualmente verso un hardware che supporta nativamente la crittografia una volta attivata la modalità monitor.

Tramite:

• Log di flusso VPC con il campo dello stato della crittografia
• Dashboard della console
• Comando GetVpcResourcesBlockingEncryptionEnforcement

No, devi creare nuovi log di flusso aggiungendo manualmente il campo dello stato di crittografia. Si consiglia inoltre di aggiungere i campi del percorso del traffico e della direzione del flusso.

Una volta che un VPC è in modalità di applicazione, impedisce la creazione o il collegamento di risorse che consentono il traffico non crittografato all'interno del confine del VPC. Ti verrà impedito di eseguire istanze che non supportano la crittografia nitro nativa.

No, devi prima:

• abilitare la modalità monitor;
• identificare le risorse non conformi;
• modificare o creare esclusioni per le risorse non conformi;
• passare alla modalità di applicazione.

È necessario creare un'esclusione per quella risorsa dagli otto tipi di esclusione supportati. Altre risorse non supportate devono essere migrate dal VPC o eliminate prima di attivare la modalità di applicazione. Le risorse supportate dai controlli di applicazione devono essere migrate su istanze conformi alla crittografia prima di attivare la modalità di applicazione.

Completa la seguente procedura:

• Rivedi i log di flusso e la conformità delle risorse
• Pianifica le migrazioni delle risorse necessarie
• Configura le esclusioni richieste quando si passa alla modalità di applicazione

Sì, tranne nello scenario in cui il peering VPC è stabilito tra due VPC senza esclusioni. In questo caso, prima è necessario eliminare il peering del VPC tra i due VPC, poi passare alla modalità monitor.

Utilizza il comando GetVpcResourcesBlockingEncryptionEnforcement per identificare tutte le risorse che potrebbero bloccare l'applicazione. In alternativa, puoi utilizzare la console per trovare risorse non crittografate.

Sono supportate otto esclusioni:

• Gateway Internet
• Gateway NAT
• Gateway Internet solo in uscita
• Connessioni peering VPC a VPC con crittografia non applicata
• Gateway virtuale privato
• Funzioni Lambda
• VPC Lattice
• Elastic File System

0: non crittografato
1: crittografato con nitro
2: applicazione crittografata
3: crittografato con nitro e con applicazione
(-): controlli di crittografia sconosciuti/VPC disattivati

Per crittografare il traffico tra i VPC che hanno i controlli di crittografia abilitati, puoi utilizzare Peering VPC o Transit Gateway. Quando si utilizza Transit Gateway, è necessario attivare il supporto della crittografia in modo esplicito utilizzando la console o il comando modify-transit-gateway. Non sono previsti costi separati per l'attivazione della crittografia su Transit Gateway, ma sono previsti i costi standard dei controlli di crittografia VPC per tutti i VPC associati a Transit Gateway (a prescindere dall’attivazione dei controlli di crittografia su questi VPC).

Usa il comando “modify-transit-gateway” o abilitalo tramite la Console AWS. Devi abilitare esplicitamente il supporto della crittografia su un Transit Gateway per crittografare il traffico tra i tuoi VPC con i controlli di crittografia attivati.

L'attivazione della crittografia sul TGW esistente non interrompe i flussi di traffico esistenti e la migrazione degli allegati VPC verso corsie crittografate avverrà senza interruzioni e automaticamente. Puoi abilitare il supporto della crittografia su un Transit Gateway per crittografare il traffico tra i tuoi VPC. Il traffico tra due VPC in modalità di applicazione (senza esclusioni) è crittografato end-to-end tramite il TGW. La crittografia su Transit Gateway consente inoltre di connettere due VPC che si trovano nelle diverse modalità dei controlli di crittografia.

Dipende. Il traffico tra due VPC in modalità di applicazione (senza esclusioni) è crittografato end-to-end tramite il TGW. La crittografia su Transit Gateway consente inoltre di connettere due VPC che si trovano nelle diverse modalità dei controlli di crittografia. È consigliabile utilizzarlo quando si desidera applicare i controlli di crittografia in un VPC connesso a un VPC non crittografato. In uno scenario del genere, tutto il traffico all'interno del tuo VPC con crittografia applicata, incluso il traffico tra VPC, è crittografato. Il traffico inter-VPC è crittografato tra le risorse del VPC con crittografia applicata e il Transit Gateway. Inoltre, la crittografia dipende dalle risorse a cui è diretto il traffico nel VPC non applicato e non è garantito che sia crittografato (poiché il VPC non è in modalità di applicazione). Tutti i VPC devono trovarsi nella stessa regione.

Sì, il traffico rimarrà crittografato fino a quando non raggiungerà l'allegato TGW nel VPC senza crittografia. Il traffico rimane crittografato dall'origine fino all'allegato TGW nel VPC di destinazione, indipendentemente dallo stato di crittografia del VPC di destinazione.

Attivate la crittografia sul TGW mantenendo le connessioni esistenti: la transizione viene gestita automaticamente. L'attivazione della crittografia su TGW non interferisce con i flussi di traffico esistenti.

Sì, TGW supporta la migrazione incrementale gestendo il traffico crittografato e non crittografato durante la transizione.

No. Private Link con i controlli di crittografia VPC è supportato solo per i servizi AWS. Gli endpoint VPC per servizi non AWS non possono rimanere nei VPC in cui si desidera applicare la crittografia. Dovresti eliminare quegli endpoint prima di passare alla modalità di applicazione sul VPC. I VPC in esecuzione in modalità di applicazione possono essere collegati a Peering VPC o Transit Gateway per garantire la crittografia end-to-end.