Domande frequenti su Amazon RDS

Un'istanza database può essere considerata come un ambiente di database nel cloud con le risorse di calcolo e di archiviazione specificate dall'utente. È possibile creare ed eliminare delle istanze database, definire e perfezionare gli attributi di infrastruttura delle istanze, controllare l'accesso e la sicurezza tramite la Console di gestione AWS, le API di Amazon RDS e gli strumenti dell'interfaccia della riga di comando di AWS. È possibile eseguire una o più istanze DB e ogni istanza può supportare uno o più database o schemi di database, a seconda del tipo di motore.

Creare istanze DB è semplice, utilizzando la Console di gestione AWS, le API di Amazon RDS, o un'interfaccia della riga di comando di AWS. Per avviare un'istanza DB utilizzando la Console di gestione AWS, fai clic su "RDS", quindi sul pulsante "Avvia istanza DB" nella scheda Istanze. Scegli quindi i parametri dell'istanza DB, specificandone motore di database e versione, modello di licenza, tipo di istanza, tipo e volume di archiviazione e credenziali dell'utente master.

È anche possibile modificare la policy di conservazione del backup dell'istanza DB, la finestra di backup preferita e la finestra di manutenzione programmata. In alternativa, puoi creare la tua istanza database utilizzando l'API CreateDBInstance o il comando create-db-instance.

Una volta che l'istanza database è disponibile, puoi recuperarne l'endpoint attraverso la descrizione dell'istanza database nella Console di gestione AWS, oppure utilizzando l'API DescribeDBInstance o il comando describe-db-instances. Usando questo endpoint, potrai costruire la stringa di connessione necessaria per connetterti direttamente alla tua istanza DB utilizzando lo strumento di database o il linguaggio di programmazione preferito. Per consentire richieste di rete all'istanza DB in esecuzione, dovrai autorizzare l'accesso. Per informazioni dettagliate su come costruire la stringa di connessione e iniziare, consulta la nostra Guida alle operazioni di base.

Di default, i clienti possono avere fino a un totale di 40 istanze DB in Amazon RDS. Di queste 40, fino a 10 possono essere istanze database di RDS per Oracle o SQL Server con il modello "Licenza inclusa". Tutte e 40 possono essere utilizzate per Amazon Aurora, RDS per PostgreSQL, RDS per MySQL, RDS per MariaDB e RDS per Oracle secondo il modello Bring Your Own Licence (BYOL). RDS per SQL Server, tuttavia, ha un limite di 100 database per singola istanza database. Per ulteriori informazioni, consulta la Guida per l'utente di Amazon RDS per SQL Server.

• RDS per Amazon Aurora: nessun limite imposto dal software
• RDS per MySQL: nessun limite imposto dal software
• RDS per MariaDB: nessun limite imposto dal software
• RDS per Oracle: un database per ogni istanza; nessun limite imposto dal software al numero di schemi per ogni database
• RDS per SQL Server: fino a 100 database per ogni istanza
• RDS per PostgreSQL: nessun limite imposto dal software
• RDS per Db2: fino a 1 database per istanza

Di seguito sono riportati alcuni modi per importare dati in Amazon RDS:

• MySQL: utility mysqldump o mysqlimport
• Oracle: Data Pump, import/export o SQL Loader
• SQL Server: procedura guidata di import/export, file di backup completi (.bak) o Bulk Copy Program (BCP)
• PostgreSQL: pg_dump

Per maggiori informazioni sull'importazione e l'esportazione dei dati, consulta la Guida all'importazione dei dati per MySQL, la Guida all'importazione dei dati per Oracle, la Guida all'importazione dei dati per SQL Server, la Guida all'importazione dei dati per PostgreSQL oppure la Guida all'importazione dei dati per Db2.

Inoltre, AWS Database Migration Service può aiutarti a migrare database in AWS in modo sicuro.

La finestra di manutenzione di Amazon RDS offre l'opportunità di controllare i periodi in cui l'istanza database viene modificata, ad esempio in caso di aggiornamento della versione dei moduli di gestione di database, e, se richieste o necessarie, vengono applicate le patch software. Se è programmato un evento di manutenzione per una determinata settimana, questo verrà avviato nella finestra di manutenzione indicata.

