Amazon Aurora è un servizio di database relazionale moderno che offre prestazioni e disponibilità elevata su vasta scala, edizioni compatibili con MySQL e PostgreSQL totalmente open source e una gamma di strumenti di sviluppo per creare applicazioni serverless e basate sul machine learning (ML).

Aurora vanta un sistema di archiviazione distribuito con tolleranza ai guasti e riparazione automatica che è disaccoppiato dalle risorse di calcolo e che aumenta fino a 128 TiB per istanza di database. Il servizio offre prestazioni e disponibilità elevate con un massimo di quindici repliche di lettura a bassa latenza, ripristino point-in-time (PITR), backup continuo su Amazon Simple Storage Service (Amazon S3) e replica su tre zone di disponibilità (AZ).

Aurora è anche un servizio completamente gestito che automatizza le attività di amministrazione che richiedono tempo come il provisioning dell'hardware, l'impostazione del database, l'applicazione delle patch e i backup, fornendo al contempo la sicurezza, la disponibilità e l'affidabilità dei database commerciali a un decimo del costo.

Amazon Aurora è completamente compatibile con i database MySQL open-source esistenti e aggiunge regolarmente assistenza per le nuove versioni. Ciò significa che puoi eseguire facilmente la migrazione dei database MySQL da e verso Aurora utilizzando gli strumenti di importazione/esportazione standard o gli snapshot. Significa anche che la maggior parte del codice, delle applicazioni, dei driver e degli strumenti già impiegati con i database MySQL può essere utilizzata con Aurora con modifiche minime o senza alcuna modifica. Questo rende facile lo spostamento delle applicazioni tra i due motori.

Puoi visualizzare le informazioni sulla compatibilità della versione corrente di Amazon Aurora MySQL nella documentazione.

Amazon Aurora è completamente compatibile con i database PostgreSQL open-source esistenti e aggiunge regolarmente assistenza per le nuove versioni. In questo modo puoi migrare facilmente i database PostgreSQL verso e da Aurora usando gli strumenti di import/export standard o gli snapshot. Significa anche che la maggior parte del codice, delle applicazioni, dei driver e degli strumenti già usati con i database PostgreSQL può essere usata con Aurora con modifiche minime o senza alcuna modifica.

Puoi visualizzare le informazioni sulla compatibilità della versione corrente di Amazon Aurora PostgreSQL nella documentazione.

Amazon supporta pienamente Aurora PostgreSQL e tutte le estensioni disponibili con Aurora. Se ti occorre il supporto per Aurora PostgreSQL, contatta il Supporto AWS. Se disponi di un account attivo del Supporto AWS Premium, potrai contattare il servizio per i problemi specifici di Aurora.

Per provare Aurora, accedi alla Console di gestione AWS, seleziona RDS nella categoria Database e scegli Amazon Aurora come motore di database. Per indicazioni e risorse dettagliate, consulta la nostra pagina Nozioni di base su Amazon Aurora.

Puoi vedere la disponibilità delle Regioni per Aurora qui.

Per eseguire la migrazione da MySQL ad Aurora e viceversa esistono diverse opzioni:

• È possibile utilizzare l'utility mysqldump standard per esportare i dati da MySQL e l'utility mysqlimport per importare i dati in Aurora e viceversa.
• È inoltre possibile utilizzare la funzionalità di migrazione snapshot database di Amazon RDS per eseguire la migrazione di uno snapshot database Amazon RDS per MySQL in Aurora utilizzando la Console di gestione AWS.

Nella maggior parte dei casi, il processo di migrazione verso Aurora viene completato in meno di un'ora; la durata effettiva dipende tuttavia dal formato e dalle dimensioni del set di dati. Per ulteriori informazioni, consulta il whitepaper Best Practices for Migrating MySQL Databases to Amazon Aurora (Best practice per la migrazione di database MySQL in Amazon Aurora).

Per eseguire la migrazione da PostgreSQL ad Aurora e viceversa esistono diverse opzioni:

• È possibile utilizzare l'utility pg_dump standard per esportare i dati da PostgreSQL e l'utility pg_restore per importare i dati in Aurora e viceversa.
• È inoltre possibile utilizzare la funzionalità di migrazione snapshot database di RDS per eseguire la migrazione di uno snapshot database di Amazon RDS per PostgreSQL in Aurora utilizzando la Console di gestione AWS.

Nella maggior parte dei casi, il processo di migrazione verso Aurora viene completato in meno di un'ora; la durata effettiva dipende tuttavia dal formato e dalle dimensioni del set di dati.

Per eseguire la migrazione delle applicazioni SQL Server verso Amazon Aurora nell'edizione compatibile con PostgreSQL, puoi utilizzare Babelfish per Aurora PostgreSQL. Le tue applicazioni funzioneranno senza alcuna modifica. Per ulteriori informazioni, consulta la documentazione di Babelfish.

No, Aurora funziona con i driver di database PostgreSQL standard.

Amazon Aurora garantisce incrementi significativi a livello di prestazioni rispetto a MySQL grazie all'integrazione avanzata del motore del database con un livello di archiviazione virtualizzato basato su SSD appositamente sviluppato per i carichi di lavoro del database, riducendo le operazioni di scrittura nel sistema di archiviazione, nonché il conflitto tra blocchi e permettendo l'eliminazione dei ritardi creati dai thread dei processi del database.

I nostri test con SysBench su istanze r3.8xlarge hanno dimostrato che Amazon Aurora è in grado di offrire oltre 500.000 selezioni/sec e 100.000 aggiornamenti/sec, ovvero prestazioni cinque volte superiori allo stesso benchmark eseguito in MySQL con lo stesso hardware. Per istruzioni dettagliate su questo benchmark e su come replicarlo, consulta la Guida Amazon Aurora nell'edizione compatibile con MySQL Performance Benchmarking.

Amazon Aurora garantisce incrementi significativi a livello di prestazioni di PostgreSQL grazie all'integrazione avanzata del motore di database con un livello di archiviazione virtualizzato basato su SSD appositamente sviluppato per i carichi di lavoro del database, alla riduzione delle operazioni di scrittura nel sistema di archiviazione, alla riduzione del conflitto tra blocchi e all'eliminazione dei ritardi creati dai thread dei processi del database.

I nostri test con SysBench su istanze r4.16xlarge hanno dimostrato che Amazon Aurora è in grado di offrire selezioni/sec e aggiornamenti/sec oltre tre volte superiori allo stesso benchmark eseguito in PostgreSQL con lo stesso hardware. Per istruzioni dettagliate su questo benchmark e su come replicarlo, consulta la Guida Amazon Aurora nell'edizione compatibile con PostgreSQL Performance Benchmarking.

Amazon Aurora è compatibile con MySQL, perciò gli strumenti e le applicazioni MySQL esistenti potranno essere eseguiti senza alcuna modifica. Tuttavia, una delle aree in cui le prestazioni di Amazon Aurora risultano migliorate rispetto a MySQL è costituita dai carichi di lavoro a elevata simultaneità. Per ottimizzare la velocità di trasmissione effettiva del carico di lavoro in Amazon Aurora, consigliamo di creare applicazioni in grado di gestire un numero elevato di query e transazioni simultanee.

Amazon Aurora è compatibile con PostgreSQL, perciò gli strumenti e le applicazioni PostgreSQL esistenti potranno essere eseguiti senza alcuna modifica. Tuttavia, una delle aree in cui le prestazioni di Amazon Aurora risultano migliorate rispetto a PostgreSQL è costituita dai carichi di lavoro a elevata simultaneità. Per ottimizzare la velocità di trasmissione effettiva del carico di lavoro in Amazon Aurora, consigliamo di creare applicazioni in grado di gestire un numero elevato di query e transazioni simultanee.

