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

Uso di un cluster database in un VPC

Il cluster database deve essere all'interno di un cloud privato virtuale (VPC). Un VPC è una rete virtuale logicamente isolata dalle altre reti virtuali nel cloud. AWS Amazon VPC ti consente di avviare AWS risorse, come un cluster di istanze Amazon DB un'istanza Amazon EC2, in un VPC. Il VPC può essere un VPC predefinito fornito con l'account o uno creato da te. Tutti i VPC sono associati al tuo account. AWS

Il VPC predefinito ha tre sottoreti che è possibile usare per isolare le risorse all'interno del VPC. Il VPC predefinito ha anche un gateway Internet che può essere usato per fornire l'accesso alle risorse all'interno del VPC dall'esterno del VPC.

Per un elenco di scenari relativi ai cluster database Amazon Aurora in un VPC , consulta Scenari per accedere a un cluster database in un VPC.

Nei seguenti tutorial puoi imparare a creare un VPC da usare per uno scenario Amazon Aurora comune:

Uso di un cluster database in un VPC

Ecco alcuni consigli per l'uso di un cluster database in un VPC:

Controllo della crittografia VPC

I controlli di crittografia VPC ti consentono di applicare la crittografia in transito per tutto il traffico di rete all'interno dei tuoi VPC. Utilizza il controllo della crittografia per soddisfare i requisiti di conformità normativa assicurando che solo l'hardware in grado di crittografare Nitro-based possa essere fornito nei VPC designati. Il controllo della crittografia rileva inoltre i problemi di compatibilità al momento della richiesta dell'API anziché durante il provisioning. I carichi di lavoro esistenti continuano a funzionare e vengono bloccate solo le nuove richieste incompatibili.

Imposta i controlli di crittografia VPC impostando la modalità di controllo VPC su:

Per verificare la modalità di controllo corrente per il tuo VPC, usa il comando Console di gestione AWS o DescribeVpcsCLI o API.

Se il tuo VPC applica la crittografia, puoi eseguire il provisioning solo di che supportano la crittografia in transito in quel VPC. Per ulteriori informazioni, consultare Tipi di classi di istanza database. Per informazioni sulle istanze Nitro, consulta Istanze costruite sul sistema AWS Nitro nella Guida per l'utente di Amazon EC2.

Aurora ServerlessPer MySQL e PostreSQL, il controllo della crittografia richiede la versione 3 o successiva della piattaforma.

Utilizzo di gruppi di sottoreti database

Le sottoreti sono segmenti di un intervallo di indirizzi IP di un VPC che si designa per raggruppare le risorse in base alle esigenze operative e di sicurezza. Un gruppo di sottoreti DB è una raccolta di sottoreti (generalmente private) creata in un VPC e che è possibile indicare per i cluster database. Utilizzando un gruppo di sottoreti DB, è possibile specificare un particolare VPC durante la creazione di cluster di istanze utilizzando AWS CLI l'API o RDS. Se utilizzi la console, puoi scegliere il VPC e i gruppi di sottorete che desideri usare.

Ogni gruppo di sottoreti database deve avere almeno due zone di disponibilità in una determinata Regione AWS. Quando si crea un cluster database in un VPC, è necessario selezionare anche un gruppo di sottoreti DB. Dal gruppo di sottoreti DB, Amazon Aurora sceglie una sottorete e un indirizzo IP all'interno di essa da associare all'istanza database primaria nel cluster database. Il database utilizza la zona di disponibilità che contiene la sottorete. Aurora Amazon assegna sempre un indirizzo IP da una sottorete con spazio libero per gli indirizzi IP.

Le sottoreti di un gruppo di sottoreti DB sono pubbliche o private. Le sottoreti sono pubbliche o private, a seconda della configurazione impostata per gli elenchi di controllo dell'accesso alla rete (ACL) e le tabelle di routing. Affinché un cluster database possa essere accessibile a livello pubblico, tutte le sottoreti nel gruppo di sottoreti database devono essere pubbliche. Se una sottorete associata a un cluster database accessibile pubblicamente cambia da pubblica a privata, ciò può avere ripercussioni sulla disponibilità del cluster database.

Per creare un gruppo di sottoreti DB che supporti la modalità dual-stack, assicurati che a ogni sottorete aggiunta al gruppo sia associata un blocco CIDR Internet Protocol versione 6 (IPv6). Per ulteriori informazioni, consulta Assegnazione di indirizzi IP in Amazon Aurora e Migrazione a IPv6 nella Guida per l'utente di Amazon VPC.

