**Contribuisci a migliorare questa pagina** Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Visualizzazione di requisiti di rete di Amazon EKS per VPC e sottoreti Durante la creazione di un cluster, in genere si specificano un [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html) e due sottoreti che si trovano in zone di disponibilità diverse. Questo argomento offre una panoramica dei requisiti e delle considerazioni specifiche di Amazon EKS per il VPC e le sottoreti utilizzate con il cluster. Se non si dispone di un VPC da utilizzare con Amazon EKS, si veda [Creazione di un Amazon VPC per il cluster Amazon EKS.](creating-a-vpc.md). Se stai creando un cluster locale o esteso su AWS Outposts, consulta [Creazione di VPC e sottoreti per i cluster Amazon EKS su AWS Outposts](eks-outposts-vpc-subnet-requirements.md) invece di questo argomento. Il contenuto di questo argomento si applica ai cluster Amazon EKS con nodi ibridi. Per ulteriori requisiti di rete per i nodi ibridi, consulta [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md). ## Considerazioni e requisiti relativi al VPC Durante la creazione di un cluster, il VPC specificato deve soddisfare i requisiti e le considerazioni seguenti: + Il VPC deve disporre di un numero sufficiente di indirizzi IP da mettere a disposizione per il cluster, i nodi e le altre risorse Kubernetes da creare. In caso contrario, è possibile provare ad aumentare il numero di indirizzi IP disponibili. È possibile farlo aggiornando la configurazione del cluster per modificare le sottoreti e i gruppi di sicurezza utilizzati dal cluster. È possibile eseguire l' Console di gestione AWS aggiornamento dalla versione più recente della AWS CLI e dalla `eksctl` versione `v0.164.0-rc.0` o successiva. AWS CloudFormation Potrebbe essere necessario eseguire questa operazione per fornire alle sottoreti più indirizzi IP disponibili per aggiornare in modo corretto una versione del cluster. **Importante** Tutte le sottoreti aggiunte devono appartenere allo stesso set fornito originariamente al momento della AZs creazione del cluster. Le nuove sottoreti devono soddisfare tutti gli altri requisiti, ad esempio devono disporre di sufficienti indirizzi IP. Supponiamo ad esempio che hai creato un cluster e specificato quattro sottoreti. Nell'ordine in cui le hai specificate, la prima sottorete si trova nella zona di disponibilità `us-west-2a`, la seconda e la terza si trovano nella zona di disponibilità `us-west-2b` e la quarta si trova nella zona di disponibilità `us-west-2c`. Se desideri modificare le sottoreti, devi fornire almeno una sottorete in ciascuna delle tre zone di disponibilità e le sottoreti devono trovarsi nello stesso VPC delle sottoreti originali. Se hai bisogno di più indirizzi IP rispetto ai blocchi CIDR nel VPC, puoi aggiungere altri blocchi CIDR [associando ulteriori blocchi di routing interdominio senza classi (CIDR)](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) al VPC. L'associazione di blocchi di CIDR privati (RFC 1918) e pubblici (non RFC 1918) può avvenire prima o dopo la creazione del cluster. È possibile aggiungere nodi che utilizzano il nuovo intervallo CIDR subito dopo averlo aggiunto. Tuttavia, poiché il piano di controllo riconosce il nuovo intervallo CIDR solo dopo il completamento della riconciliazione, il riconoscimento dell’intervallo CIDR associato a un VPC da parte del cluster può richiedere fino a un’ora. È quindi possibile eseguire i comandi `kubectl attach``kubectl cp`,`kubectl exec`,`kubectl logs`, e (questi `kubectl port-forward` comandi utilizzano il`kubelet API`) per nodi e pod nel nuovo blocco CIDR. Inoltre, se si dispone di pod che funzionano come backend webhook, devi attendere il completamento della riconciliazione del piano di controllo. + Evita le sovrapposizioni degli intervalli di indirizzi IP quando connetti il tuo cluster EKS ad altri VPCs tramite Transit Gateway, peering VPC o altre configurazioni di rete. I conflitti di CIDR si verificano quando il servizio CIDR del cluster EKS si sovrappone al CIDR di un VPC connesso. In questi scenari, gli indirizzi ServiceIP hanno la priorità sulle risorse VPCs connesse allo stesso indirizzo IP, sebbene il routing del traffico possa diventare imprevedibile e le applicazioni potrebbero non riuscire a connettersi alle risorse previste. Per evitare conflitti CIDR, assicurati che il tuo servizio EKS CIDR non si sovrapponga a nessun VPC connesso CIDRs e mantieni un registro centralizzato di tutte le assegnazioni CIDR. Se si riscontrano sovrapposizioni di CIDR, è possibile utilizzare un gateway di transito con un VPC di servizi condivisi. Per ulteriori informazioni, consulta [Isolato VPCs con servizi condivisi](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-isolated-shared.html) e [modelli di conservazione degli indirizzi IP routabili VPC di Amazon EKS in una](https://aws.amazon.com/blogs/containers/eks-vpc-routable-ip-address-conservation) rete ibrida. Inoltre, consulta la VPCs sezione Comunicazione trasversale della pagina [Considerazioni su VPC e sottorete](https://docs.aws.amazon.com/eks/latest/best-practices/subnets.html) nella Guida alle best practice di EKS. + Se vuoi che Kubernetes assegni indirizzi `IPv6` a pod e servizi, associa un intervallo CIDR `IPv6` al tuo VPC. Per ulteriori informazioni, consulta [Associare un blocco IPv6 CIDR al tuo VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr) nella Amazon VPC User Guide. Non è possibile utilizzare indirizzi `IPv6` con pod e servizi in esecuzione su nodi ibridi e non è possibile utilizzare nodi ibridi con cluster configurati con la famiglia di indirizzi IP `IPv6`. + Il VPC deve supportare il nome host `DNS` e la risoluzione `DNS`. In caso contrario, i nodi non possono registrarsi al cluster. Per ulteriori informazioni, consulta [Attributi DNS nel VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) nella Guida per l'utente di Amazon VPC. + Il VPC potrebbe richiedere l'utilizzo di endpoint VPC. AWS PrivateLink Per ulteriori informazioni, consulta [Considerazioni e requisiti relativi alle sottoreti](#network-requirements-subnets). Se il cluster è stato creato con Kubernetes `1.14` o versioni precedenti, Amazon EKS aggiunge il tag seguente al VPC: | Chiave | Valore | | --- | --- | | `kubernetes.io/cluster/my-cluster ` | `owned` | Questo tag è stato utilizzato solo da Amazon EKS, per cui è possibile rimuoverlo senza influire sui servizi. Non è necessario con la versione `1.15` del cluster o con versioni successive. ## Considerazioni e requisiti relativi alle sottoreti Durante la creazione di un cluster, Amazon EKS crea da 2 a 4 [interfacce di rete elastiche](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) nelle sottoreti specificate. Queste interfacce di rete consentono la comunicazione tra il cluster e il VPC. Queste interfacce di rete abilitano anche le funzionalità di Kubernetes che utilizzano. `kubelet API` Le connessioni all'`kubelet`API vengono utilizzate nei comandi`kubectl attach`,, `kubectl cp``kubectl exec`, `kubectl logs` e. `kubectl port-forward` Ogni interfaccia di rete creata da Amazon EKS ha il testo `Amazon EKS cluster-name ` nella sua descrizione. Amazon EKS può creare le proprie interfacce di rete in qualsiasi sottorete specificata al momento della creazione di un cluster. Puoi modificare le sottoreti in cui Amazon EKS crea le interfacce di rete dopo la creazione del cluster. Quando aggiorni la versione Kubernetes di un cluster, Amazon EKS elimina le interfacce di rete originali e ne crea di nuove Queste interfacce di rete potrebbero essere create all'interno delle stesse sottoreti o in sottoreti diverse rispetto alle interfacce di rete originali. Per verificare in quali sottoreti vengono create le interfacce di rete, puoi limitare il numero di sottoreti specificate a due quando crei un cluster o aggiornare le sottoreti dopo aver creato il cluster. ### Requisiti relativi alla sottorete per i cluster Le [sottoreti](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types) specificate al momento della creazione o dell'aggiornamento di un cluster devono soddisfare i seguenti requisiti: + Ciascuna sottorete deve disporre di almeno sei indirizzi IP  per l'uso da parte di Amazon EKS. Tuttavia, consigliamo di utilizzare almeno 16 indirizzi IP. + Le due sottoreti devono trovarsi in almeno due zone di disponibilità diverse. + Le sottoreti non possono risiedere in AWS Outposts o Wavelength. AWS Tuttavia, se sono presenti nel VPC, puoi implementare nodi autogestiti e risorse Kubernetes per questi tipi di sottoreti. Per ulteriori informazioni sulla gestione dei nodi, consulta [Gestione autonoma dei nodi con nodi autogestiti](worker.md). + Le sottoreti possono essere pubbliche o private. Tuttavia, si consiglia di specificare sottoreti private, se possibile. Una sottorete pubblica è una sottorete con una tabella di routing che include un instradamento a un [gateway Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html), mentre la sottorete privata non comprende tale instradamento. + Le sottoreti non possono risiedere nelle seguenti zone di disponibilità: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/network-reqs.html) ### IP address family usage by component La tabella seguente contiene la famiglia di indirizzi IP utilizzata da ciascun componente di Amazon EKS. È possibile utilizzare una network address translation (NAT) o un altro sistema di compatibilità per connettersi a questi componenti da indirizzi IP di origine in famiglie con il valore “No” per una voce di tabella. La funzionalità può variare a seconda dell’impostazione della famiglia IP (`ipFamily`) del cluster. Questa impostazione modifica il tipo di indirizzi IP utilizzati per l’intervallo CIDR assegnato da Kubernetes ai servizi. Un cluster con il valore di impostazione di IPv4 viene definito *IPv4 cluster*, mentre un cluster con il valore di impostazione di IPv6 viene definito *IPv6 cluster*. | Componente | IPv4 indirizzi | IPv6 indirizzi | Indirizzi dual stack | | --- | --- | --- | --- | | Endpoint pubblico dell’API EKS | Sì1,3 | Sì1,3 | Sì1,3 | | Endpoint VPC di API EKS | Sì | No | No | | Endpoint pubblico di API di autenticazione EKS (EKS Pod Identity) | Sì1 | Sì1 | Sì1 | | Endpoint VPC di API di autenticazione EKS (EKS Pod Identity) | Sì1 | Sì1 | Sì1 | | `IPv4` Endpoint pubblico del cluster Kubernetes2 | Sì | No | No | | `IPv4` Endpoint privato del cluster Kubernetes2 | Sì | No | No | | `IPv6` Endpoint pubblico del cluster Kubernetes2 | Sì1,4 | Sì1,4 | Sì4 | | `IPv6` Endpoint privato del cluster Kubernetes2 | Sì1,4 | Sì1,4 | Sì4 | | Sottoreti del cluster Kubernetes | Sì2 | No | Sì2 | | Indirizzi IP primari del nodo | Sì2 | No | Sì2 | | Intervallo CIDR del cluster per gli indirizzi IP del servizio | Sì2 | Sì2 | No | | Indirizzi IP del pod da CNI di VPC | Sì2 | Sì2 | No | | Emittente IRSA OIDC URLs | Sì1,3 | Sì1,3 | Sì1,3 | **Nota** 1 L’endpoint è dual-stack con gli indirizzi sia `IPv4` che `IPv6`. Le applicazioni esterne AWS, i nodi del cluster e i pod all'interno del cluster possono raggiungere questo endpoint tramite l'uno o l'altro. `IPv4` `IPv6` 2 Si sceglie tra un cluster `IPv4` e un cluster `IPv6` nell’impostazione della famiglia IP (`ipFamily`) del cluster quando se ne crea uno e questa impostazione non può essere modificata. È invece necessario scegliere un’impostazione diversa quando si crea un altro cluster e si migrano i carichi di lavoro. 3 L’endpoint dual-stack è stato introdotto nell’agosto 2024. *Per utilizzare gli endpoint dual-stack con la AWS CLI, consulta la configurazione degli endpoint [Dual-stack e FIPS nella and](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) Tools Reference Guide. AWS SDKs * Di seguito sono elencati i nuovi endpoint: **endpoint pubblico dell’API EKS** `eks.region.api.aws` **Emittente IRSA OIDC URLs** `oidc-eks.region.api.aws` 4 L’endpoint del cluster dual-stack è stato introdotto nell’ottobre 2024. EKS crea il seguente endpoint per i nuovi cluster creati dopo questa data e selezionati `IPv6` nell’impostazione della famiglia IP (IpFamily) del cluster: **Endpoint del cluster public/private EKS** `eks-cluster.region.api.aws` ### Requisiti relativi alla sottorete per i nodi È possibile implementare nodi e risorse Kubernetes nelle stesse sottoreti specificate al momento della creazione del cluster. Tuttavia, non è necessario. di tali risorse può avvenire anche in sottoreti non specificate precedentemente. L’implementazione di nodi in sottoreti diverse non comporta la creazione di interfacce di rete cluster in tali sottoreti da parte di Amazon EKS. Qualsiasi sottorete in cui si implementano nodi e risorse Kubernetes deve soddisfare i requisiti seguenti: + Le sottoreti devono mettere a disposizione un numero sufficiente di indirizzi IP per implementare tutti i nodi e le risorse Kubernetes. + Se si desidera che Kubernetes assegni indirizzi `IPv6` a pod e servizi, è necessario disporre di un intervallo CIDR `IPv6` e un intervallo CIDR `IPv4` associati alla sottorete. Per ulteriori informazioni, consulta [Associare un blocco IPv6 CIDR alla sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-associate-ipv6-cidr) nella Amazon VPC User Guide. Le tabelle di instradamento associate alle sottoreti devono includere instradamenti a indirizzi `IPv4` e `IPv6`. Per maggiori informazioni, consulta [Routes](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-table-routes) (Instradamenti) nella Guida dell'utente di Amazon VPC. Ai pod viene assegnato solo un indirizzo `IPv6`, mentre alle interfacce di rete create da Amazon EKS per il cluster e ai nodi vengono assegnati un indirizzo `IPv4` e uno `IPv6`. + Se è necessario garantire ai pod un accesso in entrata da Internet, assicurarsi di disporre di almeno una sottorete pubblica con un numero sufficiente di indirizzi IP disponibili su cui implementare i bilanciatori di carico e gli ingressi. È possibile implementare i load balancer nelle sottoreti pubbliche. I bilanciatori di carico possono bilanciare il carico sui pod di sottoreti private o pubbliche. Consigliamo di implementare i nodi su sottoreti private, se possibile. + Se si prevede di implementare i nodi in una sottorete pubblica, quest'ultima deve essere configurata per assegnare automaticamente indirizzi `IPv4` pubblici o indirizzi `IPv6`. Se si implementano nodi in una sottorete privata a cui è associato un blocco CIDR `IPv6`, anche questa sottorete deve essere configurata per assegnare automaticamente indirizzi `IPv6`. Se hai utilizzato il AWS CloudFormation modello fornito da Amazon EKS per distribuire il tuo VPC dopo il 26 marzo 2020, questa impostazione è abilitata. Se hai utilizzato i modelli per implementare il VPC prima di tale data o utilizzi un VPC personale, devi abilitare questa impostazione manualmente. Per il modello, consulta [Creazione di un Amazon VPC per il cluster Amazon EKS.](creating-a-vpc.md). Per ulteriori informazioni, consulta [Modificare l'attributo di IPv4 indirizzamento pubblico per la sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-public-ip) e [Modificare l'attributo di IPv6 indirizzamento per la sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-ipv6) nella Amazon [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/) User Guide. + Se la sottorete in cui distribuisci un nodo è una sottorete privata e la relativa tabella di routing non include un percorso verso un [dispositivo NAT (Network Address Translation) ()](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat.html) o un [gateway di sola uscita (`IPv4`)`IPv6`, aggiungi endpoint](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) VPC utilizzando al tuo VPC. AWS PrivateLink Gli endpoint VPC sono necessari per tutti i AWS servizi con cui i nodi e i pod devono comunicare. Alcuni esempi includono Amazon ECR, Elastic Load Balancing, CloudWatch Amazon AWS , Security Token Service e Amazon Simple Storage Service (Amazon S3). L'endpoint deve includere la sottorete in cui si trovano i nodi. Non tutti i AWS servizi supportano gli endpoint VPC. Per ulteriori informazioni, consulta [Cos'è? AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) e [AWS servizi che si integrano con AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html). Per un elenco di altri requisiti Amazon EKS, consulta [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md). + Se si desidera implementare i load balancer in una sottorete, quest'ultima deve presentare il tag seguente: + Sottoreti private [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/network-reqs.html) + Sottoreti pubbliche [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/network-reqs.html) In passato, quando si creava un cluster Kubernetes che è la versione `1.18` e precedenti, Amazon EKS aggiungeva il seguente tag a tutte le sottoreti specificate. | Chiave | Valore | | --- | --- | | `kubernetes.io/cluster/my-cluster ` | `shared` | Adesso, se crei un nuovo cluster Kubernetes, Amazon EKS non aggiunge alcun tag alle sottoreti. Se il tag era applicato a sottoreti utilizzate da un cluster che in precedenza era una versione precedente a `1.19`, il tag non veniva rimosso automaticamente dalle sottoreti quando il cluster veniva aggiornato a una versione più recente. La versione `2.1.1` o precedente del AWS Load Balancer Controller richiede questo tag. Se si utilizza una versione più recente di Load Balancer Controller, è possibile rimuovere il tag senza interrompere i servizi. Per ulteriori informazioni sul controller, consulta [Indirizza il traffico Internet con AWS Load Balancer Controller](aws-load-balancer-controller.md). Se hai distribuito un VPC `eksctl` utilizzando o uno qualsiasi dei modelli AWS CloudFormation VPC di Amazon EKS, si applica quanto segue: + **In data 26 marzo 2020 o successiva**. Gli indirizzi `IPv4` pubblici vengono assegnati automaticamente dalle sottoreti pubbliche ai nuovi nodi implementati nelle sottoreti pubbliche. + **Prima del 26 marzo 2020**: gli indirizzi `IPv4` pubblici non vengono assegnati automaticamente dalle sottoreti pubbliche ai nuovi nodi implementati nelle sottoreti pubbliche. Questa modifica influisce sui nuovi gruppi di nodi implementati nelle sottoreti pubbliche nei modi seguenti: + ** [Gruppi di nodi gestiti](create-managed-node-group.md) **: se il gruppo di nodi viene implementato in una sottorete pubblica in data 22 aprile 2020 o successiva, la sottorete pubblica deve disporre dell’assegnazione automatica degli indirizzi IP pubblici abilitati. Per ulteriori informazioni, consulta [Modifica dell'attributo di IPv4 indirizzamento pubblico per la sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). + **Gruppi di nodi autogestiti [Linux](launch-workers.md), [Windows](launch-windows-workers.md) o [Arm](eks-optimized-ami.md#arm-ami)**: se il gruppo di nodi viene implementato in una sottorete pubblica in data 26 marzo 2020 o successiva, la sottorete pubblica deve disporre dell’assegnazione automatica degli indirizzi IP pubblici abilitati. Altrimenti, i nodi devono essere avviati con un indirizzo IP pubblico. Per ulteriori informazioni, vedere [Modifica dell'attributo di IPv4 indirizzamento pubblico per la sottorete o Assegnazione di un indirizzo](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) [pubblico IPv4 ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#vpc-public-ip) durante l'avvio dell'istanza. ## Considerazioni e requisiti relativi alle sottoreti condivisi Puoi utilizzare la *condivisione VPC* per condividere sottoreti con altri AWS account all'interno delle stesse Organizzazioni. AWS È possibile creare cluster Amazon EKS in sottoreti condivise, tenendo a mente le seguenti considerazioni: + Il proprietario della sottorete VPC deve condividere una sottorete con un account partecipante prima che tale account possa creare un cluster Amazon EKS al suo interno. + Non è possibile avviare le risorse utilizzando il gruppo di sicurezza predefinito per il VPC, in quanto questo appartiene al proprietario. Inoltre, i partecipanti non possono avviare le risorse utilizzando i gruppi di sicurezza di proprietà di altri partecipanti o del proprietario. + In una sottorete condivisa, il partecipante e il proprietario controllano separatamente i gruppi di sicurezza all'interno di ciascun account. Il proprietario della sottorete può visualizzare i gruppi di sicurezza che sono stati creati dai partecipanti, ma non può eseguire operazioni sugli stessi. Se il proprietario della sottorete desidera rimuovere o modificare questi gruppi di sicurezza, è il partecipante che ha creato il gruppo di sicurezza che deve eseguire l'operazione. + Se un cluster viene creato da un partecipante, valgono le seguenti considerazioni: + Il ruolo IAM del cluster e i ruoli IAM del nodo devono essere creati in quell'account. Per ulteriori informazioni, consultare [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md) e [Ruolo IAM del nodo Amazon EKS](create-node-role.md). + Tutti i nodi devono essere creati dallo stesso partecipante, inclusi i gruppi di nodi gestiti. + Il proprietario del VPC condiviso non può visualizzare, aggiornare o eliminare un cluster creato da un partecipante nella sottorete condivisa. Ciò si aggiunge alle risorse VPC alle quali ogni account ha un accesso diverso. Per ulteriori informazioni, consulta la sezione [Responsabilità e autorizzazioni per proprietari e partecipanti](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) nella *Guida per l'utente di Amazon VPC*. + Se si utilizza la funzionalità *rete personalizzata* del plugin CNI di Amazon VPC, è necessario utilizzare le mappature degli ID delle zone di disponibilità elencate nell’account del proprietario per creare ciascun `ENIConfig`. Per ulteriori informazioni, consulta [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md). Per ulteriori informazioni sulla condivisione delle sottoreti VPC, consulta la pagina [Condivisione del VPC con altri account](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) nella *Guida per l'utente di Amazon VPC*.