Consulta la pagina dei prezzi di Aurora per avere informazioni aggiornate.

Al momento il Piano gratuito AWS non prevede alcuna offerta per Aurora. Tuttavia, Aurora archivia in modo duraturo i tuoi dati in tre zone di disponibilità in una regione e addebita una sola copia dei dati. Non vengono addebitati costi per i backup fino al 100% delle dimensioni del cluster di database. Inoltre, non vengono addebitati costi per gli snapshot durante il periodo di conservazione dei backup configurato per il cluster di database.

No, la replica di Aurora è inclusa nel prezzo. Il costo verrà addebitato in base allo spazio di archiviazione utilizzato dal database nel layer di database e non in base allo spazio di archiviazione utilizzato dal layer di archiviazione virtualizzato di Aurora.

Le operazioni I/O vengono eseguite dal motore di database Aurora nel relativo layer di archiviazione virtualizzato basato su SSD. Ogni operazione di lettura delle pagine del database viene considerata un I/O.
Il motore di database Aurora esegue le letture nel layer di storage per recuperare le pagine del database non presenti in memoria nella cache:

• Se il traffico di query può essere fornito totalmente dalla memoria o dalla cache, non ti sarà addebitato alcun costo per il recupero delle pagine di dati dalla memoria.
• Se il traffico di query non può essere fornito totalmente dalla memoria, ti saranno addebitati dei costi per ogni pagina di dati che sarà necessario recuperare dall'archiviazione.
  Ogni pagina di database è di 16 KB in Amazon Aurora nell'edizione compatibile con MySQL e 8 KB in Aurora nell'edizione compatibile con PostgreSQL.

Il servizio Aurora è stato sviluppato in modo da eliminare le operazioni I/O non necessarie per ridurre i costi e garantire la disponibilità delle risorse per la gestione del traffico di lettura/scrittura. Le operazioni I/O di scrittura vengono consumate solo quando vengono rieseguiti registri di log su Aurora nell'edizione compatibile con MySQL o quando vengono scritti in anticipo registri di log su Aurora nell'edizione compatibile con PostgreSQL nel livello di archiviazione allo scopo di rendere le scritture durevoli.

Le operazioni I/O di scrittura vengono conteggiate in unità di 4 KB. Ad esempio, un registro di log la cui dimensione è pari a 1.024 byte viene conteggiato come un'operazione I/O. Tuttavia, se il registro di log è più grande di 4 KB, sarà necessaria più di un'operazione I/O per conservarlo.

Le operazioni di scrittura simultanee i cui registri di log hanno dimensioni minori di 4 KB potrebbero essere raggruppate in batch dal motore di database Aurora per ottimizzare il consumo di I/O. Diversamente dai motori di database tradizionali, Aurora non scarica pagine di dati di scarsa qualità nell'archiviazione.

È possibile visualizzare il numero di richieste I/O utilizzate da un'istanza di Aurora nella Console di gestione AWS. Per verificare il consumo di I/O, passa alla sezione Amazon RDS della console, controlla l'elenco delle istanze, seleziona le istanze Aurora, quindi cerca i parametri "VolumeReadIOPs" e "VolumeWriteIOPs" nella sezione relativa al monitoraggio.

Per ulteriori informazioni sui prezzi delle operazioni I/O, visita la pagina dei prezzi di Aurora. Le operazioni I/O di lettura e scrittura vengono addebitate quando si configurano i cluster di database nella configurazione Aurora Standard. Non vengono invece addebitati costi per le operazioni I/O di lettura e scrittura quando si configurano i cluster di database su Amazon Aurora I/O-Optimized.

Aurora ti offre la flessibilità necessaria per ottimizzare la spesa del database scegliendo tra due opzioni di configurazione in base alle tue esigenze in termini di rapporto prezzo/prestazioni e prevedibilità/prezzo. Le due opzioni di configurazione sono Aurora Standard e Aurora ottimizzato per I/O. Nessuna delle due opzioni richiede il provisioning anticipato di I/O o spazio di archiviazione ed entrambe sono in grado di dimensionare le operazioni I/O per supportare le applicazioni più impegnative.

Aurora Standard è una configurazione di cluster di database che offre prezzi convenienti per la maggior parte delle applicazioni con un utilizzo di I/O da basso a moderato. Con Aurora Standard, si pagano istanze di database, spazio di archiviazione e I/O pay-per-request.

Aurora ottimizzato per I/O è una configurazione di cluster di database che offre prestazioni di prezzo migliorate per applicazioni ad alta intensità di I/O come sistemi di elaborazione dei pagamenti, sistemi di e-commerce e applicazioni finanziarie. Inoltre, se la spesa I/O supera il 25% della spesa totale del database Aurora, puoi risparmiare fino al 40% sui costi per carichi di lavoro ad alta intensità di I/O con Aurora ottimizzato per I/O. Aurora ottimizzato per I/O offre prezzi prevedibili per tutte le applicazioni, in quanto non sono previsti costi per le operazioni I/O di lettura e scrittura. Di conseguenza, questa configurazione è ideale per i carichi di lavoro ad alta variabilità di I/O.

Aurora I/O-Optimized è la scelta ideale quando sono necessari costi prevedibili per qualsiasi applicazione. Questa opzione offre un rapporto prezzo/prestazioni migliorato per le applicazioni ad alta intensità di I/O, che richiedono una velocità di trasmissione effettiva in scrittura elevata o eseguono query analitiche per l'elaborazione di grandi quantità di dati. Per i clienti con una spesa I/O superiore al 25% della fattura Aurora, puoi risparmiare fino al 40% sui costi per carichi di lavoro ad alta intensità di I/O con Aurora ottimizzato per I/O.

È possibile utilizzare l'esperienza in un clic disponibile nella Console di gestione AWS per modificare il tipo di archiviazione dei cluster di database esistenti in Aurora I/O-Optimized. È inoltre possibile apportare la modifica richiamando l'Interfaccia della linea di comando AWS (AWS CLI) o l'SDK AWS.

È possibile effettuare il passaggio dei cluster di database esistenti ad Aurora I/O-Optimized una volta ogni 30 giorni. È possibile tornare ad Aurora Standard in qualsiasi momento.

Sì, Aurora I/O-Optimized funziona con le istanze riservate Aurora esistenti. Aurora tiene automaticamente conto della differenza di prezzo tra Aurora Standard e Aurora I/O-Optimized con istanze riservate. Gli sconti sulle istanze riservate con Aurora I/O-Optimized consentono un ulteriore risparmio sulla spesa di I/O.

Non sono previste modifiche al prezzo di backtrack, snapshot, esportazione o backup continuo con Aurora I/O-Optimized.

Sì, per la replica dei dati tra Regioni continueranno a essere applicate le tariffe per le operazioni I/O necessarie. Aurora I/O-Optimized non addebita alcun costo per le operazioni I/O di lettura e scrittura, che sono diverse dalla replica dei dati.

Non sono previsti costi aggiuntivi per Amazon Aurora Optimized Reads per Aurora PostgreSQL oltre al prezzo delle istanze R6id basate su Intel e R6gd basate su Graviton. Per maggiori informazioni, visita la pagina dei prezzi di Aurora.

La soglia minima di archiviazione è pari a 10 GB. In base all'utilizzo del database, la capacità di archiviazione di Amazon Aurora aumenterà automaticamente fino a 128 TiB, con incrementi di 10 GB senza alcuna conseguenza per le prestazioni del database. Non è necessario effettuare il provisioning di archiviazione in anticipo.

Esistono due modi per ridimensionare le risorse di calcolo associate alla mia istanza di database Amazon Aurora: tramite Aurora Serverless e tramite regolazione manuale.