Quando Amazon Aurora crea un cluster database in un VPC, assegna un'interfaccia di rete al cluster database usando un indirizzo IP dal gruppo di sottoreti del database. Tuttavia, consigliamo vivamente di usare il nome del sistema dei nomi di dominio (DNS) per collegare il cluster database, perché l'indirizzo IP sottostante varia durante un failover.

Sottoreti condivise

Puoi creare un cluster database in un VPC condiviso.

Alcune considerazioni da tenere presente durante l'utilizzo di VPC condivisi:

Assegnazione di indirizzi IP in Amazon Aurora

Gli indirizzi IP permettono alle risorse nel VPC di comunicare tra loro e con le risorse su Internet. Amazon Aurora supporta entrambi i protocolli di indirizzamento, IPv4 e IPv6. Per impostazione di default, Amazon Aurora e Amazon VPC utilizzano il protocollo di indirizzamento IPv4. Non puoi disattivare questo comportamento. Quando crei un VPC, assicurati di specificare un blocco CIDR IPv4 (un intervallo di indirizzi IPv4 privati). Puoi scegliere di assegnare un blocco CIDR IPv6 al VPC e alle sottoreti e di assegnare gli indirizzi IPv6 di tale blocco a cluster database presenti nella sottorete.

Il supporto del protocollo IPv6 espande il numero di indirizzi IP supportati. L’utilizzo del protocollo IPv6 consente di disporre di un numero sufficiente di indirizzi per adeguarsi alla futura espansione di Internet. Le risorse RDS nuove ed esistenti possono utilizzare indirizzi IPv4 e IPv6 all'interno del VPC. La configurazione, la protezione e la traduzione del traffico di rete tra i due protocolli utilizzati in diverse parti di un’applicazione può causare sovraccarico operativo. Puoi standardizzare il protocollo IPv6 per le risorse Amazon RDS per semplificare la configurazione di rete.

Indirizzi IPv4

Quando crei un VPC, devi specificare un intervallo di indirizzi IPv4 per il VPC sotto forma di un blocco (CIDR), ad esempio 10.0.0.0/16. Un gruppo di sottoreti DB definisce l'intervallo di indirizzi IP in questo blocco CIDR che può essere usato da cluster database. Questi indirizzi IP possono essere privati o pubblici.

Un indirizzo IPv4 privato è un indirizzo IP non raggiungibile tramite Internet. Puoi utilizzare indirizzi IPv4 privati per la comunicazione tra cluster database e altre risorse, ad esempio istanze Amazon EC2, nello stesso VPC. Ogni cluster database dispone di un indirizzo IP privato per la comunicazione nel VPC.

Un indirizzo IP pubblico è un indirizzo IPv4 raggiungibile tramite Internet. Puoi utilizzare gli indirizzi pubblici per la comunicazione tra cluster database e risorse su Internet, ad esempio un client SQL. Puoi controllare se cluster database ricevono un indirizzo IP pubblico.

Amazon RDS utilizza indirizzi Public Elastic IPv4 dal pool di indirizzi IPv4 pubblico di EC2 per istanze di database accessibili al pubblico. Questi indirizzi IP sono visibili nel tuo AWS account quando usi la describe-addresses CLI, l'API o visualizzi la sezione Elastic IP (EIP) nel. Console di gestione AWS Ogni indirizzo RDS-managed IP è contrassegnato da un service_managed attributo impostato su. "rds"

Sebbene questi IP siano visibili nel tuo account, rimangono completamente gestiti da Amazon RDS e non possono essere modificati o rilasciati. Amazon RDS rilascia nuovamente gli IP nel pool di indirizzi IPv4 pubblico quando non sono più in uso.

CloudTrail registra le chiamate API relative all'EIP di RDS, ad esempio. AllocateAddress Queste chiamate API vengono richiamate dal Service Principal. rds.amazonaws.com

Per un tutorial che mostra come creare un VPC solo con indirizzi IPv4 privati da usare con uno scenario Amazon Aurora comune, consulta Tutorial: Creazione di un Amazon VPC da utilizzare con un cluster database (solo IPv4).

Indirizzi IPv6

Puoi anche scegliere di associare un blocco CIDR IPv6 al VPC e alle sottoreti e di assegnare gli indirizzi IPv6 del blocco alle risorse presenti nel VPC. Ogni indirizzo IPv6 è univoco a livello globale.