Gli eventi di manutenzione che richiedono ad Amazon RDS di mettere offline la tua istanza DB sono le operazioni di ridimensionamento della capacità di calcolo (che generalmente durano solo pochi minuti), gli aggiornamenti delle versioni dei moduli di gestione di database e l’applicazione di patch software. Le operazioni di patch software necessarie vengono programmate automaticamente solo per le patch correlate alla sicurezza e alla durabilità. Queste operazioni di patch vengono eseguite di rado (generalmente poche volte all'anno) e raramente richiedono un tempo considerevole nella finestra di manutenzione.

Se non specifichi una finestra di manutenzione settimanale preferita durante la creazione dell'istanza database, verrà assegnato un valore predefinito di 30 minuti. Se desideri modificare i tempi in cui viene eseguita la manutenzione, puoi farlo modificando l'istanza database nella Console di gestione AWS, l'API ModifyDBInstance o il comando modify-db-instance. Ciascuna istanza database può avere finestre di manutenzione preferite differenti, se lo desideri.

L'esecuzione di un'istanza DB come un’implementazione Multi-AZ può ridurre ulteriormente l'impatto di un evento di manutenzione. Per ulteriori informazioni sulle operazioni di manutenzione, consulta la Guida per l'utente di Amazon RDS.

Per i database di produzione, ti consigliamo di abilitare il monitoraggio avanzato, che fornisce l'accesso a oltre 50 metriche relative a CPU, memoria, file system e I/O su disco. Queste caratteristiche possono essere abilitate nelle singole istanze e puoi deciderne la granularità (fino a 1 secondo). Alti livelli di utilizzo della CPU possono ridurre le prestazioni delle query e in questo caso ti consigliamo di modificare la classe dell'istanza DB. Per maggiori informazioni sul monitoraggio delle istanze database, consulta la Guida per l'utente di Amazon RDS.

Se usi RDS per MySQL o MariaDB, puoi accedere ai registri delle query lente per il database e verificare se ci sono query SQL a esecuzione lenta e, in caso affermativo, verificare le caratteristiche prestazionali di ciascuna. Puoi impostare il parametro di database "slow_query_log" e interrogare la tabella mysql.slow_log per esaminare le query SQL a esecuzione lenta. Per maggiori informazioni, consulta la Guida per l'utente di Amazon RDS.

Se usi RDS per Oracle, puoi utilizzare i dati dei trace file di Oracle per individuare le query lente. Per maggiori informazioni su come accedere ai dati dei trace file, consulta la Guida per l'utente di Amazon RDS. 

Se usi RDS per SQL Server, puoi utilizzare i dati dei trace file di SQL Server lato client per individuare le query lente. Per ulteriori informazioni su come accedere ai dati dei trace file lato server consulta la Guida per l'utente di Amazon RDS.

Per l'elenco delle versioni di motori di database supportati, fai riferimento alla documentazione per ciascun motore:

• Amazon Aurora
• Amazon RDS per PostgreSQL
• Amazon RDS per MySQL
• Amazon RDS for MariaDB
• Amazon RDS per SQL Server
• Amazon RDS per Oracle
• Amazon RDS per Db2

Per le specifiche di numerazione delle versioni, consulta la pagina delle domande frequenti per ciascun motore di database Amazon RDS:

• Amazon RDS per MySQL
• Amazon RDS for MariaDB
• Amazon RDS per PostgreSQL
• Amazon RDS per Oracle
• Amazon RDS per SQL Server
• Amazon Aurora
• Amazon RDS per Db2

Man mano, Amazon RDS aggiunge supporto alle nuove versioni "principali" e "secondarie" del motore di database. Il numero di nuove versioni supportate può variare in base alla frequenza e al contenuto delle versioni e delle patch rilasciate dal fornitore o dall'organizzazione di sviluppo del motore, oltre che agli esiti di un'approfondita valutazione di tali versioni e patch da parte del nostro team di tecnici dei database. Tuttavia, come indicazione generale, abbiamo l'obiettivo di supportare le nuove versioni dei motori entro 5 mesi dalla loro disponibilità generale.

Al momento della creazione di una nuova istanza database, è possibile specificare una qualsiasi delle versioni supportate (principale e secondaria) tramite l'operazione Avvia istanza database nella Console di gestione AWS o l'API CreateDBInstance. Va ricordato che non tutte le versioni di motori di database sono disponibili in tutte le regioni AWS.

Amazon RDS si impegna a mantenere aggiornata la tua istanza database fornendo le versioni più recenti dei motori di database supportati. Al momento del rilascio di una nuova versione di un motore di database da parte del fornitore o dell'organizzazione di sviluppo, viene accuratamente testata dal nostro team di tecnici dei database prima di renderla disponibile in Amazon RDS.

Ti consigliamo di mantenere aggiornata la tua istanza database alla versione secondaria più attuale, dal momento che contiene le ultime correzioni in termini di sicurezza e funzionalità. A differenza degli aggiornamenti delle versioni principali, quelli delle versioni secondarie includono solo modifiche del database retrocompatibili con le precedenti versioni secondarie (della stessa versione principale) del motore di database. 

Se una nuova versione secondaria non contiene correzioni a beneficio dei clienti RDS, possiamo scegliere di non renderla disponibile in Amazon RDS. Poco dopo il rilascio di una nuova versione secondaria in Amazon RDS, la imposteremo come versione secondaria di preferenza per le nuove istanze DB. 

Per aggiornare manualmente un'istanza database a una versione di motore supportata, utilizza il comando Modify DB Instance nella Console di gestione AWS o l'API ModifyDBInstance e configura il parametro DB Engine Version alla versione desiderata. Per impostazione predefinita, l'aggiornamento sarà applicato durante la finestra di manutenzione successiva. È inoltre possibile scegliere di effettuare subito l'aggiornamento, selezionando l'opzione Apply Immediately nell'API della console.

Qualora scopriamo che una nuova versione secondaria del motore contiene correzioni di errori significative rispetto a una versione secondaria rilasciata in precedenza, programmeremo aggiornamenti automatici per le istanze DB che presentino l'impostazione Auto Minor Version Upgrade su "Yes". L'installazione di tali aggiornamenti sarà programmata durante le finestre di manutenzione specificate dal cliente.

Queste attività vengono pianificate in anticipo per consentire ai clienti di prepararsi; si tratta di tempi di inattività necessari per aggiornare la versione del motore di database, anche in caso di istanze su più zone di disponibilità. Se desideri disattivare gli aggiornamenti automatici della versione secondaria, puoi impostare Auto Minor Version Upgrade su "No".

Nel caso di RDS per Oracle e RDS per SQL Server, se l'aggiornamento alla versione secondaria successiva richiede una modifica a un'edizione diversa, è possibile che non programmiamo aggiornamenti automatici anche se hai attivato l'impostazione Auto Minor Version Upgrade. La decisione di programmare o meno aggiornamenti automatici in tali situazioni verrà presa caso per caso.

Poiché gli aggiornamenti delle versioni principali presentano rischi relativi alla compatibilità, non saranno eseguiti automaticamente e dovranno essere inizializzati dall'utente (ad eccezione dei casi in cui versioni principali vengano dichiarate obsolete, vedi sotto). Per maggiori informazioni sull'aggiornamento di un'istanza database a una nuova versione del motore, consulta la Guida per l'utente di Amazon RDS.

Sì. Puoi creare uno snapshot di database dell'istanza DB esistente, eseguire il ripristino dallo snapshot DB per creare una nuova istanza database e avviare l'aggiornamento della versione su questa nuova istanza. Prima di decidere se aggiornare anche l'istanza database originale, potrai quindi effettuare le prove che desideri sulla copia aggiornata.

Per maggiori informazioni sul ripristino di un'istanza database, consulta la Guida per l'utente di Amazon RDS.

• Abbiamo intenzione di supportare le versioni principali (ad esempio, MySQL 5.6, PostgreSQL 9.6) per almeno 3 anni da quando vengono inizialmente supportate da Amazon RDS.
• Abbiamo intenzione di supportare le versioni secondarie (ad esempio, MySQL 5.6.37, PostgreSQL 9.6.1) per almeno un anno da quando vengono inizialmente supportate da Amazon RDS.

Periodicamente, dichiareremo obsolete versioni di motori principali o secondarie. Le versioni principali sono rese disponibili almeno fino alla fine del ciclo di vita della versione comunitaria corrispondente o fino a quando la versione non riceve più correzioni software o aggiornamenti di sicurezza. Per le versioni secondarie, ciò avviene quando una versione secondaria presenta bug o problemi di sicurezza significativi che sono stati risolti in una versione secondaria successiva.

Facciamo il possibile per aderire a queste linee guida, tuttavia in alcuni casi potemmo dichiarare obsolete versioni specifiche, principali o secondarie, prima del previsto (ad esempio se ci sono problemi di sicurezza). Nell'improbabile caso in cui tali situazioni si verificassero, Amazon RDS aggiornerà automaticamente il modulo di gestione di database per risolvere la questione. Circostanze specifiche possono richiedere tempistiche diverse, a seconda del problema in questione.

Quando una versione secondaria di un motore di database diventa obsoleta in Amazon RDS, diamo un periodo di tre (3) mesi di tempo a seguito dell'annuncio, prima di dare inizio agli aggiornamenti automatici. Al termine di questo periodo, tutte le istanze che eseguano ancora la versione secondaria dichiarata obsoleta verranno programmate per l'aggiornamento automatico alla versione secondaria più recente supportata durante la finestra di manutenzione programmata.

Quando una versione principale del motore di database diventa obsoleta in Amazon RDS, forniremo un periodo minimo di sei (6) mesi da quando viene dichiarata obsoleta, per consentirti di inizializzare un aggiornamento a una versione principale supportata. Al termine del periodo, verrà eseguito un aggiornamento automatico alla versione principale successiva di tutte le istanze che eseguono la versione dichiarata obsoleta durante le relative finestre di manutenzione programmata.

In alcuni casi, possiamo rendere obsolete specifiche versioni, principali o secondarie, senza preavviso, ad esempio quando scopriamo che una versione non soddisfa i nostri standard di qualità, prestazioni o sicurezza. Nell'improbabile caso in cui ciò si verifichi, Amazon RDS interromperà la creazione di nuove istanze di database e cluster con queste versioni. I clienti esistenti potranno continuare a eseguire i propri database. Circostanze specifiche possono richiedere tempistiche diverse, a seconda del problema in questione.

Paghi solo quello che utilizzi e non ci sono tariffe minime né commissioni di installazione. Il tuo utilizzo viene fatturato in base a quanto segue:

• Ore dell'istanza DB: in base alla classe (ad esempio, db.t2.micro, db.m4.large) dell'istanza database utilizzata. Le ore di utilizzo parziale dell'istanza database sono fatturate in incrementi di un secondo con una tariffa minima di 10 minuti derivante da un'operazione di modifica dello stato fatturabile quali la creazione, l'avvio o la modifica della classe di istanza database. Per ulteriori dettagli, leggi il nostro annuncio sulle novità.
• Archiviazione (per GB al mese): capacità di archiviazione che hai assegnato alla tua istanza database. Se la capacità di storage assegnata viene ridimensionata nel corso del mese, l'addebito sarà ripartito proporzionalmente.
• Richieste I/O al mese: numero totale di richieste di I/O inoltrate per l'archiviazione (solo per Amazon RDS Magnetic Storage e Amazon Aurora)
• Capacità di IOPS allocata al mese: quantità di capacità di IOPS allocata, indipendentemente dal numero di IOPS effettivo (solo per l'archiviazione con capacità di IOPS allocata (SSD) di Amazon RDS)
• Storage di backup: lo storage di backup è lo storage associato ai backup automatici di database e a tutti gli snapshot di database avviati manualmente. Estendendo il periodo di retention dei backup o creando ulteriori snapshot del database, si aumenta lo storage di backup consumato dal database.
• Trasferimento dati: il trasferimento dei dati via Internet, in entrata e in uscita dalla tua istanza database.

Per informazioni sui prezzi di Amazon RDS, visita la sezione dedicata ai prezzi nella pagina dei prodotti Amazon RDS.

La fatturazione di un'istanza DB inizia appena l'istanza è disponibile. La fatturazione continua finché l'istanza DB non giunge al termine, a seguito della sua eliminazione o in caso di malfunzionamento dell'istanza.

Le ore dell'istanza database vengono fatturate per ogni ora in cui l'istanza database è in esecuzione in stato disponibile. Se non desideri più ricevere addebiti per la tua istanza DB, dovrai interromperla o eliminarla per evitare che vengano fatturate altre ore associate all'istanza. Le ore di utilizzo parziale dell'istanza database sono fatturate in incrementi di un secondo con una tariffa minima di 10 minuti derivante da un'operazione di modifica dello stato fatturabile quali la creazione, l'avvio o la modifica della classe di istanza database.

Per tutta la durata della sospensione di un'istanza database, vengono addebitati i costi per lo storage assegnato (ad esempio lo storage Provisioned IOPS) e lo storage di backup (ad esempio backup automatici e snapshot entro la finestra di retention specificata), ma non sarà addebitato alcun costo per le ore-istanza del database.

Lo spazio di archiviazione di backup gratuito viene fornita fino al totale dello spazio di archiviazione del database dell'account nell'intera regione. Ad esempio, se disponi di un'istanza DB MySQL con 100 GB di spazio di archiviazione al mese e di un'istanza DB PostgreSQL con 150 GB di spazio di archiviazione al mese, entrambi nella stessa regione e con lo stesso account, ti forniremo 250 GB di spazio di archiviazione di backup in questo account e in questa regione senza costi aggiuntivi. Ti verranno addebitate solo le spese per lo spazio di archiviazione di backup che supera tale quantità.

Ogni giorno, lo spazio di archiviazione totale del database dell'account nella regione viene confrontato con lo spazio di archiviazione di backup totale nella regione e viene addebitato solo lo spazio di archiviazione di backup in eccesso. Ad esempio, se ogni giorno hai esattamente 10 GB di spazio di archiviazione di backup in eccesso, in quel mese ti verranno addebitati 10 GB di spazio di archiviazione di backup. In alternativa, se disponi di 300 GB di spazio di archiviazione allocato ogni giorno e di 500 GB di spazio di archiviazione di backup ogni giorno, ma solo per metà del mese, ti verrà addebitato solo un costo di 100 GB/mese di spazio di archiviazione di backup (e non di 200 GB/mese), poiché l'addebito viene calcolato giornalmente (proporzionalmente) e i backup non sono stati eseguiti per l'intero mese. Lo spazio di archiviazione di backup gratuito è specifico per l'account e per la regione.

Le dimensioni dei backup sono direttamente proporzionali alla quantità di dati presenti sull'istanza. Ad esempio, se disponi di un'istanza DB con 100 GB di spazio di archiviazione allocato, ma in quello spazio di archiviazione vengono memorizzati solo 5 GB di dati, il primo backup sarà di soli 5 GB circa (non di 100 GB). I backup successivi sono incrementali e memorizzano solo i dati modificati sull'istanza DB. La dimensione dello spazio di archiviazione di backup non viene visualizzata in RDS Console né nella risposta dell'API DescribeDBSnapshots.

Lo storage assegnato all'istanza DB per i dati primari si trova all'interno di un'unica zona di disponibilità. Quando si esegue il backup del database, i dati di backup (compresi i registri delle transazioni) vengono replicati in modo geo-ridondante in più zone di disponibilità, per offrire livelli ancora maggiori di durata dei dati. Il prezzo dello storage di backup che eccede l'assegnazione gratuita riflette questa replica supplementare realizzata per massimizzare la durata dei backup critici.

Se specifichi che la tua istanza database dev'essere un'implementazione multi-AZ, la fatturazione avverrà in base ai prezzi delle implementazioni multi-AZ, pubblicati nella pagina dei prezzi Amazon RDS. La fatturazione dell'implementazione Multi-AZ si basa su questi elementi:

• Ore dell'istanza DB multi-AZ: in base alla classe (ad esempio, db.t2.micro, db.m4.large) dell'istanza DB utilizzata. Come per le implementazioni standard in un'unica zona di disponibilità, le ore di utilizzo parziale dell'istanza database sono fatturate in incrementi di un secondo con una tariffa minima di 10 minuti derivante da un'operazione di modifica dello stato fatturabile quali la creazione, l'avvio o la modifica della classe di istanza database. Se converti l'implementazione dell'istanza database tra standard e Multi-AZ in una determinata ora, ti verranno addebitate entrambe le tariffe in vigore per quell'ora.
• Storage assegnato (per istanza database Multi-AZ): se converti l'implementazione dell'istanza tra standard e Multi-AZ in una determinata ora, ti verrà addebitata la più alta delle tariffe di storage in vigore per quell'ora.
• Richieste di I/O al mese: numero totale di richieste di I/O inoltrate. Le implementazioni Multi-AZ utilizzano una maggiore quantità di richieste di I/O rispetto a quelle standard, a seconda del rapporto scrittura/lettura del database. Le operazioni di I/O in scrittura associate agli aggiornamenti del database raddoppieranno quando Amazon RDS replica in modo sincrono i dati nell'istanza DB in standby. Le operazioni di I/O in lettura rimarranno invariate.
• Storage di backup: l'utilizzo dello storage di backup non varia in base al fatto che l'istanza DB sia un'implementazione standard o Multi-AZ. I backup verranno semplicemente ricavati dalla modalità standby per evitare la sospensione delle operazioni di I/O nell'istanza principale.
• Trasferimento dei dati: il trasferimento di dati che avviene nel replicare i dati tra l'istanza principale e quella di standby non sarà fatturato. Il trasferimento dei dati via Internet, in entrata e in uscita dalla tua istanza database, viene fatturato allo stesso modo di un'implementazione standard.

Salvo diversamente specificato, i prezzi sono al netto di eventuali tasse e imposte doganali, inclusa l'IVA ed eventuali imposte sulle vendite. Per i clienti con indirizzo di fatturazione in Giappone, l'utilizzo dei servizi AWS è soggetto all'imposta sul consumo giapponese. Ulteriori informazioni.

Il Piano gratuito AWS per Amazon RDS consente di usare gratuitamente micro istanze database single-AZ che eseguono MySQL, MariaDB, PostgreSQL e SQL Server Express Edition. Il piano di utilizzo gratuito è limitato a 750 ore di istanza al mese. I clienti riceveranno inoltre 20 GB di storage di database General Purpose (SSD) e 20 GB di storage di backup gratuiti al mese.

I nuovi account AWS ricevono 12 mesi di accesso con il Piano gratuito AWS. Per ulteriori informazioni, consulta le domande frequenti sul Piano gratuito AWS.

Sì. È possibile eseguire più istanze DB Micro Single-AZ contemporaneamente ed essere idonei all'utilizzo considerato nel piano gratuito AWS per Amazon RDS. Tuttavia, l'eventuale utilizzo eccedente le 750 ore di istanza, tra tutte le istanze database Micro Single-AZ di Amazon RDS, in tutti i motori di database e in tutte le regioni, sarà fatturato alle tariffe standard di Amazon RDS.

Ad esempio, se esegui due istanze database Micro Single-AZ per 400 ore ciascuna nello stesso mese, accumulerai 800 ore di utilizzo delle istanze, di cui 750 sono gratuite. Le restanti 50 ore saranno fatturate alla tariffa standard di Amazon RDS.

No. Un cliente che ha accesso al piano gratuito AWS può utilizzare fino a 750 ore di istanza di istanze Micro con l'esecuzione di MySQL, PostgreSQL o SQL Server Express Edition. L'eventuale utilizzo eccedente le 750 ore di istanza, tra tutte le istanze DB Micro AZ singola di Amazon RDS e in tutte le regioni e i motori di database idonei, sarà fatturato alle tariffe standard di Amazon RDS.

Le ore di istanza che vanno oltre quelle fornite dal piano gratuito vengono fatturate alle tariffe standard di Amazon RDS. Per i dettagli, consulta la pagina dei prezzi di Amazon RDS.

Le istanze riservate di Amazon RDS offrono la possibilità di prenotare un'istanza database per un periodo da uno a tre anni e in cambio ottenere un consistente sconto rispetto ai prezzi delle istanze on demand per l'istanza database. Esistono tre opzioni di pagamento per le IR (Nessun anticipo, Pagamento anticipato parziale e Pagamento anticipato intero costo), che consentono di bilanciare l'importo pagato in anticipo con la tariffa oraria in vigore.

Dal punto di vista funzionale, le istanze riservate e quelle on demand sono identiche. L'unica differenza è la modalità di fatturazione delle istanze DB. Con le istanze riservate, acquisti una prenotazione di uno o tre anni e in cambio ricevi una tariffa oraria effettiva inferiore (rispetto alle istanze DB on demand) per la tutta la durata del periodo. Se non vengono acquistate istanze riservate in una regione, tutte le istanze database saranno fatturate secondo le tariffe orarie on demand in vigore.

È possibile acquistare istanze riservate nella sezione "Istanza riservata" della Console di gestione AWS per Amazon RDS. In alternativa, puoi usare l'API di Amazon RDS o l'interfaccia a riga di comando di AWS per visualizzare un elenco delle prenotazioni disponibili e acquistare una prenotazione di istanza DB.

Una volta completato l'acquisto della prenotazione, non c'è alcuna differenza tra l'utilizzo di un'istanza DB riservata e un'istanza DB on demand. Avvia un'istanza database con le stesse opzioni (classe di istanza, motore e regione) della prenotazione. Per tutta la durata di attività dell'acquisto, Amazon RDS applicherà la tariffa oraria ridotta alla quale hai diritto per la nuova istanza database.

Le istanze riservate di Amazon RDS sono acquistate per regione, non per una specifica zona di disponibilità. Poiché le istanze riservate non sono specifiche per una zona di disponibilità, non costituiscono prenotazione di capacità. Questo significa che anche se la capacità è limitata a una zona di disponibilità, le prenotazioni non possono comunque essere acquistate nella regione; lo sconto sarà applicato all'utilizzo corrispondente in una qualsiasi zona di disponibilità all'interno della regione.

Puoi acquistare fino a 40 istanze DB riservate. Se ti occorrono più di 40 istanze database, compila il modulo per la richiesta di istanze database di Amazon RDS.

Acquista semplicemente una prenotazione di un'istanza database con la stessa classe di istanza database, motore database, opzione Multi-AZ e modello di licenza all'interno della stessa regione dell'istanza database che stai attualmente utilizzando e che desideri prenotare. Se l'acquisto della prenotazione viene completato correttamente, Amazon RDS applicherà automaticamente la nuova tariffa oraria di utilizzo all'istanza database attuale.

Le variazioni dei prezzi associati a un'istanza riservata si attivano alla ricezione della richiesta, mentre viene elaborata l'autorizzazione al pagamento. È possibile seguire lo stato della prenotazione nella pagina dedicata all'attività dell'account AWS oppure utilizzando l'API DescribeReservedDBInstances o il comando describe-reserved-db-instances. Se il pagamento in un'unica soluzione non viene autorizzato a partire dal periodo di fatturazione successivo, la tariffa scontata non sarà applicata.

Allo scadere del periodo di prenotazione, all'istanza riservata tornerà ad essere applicata la tariffa oraria on demand corrispondente alla classe dell'istanza database e alla regione.

Amazon RDS, al momento di creare, modificare o eliminare istanze database, non distingue tra istanze on demand e istanze riservate. Nel calcolo della fattura, il nostro sistema applica automaticamente le tariffe della tua prenotazione, quindi tutte le istanze idonee sono addebitate alla tariffa oraria riservata inferiore.

Ogni prenotazione è associata alla seguente serie di attributi: motore di database, classe dell'istanza database, opzione di implementazione Multi-AZ, modello di licenza e regione.

Le prenotazioni per motori di database e modelli di licenza compatibili con la flessibilità sulle dimensioni (MySQL, MariaDB, PostgreSQL, Amazon Aurora e Oracle BYOL) saranno automaticamente applicate alle istanze database in esecuzione indipendentemente dalle dimensioni, purché la famiglia di istanze sia la stessa (ad es. M4, T2 o R3) e si tratti dello stesso motore di database nella stessa regione. Le istanze database potranno essere sia Single-AZ sia Multi-AZ.

Supponiamo ad esempio di aver acquistato una prenotazione db.m4.2xlarge per MySQL. Se si decide di aumentarne le dimensioni trasformandola in un'istanza db.m4.4xlarge, la tariffa scontata coprirà il 50% dell'utilizzo della nuova istanza.

Se il motore di database o il modello di licenza non è compatibile con la flessibilità sulle dimensioni (Microsoft SQL Server o Oracle "Licenza inclusa"), ciascuna prenotazione potrà essere applicata a un'istanza DB con gli stessi attributi per tutta la sua durata. Se decidi di modificare uno di questi attributi per l'istanza database in esecuzione prima della fine del periodo di prenotazione, a quell'istanza saranno applicate nuovamente le tariffe orarie previste per le istanze on demand.

Per ulteriori informazioni sulla flessibilità delle istanze, consulta la Guida per l'utente di Amazon RDS.

Ogni istanza riservata è associata a una regione specifica, che rimane fissa per tutta la durata della prenotazione e non può essere modificata. Ogni prenotazione può però essere utilizzata in una qualsiasi delle zone di disponibilità della regione associata.

Sì. Con l’acquisto di una istanza riservata puoi selezionare l’opzione Multi-AZ nella configurazione di istanze DB disponibili per l’acquisto. Inoltre, se utilizzi un motore DB e un modello di licenza che supporta la flessibilità di dimensione di istanze riservate, un'istanza riservata multi-AZ coprirà l'utilizzo di due istanze database con AZ singola.

Una prenotazione per un'istanza database si può applicare a una replica di lettura, purché la classe e la regione dell'istanza siano le stesse. Nel calcolo della fattura, il nostro sistema applica automaticamente le tariffe della tua prenotazione, quindi tutte le istanze database idonee ti sono addebitate alla tariffa oraria dell'istanza riservata inferiore.

No, non è possibile annullare le istanze DB prenotate; l'eventuale pagamento in un'unica soluzione non è rimborsabile. Durante il periodo dell'istanza riservata continuerai a pagare per tutte le ore, indipendentemente dall'utilizzo.

Quando acquisti un IR con l'opzione Pagamento anticipato intero costo, paghi l'intera istanza riservata con un solo pagamento anticipato. Puoi scegliere di non pagare alcun costo anticipato con l'opzione Nessun pagamento anticipato. L'intero valore dell'IR senza pagamento anticipato viene distribuito su ogni ora del periodo e pagherai per ogni ora del periodo a prescindere dall'utilizzo. L'opzione Pagamento anticipato parziale è un ibrido tra le altre due opzioni. Dovrai effettuare un piccolo pagamento anticipato e ti sarà addebitata una bassa tariffa oraria per ogni ora della durata del termine, indipendentemente dall'utilizzo.

Per selezionare la classe dell'istanza database e la capacità di archiviazione iniziali, è opportuno valutare le esigenze di calcolo, memoria e archiviazione della tua applicazione. Per informazioni sulle classi di istanze database disponibili, consulta la Guida per l'utente di Amazon RDS.

Puoi dimensionare le risorse di calcolo e la capacità di archiviazione assegnate alla tua istanza database nella Console di gestione AWS (selezionando l'istanza database desiderata e facendo clic sul pulsante Modifica), oppure tramite l'API di Amazon RDS o l'interfaccia a riga di comando di AWS. Le risorse di memoria e di CPU si modificano cambiando la classe dell'istanza DB, mentre puoi cambiare l'archiviazione disponibile modificando l'assegnazione di archiviazione. 

Se modifichi la classe dell'istanza o lo storage assegnato, le modifiche richieste diventeranno effettive durante la finestra di manutenzione specificata. In alternativa, è possibile utilizzare il flag "apply-immediately" per rendere subito effettive le richieste di ridimensionamento. Tieni presente che anche tutte le altre modifiche di sistema in sospeso diventeranno effettive.

Alcune istanze RDS per SQL Server precedenti in uso potrebbe non essere idonee per il ridimensionamento. Per ulteriori informazioni, consulta la pagina Domande Frequenti RDS per SQL Server.

Amazon RDS utilizza i volumi EBS per lo storage del database e dei log. A seconda delle dimensioni dello storage richiesto, Amazon RDS esegue automaticamente lo striping di più volumi EBS per migliorare le prestazioni degli IOPS. Per MySQL e Oracle, sarà possibile notare un miglioramento nella capacità I/O dell'istanza DB esistente quando si aumenta lo spazio di archiviazione. È possibile dimensionare la capacità di archiviazione assegnata alla tua istanza DB usando la Console di gestione AWS, l'API ModifyDBInstance o il comando modify-db-instance.

Per ulteriori informazioni, consulta Archiviazione per Amazon RDS.

La capacità di storage allocata per l'istanza DB può essere aumentata senza inficiarne la disponibilità. Tuttavia, quando decidi di dimensionare le risorse di calcolo disponibili per l'istanza database, il tuo database risulterà temporaneamente non disponibile durante la modifica di classe dell'istanza. Questo intervallo di mancata disponibilità dura di solito alcuni minuti e si verifica durante la finestra di manutenzione dell'istanza database (a meno che tu non richieda l'applicazione immediata delle modifiche).

Amazon RDS supporta classi di istanze DB e opzioni di storage ideali a soddisfare un'ampia gamma di esigenze applicative. Se la classe di istanze database di maggiori dimensioni non offre sufficienti risorse di calcolo o l'allocazione di storage più ampia non è abbastanza capiente per la tua applicazione, puoi ripartire i dati su più istanze database tramite il partizionamento.

L'archiviazione per uso generico (SSD) di Amazon RDS è idonea per un'ampia gamma di carichi di lavoro di database con requisiti di I/O moderati. Con una capacità di base che si aggira attorno ai 3 IOPS/GB e la possibilità di espandere le prestazioni fino a 3.000 IOPS, questa opzione di storage fornisce prestazioni prevedibili ideali per soddisfare le esigenze della maggior parte delle applicazioni.

L'archiviazione di capacità di IOPS allocata (SSD) di Amazon RDS è un'opzione di archiviazione con volumi SSD creata per offrire prestazioni I/O elevate, prevedibili e costanti. Con l’archiviazione di capacità di IOPS allocata (SSD) di Amazon RDS, durante la creazione di un'istanza DB decidi un volume IOPS, e Amazon RDS manterrà tale volume costante per tutto il ciclo di vita di quell'istanza DB. L’archiviazione di capacità di IOPS allocata (SSD) di Amazon RDS è ottimizzata per carichi di lavoro di database transazionali (OLTP) con intenso traffico di I/O. Per ulteriori dettagli, consulta la Guida per l'utente di Amazon RDS.

L'archivio magnetico di Amazon RDS è utile per piccoli carichi di lavoro di database in cui l'accesso ai dati è meno frequente. Lo storage Magnetic non è la soluzione ideale in caso di istanze database in produzione.

Consigliamo di scegliere il tipo di storage più adatto al tuo carico di lavoro.

• Carichi di lavoro OLTP ad elevate prestazioni: archiviazione di capacità di IOPS allocata (SSD) di Amazon RDS
• Carichi di lavoro con requisiti di I/O moderati: storage General Purpose (SSD) Amazon RDS

Le prestazioni di IOPS supportate da Amazon RDS variano a seconda del motore di database. Per ulteriori dettagli, consulta la Guida per l'utente di Amazon RDS.

Amazon RDS offre due metodi differenti per il backup e il ripristino dei dati di un'istanza database: i backup automatici e le istantanee DB (snapshot database).

La funzione di backup automatico di Amazon RDS consente il ripristino point-in-time dell'istanza database. Quando i backup automatici di un'istanza DB sono abilitati, Amazon RDS esegue automaticamente tutti i giorni uno snapshot completo dei dati durante una finestra di backup configurabile e memorizza i registri delle transazioni (durante gli aggiornamenti dell'istanza DB). Quando viene avviato un ripristino point-in-time, i log delle transazioni vengono applicati al backup giornaliero più recente per ripristinare l'istanza DB allo stato richiesto. 

Amazon RDS conserva i backup di un'istanza DB per un periodo di tempo limitato definito dall'utente, chiamato periodo di retention, la cui durata di default è di 7 giorni; questo periodo può tuttavia essere configurato per un intervallo di tempo massimo di 35 giorni. Quando avvii un ripristino point-in-time, puoi anche specificare il secondo esatto a cui ripristinare i dati, fino al punto di ripristino più recente. Per ottenere il punto di ripristino più recente dell'istanza database, normalmente creato negli ultimi cinque minuti, è anche possibile usare l'API DescribeDBInstances. 

In alternativa, è possibile individuare il punto di ripristino più recente per un'istanza DB selezionandolo all'interno della Console di gestione AWS e consultando la scheda "Descrizione" nel riquadro inferiore della console.

Gli snapshot DB sono creati manualmente e consentono di effettuare il backup dell'istanza DB in uno stato conosciuto ogni volta che desideri, in modo da ripristinare l'istanza in uno stato specifico in qualsiasi momento. Per creare snapshot DB, è possibile utilizzare la Console di gestione AWS, l'API CreateDBSnapshot o il comando create-db-snapshot; gli snapshot creati in questo modo saranno conservati finché non verranno eliminati manualmente.

Gli snapshot creati da Amazon RDS per i backup automatici possono essere copiati (tramite la console AWS o il comando copy-db-snapshot) o utilizzati per la funzionalità di ripristino. Per identificarli è possibile usare il tipo di snapshot "automated". Per vedere la data e l'ora di creazione dello snapshot, è sufficiente consultare il campo "Snapshot Created Time". 

In alternativa, l'identificatore degli snapshot di tipo "automated" contiene l'ora (secondo il fuso di riferimento UTC) in cui è stato creato lo snapshot.

Nota: quando viene eseguita un'operazione di ripristino point-in-time oppure da snapshot DB, viene creata una nuova istanza DB con un nuovo endpoint; se desideri, puoi eliminare l'istanza DB precedente. In questo modo è possibile creare più istanze database da un determinato snapshot di database o da un backup point-in-time.

Di default, Amazon RDS permette backup automatici delle istanze DB con un periodo di conservazione di 7 giorni. Se desideri modificare i tempi di conservazione del backup, puoi usare la console RDS, l'API CreateDBInstance (al momento della creazione di una nuova istanza database) oppure l'API ModifyDBInstance (per le istanze esistenti). Usa questi metodi per modificare il parametro RetentionPeriod in qualsiasi numero da 0 (che disabilita i backup automatici) al numero di giorni di conservazione desiderati, fino a 35. Il valore non può essere impostato su 0 se l’istanza DB è una sorgente delle repliche di lettura. Per ulteriori informazioni sui backup automatici, consulta la Guida per l'utente di Amazon RDS.

La finestra di backup è un intervallo di tempo definito dall'utente durante il quale viene eseguito il backup dell'istanza DB. Amazon RDS usa i backup periodici e i log delle transazioni per consentire il ripristino dell'istanza DB a qualsiasi punto nel tempo compreso nel periodo di retention, fino al LatestRestorableTime (di solito fino agli ultimi minuti). Durante la finestra di backup, le operazioni I/O di storage possono venire brevemente sospese (in genere per pochi secondi), in modo da consentire l'avvio del processo di backup dei dati, e la latenza potrebbe pertanto aumentare. Nelle implementazioni Multi-AZ dei database le operazioni I/O non vengono sospese, perché il backup viene acquisito dall'istanza di standby.

Gli snapshot database e i backup automatici di Amazon RDS vengono conservati in S3.

Per gestire il periodo di conservazione dei backup automatici è necessario modificare il parametro RetentionPeriod, utilizzando la Console di gestione AWS, l'API ModifyDBInstance o il comando modify-db-instance. Se desideri disattivare i backup automatici, è sufficiente impostare il periodo di retention su 0 (opzione non consigliata). Gli snapshot DB creati manualmente sono gestiti invece nella sezione "Snapshot" della console di Amazon RDS. In alternativa, puoi consultare un elenco degli snapshot database creati dall'utente per una determinata istanza database tramite l'API DescribeDBSnapshots o il comando describe-db-snapshots e cancellare gli snapshot con l'API DeleteDBSnapshot o il comando delete-db-snapshot.

La presenza di 1 o 2 snapshot DB automatici in più rispetto al numero di giorni del periodo di retention è normale. Viene conservato uno snapshot automatico aggiuntivo per garantire la possibilità di eseguire un ripristino temporizzato in qualsiasi momento durante il periodo di retention.

Se, ad esempio, la tua finestra di backup è impostata su 1 giorno, saranno necessarie 2 istantanee automatiche per supportare le operazioni di ripristino a qualsiasi momento nelle 24 ore precedenti. Potresti anche notare che viene sempre creato un nuovo snapshot automatico aggiuntivo prima dell'eliminazione dello snapshot automatico precedente.

Quando elimini un'istanza database, puoi creare uno snapshot DB finale.In tal caso, puoi usare questo snapshot DB per ripristinare l'istanza DB eliminata in un secondo momento. Dopo l'eliminazione dell'istanza DB, Amazon RDS conserva questo snapshot DB creato dall'utente insieme a tutti gli altri snapshot DB creati manualmente. Consulta la pagina dei prezzi per ulteriori dettagli sui costi di archiviazione dei backup.

Quando si elimina un'istanza DB, è possibile conservare i backup automatici fino al periodo di conservazione del backup. Per ulteriori informazioni, vedere Conservazione dei backup automatici.

Amazon VPC ti consente di creare un ambiente di rete virtuale in una sezione isolata e privata del cloud AWS, dove potrai esercitare un controllo completo su elementi quali gli intervalli di indirizzi IP privati, le sottoreti, le tabelle di routing e i gateway di rete. Con Amazon VPC, potrai definire una topologia di rete virtuale e personalizzarne la configurazione in modo che sia simile a una rete IP tradizionale, che potrai gestire nel tuo data center.

Per esempio, puoi sfruttare VPC quando vuoi eseguire un'applicazione web rivolta al pubblico, mantenendo allo stesso tempo i server backend non accessibili al pubblico in una sottorete privata. Puoi creare una sottorete pubblica per i tuoi server Web, con accesso a Internet, e collocare le istanze database di Amazon RDS per il back-end in una sottorete privata senza accesso a Internet. Per ulteriori informazioni su Amazon VPC, consulta la Guida per l'utente di Amazon Virtual Private Cloud.

Se il tuo account AWS è stato creato prima del 04-12-2013, potresti riuscire a eseguire Amazon RDS in un ambiente Amazon Elastic Compute Cloud (EC2)-Classic. Le funzionalità di base di Amazon RDS sono le stesse, indipendentemente dall'eventuale utilizzo di Amazon Elastic Compute Cloud (EC2)-Classic o EC2-VPC. Sia che le istanze DB siano implementate all'interno o all'esterno di un VPC, Amazon RDS gestirà comunque i backup, l'applicazione di patch al software, il rilevamento automatico di errori, le repliche di lettura e il ripristino. Per informazioni sulle differenze tra EC2-Classic ed EC2-VPC, consulta la documentazione di EC2.

Un gruppo di sottoreti database è una raccolta di sottoreti che puoi configurare come istanze database di Amazon RDS in un VPC. Ogni gruppo di sottoreti DB dovrebbe disporre di almeno una sottorete per ogni zona di disponibilità in una determinata regione. Quando viene creata un'istanza DB in VPC, è necessario selezionare un gruppo di sottorete DB. Amazon RDS usa quindi quel gruppo e una zona di disponibilità a tua scelta per selezionare una sottorete e un indirizzo IP all'interno di quella sottorete. Amazon RDS crea un'interfaccia di rete elastica e la associa all'istanza database con quell'indirizzo IP.

Nota: consigliamo vivamente di usare il tuo nome DNS per collegarti alla tua istanza database, poiché l'indirizzo IP potrebbe variare (ad esempio, durante un failover).

Per le implementazioni multi-AZ, definire una sottorete per tutte le zone di disponibilità in una regione consente ad Amazon RDS di creare, in caso di necessità, un nuovo standby in un'altra zona di disponibilità. Questa operazione va effettuata anche per le implementazioni Single-AZ, in modo da poterle eventualmente convertire in implementazioni Multi-AZ in un secondo momento.

Per una procedura passo-passo del processo, consulta la sezione Creazione di un'istanza database nel VPC della Guida per l'utente di Amazon RDS.

Visita la sezione relativa ai gruppi di sicurezza della Guida per l'utente di Amazon RDS per scoprire tutte le modalità che hai a disposizione per controllare l'accesso alle tue istanze database.

È possibile accedere alle istanze database implementate all'interno di un VPC (cloud privato virtuale) tramite le istanze EC2 implementate nello stesso cloud. Se queste istanze EC2 sono distribuite in una sottorete pubblica con associato un IP elastico, è possibile accedervi tramite Internet. È possibile accedere ad istanze database implementate all'interno di un VPC da Internet o da istanze EC2 esterne al VPC, utilizzando una VPN o un host bastione che potrai avviare nella tua sottorete pubblica, o usando l'opzione Accessibile pubblicamente di Amazon RDS:

• Per usare un host bastione, è necessario configurare una sottorete pubblica con un'istanza EC2 che agisca come bastione SSH. Questa sottorete pubblica deve disporre di un gateway internet di regole di routing che consentano l'indirizzamento del traffico sull'host SSH, che deve quindi inoltrare le richieste all'indirizzo IP privato dell'istanza DB di Amazon RDS.
• Per usare una connessione pubblica, è sufficiente creare un'istanza database con l'opzione Publicly Accessible impostata su Yes. Se l'opzione Publicly Accessible è attiva, le istanze DB all'interno di VPC sono completamente accessibili all'esterno del cloud privato virtuale per impostazione predefinita. Non è quindi necessario configurare una VPN o un bastion host per accedere alle istanze.

È anche possibile configurare un gateway VPN che estenda la rete aziendale all'interno di VPC, consentendo così l'accesso all'istanza database di Amazon RDS all'interno del cloud privato virtuale. Per ulteriori informazioni, consulta la Guida per l'utente di Amazon VPC.

Consigliamo vivamente di usare il tuo nome DNS per collegare l'istanza database, perché l'indirizzo IP può variare (ad esempio, durante un failover).

Se l'istanza DB non si trova all'interno di un VPC, puoi usare la Console di gestione AWS per trasferire l'istanza all'interno di VPC. Per maggiori dettagli, consulta la Guida per l'utente di Amazon RDS. Puoi anche creare uno snapshot di un'istanza DB fuori dal cloud privato virtuale e ripristinarla all'interno di VPC specificando il gruppo di sottorete di database che desideri impiegare. In alternativa, puoi usare la funzionalità "Restore to Point in Time".

La migrazione di istanze database dall'interno all'esterno del VPC non è supportata. Per motivi di sicurezza, uno snapshot DB di un'istanza DB all'interno di VPC non può essere ripristinato all'esterno di VPC. Lo stesso vale per la funzionalità "Restore to Point in Time". 

Devi modificare le tabelle di routing e le reti ACL nel VPC per assicurarti che l'istanza database sia raggiungibile dalle istanze client nel VPC. Per le implementazioni multi-AZ, dopo un failover, l'istanza EC2 client e l'istanza database di Amazon RDS potrebbero trovarsi in zone di disponibilità differenti. Le liste di controllo degli accessi di rete devono essere configurate in modo che consentano la comunicazione tra diverse zone di disponibilità.

Un gruppo di sottorete di database esistente può essere aggiornato aggiungendo altre sottoreti sia per zone di disponibilità esistenti sia per nuove zone di disponibilità aggiunte dopo la creazione dell'istanza DB. La rimozione di sottoreti da un gruppo di sottorete database esistente può provocare interruzioni della disponibilità per le istanze in esecuzione in una zona di disponibilità rimossa dal gruppo di sottorete. Per maggiori dettagli, consulta la Guida per l'Utente di Amazon RDS.

Per iniziare a usare Amazon RDS, è necessario disporre di un account sviluppatore di AWS. Se non ne hai già uno al momento di registrarti per Amazon RDS, ti verrà chiesto di crearlo all'inizio della procedura di registrazione. Un account utente master è diverso da un account sviluppatore di AWS e viene utilizzato esclusivamente nel contesto di Amazon RDS per controllare gli accessi alle tue istanze database. L'account utente master è un account utente di database nativo da usare per connettersi alle istanze database. 

Puoi specificare il nome utente master e la password che desideri associare a ciascuna istanza database nel momento in cui viene creata. Una volta creata l'istanza database, puoi connetterti al database utilizzando le credenziali di utente master. Potrai quindi anche creare account utente aggiuntivi in modo da restringere l'accesso all'istanza database.

Per MySQL, i privilegi di default dell'utente master includono: creazione, rimozione di associazione, riferimenti, evento, modifica, eliminazione, creazione dell'indice, inserimento, selezione, aggiornamento, creazione di tabelle temporanee, blocco di tabelle, attivazione, creazione di visualizzazione, apertura di visualizzazione, modifica di routine, creazione di routine, esecuzione, creazione di utente, processo, apertura database, opzione di concessione.

Per Oracle, l'utente master riveste il ruolo di "dba". L'utente master eredita la maggior parte dei privilegi associati a tale ruolo. Consulta la Guida per l'utente di Amazon RDS per un elenco di privilegi limitati e alternative correlate per eseguire operazioni a livello di amministratore che potrebbero richiedere tali privilegi.

Per SQL Server, un utente che crea un database riceve il ruolo di "db_owner". Consulta la Guida per l'utente di Amazon RDS per un elenco di privilegi limitati e alternative correlate per eseguire operazioni a livello di amministratore che potrebbero richiedere tali privilegi.

No, il funzionamento è analogo alla gestione di un comune database relazionale.

Sì. È necessario abilitare l'accesso al tuo database tramite Internet configurando i gruppi di sicurezza. È possibile autorizzare l'accesso solo a indirizzi IP specifici, a intervalli di indirizzi IP o a sottoreti corrispondenti ai server del data center in uso.

Sì, l’opzione è supportata da i tutti i motori Amazon RDS. Amazon RDS genera un certificato SSL/TLS per ogni istanza database. Una volta stabilita la connessione crittografata, i dati trasferiti tra l'istanza database e l'applicazione saranno crittografati durante la trasmissione.

Il protocollo SSL offre notevoli vantaggi dal punto di vista della sicurezza, ma va ricordato che la crittografia SSL/TLS richiede notevoli risorse di calcolo e provocherà pertanto un aumento della latenza alla connessione del database. Il supporto per il protocollo SSL/TLS in Amazon RDS prevede la crittografia della connessione tra l'applicazione e l'istanza DB; sconsigliamo di utilizzarlo per l'autenticazione dell'istanza DB.

Per informazioni su come stabilire una connessione crittografata con Amazon RDS, consulta la Guida per l'utente di MySQL, la Guida per l'utente di MariaDB, la Guida per l'utente di PostgreSQL Server o la Guida per l'utente di Oracle. Per ulteriori informazioni sul funzionamento del protocollo SSL/TLS con questi motori, puoi consultare direttamente la documentazione di MySQL, la documentazione di MariaDB, la documentazione di MSDN SQL Server, la documentazione di PostgreSQL o la documentazione di Oracle.

Amazon RDS supporta la crittografia dei dati a riposo per tutti i motori di database, utilizzando le chiavi gestite attraverso il Sistema AWS di gestione delle chiavi (KMS). Su un'istanza database in esecuzione con crittografia Amazon RDS, i dati salvati a riposo nello storage vengono criptati, così come i backup, le repliche di lettura e gli snapshot. La crittografia e la decrittografia sono gestite in modo trasparente. Per ulteriori informazioni sull'uso di KMS con Amazon RDS, consulta la Guida per l'utente di Amazon RDS.

Puoi anche aggiungere la crittografia a un'istanza DB o un cluster DB precedentemente decrittati creando un’istantanea DB e poi creando una copia dell’istantanea e specificando la chiave crittografica KMS. A questo punto puoi ripristinare un'istanza database o un cluster database crittografati dallo snapshot crittografato.

Amazon RDS per Oracle e SQL Server supportano le tecnologie di Transparent Data Encryption (TDE) dei relativi motori. Per ulteriori informazioni, consulta le sezioni della Guida per l'utente di Amazon RDS per Oracle e SQL Server.

Puoi controllare quali operazioni sono consentite agli utenti e ai gruppi IAM AWS sulle risorse Amazon RDS. Per farlo, seleziona le risorse Amazon RDS nelle policy IAM di AWS che desideri applicare agli utenti o ai gruppi. Le risorse Amazon RDS che è possibile selezionare all'interno di una policy IAM di AWS includono istanze database, snapshot database, repliche di lettura, gruppi di sicurezza database, gruppi di opzioni database, gruppi di parametri database, abbonamenti correlati a eventi e gruppi di sottoreti database. 

Inoltre, è possibile applicare tag a queste risorse aggiungendovi metadati. Con l’applicazione dei tag, è possibile i suddividere le risorse in categorie (ad esempio istanze DB di "Sviluppo", istanze DB di "Produzione", istanze DB di "Test", ecc.) e policy IAM di AWS in scrittura che elenchino le autorizzazioni (ovvero le azioni) relative alle risorse contrassegnate con gli stessi tag. Per ulteriori informazioni, consulta Applicazione di tag alle risorse Amazon RDS.

Sì. AWS CloudTrail è un servizio Web che registra le chiamate alle API AWS e fornisce i relativi file di registro. Lo storico delle chiamate API AWS creato da CloudTrail rende possibile analisi di sicurezza, monitoraggio delle modifiche alle risorse e audit di conformità. 

Sì, tutti i motori di database Amazon RDS sono idonei per HIPAA, quindi è possibile usarli per costruire applicazioni conformi allo standard HIPAA e archiviare informazioni sanitarie, fra cui i dati sanitari protetti (PHI) da un contratto di società in affari (BAA) stipulato con AWS.

Se è già stato stipulato un contratto BAA, non è necessaria alcuna operazione per iniziare a usare questi servizi negli account coperti dal contratto BAA. Se non è ancora stato stipulato un contratto BAA con AWS, oppure per qualsiasi altra domanda in merito alle applicazioni conformi allo standard HIPAA in AWS, contatta il gestore del tuo account.

Di default, Amazon RDS seleziona i parametri di configurazione ottimali per l'istanza DB in base alla classe di istanze e alla capacità di storage. Tuttavia, se desideri modificarli, puoi farlo tramite la console di gestione AWS, le API di Amazon RDS o l'interfaccia a riga di comando di AWS. Si noti che la modifica dei parametri di configurazione rispetto ai valori raccomandati può provocare effetti inattesi che possono andare da un calo delle prestazioni a crash di sistema, e dovrebbe essere effettuata solo da utenti esperti che conoscono i rischi che ne derivano.

Un gruppo di parametri di database agisce come "container" per i valori di configurazione di un motore applicabili a una o più istanze database. Se decidi di creare un'istanza DB senza specificare un gruppo di parametri di database, ne viene utilizzato uno predefinito. Questo gruppo predefinito contiene le impostazioni di default del motore e del sistema di Amazon RDS ottimizzate per l'istanza DB in esecuzione.

Se tuttavia desideri eseguire l'istanza con i valori di configurazione del motore personalizzati, puoi creare un nuovo gruppo di parametri di database, apportare le modifiche desiderate ai parametri e impostare l'istanza DB in modo che applichi il nuovo gruppo di parametri di database. Una volta associate, tutte le istanze database che usano un determinato gruppo di parametri di database riceveranno tutti gli aggiornamenti dei parametri relativi a tale gruppo.

Per ulteriori informazioni sulla configurazione dei gruppi di parametri di database, leggi la Guida per l'utente di Amazon RDS.

Puoi usareAWS Config per registrare in modo continuo le modifiche alla configurazione di istanze database, gruppi di sottorete database, snapshot database, gruppi di sicurezza database e abbonamenti a eventi di Amazon RDS e ricevere notifica delle modifiche tramite Amazon Simple Notification Service (SNS). Puoi usare AWS Config per creare regole che stabiliscano se le configurazioni delle risorse Amazon RDS corrispondono a quelle desiderate.

Quando crei o modifichi un'istanza database per eseguirla come implementazione multi-AZ, Amazon RDS elabora automaticamente una replica sincrona di "stand-by", conservandola in una zona di disponibilità differente. Gli aggiornamenti all'istanza DB vengono replicati in modo sincrono sulla copia di stand-by nell'altra zona di disponibilità, mantenendo entrambe le istanze sincronizzate e proteggendo così gli aggiornamenti più recenti del database da eventuali errori dell'istanza DB. 

Durante determinati tipi di finestra di manutenzione, oppure nell'eventualità di un errore dell'istanza DB o della zona di disponibilità, Amazon RDS esegue automaticamente il failover sulla copia di standby per consentire di ripristinare le operazioni di lettura e scrittura del database non appena la copia di standby viene attivata. Poiché il registro di nome dell'istanza database rimane invariato, l'applicazione potrà ripristinare l'operatività sul database senza la necessità di interventi manuali a livello amministrativo. Con le implementazioni Multi-AZ le repliche sono trasparenti. Non è necessario interagire direttamente con la copia di stand-by, né questa può essere utilizzata per il traffico in lettura. Per ulteriori informazioni sulle implementazioni multi-AZ, consulta la Guida per l'utente di Amazon RDS.

Le zone di disponibilità sono percorsi separati all'interno di una regione, isolati dai potenziali errori di altre zone di disponibilità. Ciascuna zona di disponibilità gestisce un'infrastruttura fisica propria, distinta e indipendente ed è progettata in modo da essere altamente affidabile. Macchinari e attrezzature facilmente soggetti a guasto, come generatori e apparecchiature di raffreddamento, non sono condivisi tra le zone di disponibilità. Inoltre, sono fisicamente separate, in modo tale che anche eventi estremi molto rari, come incendi, trombe d'aria o inondazioni, colpirebbero una sola zona di disponibilità. Le zone di disponibilità all'interno della stessa regione dispongono di connettività a latenza molto ridotta.

Quando esegui un'istanza database come implementazione Multi-AZ, l'istanza "principale" opera le attività in lettura e scrittura del database. Oltre a questa istanza, Amazon RDS ne crea e mantiene una di "standby", che è una replica aggiornata di quella principale. In caso di failover, l'istanza di standby viene "promossa". Dopo il failover, l'istanza di standby diventa infatti l'istanza principale e accetta le operazioni del database. Prima di questa promozione, non avrai alcuna interazione con la copia di stand-by (ad esempio operazioni in lettura). Se sei interessato a ridimensionare il traffico in lettura oltre la capacità di una singola istanza database, consulta le domande frequenti relative alle Repliche di lettura.

Il principale vantaggio dell'esecuzione di un'istanza DB come implementazione Multi-AZ è il miglioramento di durabilità e disponibilità del database. La disponibilità e la tolleranza ai guasti offerte dalle implementazioni Multi-AZ ne fanno una soluzione ideale per gli ambienti di produzione.
 

L'esecuzione di un'istanza DB come implementazione Multi-AZ consente di proteggere i dati nell'eventualità di un errore di un componente o di un calo della disponibilità in una zona di disponibilità. Se ad esempio si verifica un errore in un volume di storage sull'istanza primaria, Amazon RDS avvia automaticamente un failover sull'istanza di standby, dove gli aggiornamenti del database sono ancora intatti. In questo modo è possibile migliorare la durabilità dei dati delle distribuzioni standard in una singola zona di disponibilità, per le quali le operazioni di ripristino devono essere avviate manualmente e gli aggiornamenti applicati dopo l'ultimo punto di ripristino (in genere per un intervallo di tempo di cinque minuti) non sono disponibili.

Quando un'istanza DB viene eseguita come implementazione Multi-AZ, risulta migliorata anche la disponibilità del database. Se si verifica un errore nella zona di disponibilità o nell'istanza DB, le conseguenze sulla disponibilità si restringono all'intervallo di tempo necessario per il completamento del failover automatico. La distribuzione su più zone di disponibilità è vantaggiosa anche per gli interventi di manutenzione programmati.

Ad esempio le attività di I/O non vengono sospese sull'istanza primaria durante la finestra di backup, perché i backup automatici vengono eseguiti sull'istanza di standby. L'applicazione di patch o la modifica alla classe dell'istanza database vengono eseguite prima sulla copia di standby, e solo in seguito viene effettuato il failover automatico. In questo modo l'impatto sulla disponibilità è limitato solo al tempo necessario per il completamento del failover.

Un altro vantaggio implicito dell'esecuzione di un'istanza DB come implementazione Multi-AZ è che il failover è automatico e non richiede alcun intervento a livello amministrativo. Nel contesto di Amazon RDS, questo significa che non devi monitorare gli eventi relativi all'istanza database né avviarne manualmente il ripristino (tramite le API RestoreDBInstanceToPointInTime o RestoreDBInstanceFromSnapshot) quando si verifica un errore in una zona di disponibilità o nell'istanza stessa.

In una distribuzione standard dell'istanza database in una zona di disponibilità singola, è possibile rilevare un aumento della latenza causata dalla replica sincrona dei dati.

No, la replica di standby Multi-AZ non può essere utilizzata per le richieste in lettura. Le implementazioni Multi-AZ sono state progettate per fornire maggiori disponibilità e durabilità, più che per migliorare il dimensionamento in lettura. Per questo motivo impiegano la replica sincrona tra l'istanza principale e quella di standby. Nelle nostre implementazioni la copia principale e quella di stand-by sono costantemente sincronizzate, ma l'istanza di stand-by non può essere utilizzata per eseguire operazioni di lettura o scrittura. Se cerchi una soluzione che garantisca scalabilità in lettura, consulta le domande frequenti relative alle Repliche di lettura.

Per creare un'implementazione multi-AZ di un'istanza database, è sufficiente fare clic su "Sì" per l'opzione "Implementazione multi-AZ" all'avvio di un'istanza DB con la Console di gestione AWS.

In alternativa, se desideri usare le API di Amazon RDS, puoi richiamare l'API CreateDBInstance e impostare il parametro "Multi-AZ" sul valore "true". Per convertire un'istanza database standard (Single-AZ) in Multi-AZ, è necessario modificarla nella Console di gestione AWS oppure utilizzare l'API ModifyDBInstance e configurare il parametro "Multi-AZ" come "true".

Per i motori dei database RDS per PostgreSQL,RDS per MySQL, RDS per MariaDB, RDS per SQL Server, RDS per Oracle e RDS per Db2, quando scegli di convertire un'istanza Amazon RDS da AZ singola a multi-AZ, si verificano i seguenti eventi:

• Viene acquisita un’istantanea dell'istanza primaria.
• Viene creata una nuova istanza in standby in una zona di disponibilità differente rispetto a quella dello snapshot.
• Viene configurata una replica sincrona tra l'istanza primaria e quella in standby.

Non è dunque previsto che si verifichi alcuna interruzione quando un'istanza viene trasformata da Single-AZ a Multi-AZ. Tuttavia, potrebbe notarsi una maggiore latenza mentre i dati sull'istanza di stand-by si allineano a quelli dell'istanza primaria.

Amazon RDS riconosce gli scenari di errore più comuni delle implementazioni Multi-AZ e avvia automaticamente il ripristino, consentendoti di riprendere l'operatività del database con la massima rapidità senza alcun intervento manuale a livello amministrativo. Amazon RDS effettua un failover automaticamente nei seguenti casi:

• Calo di disponibilità nella zona di disponibilità principale
• Perdita di connettività di rete nell'istanza principale
• Errore dell'unità di elaborazione nell'istanza principale
• Errore di storage nell'istanza principale

Nota: L'esecuzione di operazioni quali il dimensionamento dell'istanza database o l'upgrade di sistema, ad esempio l'applicazione di patch al sistema operativo, su implementazioni Multi-AZ avviene prima sull'istanza di standby per non pregiudicare la disponibilità e solo in seguito viene effettuato il failover automatico. In questo modo l'impatto sulla disponibilità è limitato al tempo necessario per il completamento del failover. Nota: le implementazioni multi-AZ di Amazon RDS non effettuano automaticamente il failover in caso di operazioni del database quali query che richiedono tempi di elaborazione particolarmente lunghi, blocchi critici o errori di danneggiamento del database.

Sì, per informarti dell'esecuzione del failover automatico Amazon RDS creerà un evento di istanza DB. Per ottenere informazioni sugli eventi correlati all'istanza DB, fai clic sulla sezione "Events" della Console di Amazon RDS, oppure usa l'API DescribeEvents. Puoi anche usare le Notifiche di eventi di Amazon RDS per ricevere avvisi quando si verifica un determinato evento di database.

Il failover viene gestito automaticamente da Amazon RDS, consentendoti di riprendere l'operatività del database con la massima rapidità senza alcun intervento manuale a livello amministrativo. Durante l'esecuzione di un failover, Amazon RDS cambia il record di nome (CNAME) dell'istanza DB in modo che punti alla copia di standby, che diventa quindi la copia principale. Ti consigliamo di seguire le opportune best practice e di implementare tentativi multipli di connessione al database a livello di applicazione.

Un failover si definisce come l'intervallo di tempo compreso tra il rilevamento di un errore sull'istanza primaria e la ripresa delle transazioni sull'istanza di standby, e in genere viene completato in uno o due minuti. Sulla durata del failover può influire anche la presenza di un numero elevato di transazioni non confermate da recuperare; per ottenere risultati ottimali, si consiglia di usare, per le implementazioni Multi-AZ, tipi di istanza di dimensioni adeguate. AWS consiglia inoltre di impiegare volumi Provisioned IOPS con istanze Multi-AZ, che consentono di ottenere prestazioni di throughput rapide, prevedibili e costanti.

Amazon RDS effettua automaticamente il failover senza alcun intervento manuale nel caso si verifichino determinate condizioni di errore. Amazon RDS, inoltre, offre un'opzione che consente di avviare un failover al riavvio di un'istanza. Puoi usare questa funzionalità tramite la Console di gestione AWS oppure richiamando l'API RebootDBInstance.

Con le implementazioni Multi-AZ, è sufficiente impostare il parametro "Multi-AZ" su "true". La creazione della copia di standby, la replica sincrona e il failover vengono gestiti automaticamente. Questo significa che non è possibile selezionare la zona di disponibilità in cui distribuire l'istanza di standby, né modificare il numero di copie di standby disponibili (Amazon RDS fornisce una copia di standby dedicata per ogni istanza DB principale). L'istanza di standby, inoltre, non può essere configurata in modo da accettare attività in lettura. Ulteriori informazioni sulle configurazioni Multi-AZ.

Sì. L'istanza di stand-by viene automaticamente assegnata in una zona di disponibilità differente rispetto all'istanza database principale, ma all'interno della stessa regione.

Sì. Per conoscere il percorso dell'istanza principale, usa la Console di gestione AWS o l'API DescribeDBInstances.

Le zone di disponibilità sono state progettate in modo da connettersi tra loro in rete con una latenza minima, quando si trovano in una stessa regione. Potrebbe essere opportuno progettare la propria applicazione e organizzare le altre risorse AWS in modo che offrano ridondanza su più zone di disponibilità, consentendo una maggiore resistenza all'applicazione in caso di errore in una zona. A questo scopo è possibile utilizzare le implementazioni Multi-AZ, che soddisfano questa esigenza a livello di database senza alcun intervento manuale a livello amministrativo.

L'utilizzo delle funzionalità di backup automatico e snapshot DB è lo stesso in una distribuzione standard in una singola zona di disponibilità e in un'implementazione Multi-AZ. Se è in esecuzione un'implementazione Multi-AZ, i backup automatici e gli snapshot DB vengono effettuati sulla copia di standby, per evitare rallentamenti nelle operazioni di I/O sull'istanza principale. In ogni caso, sia nelle implementazioni Multi-AZ sia in quelle Single-AZ, durante i backup possono verificarsi incrementi della latenza nelle operazioni di I/O (di solito di alcuni minuti).

Anche le operazioni di ripristino (sia point-in-time sia da snapshot DB) vengono avviate nelle implementazioni Single-AZ e Multi-AZ nello stesso modo. Le distribuzioni di nuove istanze DB possono essere create con le API RestoreDBInstanceFromSnapshot oppure RestoreDBInstanceToPointInTime. Queste distribuzioni possono essere sia standard sia Multi-AZ, indipendentemente dal tipo di implementazione del backup sorgente.

Con le repliche di lettura è più facile sfruttare la funzionalità di replica integrata nei motori supportati in modo da impiegare la scalabilità orizzontale delle risorse aggirando le limitazioni di capacità di un'istanza database singola nei carichi di lavoro di database particolarmente gravosi in lettura.

Per creare una replica di lettura sono sufficienti pochi clic nella Console di gestione AWS oppure l'API CreateDBInstanceReadReplica. Una volta creata la replica di lettura, gli aggiornamenti del database nell'istanza database sorgente saranno replicati utilizzando la replica asincrona integrata nel motore di database supportato. È possibile creare diverse repliche di lettura per una singola istanza DB sorgente e distribuirvi il traffico in lettura.

Poiché le repliche in lettura usano le funzioni di replica integrate nei motori supportati, possono avere punti di forza e limitazioni. In particolare, gli aggiornamenti vengono applicati prima all'istanza DB sorgente e solo successivamente alle repliche di lettura; questo sfasamento temporale può variare in modo significativo. Le repliche di lettura possono essere associate alle implementazioni multi-AZ, che già potenziano la disponibilità in scrittura e la durabilità dei dati, per sfruttare una maggiore scalabilità in lettura.

La distribuzione di una o più repliche di lettura per un'istanza DB sorgente può risultare molto utile in diversi scenari. Alcuni casi d'uso possono essere, per esempio:

• Dimensionamento oltre la capacità di calcolo o di I/O di una singola istanza database per carichi di lavoro di database gravosi in lettura. Il traffico di lettura in eccesso può essere reindirizzato a una o più repliche di lettura.
• Assegnazione di traffico in lettura mentre l'istanza DB di origine non è disponibile. Se l'istanza DB sorgente non è in grado di ricevere richieste di I/O, ad esempio durante un backup o una fase di manutenzione programmata, puoi reindirizzare il traffico in lettura alle repliche di lettura. In questo caso, è necessario ricordare che i dati sulla replica di lettura potrebbero essere obsoleti, poiché l'istanza database non è disponibile.
• Scenari relativi alla creazione di report aziendali o data warehousing. È possibile eseguire le query dei report su una replica di lettura, invece che sull'istanza database principale occupata nella produzione.
• Si può utilizzare una replica in lettura per il ripristino di emergenza dell'istanza database fonte, sia nella stessa regione AWS, sia in un'altra regione.

Sì. I backup automatici su un'istanza database fonte vanno abilitati prima di aggiungere le repliche di lettura impostando il tempo di conservazione del backup su un valore maggiore di 0. Per consentire il corretto funzionamento delle repliche di lettura, i backup devono essere abilitati.

Amazon Aurora: tutti i cluster DB.

Amazon RDS per MySQL: la creazione di repliche di lettura è supportata da tutte le istanze di DB. Per garantire le repliche di lettura, devono essere attivi i backup automatici sull'istanza DB sorgente. I backup automatici sulla replica di lettura sono supportati solo per le repliche di Amazon RDS su cui è in esecuzione MySQL 5.6 o versione successiva; le versioni 5.5 e precedenti non sono supportate.

Amazon RDS per PostgreSQL: le repliche di lettura sono supportate solo da istanze DB con PostgreSQL versione 9.3.5 o versioni successive. Le istanze PostgreSQL esistenti con versioni precedenti devono essere aggiornate alla 9.3.5 per poter sfruttare le repliche di lettura di Amazon RDS.

Amazon RDS per MariaDB: le repliche di lettura sono supportate da tutte le istanze di DB. Per garantire le repliche di lettura, devono essere attivi i backup automatici sull'istanza DB sorgente.

Amazon RDS per Oracle: supportato da versione 12.1.0.2.v12 e superiori, e da tutte le versioni 12.2 che utilizzano il modello di licenza Bring Your Own License con Oracle Database Enterprise Edition e che dispongono dell’opzione di licenza Active Data Guard.

Amazon RDS per SQL Server: le repliche di lettura sono supportate dalla licenza Enterprise Edition nella configurazione Multi-AZ quando la tecnologia di replica sottostante utilizza gruppi di disponibilità Always On per le versioni di SQL Server 2016 e 2017.

Puoi creare una replica di lettura in pochi minuti utilizzando l'API standard CreateDBInstanceReadReplica oppure in pochi passaggi nella Console di gestione AWS. Al momento della creazione di una replica di lettura, è possibile identificarla come replica di lettura specificando un identificatore SourceDBInstanceIdentifier. L’identificatore istanze DB è un identificatore di istanza database per l'istanza sorgente da cui devono essere create le repliche. Analogamente a quanto accade per le istanze DB standard, è anche possibile specificare la zona di disponibilità, la classe dell'istanza DB e la finestra di manutenzione preferenziale. La versione del motore (ad esempio PostgreSQL 9.3.5) e l'allocazione di storage di una replica di lettura vengono ereditate dall'istanza DB sorgente. 

Quando viene avviata la creazione di una replica di lettura, Amazon RDS acquisisce uno snapshot dell'istanza DB sorgente e ne avvia la replica. Di conseguenza, potrà verificarsi una breve interruzione delle operazioni di I/O sull'istanza database fonte durante l'acquisizione dello snapshot. Tale interruzione dura in genere circa un minuto; è possibile evitarla configurando l'istanza di database come implementazione Multi-AZ (perché in questo caso gli snapshot vengono acquisiti dalla copia di standby).

È inoltre in fase di sviluppo una funzionalità di ottimizzazione di Amazon RDS che consente di assegnare lo stesso snapshot sorgente a tutte le repliche di lettura create in un arco di tempo di 30 minuti, per limitare l'impatto sulle operazioni di I/O (la replica di recupero per ciascuna replica di lettura viene avviata dopo la creazione).

Puoi collegarti alle repliche di lettura esattamente come ci si connette alle istanze database standard, utilizzando l'API DescribeDBInstance o la Console di gestione AWS per recuperare gli endpoint correlati. Se usi più di una replica di lettura, sarà l'applicazione a determinare la distribuzione del traffico in lettura fra queste repliche.

Amazon RDS per MySQL, MariaDB e PostgreSQL consentono di creare fino a 15 repliche di lettura per ogni istanza database sorgente. Amazon RDS per Oracle e SQL Server consentono di creare fino a 5 repliche di lettura per ogni istanza database sorgente.

Sì, Amazon RDS (ad eccezione di RDS for SQL Server) supporta repliche di lettura tra più regioni. La quantità di tempo che passa tra scrittura dei dati sull'istanza del DB di origine e disponibilità nella replica di lettura dipende dalla latenza di rete tra le due regioni.

No. Le repliche di lettura in Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle e SQL Server sono implementate utilizzando la replica asincrona nativa di tali motori. Amazon Aurora usa un meccanismo di replica asincrono ma differente.

Se intendi usare la replica per migliorare la disponibilità in scrittura del database e proteggere gli aggiornamenti più recenti da errori, ti consigliamo di eseguire l'istanza DB come implementazione Multi-AZ. Con le repliche di lettura di Amazon RDS, che impiegano i motori nativi supportati di replica asincrona, le operazioni di scrittura sul database vengono applicate prima all'istanza DB sorgente e solo successivamente alle repliche di lettura; questo sfasamento temporale può variare in modo significativo. 

La replica impiegata dalle implementazioni Multi-AZ è invece sincrona, perciò tutte le operazioni di scrittura nell'istanza principale e in quella di standby avvengono contemporaneamente. In questo modo, gli aggiornamenti più recenti del database sono al sicuro, perché in caso di failover saranno presenti nella copia di standby. 

Le repliche delle implementazioni Multi-AZ, inoltre, sono completamente gestite. Amazon RDS monitora automaticamente lo stato di istanze DB e zone di disponibilità, avviando automaticamente il failover sulla replica di standby (o su una replica di lettura, nel caso di Amazon Aurora) in caso di problemi.

Sì. Poiché le istanze DB su più zone di disponibilità soddisfano esigenze differenti rispetto alle repliche di lettura, consigliamo di usarle entrambe all'interno degli ambienti di produzione e di associare una replica di lettura a un'implementazione di istanza di DB Multi-AZ. L'istanza DB Multi-AZ sorgente offre una maggiore disponibilità in scrittura e durata dei dati e la replica di lettura associata migliora la scalabilità del traffico in lettura.

Sì. Amazon RDS per MySQL, MariaDB, PostgreSQL e Oracle consente di abilitare la configurazione Multi-AZ sulle repliche di lettura per supportare il disaster recovery e ridurre al minimo le interruzioni dovute agli aggiornamenti dei motori.

In caso di failover Multi-AZ, le repliche di lettura associate e disponibili riprendono automaticamente la replica al completamento del failover (dopo, quindi, il recupero degli aggiornamenti dalla nuova istanza primaria).

Amazon Aurora, Amazon RDS per MySQL e MariaDB: puoi creare tre livelli di repliche di lettura. Una replica di lettura di secondo livello da una replica di lettura di primo livello esistente e una replica di terzo livello da repliche di lettura di secondo livello. Creando una replica di lettura di secondo e terzo livello, è possibile spostare parte del carico di replica dall'istanza database master a diversi livelli di replica di lettura in base alle esigenze dell'applicazione.

Nota: lo sfasamento nell'aggiornamento della replica di lettura di secondo livello potrebbe essere maggiore a causa della latenza introdotta dal livello aggiuntivo di replica poiché le transazioni vengono replicate da quella primaria alla replica di primo livello e successivamente alla replica di secondo livello. Analogamente, la replica di terzo livello può avere un ritardo rispetto alla replica di lettura di secondo livello.

Amazon RDS per Oracle e Amazon RDS per SQL Server: la creazione di repliche di lettura di secondo livello non è attualmente supportata.

Le repliche di lettura sono state progettate per il traffico in lettura. Sono previsti tuttavia dei casi d'uso in cui utenti avanzati intendono completare istruzioni SQL DDL (Data Definition Language) su repliche di lettura. Ad esempio, è possibile aggiungere un indice di database a una replica di lettura usata per la creazione di report aziendali senza aggiungere lo stesso indice all'istanza database fonte correlata.

Amazon RDS for MySQL può essere configurato per consentire le istruzioni SQL DDL su repliche di lettura. Se desideri abilitare operazioni diverse dalla lettura per una determinata replica di lettura, modifica il gruppo di parametri database attivo per la replica di lettura, configurando il parametro "read_only" su "0".

Amazon RDS per PostgreSQL non supporta al momento l'esecuzione di istruzioni SQL DDL su una replica di lettura.

Sì. Per ulteriori informazioni, consulta la Guida per l'utente di Amazon RDS.

Gli aggiornamenti all'istanza DB sorgente vengono replicati automaticamente alle repliche di lettura associate. Quando viene usata una tecnologia di replica asincrona di uno dei motori supportati, tuttavia, una replica di lettura può risultare in ritardo rispetto all'istanza DB sorgente per una serie di motivi. In genere questo accade nelle seguenti situazioni:

• Il volume di I/O in scrittura sull'istanza DB sorgente raggiunge una velocità superiore a quella della replica di lettura (questo problema, in particolare, si presenta se la capacità di elaborazione di una replica di lettura è inferiore a quella dell'istanza DB sorgente)
• Transazioni complesse o che richiedono lunghi tempi di elaborazione sull'istanza DB ritardano le operazioni di replica
• Sono presenti partizioni di rete o latenze elevate tra l'istanza DB sorgente e la replica di lettura

Le repliche di lettura ereditano i punti di forza e le limitazioni delle funzioni di replica native dei motori supportati. Quando utilizzi la funzione di replica di lettura, è importante tenere conto del potenziale sfasamento temporale tra la replica di lettura e l'istanza database sorgente o "inconsistenza".

È possibile usare l'API standard DescribeDBInstances per ottenere un elenco di tutte le istanze database implementate (incluse le repliche di lettura); in alternativa è sufficiente fare clic sulla scheda "DB Instances" (Istanze database) della console di Amazon RDS.

Amazon RDS consente di acquisire visibilità sullo sfasamento delle repliche di lettura rispetto alle istanze del database sorgente correlate. Il numero di secondi di ritardo accumulati dalla replica di lettura rispetto alla primaria viene pubblicato come metrica di Amazon CloudWatch ("Replica Lag") ed è disponibile tramite la Console di gestione AWS o le API di Amazon CloudWatch.

Per Amazon RDS per MySQL, la fonte di questa informazione è la stessa che viene visualizzata eseguendo un comando standard MySQL "Show Replica Status" (Mostra stato replica) sulla replica di lettura. Per Amazon RDS for PostgreSQL, è possibile consultare i parametri di replica usando la visualizzazione pg_stat_replication sull'istanza DB sorgente.

Amazon RDS monitora lo stato delle repliche di lettura e aggiorna il campo relativo allo stato della replica nella Console di gestione AWS inserendo il valore "Error" in caso di interruzioni (ad esempio in caso di query DML sulla replica che entrano in conflitto con gli aggiornamenti eseguiti sull'istanza database master, causa nota di errori di replica). È possibile rivedere i dettagli dell'errore in questione, segnalato dal motore MySQL, consultando il campo Replication Error (Errore di replica) e prendendo misure appropriate per risolverlo. Per ulteriori informazioni sulla risoluzione dei problemi relativi alla replica, consulta la sezione Risoluzione di un problema di replica di lettura della guida per l'utente di Amazon RDS per MySQL e PostgreSQL. 

Quando un problema relativo alla replica viene risolto, il campo "Replication State" viene modificato in "Replicating".

Perché la replica avvenga in modo efficiente, è consigliato assegnare alle repliche di lettura risorse di elaborazione e di storage pari o superiori a quelle delle rispettive istanze DB sorgente. In caso contrario, il ritardo della replica potrebbe aumentare in modo significativo, oppure la replica di lettura potrebbe esaurire lo spazio di storage per gli aggiornamenti.

Per eliminare una replica di lettura bastano l'identificatore dell'istanza database correlata inserito nell'API DeleteDBInstance oppure pochi passaggi sulla Console di gestione AWS. 

Una replica di Amazon Aurora rimarrà attiva e continuerà a ricevere il traffico in lettura anche successivamente all'eliminazione dell'istanza DB sorgente correlata. Una delle repliche nel cluster verrà automaticamente convertita in nuova istanza master e accetterà il traffico di scrittura.

Una replica di lettura di Amazon RDS for MySQL o MariaDB rimarrà attiva e continuerà a ricevere il traffico in lettura anche successivamente all'eliminazione dell'istanza DB sorgente correlata. Se, oltre all'istanza DB sorgente, desideri eliminare anche la replica di lettura, devi farne esplicita richiesta tramite l'API DeleteDBInstance o la Console di gestione AWS.

Se elimini un'istanza di database di Amazon RDS per PostgreSQL che dispone di repliche di lettura, tutte le repliche vengono promosse a istanze DB autonome e saranno in grado di ricevere traffico in lettura e in scrittura. Le nuove istanze saranno indipendenti l'una dall'altra. Se, oltre all'istanza database sorgente, desideri eliminare anche queste nuove istanze database, devi farne esplicita richiesta tramite l'API DeleteDBInstance o la Console di gestione AWS.

Le repliche di lettura vengono fatturate come istanze DB standard e prevedono le stesse tariffe. Analogamente alle istanze database standard, la tariffa basata sulle ore-istanza database per le repliche di lettura è determinata dalla classe dell'istanza della replica di lettura. Consulta la pagina dei prezzi per informazioni aggiornate sui prezzi. I trasferimenti di dati generati durante la replica dei dati tra l'istanza DB sorgente e la replica di lettura nella stessa regione AWS non saranno fatturati.

La fatturazione di una replica di lettura inizia subito dopo la sua creazione (dal momento in cui il suo stato è "attivo"). La fatturazione della replica di lettura proseguirà secondo le tariffe orarie standard per le istanze DB di Amazon RDS finché non viene inviato il comando di eliminazione.

Il monitoraggio avanzato per Amazon RDS consente una maggiore visibilità sullo stato di integrità delle istanze Amazon RDS. Sarà sufficiente attivare l'opzione "monitoraggio avanzato" per un'istanza database di Amazon RDS e impostare un livello di granularità, e la funzione monitoraggio avanzato raccoglierà informazioni critiche su processi e parametri di sistema secondo la granularità definita.

Per un livello ancora più approfondito di diagnostica e visualizzazione del carico del database e un periodo di conservazione dei dati maggiore, puoi provare Approfondimenti sulle prestazioni.

Enhanced Monitoring acquisisce i parametri a livello di sistema dell'istanza Amazon RDS, ad esempio CPU, memoria, file system e operazioni I/O su disco. Per un elenco completo dei parametri, consulta la relativa documentazione.

Enhanced Monitoring supporta tutti i motori database di Amazon RDS.

Enhanced Monitoring supporta tutti i tipi di istanza esclusi t1.micro e m1.small. Il software impegna in minima parte CPU, memoria e traffico I/O per operazioni di monitoraggio di carattere generale; consigliamo di impiegare un livello maggiore di granularità per le istanze medium o di dimensione maggiore. Per le istanze database non in ambienti di produzione, Enhanced Monitoring è disattivato di default ed è possibile lasciarlo inattivo o modificarne la granularità quando viene attivato.

Nella console è possibile consultare tutte le informazioni su processi e parametri di sistema per le istanze database di Amazon RDS su grafici intuitivi. Potrai quindi scegliere quali parametri monitorare per ciascuna istanza e personalizzare il pannello di controllo in base alle tue esigenze.

No. È possibile configurare livelli diversi di granularità per ciascuna istanza database nell'account Amazon RDS. Oltre a selezionare la granularità, è anche possibile decidere su quali istanze abilitare Enhanced Monitoring.

È possibile consultare i valori di tutti i parametri di prestazione fino a 1 ora, con una granularità massima di 1 secondo sulla base delle tue impostazioni.

I parametri provenienti da Enhanced Monitoring per Amazon RDS vengono inoltrati nell'account CloudWatch Logs. È possibile creare filtri di parametri in CloudWatch a partire da CloudWatch Logs e visualizzare i grafici nel pannello di controllo di CloudWatch. Per ulteriori informazioni, consulta la pagina di Amazon CloudWatch.

Si consiglia di usare CloudWatch per visualizzare la cronologia dei valori non disponibili nel pannello di controllo della console di Amazon RDS. Puoi monitorare le istanze Amazon RDS in CloudWatch per accertare la diagnostica di integrità dell'intero stack AWS. Al momento CloudWatch supporta un livello granularità massima di 1 minuto; per livelli inferiori di granularità, sarà utilizzata una media dei valori rilevati.

Sì. È possibile creare in CloudWatch un allarme che invii una notifica quando cambia il proprio stato. L'allarme è collegato a un singolo parametro per tutto il tempo specificato, ed esegue una o più operazioni in base alla relazione tra il valore del parametro e la soglia impostata, su più intervalli predefiniti. Per ulteriori informazioni sugli allarmi di CloudWatch, consulta la Guida per gli sviluppatori di Amazon CloudWatch.

Enhanced Monitoring per Amazon RDS offre un set di parametri sotto forma di payload JSON, inoltrati nell'account CloudWatch Logs. Il livello di granularità con cui i payload JSON vengono inoltrati è l'ultimo configurato per l'istanza Amazon RDS.

Esistono due metodi per consultare i parametri tramite pannelli di controllo o applicazioni di terze parti. Puoi impostare un feed quasi in tempo reale dei parametri negli strumenti di monitoraggio tramite gli abbonamenti a CloudWatch Logs. In alternativa, puoi usare i filtri in CloudWatch Logs per inviare i parametri a CloudWatch e integrare CloudWatch con la tua applicazione. Per ulteriori informazioni, consulta la documentazione di Amazon CloudWatch.

Enhanced Monitoring inoltra i payload JSON mediante un log nell'account CloudWatch Logs, perciò è possibile controllare il periodo di retention come qualsiasi altro flusso di CloudWatch Logs. Il periodo di retention configurato di default in CloudWatch Logs per Enhanced Monitoring è di 30 giorni. Per ulteriori informazioni su come modificare le impostazioni di conservazione, consulta la Guida per sviluppatori di Amazon CloudWatch.

Poiché i parametri vengono inoltrati in CloudWatch Logs, i costi dipenderanno dalle tariffe di trasferimento dei dati e di storage di CloudWatch Logs una volta superate le soglie del piano gratuito. Per ulteriori informazioni sui prezzi, consulta questa pagina. La quantità di informazioni trasferite per un'istanza Amazon RDS è direttamente proporzionale al livello di granularità impostato per la caratteristica Enhanced Monitoring. Per tenere sotto controllo i costi, gli amministratori potranno definire diversi livelli di granularità per ciascuna istanza all'interno del loro account.

Il volume stimato di dati inoltrati in CloudWatch Logs da Enhanced Monitoring per un'istanza è calcolato di seguito.

Il Server proxy per Amazon RDS è una funzionalità di proxy per database completamente gestita e altamente disponibile per Amazon RDS. RDS Proxy rende le applicazioni più scalabili, più resilienti rispetto ai problemi nel database e più sicure.

Il Server proxy per Amazon RDS è una funzionalità proxy per database completamente gestita, altamente disponibile e facile da usare di Amazon RDS e permette alle tue applicazioni di: 1) migliorare la scalabilità accumulando e condividendo connessioni al database; 2) migliorare la disponibilità riducendo il failover nel database fino al 66% e preservando le connessioni dell’applicazione durante i failover; e 3) migliorare la sicurezza rafforzando opzionalmente l’autenticazione IAM di AWS per i database ed eseguendo l'archiviazione sicura delle credenziali in Gestione dei Segreti AWS.

In base al tuo carico di lavoro, Amazon RDS Proxy può aggiungere una media di 5 millisecondi di latenza di rete per effettuare query o tempo di risposta alle transazioni. Se la tua applicazione non può tollerare 5 millisecondi di latenza o se non ha bisogno di gestione della connessione e di altre funzioni di RDS Proxy, puoi connettere la tua applicazione direttamente all’endpoint del database.

Il Server proxy per Amazon RDS trasforma il tuo approccio alla creazione di moderne applicazioni serverless che sfruttano il potenziale e la semplicità dei database relazionali. Per prima cosa, RDS Proxy permette alle applicazioni serverless di dimensionarsi in modo efficace effettuando il pooling delle connessioni al database e riutilizzandole. Secondo, con RDS Proxy non dovrai più gestire le credenziali del database nel tuo codice Lambda. Puoi utilizzare il ruolo di esecuzione IAM associato alla tua funzione Lambda per effettuare l’autenticazione con RDS Proxy e il tuo database. Terzo, non devi gestire le nuove infrastrutture o i nuovi codici per utilizzare tutto il potenziale delle applicazioni serverless supportate dai database relazionali. RDS Proxy è completamente gestito e dimensiona la sua capacità automaticamente sulla base delle domande dell’applicazione.

Server proxy per Amazon RDS è disponibile per Amazon Aurora compatibile con MySQL, Amazon Aurora compatibile con PostgreSQL, Amazon RDS per MariaDB, Amazon RDS per MySQL, Amazon RDS per PostgreSQL e Amazon RDS per SQL Server. Per un elenco delle versioni del motore supportate, consulta la Guida per l'utente di Amazon Aurora o la Guida per l'utente di Amazon RDS.

Amazon RDS Proxy si abilita per il database Amazon RDS con pochi clic nella console Amazon RDS. Durante l’abilitazione di RDS Proxy, devi specificare il VPC e le sottoreti dalle quali vuoi accedere a RDS Proxy. In quanto utente di Lambda, puoi abilitare il Server proxy per Amazon RDS per il tuo database Amazon RDS e impostare una funzione Lambda per accedervi con pochi clic dalla console di Lambda.

Sì. Puoi utilizzare le API di Amazon RDS Proxy per creare un proxy e definire gruppi di destinazione per associare il proxy a istanze o cluster del database specifici. Ad esempio:

aws rds create-db-proxy 
        --db-proxy-name '…' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

Trusted Language Extensions (TLE) per PostgreSQL consente agli sviluppatori di creare estensioni PostgreSQL ad alte prestazioni e di eseguirle in modo sicuro su Amazon Aurora e Amazon RDS. In questo modo, TLE migliora il time-to-market e solleva gli amministratori di database dal compito di certificare il codice (personalizzato e di terze parti) da utilizzare nei carichi di lavoro del database di produzione. Non appena decidi che un'estensione soddisfa le tue esigenze, puoi tranquillamente proseguire. Grazie a TLE, i fornitori di software indipendenti (ISV) possono offrire nuove estensioni PostgreSQL ai clienti che utilizzano Aurora e Amazon RDS.

Le estensioni PostgreSQL vengono eseguite nello stesso spazio di elaborazione per prestazioni elevate. Tuttavia, le estensioni potrebbero presentare difetti del software che possono causare l'arresto anomalo del database.

TLE per PostgreSQL offre vari livelli di protezione per ridurre questo rischio. TLE è progettato per limitare l'accesso alle risorse di sistema. Il ruolo rds_superuser può determinare chi è autorizzato a installare estensioni specifiche. Tuttavia, queste modifiche possono essere apportate solo tramite l'API TLE. TLE è progettato per limitare l'impatto di un difetto di estensione a una singola connessione al database. Oltre a queste misure di sicurezza, TLE è progettato per fornire ai DBA che ricoprono il ruolo di rds_superuser un controllo online dettagliato su chi può installare le estensioni e questi possono creare un modello di autorizzazioni per eseguirle.

Solo gli utenti dotati di privilegi sufficienti potranno effettuare operazioni di esecuzione e creazione utilizzando il comando "CREATE EXTENSION" (crea estensione) su un'estensione TLE. I DBA possono anche inserire nell'elenco dei consentiti gli "hook PostgreSQL" necessari per estensioni più sofisticate che modificano il comportamento interno del database e che in genere richiedono privilegi elevati.

TLE per PostgreSQL è disponibile per Amazon Aurora edizione compatibile con PostgreSQL e Amazon RDS su PostgreSQL nelle versioni 14.5 e successive. TLE viene implementato proprio come un'estensione PostgreSQL ed è possibile attivarlo attraverso il ruolo rds_superuser in modo simile a quello utilizzato per altre estensioni supportate su Aurora e Amazon RDS.

Puoi eseguire TLE per PostgreSQL in PostgreSQL 14.5 o versioni successive in Amazon Aurora e Amazon RDS.  

Attualmente, TLE per PostgreSQL è disponibile in tutte le regioni AWS (escluse le regioni AWS Cina) e nelle regioni AWS GovCloud.

TLE per PostgreSQL è disponibile per i clienti Aurora e Amazon RDS senza costi aggiuntivi.

Aurora e Amazon RDS supportano un set selezionato composto da oltre 85 estensioni per PostgreSQL. AWS gestisce i rischi per la sicurezza per ciascuna di queste estensioni nell'ambito del modello di responsabilità condivisa AWS. L'estensione che implementa TLE per PostgreSQL è inclusa in questo set. Le estensioni scritte da te (o ottenute da terze parti) che installi in TLE sono considerate parte del codice della tua applicazione. Pertanto, sei responsabile della sicurezza delle tue applicazioni che utilizzano estensioni TLE.

Puoi creare funzioni per sviluppatori, come la compressione bitmap e la privacy differenziale (ad esempio, query statistiche accessibili pubblicamente che proteggono la privacy delle persone).

TLE per PostgreSQL attualmente supporta JavaScript, PL/pgSQL, Perl e SQL.

Una volta che il ruolo rds_superuser ha attivato TLE per PostgreSQL, puoi implementare le estensioni TLE utilizzando il comando "SQL CREATE EXTENSION" da qualsiasi client PostgreSQL, ad esempio psql. Questo metodo è simile a quello che utilizzeresti per creare una funzione definita dall'utente scritta in un linguaggio procedurale, come PL/pgSQL o PL/Perl. Puoi controllare quali utenti sono autorizzati a implementare estensioni TLE e a utilizzare estensioni specifiche.

TLE per PostgreSQL accede al tuo database PostgreSQL esclusivamente tramite l'API TLE. I linguaggi attendibili supportati da TLE includono tutte le funzioni dell'interfaccia di programmazione del server PostgreSQL (SPI) e il supporto per gli hook PostgreSQL, incluso l'hook per il controllo della password.

Puoi trovare ulteriori informazioni sul progetto TLE per PostgreSQL visitando la pagina ufficiale di TLE su GitHub.

Le implementazioni blu/verdi di Amazon RDS sono disponibili in Amazon Aurora compatibile con MySQL, Amazon Aurora compatibile con PostgreSQL, Amazon RDS per MySQL, Amazon RDS per MariaDB e Amazon RDS per PostgreSQL. 

Le implementazioni blu/verdi di Amazon RDS sono disponibili per le edizioni di Amazon Aurora compatibili con MySQL versioni 5.6 e successive, RDS per MySQL versioni 5.7 e successive e RDS per versioni MariaDB 10.2 e successive. Le implementazioni blu/verdi sono supportate anche per le edizioni di Amazon Aurora compatibili con PostgreSQL e per Amazon RDS per PostgreSQL versioni 11.21 e successive, 12.16 e successive, 13.12 e successive, 14.9 e successive e 15.4 e successive. Puoi trovare ulteriori informazioni sulle versioni disponibili nella documentazione di Amazon Aurora e Amazon RDS. 

Le implementazioni blu/verdi di Amazon RDS sono disponibili in tutte le regioni AWS applicabili e nelle regioni AWS GovCloud.

Le implementazioni blu/verdi di Amazon RDS consentono di effettuare aggiornamenti del database più sicuri, semplici e veloci senza alcuna perdita di dati. Le implementazioni blu/verdi sono delle versioni principali o secondarie, aggiornamenti del sistema operativo, modifiche allo schema in ambienti verdi che non interrompono la replica logica, come l'aggiunta di una nuova colonna alla fine di una tabella o le modifiche alle impostazioni dei parametri del database. È possibile utilizzare le implementazioni blu/verdi per effettuare più aggiornamenti del database contemporaneamente utilizzando un unico switchover. Ciò consente di rimanere aggiornati con le patch di sicurezza, migliorare le prestazioni e accedere alle nuove funzionalità del database con tempi di inattività brevi e prevedibili.

L'esecuzione dei tuoi carichi di lavoro sulle istanze verdi avrà lo stesso prezzo di quella sulle istanze blu. Il costo dell'esecuzione su istanze blu e verdi include i nostri attuali prezzi standard per db.instances, il costo dell'archiviazione, il costo degli I/O di lettura/scrittura e di qualsiasi funzionalità abilitata, come il costo dei backup e degli Approfondimenti sulle prestazioni di Amazon RDS. Di fatto, per tutta la durata dell'implementazione blu/verde ti troverai a pagare circa il doppio del costo dell'esecuzione dei carichi di lavoro su db.instance.

Ad esempio: disponi di un database RDS per MySQL 5.7 in esecuzione su due db.instance r5.2xlarge (con un'istanza di database primaria e una replica di lettura), nella Regione AWS us-east-1 con una configurazione multi-AZ (MAZ). Ognuna delle db.instance r5.2xlarge è configurata per Amazon Elastic Block Storge (EBS) per uso generico da 20 GiB. Crei un clone della topologia dell'istanza blu utilizzando implementazioni blu/verdi di Amazon RDS, lo esegui per 15 giorni (360 ore) e quindi elimini le istanze blu dopo che il passaggio è stato completato. Le istanze blu costano 1,387 USD per 15 giorni a una tariffa on demand di 1,926 USD/ora (istanza+costo di EBS). Il costo totale per l'utilizzo delle implementazioni blu/verdi per quei 15 giorni è di 2,774 USD, che è il doppio del costo di esecuzione delle istanze blu per un tale periodo di tempo.

Le implementazioni blu/verde di Amazon RDS consentono di apportare modifiche più sicure, semplici e rapide al database; ad esempio, aggiornamenti di versioni principali o secondarie, modifiche dello schema, ridimensionamento delle istanze, modifiche dei parametri del motore e aggiornamenti di manutenzione.

Nelle implementazioni blu/verdi di Amazon RDS, l'ambiente blu è l'ambiente di produzione attuale. L'ambiente verde è il tuo ambiente di staging che dopo il passaggio diventerà il tuo nuovo ambiente di produzione.

Quando le implementazioni blu/verdi di Amazon RDS avviano uno switchover, bloccano le scritture negli ambienti blu e verdi fino al completamento del processo. Durante lo switchover, l'ambiente di staging (o ambiente verde) raggiunge il sistema di produzione, garantendo la coerenza dei dati tra l'ambiente di staging e quello di produzione. Una volta che l'ambiente di produzione e quello di staging sono completamente sincronizzati, le implementazioni blu/verdi promuovono l'ambiente di staging come ambiente di produzione, reindirizzando il traffico verso l'ambiente di produzione appena promosso. Le implementazioni blu/verdi sono progettate per abilitare le scritture nell'ambiente verde dopo che lo switchover è stato completato, prevenendo la perdita di dati durante il processo.

Se il tuo ambiente blu è una replica logica autogestita o un abbonato, bloccheremo lo switchover. Si consiglia di interrompere prima la replica nell'ambiente blu, procedere con lo switchover e quindi riprendere la replica. Al contrario, se l'ambiente blu è l'origine di una replica logica autogestita o di un publisher, è possibile continuare con lo switchover. Tuttavia, sarà necessario aggiornare la replica autogestita per eseguire la replica dall'ambiente verde dopo lo switchover.

Le implementazioni blu/verdi di Amazon RDS non cancellano il tuo vecchio ambiente di produzione. Se necessario, puoi accedervi per ulteriori convalide o per effettuare test di regressione o sulle prestazioni. Se non hai più bisogno del vecchio ambiente di produzione, puoi anche eliminarlo. Gli addebiti in fattura standard vengono applicati alle vecchie istanze di produzione fino a quando non le elimini.

La funzione dei guardrail nel processo di passaggio delle implementazioni blu/verdi di Amazon RDS è quella di bloccare la scrittura sugli ambienti blu e verde fino a quando l'ambiente verde non si riporta in pari prima del passaggio. Le implementazioni blu/verdi eseguono anche controlli dell'integrità del primario e delle repliche negli ambienti blu e verde. Inoltre, eseguono controlli dell'integrità della replica, ad esempio, per verificare se la replica è stata interrotta o se sono presenti errori. Rilevano transazioni di lunga durata tra i tuoi ambienti blu e verdi. Puoi specificare il tempo di inattività massimo tollerabile (fino a 30 secondi) e se la transazione in corso lo supera, il passaggio andrà in timeout.

No, le implementazioni blu/verdi di Amazon RDS non supportano database globali,server proxy per Amazon RDS, repliche di lettura tra regioni o repliche di lettura a cascata.

No, al momento non puoi utilizzare le implementazioni blu/verdi di Amazon RDS per eseguire il rollback delle modifiche.

MySQL protegge gli utenti dalla perdita di dati scrivendoli due volte in memoria (prima nel "buffer doublewrite" e poi nell'archiviazione tabelle) in pagine da 16 KiB, in un sistema di archiviazione durevole. Le scritture ottimizzate per Amazon RDS scrivono le pagine di dati da 16 KiB direttamente nei file di dati in modo affidabile e duraturo, in un solo passaggio, utilizzando la funzionalità Torn Write Prevention di AWS Nitro System.

Le scritture ottimizzate per Amazon RDS sono disponibili per la versione principale di MySQL 8.0.30 e successive.

Le scritture ottimizzate di Amazon RDS sono disponibili per le istanze db.r6i e db.r5b. Sono disponibili in tutte le Regioni in cui sono presenti queste istanze, escluse le Regioni AWS Cina.

No. Amazon Aurora edizione compatibile con MySQL evita a priori l'impiego del "buffer doublewrite". Infatti, Amazon Aurora replica i dati in sei modi diversi su tre zone di disponibilità (AZ) e utilizza un approccio basato sul quorum per scrivere i dati in modo duraturo e per leggerli correttamente in seguito.

Al momento, questa versione iniziale non supporta l'abilitazione delle scritture ottimizzate per Amazon RDS per le istanze di database esistenti, anche se la classe di istanza supporta le scritture ottimizzate.

Le scritture ottimizzate per Amazon RDS sono disponibili per i clienti di RDS per MySQL senza costi aggiuntivi.

I carichi di lavoro che utilizzano oggetti temporanei in MySQL e MariaDB per l'elaborazione delle query possono trarre beneficio dalle letture ottimizzate di Amazon RDS. Le letture ottimizzate collocano oggetti temporanei nell'archiviazione dell'istanza basata su NVMe dell'istanza di database, anziché nel volume Amazon Elastic Block Store. In questo modo si può arrivare ad aumentare fino al doppio la velocità di elaborazione delle query complesse.

Le letture ottimizzate per Amazon RDS sono disponibili per RDS per MySQL sulle versioni di MySQL 8.0.28 e successive e su RDS per MariaDB sulle versioni MariaDB 10.4.25, 10.5.16, 10.6.7 e successive.

Le letture ottimizzate per Amazon RDS sono disponibili in tutte le regioni in cui sono disponibili le istanze db.r5d, db.m5d, db.r6gd e db.m6gd, X2idn e X2iedn. Per ulteriori informazioni, consulta la documentazione sulle classi di istanze database di Amazon RDS.

I clienti dovrebbero utilizzare le letture ottimizzate per Amazon RDS in presenza di carichi di lavoro che richiedono query complesse o analisi a scopo generico, o che richiedono gruppi complessi, catalogazioni, aggregazioni di hash, join a carico elevato e CTE (Common Table Expressions). Questi casi d'uso comportano la creazione di tabelle temporanee, consentendo alle letture ottimizzate di accelerare l'elaborazione delle query del carico di lavoro.

Sì, i clienti possono convertire il loro database Amazon RDS esistente per utilizzare le letture ottimizzate per Amazon RDS spostando il carico di lavoro in un'istanza abilitata per la lettura ottimizzata. Le letture ottimizzate sono disponibili anche per impostazione predefinita su tutte le classi di istanza supportate. Se stai eseguendo il tuo carico di lavoro su istanze db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn e X2iedn, stai già traendo vantaggio dalle letture ottimizzate.