Puoi utilizzare Aurora Serverless, una configurazione on demand a scalabilità automatica per Amazon Aurora, per dimensionare le risorse di calcolo del database in base alla domanda dell’applicazione. Consente di eseguire il tuo database nel cloud senza doverne gestire la capacità. Puoi specificare l’intervallo di capacità del database desiderato e il database verrà dimensionato in base alle necessità dell’applicazione. Scopri di più nella Guida per l’utente di Aurora Serverless.

Puoi anche dimensionare manualmente le risorse di calcolo associate al database selezionando il tipo di istanza database desiderato nella Console di gestione AWS. La modifica richiesta verrà applicata durante la finestra di manutenzione specificata oppure puoi utilizzare il flag "Applica immediatamente" per modificare immediatamente il tipo di istanza database.

Durante l'esecuzione dell'operazione di dimensionamento entrambe queste opzioni incideranno sulla disponibilità per alcuni minuti. Tieni presente che verranno applicate anche tutte le altre modifiche di sistema in sospeso.

Nelle istanze di database di Amazon Aurora i backup automatici continui sono sempre abilitati. I backup non hanno alcuna influenza sulle prestazioni del database.

Sì. La creazione di snapshot non ha alcuna influenza sulle prestazioni. Il ripristino dei dati mediante gli snapshot DB richiede tuttavia la creazione di una nuova istanza DB.

Amazon Aurora rende automaticamente i dati durevoli in tre zone di disponibilità (AZ) all'interno di una regione e tenta automaticamente di ripristinare il tuo database in una AZ integra senza alcuna perdita di dati. Nel caso improbabile che i dati non siano disponibili nell'archiviazione di Amazon Aurora, è possibile eseguire il ripristino da uno snapshot DB oppure un'operazione di ripristino point-in-time in una nuova istanza. Tieni presente che in un'operazione di ripristino point-in-time, è possibile il ripristino fino a un massimo di 5 minuti prima.

È possibile scegliere di creare uno snapshot DB finale quando viene eliminata l'istanza DB. In questo caso, è possibile usare questo snapshot DB per ripristinare l'istanza di database eliminata in un secondo momento. Dopo l'eliminazione dell'istanza di database, Amazon Aurora mantiene questo snapshot DB creato dall'utente finale insieme a tutti gli altri snapshot DB creati manualmente. Solo gli snapshot DB vengono mantenuti dopo l'eliminazione dell'istanza DB, ovvero i backup automatici creati per il ripristino point-in-time non vengono conservati.

Sì. Aurora consente di creare snapshot dei database da utilizzare in un secondo momento per ripristinarli. Condividere uno snapshot con un altro account AWS è possibile; il proprietario del secondo account potrà usare lo snapshot per ripristinare un database contenente i tuoi dati. Puoi anche scegliere di rendere pubblici gli snapshot, in modo che chiunque possa ripristinare un database contenente i tuoi dati pubblici.

Puoi utilizzare questa funzione per condividere i dati tra i vari ambienti (produzione, sviluppo/test, staging, ecc.) che hanno diversi account AWS, oltre a mantenere i backup di tutti i dati protetti in un account separato nell’improbabile caso in cui l'account AWS principale sia compromesso.

Non viene addebitato alcun costo per la condivisione di snapshot tra account. Tuttavia, saranno addebitati i costi per gli snapshot e per i database ripristinati dagli snapshot condivisi. Per ulteriori informazioni, consulta la pagina dei prezzi di Aurora.

La condivisione automatica di snapshot DB non è supportata. Per condividere uno snapshot, è necessario crearne una copia e condividerla manualmente.

È possibile condividere manualmente snapshot con un massimo di 20 ID account AWS. Se desideri condividere uno snapshot con più di 20 account, puoi condividerlo pubblicamente oppure contattare il supporto per modificare le limitazioni.

Gli snapshot di Aurora possono essere condivisi all’interno di tutte le regioni AWS in cui è disponibile Aurora.

No. Gli snapshot condivisi di Aurora saranno accessibili esclusivamente da account nella stessa regione dell'account che li condivide.

Sì, puoi condividere snapshot di Aurora crittografati.

Amazon Aurora suddivide automaticamente il volume del database in segmenti da 10 GB su più dischi. Ogni blocco da 10 GB di tale volume viene replicato sei volte in tre zone di disponibilità. Amazon Aurora è stato progettato per gestire in modo trasparente la perdita di un massimo di due copie di dati senza compromettere la disponibilità delle operazioni di scrittura del database e di un massimo di tre copie senza compromettere la disponibilità delle operazioni di lettura.

Per lo storage di Amazon Aurora viene inoltre eseguita la riparazione automatica. I blocchi di dati e i dischi vengono analizzati continuamente alla ricerca di eventuali errori e riparati automaticamente.

A differenza di altri database, dopo un arresto anomalo del database Amazon Aurora non deve rieseguire il log di ripristino dall'ultimo checkpoint del database (in genere cinque minuti) e confermare l'applicazione di tutte le modifiche prima di rendere disponibile il database per le operazioni. Ciò consente di ridurre i tempi di riavvio del database a meno di 60 secondi nella maggior parte dei casi.

Amazon Aurora sposta la cache del buffer esternamente al processo del database e la rende subito disponibile al riavvio. Ciò evita di limitare l'accesso finché la cache non viene ripopolata per evitare sbalzi a livello di prestazioni.

Amazon Aurora nell'edizione compatibile con MySQL e Amazon Aurora nell'edizione compatibile con PostgreSQL supportano le repliche di Amazon Aurora che condividono lo stesso volume sottostante dell’istanza primaria all’interno della stessa regione AWS. Gli aggiornamenti eseguiti dall'istanza primaria sono visibili in tutte le repliche di Amazon Aurora.

Con Amazon Aurora nell'edizione compatibile con MySQL, è inoltre possibile creare repliche di lettura MySQL attraverso più regioni in base al motore di replica basato su binlog di MySQL. Nelle repliche di lettura di MySQL i dati provenienti dall'istanza primaria vengono riprodotti nella replica come transazioni. Per la maggior parte dei casi d'uso, compresi il dimensionamento delle operazioni di lettura e la disponibilità elevata, consigliamo di usare le repliche di Amazon Aurora.

È possibile combinare questi due tipi di replica con estrema flessibilità in base alle specifiche esigenze delle applicazioni:

Hai a disposizione due ulteriori opzioni per effettuare delle repliche oltre a quelle elencate di sopra. Puoi utilizzare Amazon Global Database per repliche fisiche più veloci tra cluster di Aurora in regioni differenti. E per le repliche tra Aurora e database nell'edizione compatibile con MySQL diversi da Aurora (anche al di fuori di AWS), puoi impostare la tua replica di binlog personale auto-gestita.

Sì, è possibile configurare repliche di Aurora in più regioni tramite replica logica o fisica. La replica fisica, definita Amazon Aurora Global Database, utilizza un'infrastruttura dedicata che lascia i database completamente disponibili al servizio dell’applicazione e può replicarsi in un massimo di cinque regioni secondarie con latenza tipica di meno di un secondo. È disponibile per Aurora nell'edizione compatibile con MySQL e Aurora nell'edizione compatibile con PostgreSQL.

Per letture globali a bassa latenza e ripristino di emergenza, si consiglia di utilizzare Amazon Aurora Global Database.
Aurora supporta la replica logica nativa in ogni motore di database (binlog per MySQL e slot di replica PostgreSQL per PostgreSQL), permettendoti di replicare sui database Aurora e non, anche tra più regioni.

Aurora nell'edizione compatibile con MySQL offre anche una caratteristica di replica di lettura tra più regioni facile da utilizzare che supporta fino a cinque regioni AWS secondarie. Si basa su una replica binlog di MySQL a thread singolo; lo sfasamento della replica può variare in base alla frequenza di modifica/applicazione e ai ritardi a livello di comunicazione di rete tra le regioni selezionate.