Il blocco CIDR IPv6 per il VPC è assegnato automaticamente dal pool di indirizzi IPv6 di Amazon. Non è possibile scegliere l'intervallo in modo autonomo.

Quando ti connetti a un indirizzo IPv6, assicurati che siano soddisfatte le seguenti condizioni:

Per ulteriori informazioni su IPv6, consulta l'argomento relativo all'assegnazione di indirizzi IP nella Guida per l'utente di Amazon VPC.

Dual-stack modalità

Un cluster di DB viene eseguito in modalità dual-stack quando può comunicare tramite entrambi i protocolli di indirizzamento IPv4 e IPv6. Le risorse possono quindi comunicare con il cluster di DB utilizzando IPv4, IPv6 o entrambi i protocolli. Le istanze DB private in modalità dual-stack dispongono di endpoint IPv6 che RDS limita al solo accesso VPC, garantendo che gli endpoint IPv6 rimangano privati. Le istanze DB pubbliche in modalità dual-stack forniscono endpoint IPv4 e IPv6 a cui è possibile accedere da Internet.

Per un tutorial che mostra come creare un VPC con indirizzi IPv4 e IP6 da usare con uno scenario Amazon Aurora comune, consulta Tutorial: Creazione di un VPC per l'utilizzo con un cluster database (modalità dual-stack).

Dual-stack modalità e sottoreti DB

Per utilizzare la modalità dual-stack, assicurati che ogni sottorete nel gruppo di sottoreti database associato a cluster database sia associata a un blocco CIDR IPv6. Per soddisfare questo requisito, puoi creare un nuovo gruppo di sottoreti database o modificare un gruppo di sottoreti database esistente. Quando cluster database sono in modalità dual-stack, i client possono connettersi normalmente. Assicurati che i firewall di sicurezza client e i gruppi di sicurezza delle istanze database RDS siano configurati in modo accurato per consentire il traffico su IPv6. Per connettersi, i client utilizzano l'endpoint dell'istanza principale del cluster database. Le applicazioni client possono specificare il protocollo preferito per la connessione a un database. In modalità dual-stack, il cluster database rileva il protocollo di rete preferito dal client (IPv4 o IPv6) e utilizza tale protocollo per la connessione.

Se un gruppo di sottoreti database smette di supportare la modalità dual-stack a causa dell'eliminazione della sottorete o dell'annullamento dell'associazione con il blocco CIDR, si può verificare una situazione di stato di rete incompatibile per le istanze database associate al gruppo di sottoreti database. Inoltre, non puoi utilizzare il gruppo di sottoreti database quando crei un nuovo cluster database in modalità dual-stack.

Per determinare se un gruppo di sottorete DB supporta la modalità dual-stack utilizzando la Console di gestione AWS, visualizza il Tipo di rete nella pagina dei dettagli del gruppo di sottorete DB. Per determinare se un sottogruppo di database supporta la modalità dual-stack utilizzando, esegui il comando describe-db-subnet-groups e visualizza nell' AWS CLI output. SupportedNetworkTypes

Le repliche di lettura vengono trattate come istanze database indipendenti e possono avere un tipo di rete diverso dall'istanza database principale. Se si modifica il tipo di rete dell'istanza database principale di una replica di lettura, tale modifica non interessa la replica di lettura. Quando si ripristina un'istanza database, è possibile ripristinarla su qualsiasi tipo di rete supportato.

Utilizzo di istanze database in modalità dual-stack

Quando crei o modifichi cluster database, puoi specificare la modalità dual-stack per consentire alle risorse di comunicare con il cluster su IPv4, IPv6 o entrambi.

Quando si utilizza Console di gestione AWS per creare o modificare un'istanza DB, è possibile specificare la modalità dual-stack nella sezione Tipo di rete. L'immagine seguente mostra la sezione Network type (Tipo di rete) nella console.

Quando utilizzi la AWS CLI per creare o modificare un cluster di DB, imposta l'--network-typeopzione per DUAL utilizzare la modalità dual-stack. Quando usi l'API RDS per creare o modificare un cluster database, per utilizzare la modalità dual-stack imposta il parametro NetworkType su DUAL. Quando modifichi il tipo di rete di un'istanza database, è possibile che si verifichi un periodo di inattività. Se la modalità dual-stack non è supportata dalla versione del motore del database o dal gruppo di sottoreti database in uso, viene restituito l'errore NetworkTypeNotSupported.