Sì, puoi aggiungere fino a 15 repliche di Aurora in ogni cluster su più regioni che condividerà la stessa archiviazione sottostante della replica corrispondente. Una replica su più regioni sarà quella principale sul cluster, mentre le repliche di Aurora nel cluster avranno in genere un ritardo rispetto alla replica principale di poche decine di millisecondi.

Sì, puoi promuovere la replica su più regioni a replica principale tramite la console Amazon RDS. La durata del processo di promozione di replica logica (binlog) in genere è di pochi minuti e dipende dal carico di lavoro. La replica su più regioni verrà interrotta al momento dell'avvio del processo di promozione.

Il Database globale Amazon Aurora consente la promozione di una regione secondaria per eseguire carichi di lavoro di lettura/scrittura completi in meno di un minuto.

Sì. È possibile assegnare un livello di priorità maggiore ad ogni istanza in un cluster. Quando si verifica un errore nell'istanza primaria, Amazon RDS promuove la replica con la priorità maggiore a istanza primaria. Se due o più repliche di Aurora hanno la stessa priorità, Amazon RDS dà precedenza alla replica di dimensioni più grandi. Se due o più repliche di Aurora hanno le stesse priorità e dimensioni, Amazon RDS dà precedenza in modo arbitrario a una replica nello stesso livello di promozione.

Per ulteriori informazioni sulla logica di failover, consulta la Guida per l’utente di Amazon Aurora.

Sì, i livelli di priorità possono essere modificati in qualsiasi momento. La sola modifica dei livelli di priorità non causerà un failover.

È possibile assegnare alle repliche che non desideri utilizzare come istanze primarie un livello di priorità inferiore. Tuttavia, se le repliche con livelli di priorità maggiori nel cluster non sono integre o non sono disponibili, Amazon RDS promuoverà quelle repliche con priorità minore.

È possibile aggiungere repliche di Amazon Aurora. Le repliche di Aurora all’interno della stessa regione AWS condivideranno la stessa archiviazione sottostante dell’istanza primaria. Qualsiasi replica di Amazon Aurora può essere promossa di livello e impostata come replica primaria senza alcuna perdita di dati; quindi, essere usata per ottimizzare la tolleranza ai guasti in caso di errore di un'istanza di database primaria.

Per migliorare la disponibilità del database, è sufficiente creare da una a 15 repliche in una qualsiasi delle tre zone di disponibilità. Amazon RDS includerà automaticamente tali repliche nella selezione primaria del failover in caso di interruzione della disponibilità del database. È possibile utilizzare Amazon Aurora Global Database se si desidera che il database copra più regioni AWS. Ciò replicherà i dati senza alcun impatto sulle prestazioni del database e offre il servizio di ripristino di emergenza in caso di interruzioni a livello regionale.

Il failover viene gestito automaticamente da Amazon Aurora, consentendoti di riprendere l'operatività del database con la massima rapidità senza alcun intervento manuale a livello amministrativo.

• Se è disponibile una replica di Aurora nella stessa zona di disponibilità o in una zona diversa, in caso di failover Aurora fa in modo che il record di nome canonico (CNAME) dell'istanza di database punti alla replica integra, che viene alzata di livello e impostata come nuova replica primaria. L'esecuzione completa dell'intero processo di failover in genere impiega meno di 30 secondi. Per una maggiore resilienza e failover più rapidi, prendi in considerazione l'utilizzo di Server proxy per Amazon RDS, che si connette automaticamente all'istanza database di failover preservando le connessioni alle applicazioni. Il proxy rende i failover trasparenti alle applicazioni e riduce i tempi di failover fino al 66%.
• Se Aurora Serverless v1 è in esecuzione e l'istanza DB o la zona di disponibilità diventano non disponibili, Aurora ricrea automaticamente l'istanza DB in una zona di disponibilità diversa. Aurora Serverless v2 funziona come se venisse eseguito il provisioning per il failover e altre funzionalità ad alta disponibilità. Per ulteriori informazioni, consulta Aurora Serverless v2 ed elevata disponibilità. 
• Se non si dispone di una replica di Aurora (istanza singola) e se Aurora Serverless non è in esecuzione, Aurora tenterà di creare una nuova istanza database nella stessa zona di disponibilità dell'istanza originale. Questa sostituzione dell'istanza originale viene eseguita in base al tentativo migliore e potrebbe non avvenire, ad esempio, se si verifica un problema che interessa in qualche modo la zona di disponibilità.
  

L'applicazione deve tentare di ristabilire le connessioni al database in caso di perdita della connessione. Il servizio di ripristino di emergenza in più regioni è un processo manuale, in cui si promuove una regione secondaria ad incaricata di carichi di lavoro di lettura/scrittura.

Amazon Aurora rileva automaticamente un problema relativo all'istanza primaria e attiva un failover. Se si sta utilizzando l'endpoint cluster, le tue connessioni di lettura/scrittura verranno automaticamente reindirizzate a una replica di Amazon Aurora che verrà promossa a primaria.

Inoltre, il traffico di lettura gestito dalle repliche di Aurora verrà brevemente interrotto. Se si sta utilizzando l'endpoint di lettura del cluster per indirizzare il traffico in lettura alla replica di Aurora, le connessioni in sola lettura verranno orientate alla replica di Aurora appena promossa fino a quando il vecchio nodo primario non viene recuperato come replica.

Dal momento che le repliche di Amazon Aurora condividono lo stesso volume di dati dell'istanza primaria all’interno della stessa regione AWS, virtualmente non si verifica alcun ritardo di replica. In genere sono stati rilevati ritardi nell'ordine di decine di millisecondi.

Per la replica in più regioni, il ritardo di replica logica basato sul log binario può aumentare in modo indefinito in base alla frequenza di modifica/applicazione e ai ritardi a livello di comunicazione di rete. Tuttavia, in condizioni standard è comune rilevare meno di un minuto di ritardo di replica. Le repliche su più regioni che utilizzano la replica fisica del Database globale Amazon Aurora hanno, in genere, uno sfasamento di meno di un secondo.

Sì, puoi impostare repliche di binlog tra un'istanza di Aurora nell'edizione compatibile con MySQL e un database MySQL esterno. Può trattarsi di un altro database eseguito su Amazon RDS o un database auto-gestito su AWS o completamente al di fuori di AWS.

Se stai eseguendo Aurora nell'edizione compatibile con MySQL 5.7, considera di impostare una replica di binlog basata su GTID. Ciò ti permette di ottenere delle repliche omogenee senza perdere transazioni o generare conflitti, anche dopo failover o tempi di inattività.

Il Database globale Amazon Aurora è una caratteristica che consente a un singolo database Amazon Aurora di coprire più regioni AWS. Replica i dati senza alcun impatto sulle performance del database, abilita letture locali veloci con, in genere, una latenza di meno di un secondo in ogni regione e assicura il servizio di ripristino di emergenza in caso di interruzioni a livello regionale. Nella rara eventualità di rallentamenti o interruzioni a livello regionale, una regione secondaria può ottenere il pieno delle capacità di lettura/scrittura in meno di un minuto. Questa caratteristica è disponibile per Aurora nell'edizione compatibile con MySQL e Aurora nell'edizione compatibile con PostgreSQL.

È possibile creare un Database globale Amazon Aurora in pochi clic dalla console di Amazon RDS. In alternativa puoi usare il Software Development Kit (SDK) di AWS o l'interfaccia a riga di comando (CLI) di AWS. È necessario eseguire il provisioning di almeno un'istanza per regione nel tuo Database globale Amazon Aurora.

È possibile creare fino a cinque regioni secondarie per un Database globale Amazon Aurora.

Sì. Se l’obiettivo è analizzare l'attività del database, valuta l'utilizzo della funzionalità di controllo avanzato di Aurora, dei log generali e dei log delle query lente, per evitare di influire sulle prestazioni del tuo database.

No. Nel caso in cui tua regione primaria non sia più disponibile, è possibile rimuovere manualmente una regione secondaria dal Database globale Amazon Aurora e promuoverla per ottenere il pieno delle capacità di lettura/scrittura. Inoltre, è necessario l’indirizzamento della tua applicazione alla regione appena promossa.

Sì. Tutte le istanze di database di Amazon Aurora devono essere create in VPC. Con Amazon VPC è possibile definire una topologia di rete virtuale molto simile a una rete tradizionale come quella che potrebbe essere gestita nel tuo data center. Questa soluzione offre il controllo completo sugli utenti che possono accedere ai database di Amazon Aurora.

Sì. Amazon Aurora usa il protocollo SSL (AES-256) per mettere al sicuro la connessione tra istanza di database e applicazione. Amazon Aurora consente di crittografare i database usando le chiavi gestite mediante Servizio di gestione delle chiavi AWS (AWS KMS).

In un'istanza di database eseguita con crittografia Amazon Aurora, i dati inattivi memorizzati nell'archiviazione sottostante sono crittografati, analogamente a quanto accade ai backup, alle repliche e agli snapshot corrispondenti nello stesso cluster. La crittografia e la decrittografia sono gestite in modo omogeneo. Per ulteriori informazioni sull'uso di AWS KMS con Amazon Aurora, consulta la Guida per l’utente di Amazon RDS.

Al momento la crittografia di un'istanza non crittografata esistente di Aurora non è supportata. Per usare la crittografia di Amazon Aurora su un database non crittografato esistente, è necessario creare una nuova istanza di database con la crittografia attivata in cui eseguire la migrazione dei dati.

L'accesso ai database di Aurora deve essere eseguito mediante la porta di database specificata durante la creazione del database. Ciò garantisce un livello di sicurezza aggiuntivo per i dati. Per istruzioni dettagliate sulle modalità di collegamento al database di Amazon Aurora, consulta la Amazon Aurora Connectivity Guide (Guida alla connettività di Amazon Aurora).

Sì, entrambe le edizioni di Aurora compatibili con PostgreSQL e MySQL sono idonee per la conformità HIPAA. Puoi utilizzarle per creare applicazioni conformi allo standard HIPAA e memorizzare informazioni sanitarie, fra cui i dati sanitari protetti (PHI) da un Business Associate Addendum (BAA) stipulato con AWS. Se hai già stipulato un contratto BAA con AWS, non è necessaria alcuna operazione per iniziare a usare questi servizi negli account coperti dal contratto BAA. Per ulteriori informazioni sulla creazione di applicazioni conformi con AWS, consulta la sezione Operatori sanitari.

Al momento, un elenco di CVE è disponibile negli Aggiornamenti di sicurezza Amazon Aurora.

Amazon GuardDuty è integrato in Aurora per aiutarti a identificare potenziali minacce ai dati archiviati nei database Aurora. Protezione RDS di GuardDuty delinea e monitora le attività di accesso e i nuovi database nel tuo account e utilizza modelli di ML su misura per rilevare accessi sospetti ai database Aurora. Per ulteriori informazioni, consulta la sezione Monitoraggio delle minacce con Protezione RDS di GuardDuty e la Guida per l'utente di Protezione RDS di GuardDuty.

Aurora Serverless è una configurazione a dimensionamento automatico on demand per Amazon Aurora. Con Aurora Serverless, è possibile eseguire il database nel cloud senza doverne gestire la capacità. La gestione manuale della capacità di un database può richiedere molto tempo e portare all'uso inefficiente delle risorse del database. Con Aurora Serverless è sufficiente creare un database, specificare l'intervallo di capacità desiderato e connettere l'applicazione. Aurora regolerà in automatico la capacità all'interno dell'intervallo specificato in base alle esigenze dell'applicazione.

L'uso di capacità del database prevede una tariffa conteggiata al secondo quando il database è attivo. Scopri di più su Aurora Serverless e inizia a utilizzarlo in poche fasi nella Console di gestione Amazon RDS.

Aurora Serverless v2 supporta ogni tipo di carico di lavoro del database, dagli ambienti di sviluppo e test, ai siti Web e alle applicazioni caratterizzati da carichi di lavoro non frequenti, intermittenti o imprevedibili fino alle applicazioni business-critical che richiedono scalabilità e disponibilità elevate. Si dimensiona in locale aggiungendo più CPU e memoria senza dover eseguire il failover del database su un'istanza di database più grande o più piccola. Di conseguenza, può dimensionarsi anche in presenza di transazioni di lunga durata, blocchi di tabelle e altro ancora.

Inoltre, dimensiona la capacità del database con incrementi fino a 0,5 unità di capacità Aurora (ACU), in modo che la capacità del database corrisponda strettamente alle esigenze dell'applicazione.

Aurora Serverless v1 è una soluzione semplice ed economica per carichi di lavoro poco frequenti, intermittenti o imprevedibili. Si avvia automaticamente, dimensiona la capacità di calcolo in base all'utilizzo dell'applicazione e si arresta quando non è in uso. Consulta la Guida per l'utente di Aurora per ulteriori informazioni.

Aurora Serverless v2 supporta tutte le funzionalità di Aurora con provisioning, incluse la replica di lettura, la configurazione multi-AZ, Database globale Aurora, Server proxy per RDS e Approfondimenti sulle prestazioni.

Sì, puoi iniziare a utilizzare Aurora Serverless v2 per gestire la capacità di calcolo del database nel cluster DB Aurora esistente. Un cluster contenente sia le istanze con provisioning che Aurora Serverless v2 è noto come cluster a configurazione mista. Puoi scegliere di avere qualsiasi combinazione di istanze con provisioning e Aurora Serverless v2 nel tuo cluster.

Per testare Aurora Serverless v2, aggiungi un lettore al tuo cluster di database Aurora e seleziona Serverless v2 come tipo di istanza. Una volta che il lettore è stato creato ed è disponibile, puoi iniziare a usarlo per carichi di lavoro di sola lettura. Dopo aver confermato che il lettore funziona come previsto, è possibile avviare un failover per iniziare a utilizzare Aurora Serverless v2 sia in lettura che in scrittura. Questa opzione fornisce un'esperienza di inattività minima per iniziare con Aurora Serverless v2.

Sì, puoi migrare da Aurora Serverless v1 a Aurora Serverless v2. Consulta la Guida per l'utente di Aurora per ulteriori informazioni.

Le informazioni sulla compatibilità di Aurora Serverless v1 sono disponibili qui. Le informazioni sulla compatibilità di Aurora Serverless v2 sono disponibili qui.

Sì, è possibile ripristinare uno snapshot eseguito da un cluster Aurora esistente in un cluster DB Aurora Serverless e viceversa.

Puoi accedere a un cluster DB Aurora Serverless dall'interno di un'applicazione client eseguita nello stesso VPC. Non puoi fornire un indirizzo IP pubblico a un database Aurora Serverless.

Anche se Aurora Serverless dimensiona automaticamente in base al carico di lavoro attivo del database, in alcuni casi la capacità potrebbe non aumentare abbastanza velocemente per far fronte a un improvviso cambiamento del carico di lavoro, come ad esempio nel caso di un gran numero di nuove transazioni. In questi casi, è possibile impostare esplicitamente la capacità a un valore specifico con la Console di gestione AWS, AWS CLI o API Amazon RDS.