Ulteriori informazioni sulla creazione di un cluster di database sono disponibili in Creazione di un cluster database Amazon Aurora. Per ulteriori informazioni sulla modifica di un cluster di database, consultare Modifica di un cluster database Amazon Aurora.

Per determinare se un cluster database è in modalità dual-stack utilizzando la console, visualizza l'opzione Network type (Tipo di rete) nella scheda Connectivity & security (Connettività e sicurezza) per il cluster database in questione.

Modifica dei cluster di DB per utilizzare la modalità dual-stack

È possibile modificare un cluster di DB per utilizzare la modalità dual-stack. A tale scopo, devi modificare il tipo di rete del cluster database. La modifica potrebbe comportare tempi di inattività.

Ti consigliamo di modificare il tipo di rete dei cluster Amazon Aurora durante una finestra di manutenzione. L'impostazione predefinita del tipo di rete delle nuove istanze sulla modalità dual stack non è al momento supportata. È possibile impostare il tipo di rete manualmente utilizzando il comando modify-db-cluster.

Prima di modificare un cluster database per utilizzare la modalità dual-stack, assicurati che il gruppo di sottoreti DB supporti la modalità dual-stack. Se il gruppo di sottoreti DB associato al cluster database non supporta la modalità dual-stack, specifica un gruppo di sottoreti database diverso che supporta tale modalità quando modifichi il cluster database. La modifica del gruppo di sottoreti di database di un cluster di database può causare tempi di inattività.

Se si modifica il gruppo di sottoreti di database di un cluster di database prima di modificare il cluster di database per l'utilizzo della modalità Dual stack, assicurati che il gruppo di sottoreti di database sia valido per il cluster di database prima e dopo la modifica.

Ti consigliamo di eseguire l'API modify-db-cluster specificando solo il parametro --network-type con valore DUAL per modificare la rete di un cluster Amazon Aurora impostando la modalità dual stack. L’aggiunta di altri parametri al parametro --network-type nella stessa chiamata API potrebbe causare tempi di inattività.

Se non riesci a connetterti al cluster database dopo la modifica, assicurati che i firewall di sicurezza e le tabelle di routing client e database siano configurati in modo accurato per consentire il traffico verso il database sulla rete selezionata (IPv4 o IPv6). Potrebbe anche essere necessario modificare i parametri del sistema operativo, le librerie o i driver per connettersi mediante un indirizzo IPv6.

Disponibilità di cluster database di rete dual-stack

Dual-stack i cluster DB di rete sono disponibili in tutti gli ambienti ad eccezione dei seguenti: Regioni AWS

Le seguenti versioni del motore del database supportano i cluster di database di rete dual-stack:

Limitazioni per cluster database di rete dual-stack

Le seguenti limitazioni si applicano ai cluster database di rete dual-stack:

Nascondere cluster database in un VPC da Internet

Uno scenario Amazon Aurora comune è quello di avere un VPC in cui disponi di un’istanza Amazon EC2 con un’applicazione web pubblica e un cluster di database con un database che non è pubblicamente accessibile. Puoi ad esempio creare un VPC che ha una sottorete pubblica e una sottorete privata. Le istanze EC2 che fungono da server web possono essere implementate nella sottorete pubblica. L'implementazione di cluster database viene invece eseguita nella sottorete privata. In tale implementazione, solo i server Web hanno accesso ai cluster database. Per un'illustrazione di questo scenario, consulta Un cluster di database in un VPC a cui accede un’istanza EC2 nello stesso VPC.

Quando si avvia un cluster database all'interno di un VPC, il cluster database dispone di un indirizzo IP privato per il traffico all'interno del VPC. Questo indirizzo IP privato non è accessibile pubblicamente. Puoi utilizzare l'opzione Public access (Accesso pubblico) per indicare se il cluster database dispone anche di un indirizzo IP pubblico oltre all'indirizzo IP privato. Se il cluster database è definito come accessibile pubblicamente, il relativo endpoint DNS utilizza l'indirizzo IP privato dall'interno del VPC. Utilizza invece l'indirizzo IP pubblico dall'esterno del VPC. L'accesso al cluster database è in ultima analisi controllato dal gruppo di sicurezza in uso. Questo accesso pubblico non è consentito se il gruppo di sicurezza assegnato al cluster database non include regole in entrata che lo consentono. Per un cluster database che deve essere accessibile pubblicamente, le sottoreti nel relativo gruppo di sottoreti DB devono disporre di un gateway Internet. Per ulteriori informazioni, consulta Impossibile connettersi all'istanza database di Amazon RDS