Una volta avviata un'operazione di dimensionamento, Aurora Serverless tenta di trovare un punto di dimensionamento, ovvero un momento in cui il database può completarlo in modo sicuro. Aurora Serverless potrebbe non essere in grado di trovare un punto di dimensionamento se sono in corso query o transazioni di lunga durata, o se sono in uso tabelle temporanee o blocchi di tabelle.

In Aurora Serverless, la capacità di database viene misurata in ACU. Si paga una tariffa fissa per ogni secondo di utilizzo di ACU. I costi di calcolo per l'esecuzione dei carichi di lavoro su Aurora Serverless dipenderanno dalla configurazione del cluster di database scelta: Aurora Standard o Aurora ottimizzato per I/O. Visita la pagina dei prezzi di Aurora per avere informazioni sui prezzi e sulla disponibilità regionale.

Letture ottimizzate di Amazon Aurora disponibile per Aurora PostgreSQL è una nuova opzione in termini di rapporto prezzo/prestazioni che offre una latenza delle query fino a 8 volte superiore e risparmi sui costi fino al 30% rispetto alle istanze che ne sono prive. È ideale per applicazioni con set di dati di grandi dimensioni che superano la capacità di memoria di un'istanza di database.

Le istanze di Letture ottimizzate di Amazon Aurora utilizzano l’archiviazione a blocchi SSD locale basata su NVMe (disponibile sulle istanze r6gd basate su Graviton e r6id basate su Intel) per migliorare la latenza delle query delle applicazioni con set di dati che superano la capacità di memoria di un'istanza di database. Letture ottimizzate include miglioramenti delle prestazioni come la memorizzazione nella cache a più livelli e gli oggetti temporanei.

La cache su più livelli offre una latenza delle query fino a 8 volte superiore e risparmi sui costi fino al 30% per applicazioni ad alta intensità di lettura e I/O come pannelli di controllo operativi, rilevamento delle anomalie e ricerche di similarità basate su vettori. Questi vantaggi si ottengono memorizzando automaticamente nella cache locale i dati rimossi dalla buffer cache del database in memoria per velocizzare gli accessi successivi a tali dati. La memorizzazione nella cache a più livelli è disponibile solo per Amazon Aurora PostgreSQL Edition con configurazione ottimizzata per I/O di Aurora.

Gli oggetti temporanei consentono un'elaborazione più rapida delle query posizionando le tabelle temporanee generate da Aurora PostgreSQL nell'archiviazione locale, migliorando le prestazioni delle query che coinvolgono ordinamenti, aggregazioni di hash, join ad alto carico e altre operazioni a uso intensivo di dati.

Letture ottimizzate di Amazon Aurora per Aurora PostgreSQL offre ai clienti con applicazioni sensibili alla latenza e set di lavoro di grandi dimensioni un'alternativa convincente in termini di rapporto prezzo/prestazioni per soddisfare i loro SLA aziendali e fare ancora di più con le loro istanze.

Letture ottimizzate di Amazon Aurora è disponibile su istanze R6id basate su Intel e R6gd basate su Graviton. Puoi vedere la disponibilità delle Regioni per Aurora qui.

Amazon Aurora Optimized Reads è disponibile per l'edizione di Aurora compatibile con PostgreSQL su istanze R6id e R6gd. Le versioni del motore supportate sono 15.4 e successive e 14.9 e successive su Aurora PostgreSQL.

Amazon Aurora Optimized Reads non è disponibile su Aurora Serverless v2 (ASv2).

Sì, Letture ottimizzate di Amazon Aurora è disponibile con entrambe le configurazioni. In entrambe le configurazioni, le istanze abilitate alla lettura ottimizzata mappano automaticamente le tabelle temporanee all’archiviazione locale basata su NVMe per migliorare le prestazioni delle query analitiche e delle ricostruzioni degli indici.

Per carichi di lavoro ad alta intensità di I/O che richiedono una lettura intensiva, le istanze abilitate alla lettura ottimizzata su Aurora PostgreSQL sono configurate per utilizzare Aurora I/O-Optimized memorizza automaticamente nella cache i dati rimossi dalla memoria su uno storage locale basato su NVMe per offrire una latenza delle query fino a 8 volte superiore e un risparmio sui costi fino al 30% rispetto alle istanze senza di essa, per applicazioni con set di dati di grandi dimensioni che superano la capacità di memoria di un'istanza di database.

I clienti possono iniziare a usare Letture ottimizzate di Amazon Aurora tramite la Console di gestione AWS, l'interfaccia a riga di comando e l'SDK. Per impostazione predefinita, Letture ottimizzate è disponibile su tutte le istanze R6id e R6gd. Per utilizzare questa funzionalità, i clienti possono semplicemente modificare i cluster di database Aurora esistenti per includere le istanze R6id e R6gd o creare nuovi cluster di database utilizzando queste istanze. Consulta la documentazione di Letture ottimizzate di Amazon Aurora per iniziare.

Circa il 90% dello spazio di archiviazione locale disponibile sulle istanze R6id e R6gd è disponibile per letture ottimizzate, Aurora riserva il 10% dello storage NVMe per ridurre l'impatto dell'amplificazione di scrittura SSD. L'allocazione dello spazio di archiviazione disponibile dipende dalle funzionalità di Letture ottimizzate abilitate.

Quando si utilizza Letture ottimizzate con le funzionalità di oggetti temporanei e cache a più livelli, lo spazio disponibile per gli oggetti temporanei nell'archiviazione locale è equivalente al doppio della dimensione della memoria disponibile su queste istanze di database. Corrisponde alla dimensione attuale dell'archiviazione di oggetti temporanei su Aurora PostgreSQL. Lo spazio su disco di archiviazione locale rimanente è disponibile per la memorizzazione nella cache dei dati.

Quando si utilizza Letture ottimizzate solo con la funzione Oggetti temporanei, tutto lo spazio su disco di archiviazione locale disponibile è disponibile per gli oggetti temporanei. Ad esempio, quando si utilizza un'istanza r6gd.8xlarge con entrambe le funzionalità Temporary Objects e Tiered Caching, 534 GiB (capacità di memoria 2x) sono riservati agli oggetti temporanei e 1054 GiB per la cache a più livelli.

Se lo spazio di archiviazione locale riporta un errore, Aurora esegue automaticamente una sostituzione dell'host. In un cluster di database multi-nodo, ciò attiva un failover all'interno della regione.

In caso di failover del database, la latenza delle query aumenterà temporaneamente dopo il failover. Questo aumento della latenza si ridurrà nel tempo e alla fine raggiungerà la latenza delle query prima del failover. Questa durata di recupero può essere accelerata abilitando la gestione della cache del cluster (CCM). Con CCM, i clienti possono designare una specifica istanza del database Aurora PostgreSQL come destinazione di failover.

Quando CCM è abilitato, la cache di archiviazione locale della destinazione di failover designata rispecchia fedelmente la cache di archiviazione locale dell'istanza primaria, riducendo il tempo di recupero dopo il failover. Tuttavia, l'abilitazione del CCM potrebbe influire sull'efficacia a lungo termine della cache di archiviazione locale se la destinazione di failover designata viene utilizzata anche per gestire un carico di lavoro di lettura separato dal carico di lavoro sull'istanza di writer.

Pertanto, i clienti che eseguono carichi di lavoro che richiedono la designazione di un reader come failover in stand-by devono consentire a CCM di aumentare la probabilità di recuperare rapidamente la latenza delle query dopo il failover. I clienti che eseguono carichi di lavoro separati sulle destinazioni di failover designate potrebbero voler bilanciare le loro esigenze di ripristino immediato della latenza dopo il failover con l'efficacia a lungo termine delle prestazioni della cache, prima di abilitare CCM.

pgvector è un'estensione open source per PostgreSQL supportata dall'edizione compatibile con Amazon Aurora PostgreSQL.

Sì. Il machine learning (ML) di Aurora espone i modelli ML come funzioni SQL, consentendo di utilizzare SQL standard per chiamare modelli ML, passare dati ad essi e restituire previsioni come risultati di query. pgvector richiede l'archiviazione degli incorporamenti vettoriali nel database, il che richiede l'esecuzione del modello ML su dati di testo o immagine di origine per generare incorporamenti e quindi spostare gli incorporamenti in batch in Aurora PostgreSQL.

Aurora ML può trasformarlo in un processo in tempo reale che consente di mantenere aggiornati gli incorporamenti in Aurora PostgreSQL effettuando chiamate periodiche ad Amazon Bedrock o Amazon SageMaker che restituisce gli incorporamenti più recenti dal modello.

Letture ottimizzate di Amazon Aurora PostgreSQL con pgvector aumenta fino a 9 volte le query al secondo per la ricerca vettoriale nei carichi di lavoro che superano la memoria di istanza disponibile. Ciò è possibile grazie alla funzionalità di memorizzazione nella cache a più livelli disponibile in Letture ottimizzate che memorizza automaticamente nella cache locale i dati rimossi dalla buffer cache del database in memoria per velocizzare gli accessi successivi a tali dati.

È consigliabile utilizzare l'integrazione Zero-ETL di Amazon Aurora con Amazon Redshift quando è necessario un accesso quasi in tempo reale ai dati transazionali. Questa integrazione consente di sfruttare il ML di Amazon Redshift con comandi SQL diretti.

L'integrazione Zero-ETL di Aurora con Amazon Redshift è disponibile nell'edizione compatibile con Aurora MySQL per Aurora MySQL versione 3.05 (compatibile con MySQL 8.0.32) e versioni successive nelle Regioni Stati Uniti orientali (Ohio), Stati Uniti orientali (Virginia settentrionale), Stati Uniti occidentali (Oregon), Asia Pacifico (Singapore), Asia Pacifico (Sydney), Asia Pacifico (Tokyo), Europa (Francoforte), Europa (Irlanda) ed Europa (Stoccolma). L'integrazione Zero-ETL di Aurora con Amazon Redshift è disponibile nell'edizione compatibile con Aurora PostgreSQL per Aurora PostgreSQL 15.4 nella Regione Stati Uniti orientali (Ohio).

L'integrazione Zero-ETL di Aurora con Amazon Redshift elimina la necessità di creare e gestire pipeline di dati complesse. È possibile consolidare i dati da uno o più cluster di database Aurora in un unico cluster di database Amazon Redshift ed eseguire analisi e ML quasi in tempo reale utilizzando Amazon Redshift su petabyte di dati transazionali di Aurora. 

L'integrazione Zero-ETL di Aurora con Amazon Redshift è compatibile con Aurora serverless v2. Quando si utilizzano sia Aurora serverless v2 che Amazon Redshift serverless, è possibile generare analisi quasi in tempo reale sui dati transazionali senza la necessità di gestire alcuna infrastruttura per le pipeline di dati.

È possibile iniziare utilizzando la console Amazon RDS per creare l'integrazione Zero-ETL specificando l'origine Aurora e la destinazione Amazon Redshift. Una volta creata l'integrazione, il database Aurora verrà replicato su Amazon Redshift e sarà possibile iniziare a interrogare i dati una volta completato il seeding iniziale. Per ulteriori informazioni, leggi la guida introduttiva per le integrazioni Zero-ETL di Aurora con Amazon Redshift.

L'elaborazione Zero-ETL e in corso delle modifiche ai dati è offerta senza costi aggiuntivi. Si paga per le risorse Amazon RDS e Amazon Redshift esistenti utilizzate per creare ed elaborare i dati di modifica generati come parte di un'integrazione Zero-ETL. Queste risorse potrebbero includere:

• I/O e archiviazione aggiuntivi utilizzati abilitando il binlog avanzato
• Costi di esportazione degli snapshot per l'esportazione iniziale dei dati per il seeding dei database Amazon Redshift
• Archiviazione Amazon Redshift aggiuntiva per i dati replicati
• Costi di trasferimento dati tra zone di disponibilità per lo spostamento dei dati dall'origine alla destinazione

Per maggiori informazioni, visita la pagina dei prezzi di Aurora.

Amazon DevOps Guru per RDS è una nuova funzionalità basata su ML per Amazon RDS (che include Amazon Aurora) che è progettata per rilevare automaticamente e diagnosticare le prestazioni del database e i problemi operativi, consentendo di risolvere i problemi in pochi minuti piuttosto che in giorni.

Amazon DevOps Guru per RDS è una caratteristica di Amazon DevOps Guru, che è progettata per rilevare problemi operativi e di prestazioni per tutti i motori Amazon RDS e decine di altri tipi di risorse. DevOps Guru per RDS espande le capacità di DevOps Guru per rilevare, diagnosticare e rimediare a un'ampia varietà di problemi relativi al database in Amazon RDS (ad esempio, sovrautilizzo delle risorse e comportamento scorretto di alcune query SQL).

Quando si verifica un problema, Amazon DevOps Guru per RDS è progettato per avvisare immediatamente gli sviluppatori e i tecnici DevOps e offre informazioni diagnostiche, dettagli sull'entità del problema e suggerimenti intelligenti di rimedio per aiutare i clienti a risolvere rapidamente i colli di bottiglia delle prestazioni e i problemi operativi legati ai database.

Amazon DevOps Guru per RDS è progettato per eliminare lo sforzo manuale e riduce il tempo (da ore e giorni a pochi minuti) per rilevare e risolvere i colli di bottiglia delle prestazioni difficili da individuare nel tuo carico di lavoro del database relazionale.

Puoi abilitare DevOps Guru per RDS per ogni database Amazon Aurora per rilevare automaticamente i problemi di prestazioni dei tuoi carichi di lavoro, ti invierà avvisi su ogni problema, spiegherà i risultati e offrirà suggerimenti sulle operazioni per risolvere il problema.
DevOps Guru per RDS aiuta a rendere l'amministrazione dei database più accessibile agli utenti non esperti e assiste gli esperti di database in modo che possano gestire ancora più database.

Amazon DevOps Guru per RDS utilizza il ML per analizzare i dati di telemetria raccolti da Approfondimenti sulle prestazioni di Amazon RDS (PI). DevOps Guru per RDS non usa nessuno dei tuoi dati archiviati nel database nella sua analisi. PI misura il carico del database, un parametro che caratterizza come un'applicazione passa il tempo nel database e i parametri selezionati generati dal database, come le variabili di stato del server in MySQL e le tabelle pg_stat in PostgreSQL.

Per iniziare a usare DevOps Guru per RDS, assicurati che Performance Insights sia abilitato attraverso la console RDS e poi abilita semplicemente DevOps Guru per i tuoi database Amazon Aurora. Con DevOps Guru, puoi scegliere che il limite di copertura dell'analisi sia il tuo intero account AWS, prescrivere gli stack specifici di AWS CloudFormation che vuoi che DevOps Guru analizzi, o usare i tag AWS per creare il raggruppamento di risorse che vuoi che DevOps Guru analizzi.

Amazon DevOps Guru per RDS aiuta a identificare una vasta gamma di problemi di prestazioni che possono influenzare la qualità del servizio dell'applicazione, come accumuli bloccati, tempeste di connessioni, regressioni SQL, conflitti tra CPU e I/O e problemi di memoria.