Puoi modificare un cluster database per attivare o disattivare l'accessibilità pubblica modificando l'opzione Public access (Accesso pubblico). Nella figura seguente viene illustrata l'opzione Public access (Accesso pubblico) nella sezione Additional connectivity configuration (Configurazioni di connettività aggiuntiva) . Per impostare l'opzione, apri la sezione Additional connectivity configuration (Configurazioni di connettività aggiuntiva) nella sezione Connectivity (Connettività) .

Per informazioni sulla modifica di un'istanza database per impostare l'opzione Public access (Accesso pubblico), consulta Modifica di un'istanza database in un cluster database.

Creazione di un cluster database in un VPC

Le procedure seguenti aiutano a creare un cluster database in un VPC. Per utilizzare il VPC predefinito, puoi iniziare con il passaggio 2 e utilizzare il VPC e il gruppo di sottoreti DB creati automaticamente. Se desideri creare un VPC aggiuntivo, puoi creare un nuovo VPC.

Segui questa procedura per creare un'istanza database in un VPC:

Fase 1. Creazione di un VPC

Crea un VPC con sottoreti in almeno due zone di disponibilità. Usi queste sottoreti quando crei un gruppo di sottoreti database. Se disponi di un VPC di default, viene creata automaticamente una sottorete in ciascuna zona di disponibilità nella Regione AWS.

Per ulteriori informazioni, consulta Creazione di un VPC con sottoreti pubbliche e private oppure Creazione di un VPC nella Guida per l'utente di Amazon VPC..

Fase 2: creazione di un gruppo di sottoreti database

Un gruppo di sottoreti DB è una raccolta di sottoreti (generalmente private) creata per un VPC e che è possibile definire per i cluster database. Un gruppo di sottoreti DB consente di specificare un particolare VPC quando si creano cluster di istanze utilizzando AWS CLI l'API o RDS. Se utilizzi la console, puoi scegliere il VPC e le sottoreti che desideri usare. Ogni gruppo di sottoreti database deve avere almeno una sottorete in almeno due zone di disponibilità nella Regione AWS. Come best practice, ogni gruppo di sottoreti database deve disporre di almeno una sottorete per ogni zona di disponibilità nella Regione AWS.

Per un cluster database che deve essere accessibile pubblicamente, le sottoreti nel gruppo di sottoreti database devono disporre di un gateway Internet. Per ulteriori informazioni sui gateway Internet, consulta Eseguire la connessione a Internet utilizzando un gateway Internet nella Guida per l'utente di Amazon VPC.

Quando crei un cluster database in un VPC, puoi selezionare un gruppo di sottoreti DB. Amazon Aurora sceglie una sottorete e un indirizzo IP al suo interno da associare al cluster database. Se non esistono gruppi di sottoreti DB, Amazon Aurora crea un gruppo di sottoreti predefinito quando crei un cluster database. Amazon Aurora crea e associa un'interfaccia di rete elastica al cluster database con tale indirizzo IP. Il cluster database utilizza la zona di disponibilità contenente la sottorete.

In questo passaggio, si crea un gruppo di sottoreti database e si aggiungono le sottoreti create per il VPC.

Fase 3: creazione di un gruppo di sicurezza VPC

Prima di creare un cluster database, devi creare un gruppo di sicurezza VPC da associare tale cluster database. Se non crei un gruppo di sicurezza VPC, puoi utilizzare il gruppo di sicurezza predefinito quando crei un cluster database. Per istruzioni su come creare un gruppo di sicurezza per il cluster database, consulta Creazione di un gruppo di sicurezza VPC per un cluster database privato oppure Controlla il traffico verso le risorse utilizzando gruppi di sicurezza nella Guida per l'utente di Amazon VPC.

Passaggio 4: creazione di un'istanza database nel VPC

In questo passaggio, si crea un cluster database e si utilizza il nome VPC, il gruppo di sottoreti DB e il gruppo di sicurezza VPC creato nel passaggio precedente.

Per informazioni dettagliate su come creare un cluster di database, consulta Creazione di un cluster database Amazon Aurora.

Quando richiesto nella sezione Connectivity (Connettività), inserisci il nome VPC, il gruppo di sottoreti DB e il gruppo di sicurezza VPC.