Approfondimenti sulle prestazioni di Amazon RDS è una caratteristica per l’ottimizzazione e il monitoraggio delle prestazioni del database che raccoglie e visualizza parametri di prestazioni del database di Amazon RDS, consentendoti di valutare rapidamente il carico sul tuo database e di determinare quando e dove agire. Amazon DevOps Guru per RDS è progettato per monitorare questi parametri, rilevare quando il database sta avendo problemi di prestazioni, analizzare i parametri e poi comunicare cosa non funziona e cosa fare al riguardo.

È consigliabile utilizzare l'API dati per nuove applicazioni moderne, in particolare quelle create con AWS Lambda che hanno necessità di accedere ad Aurora in un modello di richiesta/risposta. È consigliabile utilizzare i driver di database anziché l'API dati e gestire le connessioni persistenti al database quando un'applicazione esistente è altamente associata ai driver di database, quando ci sono query di lunga durata o quando lo sviluppatore desidera sfruttare le funzionalità del database come le tabelle temporanee o utilizzare le variabili di sessione.

La disponibilità della regione AWS e della versione del database dell'API dati per le istanze fornite da Aurora Serverless v2 e Aurora è disponibile nella nostra documentazione. I clienti che attualmente utilizzano l'API dati per Aurora Serverless v1 sono incoraggiati a migrare ad Aurora Serverless v2 per sfruttare la nuova API dati e la scalabilità più granulare di Aurora Serverless v2.

L'API dati consente di semplificare e accelerare lo sviluppo delle applicazioni moderne. Si tratta di un'API basata su HTTP sicura e facile da utilizzare che elimina la necessità di implementare driver di database, gestire pool di connessioni lato client o configurare complesse reti VPC tra l'applicazione e il database. Inoltre, migliora la scalabilità raggruppando e condividendo automaticamente le connessioni al database, riducendo così il sovraccarico di calcolo dovuto alle applicazioni che aprono e chiudono le connessioni frequentemente. 

L'attuale API dati per Aurora Serverless v1 rimarrà una sua funzionalità sia per l'edizione compatibile con PostgreSQL che per quella compatibile con MySQL di Aurora. L'API dati per le istanze fornite da Aurora Serverless v2 e Aurora non supporta Aurora Serverless v1. L'API dati per Aurora Serverless v2 e le istanze fornite da Aurora supportano le istanze di scrittura del database globale Aurora.

Gli utenti possono richiamare le operazioni dell'API dati solo se sono autorizzati a farlo. Gli amministratori possono concedere a un utente l'autorizzazione a utilizzare l'API dati allegando una policy di AWS Identity and Access Management (IAM) che ne definisce i privilegi. Inoltre, è possibile collegare la policy a un ruolo se si utilizzano i ruoli IAM. Chiamando l'API dati, è possibile passare le credenziali per il cluster DB Aurora utilizzando un segreto su AWS Secrets Manager. 

L'utilizzo dell'API dati con Aurora Serverless v1 rimane disponibile senza costi aggiuntivi. Il prezzo dell'API dati per le istanze fornite da Aurora Serverless v2 e Aurora viene calcolato in base al volume delle richieste API, come descritto nella pagina dei prezzi di Aurora. L'API dati per le istanze fornite da Aurora Serveless v2 e Aurora utilizza gli eventi del piano dati AWS CloudTrail per registrare l'attività anziché gli eventi di gestione, come nel caso dell'API dati per Aurora Serverless v1.

È possibile abilitare la registrazione degli eventi dei dati tramite la console CloudTrail, la CLI o l'SDK per tenere traccia di questa attività. Questo implicherà i costi indicati nella pagina dei prezzi di CloudTrail. Inoltre, l'utilizzo di AWS Secrets Manager implicherà i costi indicati nella pagina dei prezzi di AWS Secrets Manager. 

AWS CloudTrail acquisisce l'attività delle API AWS sotto forma di eventi di gestione o eventi di dati. Gli eventi di gestione di CloudTrail (noti anche come "operazioni sul piano di controllo") mostrano le operazioni di gestione eseguite sulle risorse dell'account AWS, come la creazione, l'aggiornamento e l'eliminazione di una risorsa. Gli eventi di dati di CloudTrail (noti anche come "operazioni sul piano dati") mostrano le operazioni sulle risorse eseguite su o all'interno di una risorsa nell'account AWS.

L'API dati esegue operazioni sul piano dati poiché esegue query sui dati all'interno del database Aurora. Pertanto, registreremo l'attività dell'API dati come eventi di dati poiché questa è la categorizzazione corretta degli eventi. Verranno addebitati costi per gli eventi relativi ai dati di CloudTrail solo se la registrazione degli eventi di dati è abilitata.

Sì, il piano gratuito dell'API dati include un milione di richieste al mese, aggregate in tutte le regioni AWS, per il primo anno di utilizzo. Dopo un anno, i clienti inizieranno a pagare per l'API dati come descritto nella pagina dei prezzi di Aurora.

Le implementazioni blu/verdi di Amazon RDS sono disponibili per le edizioni di Amazon Aurora compatibili con MySQL versioni 5.6 e successive, Amazon Aurora compatibile con 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 Aurora.

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. Se desideri eseguire solo un aggiornamento di versione minore su Aurora, ti consigliamo di utilizzare Aurora Zero Downtime Patching (ZDP).

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.instance, 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 cluster Aurora edizione 5.7 compatibile con MySQL in esecuzione su due db.instance r5.2xlarge (con un'istanza di scrittura primaria e un'istanza di lettura) nella Regione AWS us-east-1. Ognuna delle db.instance r5.2xlarge è configurata per 40 GiB di archiviazione e offre 25 milioni di I/O al mese. Crei un clone della topologia dell'istanza blu utilizzando implementazioni blu/verdi di Amazon RDS, lo esegui per 15 giorni (360 ore) e ogni istanza verde ha 3 milioni di I/O in lettura durante tale periodo. Quindi, elimini le istanze blu dopo che lo switchover è riuscito. Le istanze blu (scrittura e lettura) costano 849,2 USD per 15 giorni a una tariffa on demand di 1,179 USD/ora (istanza+archiviazione+I/O). Le istanze verdi (scrittura e lettura) costano 840,40 USD per 15 giorni a una tariffa on demand di 1,167 USD/ora (istanza+archiviazione+I/O). Il costo totale per l'utilizzo delle implementazioni blu/verdi per quei 15 giorni è di 1.689,60 USD, pari a circa il doppio del costo di esecuzione delle istanze blu per un tale periodo di tempo.

Le implementazioni blu/verdi 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 nuovo ambiente di produzione, reindirizzando il traffico verso l'ambiente di produzione appena promosso.

Le implementazioni blu/verdi di Amazon RDS sono progettate per abilitare le scritture nell'ambiente verde dopo che lo switchover è stato completato, prevenendo la perdita di dati durante il processo.

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.

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.

No, le implementazioni blu/verdi di Amazon RDS non supportano database globali Amazon Aurora, server proxy per Amazon RDS 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.

Trusted Language Extensions (TLE) per PostgreSQL consente agli sviluppatori di creare estensioni di PostgreSQL ad alte prestazioni e di eseguirle in sicurezza su Amazon Aurora. 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. Con TLE, i fornitori di software indipendenti (ISV) possono fornire nuove estensioni PostgreSQL ai clienti che utilizzano Aurora.

TLE per PostgreSQL è disponibile per la versione di Amazon Aurora edizione compatibile con PostgreSQL 14.5 e versioni successive. TLE è implementato come estensione di PostgreSQL stesso e puoi attivarlo dal ruolo rds_superuser esattamente come le altre estensioni supportate su Aurora.

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

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 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 attiva TLE per PostgreSQL, puoi implementare le estensioni TLE usando il comando SQL CREATE EXTENSION da qualsiasi client PostgreSQL, come 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.