Domande frequenti su Amazon Aurora

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 256 TiB per istanza di database. Offre elevate prestazioni e disponibilità con un massimo di 15 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 il supporto per le nuove versioni. In questo modo, è possibile migrare facilmente i database MySQL verso e da Aurora usando 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.

È possibile visualizzare le informazioni sulla compatibilità della versione corrente di Amazon Aurora MySQL 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. Nel caso di un account attivo con Supporto AWS Premium, sarà possibile contattare il servizio per i problemi specifici di Aurora.

Amazon Aurora è compatibile con i database PostgreSQL open-source esistenti come sostituto diretto e aggiunge regolarmente il supporto per le nuove versioni. In questo modo è possibile migrare facilmente i database PostgreSQL verso e da Aurora usando 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à usati con i database PostgreSQL può essere usata con Aurora con modifiche minime o senza alcuna modifica.

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

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.

La disponibilità delle regioni per Aurora è indicata qui.

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 dei database SQL Server all'edizione di Amazon Aurora compatibile con PostgreSQL, è possibile utilizzare Babelfish per Aurora PostgreSQL. Le applicazioni funzioneranno senza alcuna modifica. Per ulteriori informazioni, consulta la documentazione di Babelfish.

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 del database di Amazon RDS per eseguire la migrazione di uno snapshot del database Amazon RDS per MySQL ad 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 practice per la migrazione di database MySQL in Amazon Aurora.

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, un'area in cui le prestazioni di Amazon Aurora risultano migliorate rispetto a MySQL è costituita dai carichi di lavoro a elevata simultaneità. Per ottimizzare il throughput 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 il throughput 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.

Sì, è possibile acquistare Savings Plans del database per l'utilizzo di Amazon Aurora e ridurre i costi fino al 35% in caso di impegno per un utilizzo costante per un periodo di 1 anno. Ulteriori informazioni sull'utilizzo idoneo sono disponibili nella pagina dei prezzi dei Savings Plans del database.

No, la replica di Aurora è inclusa nel prezzo. Il costo verrà addebitato in base allo spazio di archiviazione utilizzato dal database nel livello di database e non in base allo spazio di archiviazione utilizzato dal livello 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.

Aurora è stato sviluppato per eliminare le operazioni di I/O non necessarie in modo da 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, bisogna passare alla sezione Amazon RDS della console, controllare l'elenco delle istanze, selezionare le istanze Aurora, quindi cercare le metriche "VolumeReadIOPs" e "VolumeWriteIOPs" nella sezione relativa al monitoraggio.

Per ulteriori informazioni sui prezzi delle operazioni di 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 ottimizzato per l'I/O di Amazon Aurora.

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 l'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 ottimizzato per l'I/O è 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, è possibile risparmiare fino al 40% sui costi per carichi di lavoro ad alta intensità di I/O con Aurora ottimizzato per l'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 invocare l'Interfaccia della linea di comando AWS (AWS CLI) o l'AWS SDK per apportare questa modifica.

È 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 ottimizzato per l'I/O consentono un ulteriore risparmio sulla spesa di I/O.

Non sono previste modifiche al prezzo di backtrack, snapshot, esportazione o backup continuo con Aurora ottimizzato per l'I/O.

Sì, per la replica dei dati tra regioni continueranno a essere applicate le tariffe per le operazioni I/O necessarie. Aurora ottimizzato per l'I/O 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 Letture ottimizzate di Amazon Aurora 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 GiB. In base all'utilizzo del database, la capacità di archiviazione di Aurora aumenterà automaticamente fino a 256 TiB, con incrementi di 10 GiB senza alcuna conseguenza per le prestazioni del database. Non è necessario effettuare il provisioning di archiviazione in anticipo. Aurora offre una dimensionamento orizzontale automatizzato con Amazon Aurora PostgreSQL Limitless Database, che scala l'archiviazione oltre 256 TiB. Per saperne di più, visita Utilizzo di Aurora PostgreSQL Limitless Database.

Esistono tre modi per scalare le risorse di calcolo associate al database Amazon Aurora: utilizzando Amazon Aurora Serverless, Aurora PostgreSQL Limitless Database o il dimensionamento manuale. Indipendentemente dall'opzione scelta, i prezzi sono calcolati solo in base all'utilizzo effettivo.

È possibile utilizzare Aurora Serverless, una configurazione on demand a dimensionamento automatico per Aurora, per scalare le risorse di calcolo del database in base alla domanda dell'applicazione. Consente di eseguire il database nel cloud senza doverne gestire la capacità. È possibile specificare l’intervallo di capacità del database desiderato e il database verrà scalato in base alle necessità dell’applicazione. Scopri di più nella Guida per l’utente di Aurora Serverless.

Con Aurora PostgreSQL Limitless Database, è possibile scalare automaticamente le risorse di calcolo orizzontalmente in base ai requisiti del carico di lavoro per supportare applicazioni su larga scala. Consente di scalare le applicazioni oltre i limiti di throughput di scrittura e archiviazione di una singola istanza di database, mantenendo la semplicità di funzionamento all'interno di un singolo database. 

È anche possibile scalare 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 è possibile utilizzare il flag Applica immediatamente per modificare il tipo di istanza database immediatamente.

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 snapshot di database richiede tuttavia la creazione di una nuova istanza di database.

Amazon Aurora rende automaticamente durevoli i dati in tre zone di disponibilità (AZ) all'interno di una regione e tenta automaticamente di ripristinare il 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 di database oppure un'operazione di ripristino point-in-time in una nuova istanza. È importante sottolineare che l'intervallo ripristinabile massimo per un'operazione di ripristino point-in-time può essere pari a un intervallo massimo di 5 minuti nel passato.

È 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 conserva questo snapshot DB creato dall'utente finale insieme a tutti gli altri snapshot DB creati manualmente. Solo gli snapshot di database vengono mantenuti dopo l'eliminazione dell'istanza di database, 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.

È possibile utilizzare questa funzionalità 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.

Per condividere snapshot tra account diversi non viene addebitato alcun costo. Tuttavia, saranno addebitati i costi per gli snapshot e per i database ripristinati dagli snapshot condivisi. Ulteriori informazioni sui 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. Per condividere uno snapshot con più di 20 account, è possibile 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ì, è possibile 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.

L'edizione di Amazon Aurora compatibile con MySQL e l'edizione di Amazon Aurora compatibile con PostgreSQL supportano le repliche di Amazon Aurora che condividono lo stesso volume sottostante dell'istanza primaria all'interno della medesima 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:

Sono disponibili due ulteriori opzioni per effettuare delle repliche oltre a quelle elencate di sopra. È possibile utilizzare Database globale Amazon 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), è possibile impostare la replica di binlog personale auto-gestita.

Sì, è possibile configurare repliche di Aurora in più regioni tramite replica logica o fisica. La replica fisica, chiamata Database globale Amazon Aurora, 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ì, è possibile 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ì, è possibile modificare il livello di priorità per un'istanza in qualsiasi momento. La modifica dei livelli di priorità non attiverà un failover.

È possibile assegnare alle repliche che non si desidera 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à tali 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 disaster recovery in caso di interruzioni a livello regionale.

Il failover viene gestito automaticamente da Amazon Aurora, consentendo 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, si può considerare l'uso di Server proxy per Amazon RDS, che si connette in automatico 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%. 
• Aurora Serverless v2 funziona come se venisse eseguito il provisioning per il failover e altre funzionalità ad alta disponibilità. Per avere ulteriori informazioni, consulta la pagina Aurora Serverless v2 e alta 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 disaster recovery in più regioni è un processo manuale, in cui si promuove una regione secondaria ad incaricata di carichi di lavoro di lettura/scrittura.

Amazon Aurora rileverà automaticamente un problema relativo all'istanza primaria e attiverà 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.

Sì, è possibile 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 tempo di inattività.

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.

Il Database globale Amazon Aurora è una funzionalità 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 disaster recovery 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 funzionalità è disponibile sia per Aurora nell'edizione compatibile con MySQL sia per Aurora nell'edizione compatibile con PostgreSQL.

È possibile creare un Database globale Aurora in pochi clic dalla console di Amazon RDS. In alternativa, è possibile utilizzare il Software Development Kit (SDK) di AWS o l'interfaccia a riga di comando (CLI) di AWS. È possibile utilizzare una configurazione mista di tipi di classi di istanze con provisioning o serverless tra regioni primarie e secondarie. Inoltre, è possibile configurare la propria regione primaria come configurazione cluster ottimizzata per l'I/O di Aurora e le regioni secondarie come Aurora Standard o viceversa. Per ulteriori informazioni, visita Creazione di un 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, bisognerebbe valutare 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 database.

No. Se la regione principale diventa non disponibile, è possibile utilizzare l'operazione gestita di failover globale del database tra regioni per promuovere una regione secondaria con funzionalità complete di lettura e scrittura. È anche possibile utilizzare l'endpoint di scrittura di Database globale Amazon Aurora per evitare di dover apportare modifiche al codice dell'applicazione per connettersi alla regione appena promossa. Per ulteriori informazioni, visita Connessione a Database globale Amazon Aurora.

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 utilizza 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 il Servizio AWS di gestione delle chiavi (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, agli snapshot e alle repliche 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 Guida alla connettività di Amazon Aurora.

Sì, entrambe le edizioni di Aurora compatibili con PostgreSQL e MySQL sono idonee per la conformità HIPAA. È possibile 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 è già stato 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 pagina Fornitori di servizi sanitari.

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

Amazon GuardDuty è integrato in Aurora per aiutare 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 nell'account e utilizza modelli di ML su misura per rilevare accessi sospetti ai database Aurora. Per ulteriori informazioni, consulta Monitoraggio delle minacce con Protezione RDS di GuardDuty e la Guida per l'utente di Protezione RDS di GuardDuty.

Aurora Serverless è una configurazione on demand con dimensionamento automatico 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 pochi passaggi nella Console di gestione Amazon RDS.

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

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

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

Anche se Aurora Serverless scala 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.

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 tempo di inattività minimo per iniziare con Aurora Serverless v2.

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.

In Aurora Serverless, la capacità del database viene misurata in unità di capacità di Aurora o ACU (Aurora Capacity Unit). 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 l'I/O. Visita la pagina dei prezzi di Aurora per avere informazioni sui prezzi e sulla disponibilità regionale.

Aurora PostgreSQL Limitless Database fornisce un dimensionamento orizzontale automatizzato per elaborare milioni di transazioni di scrittura al secondo e gestisce petabyte di dati mantenendo la semplicità di operare all'interno di un singolo database. È così possibile concentrarsi sulla creazione di applicazioni su larga scala senza dover creare e mantenere soluzioni complesse per scalare i dati su più istanze di database e supportare i carichi di lavoro. Aurora PostgreSQL Limitless Database è scalabile in base al carico di lavoro dell'applicazione e si paga solo per ciò che l'applicazione consuma. Per saperne di più, consulta la Guida per l'utente di Aurora PostgreSQL Limitless Database.

È consigliabile utilizzare Aurora PostgreSQL Limitless Database per le applicazioni che devono scalare orizzontalmente e richiedono un maggiore throughput di scrittura o capacità di archiviazione di dati rispetto a quella supportata da una singola istanza di database Aurora. Ad esempio, un'applicazione di contabilità può essere partizionata orizzontalmente da un utente poiché i dati contabili di ciascun utente sono indipendenti dagli altri. Aurora PostgreSQL Limitless Database scala automaticamente per supportare le applicazioni più grandi e in più rapida crescita. 

Esistono due funzionalità per il dimensionamento: Dimensionamento automatico di Amazon Aurora con le repliche Aurora e Aurora Serverless v2.

Le repliche Aurora consentono di aumentare la capacità di lettura del cluster Aurora oltre i limiti di ciò che può fornire una singola istanza di database. Le applicazioni in grado di separare il carico di lavoro di lettura da quello di scrittura possono trarre vantaggio da un massimo di 15 repliche di lettura per ottenere un throughput di lettura complessivo più elevato. Le repliche Aurora non richiedono che l'applicazione divida orizzontalmente i propri dati. Tutti i dati sono disponibili in ogni replica. Le repliche Aurora non aumentano la capacità di archiviazione di un cluster Aurora né il throughput di scrittura.

Aurora Serverless v2 è una configurazione di dimensionamento verticale on demand per Aurora che fornisce il dimensionamento automatico dell'elaborazione e della memoria del database in base alle esigenze delle applicazioni entro i limiti di capacità di una singola istanza di calcolo. Aurora Serverless v2 è supportato sia per le istanze di scrittura che per quelle di lettura. Tuttavia, non aumenta la capacità di archiviazione di un cluster Aurora. Se l'applicazione è progettata per scalare orizzontalmente, Aurora PostgreSQL Limitless Database consente di scalare il throughput di scrittura e la capacità di archiviazione del database oltre i limiti di una singola istanza di scrittura Aurora.

Aurora PostgreSQL Limitless Database divide i dati tra le istanze del database utilizzando valori specificati dal cliente in una colonna della tabella, chiamata anche chiave shard. Ad esempio, una tabella che archivia le informazioni sull'utente potrebbe essere suddivisa utilizzando la colonna ID utente come chiave shard. In realtà Aurora PostgreSQL Limitless Database è un'implementazione distribuita di nodi serverless. I nodi sono router o shard. I router gestiscono la natura distribuita del database. Ogni shard archivia un sottoinsieme di dati, consentendo l'elaborazione parallela per ottenere un throughput di scrittura elevato.

Con l'aumentare dei requisiti di elaborazione o archiviazione, Aurora innanzitutto aumenta verticalmente ogni istanza e l'archiviazione associata, quindi aumenta orizzontalmente per gestire il carico di lavoro del database per diversi valori di chiave shard. In qualsiasi momento, un valore di chiave shard è posseduto e servito da una singola istanza serverless. Quando le applicazioni si connettono ad Aurora PostgreSQL Limitless Database ed emettono una richiesta, la richiesta viene prima analizzata. Quindi, viene inviata all'istanza di calcolo che possiede il valore della chiave shard specificato dalla richiesta oppure viene orchestrata una query su più istanze.

Più istanze di calcolo, ciascuna con valori di chiave shard distinti, possono soddisfare contemporaneamente le richieste delle applicazioni per lo stesso Aurora PostgreSQL Limitless Database. Aurora PostgreSQL Limitless Database fornisce la stessa semantica delle transazioni dei sistemi Aurora PostgreSQL a scrittore singolo, eliminando la complessità della gestione di diversi domini di transazione nell'applicazione.

Aurora PostgreSQL Limitless Database supporta tre tipi di tabelle che contengono i dati: con shard, di riferimento e standard.

Tabelle con shard: queste tabelle sono distribuite su più shard. I dati vengono suddivisi tra gli shard in base ai valori delle colonne designate nella tabella, chiamate chiavi shard. Sono utili per scalare le tabelle più grandi e ad alta intensità di I/O dell'applicazione.

Tabelle di riferimento: queste tabelle copiano i dati per intero su ogni shard, in modo che le query di join possano funzionare più velocemente rimuovendo gli spostamenti di dati non necessari. Sono comunemente usate per dati di riferimento modificati di rado, come cataloghi di prodotti e codici postali.

Tabelle standard: queste tabelle sono come normali tabelle Aurora PostgreSQL. Le tabelle standard sono tutte collocate insieme su un singolo shard, in modo che le query di join possano funzionare più velocemente eliminando gli spostamenti di dati non necessari. È possibile creare tabelle con shard e di riferimento da tabelle standard.

Per saperne di più sulle considerazioni sulla compatibilità di PostgreSQL, visita Requisiti e considerazioni su Aurora PostgreSQL Limitless Database.

È possibile iniziare a usare Aurora PostgreSQL Limitless Database nella console Amazon RDS o nelle API Amazon per creare un nuovo cluster Aurora PostgreSQL con la versione del motore supportata. Per saperne di più su come iniziare, consulta la Guida per l'utente di Aurora PostgreSQL Limitless Database.

L'applicazione si connette ad Aurora PostgreSQL Limitless Database nello stesso modo in cui si connette a un cluster Aurora PostgreSQL standard. È sufficiente connettersi all'endpoint del cluster. Per saperne di più, visita la sezione Utilizzo di Aurora PostgreSQL Limitless Database.

Sì, potrebbe essere necessario modificare lo schema del database per utilizzare Aurora PostgreSQL Limitless Database. Tutte le tabelle con shard devono contenere la chiave shard, quindi potrebbe essere necessario inserire nuovamente i dati. Ad esempio, un'applicazione di contabilità potrebbe suddividere i propri dati per utente, utilizzando la colonna ID utente, dal momento che ogni utente è indipendente dagli altri. La tabella degli utenti contiene naturalmente questa
colonna, ma altre tabelle potrebbero non contenerla: ad esempio, una tabella che contiene le voci delle fatture. Poiché queste tabelle devono essere suddivise per utente per ottenere prestazioni ottimali delle query, è necessario aggiungere alla tabella la colonna ID utente.

Non ci sono vincoli di denominazione sulla colonna utilizzata per suddividere i dati, ma la definizione della colonna deve corrispondere. Servirà aggiungere la chiave shard alle query dell'applicazione e potrà anche esser necessario modificare le query e le transazioni per ottenere prestazioni ottimali. Ad esempio, la ricerca di una fattura utilizzando l'ID della fattura quando la tabella è divisa solo per ID utente sarebbe lenta perché la query dovrebbe essere eseguita su tutte le istanze del database. Tuttavia, se la query specifica anche l'ID utente, verrà indirizzata alla singola istanza di database che contiene tutti gli ordini per quell'ID utente, riducendo la latenza della query.

Sì. È possibile scegliere un'opzione di disponibilità elevata durante l'impostazione della ridondanza di calcolo su un valore maggiore di zero per il proprio Aurora PostgreSQL Limitless Database, garantendo una disponibilità del 99,99%. Ogni istanza di calcolo che archivia e accede ai dati da Aurora PostgreSQL Limitless Database può avere uno o due standby che possono subentrare alle richieste se il primario non è disponibile. I router reindirizzeranno automaticamente il traffico per minimizzare l’impatto sull'applicazione.

Aurora PostgreSQL Limitless Database è disponibile per la configurazione del cluster Aurora ottimizzato per l'I/O con compatibilità PostgreSQL 16.4. Ulteriori informazioni sulla disponibilità delle regioni AWS per Aurora PostgreSQL Limitless Database sono disponibili nella pagina dei prezzi di Aurora.

In Aurora PostgreSQL Limitless Database, la capacità del database viene misurata in ACU. Si paga una tariffa fissa per ogni secondo di utilizzo di ACU. Si applicano le tariffe di archiviazione di configurazione ottimizzate per l'I/O di Aurora. Per maggiori informazioni, visita la pagina dei prezzi di Aurora.

Per Query parallela di Amazon Aurora si intende la capacità di trasferire e distribuire il carico di calcolo di una singola query attraverso migliaia di CPU nel livello di archiviazione di Aurora. Senza Query parallela, una query inoltrata al database di Amazon Aurora sarebbe eseguita interamente all’interno di una sola istanza del cluster di database; questa operazione è simile al modo in cui opera la maggior parte dei database.

Query parallela è adatta per carichi di lavoro analitici che richiedono dati aggiornati e buone prestazioni di query, anche su tabelle di grandi dimensioni. Carichi di lavoro di questo tipo sono solitamente di natura operativa.

Prestazioni più veloci dei risultati di Query parallela che accelerano le query analitiche fino a due ordini di grandezza. Offre anche semplicità operativa e aggiornamento dei dati: è possibile inviare una query direttamente sui dati transazionali attuali nel cluster Aurora. Inoltre, Query parallela abilita carichi di lavoro transazionali e analitici nello stesso database consentendo ad Aurora di mantenere un elevato throughput delle transazioni accanto alle query analitiche simultanee.

Ne possono trarre vantaggio la maggior parte delle query su insiemi di dati di grandi dimensioni che non sono già nel pool di buffer. La versione iniziale di Query parallela spinge verso il basso e aumenta orizzontalmente l'elaborazione di oltre 200 funzioni SQL, equi-join e proiezioni.

Il miglioramento delle prestazioni di una query specifica dipende da quanto del piano di query può essere trasferito al livello di archiviazione Aurora. I clienti hanno segnalato miglioramenti superiori a un ordine di grandezza alla latenza delle query.

Sì, ma prevediamo che si tratti di casi sporadici.

Non è necessario apportare modifiche alla sintassi della query. Lo strumento di ottimizzazione delle query deciderà automaticamente se utilizzare Query parallela per una query specifica. Per verificare che una query utilizzi Query parallela, visualizzare il piano di esecuzione di query eseguendo il comando EXPLAIN. Se si desidera ignorare l'euristica e forzare Query parallela a scopo di test, utilizzare la variabile di sessione aurora_pq_force.

Query parallela può essere abilitata e disabilitata dinamicamente a livello globale e di sessione utilizzando il parametro aurora_pq.

No, non viene addebitato nient'altro oltre a quello che è già stato pagato per istanze, I/O e archiviazione.

No, i costi di I/O Query parallela per la query in questione vengono misurati al livello di storage e saranno uguali o maggiori con Query parallela attivata. Il vantaggio risiede nel miglioramento delle prestazioni di query.

Esistono due ragioni per eventuali costi maggiori di I/O con Query parallela. Innanzitutto, anche se alcuni dei dati di una tabella si trovano nel pool di buffer, la Query parallela richiede che tutti i dati vengano scansionati nel livello di archiviazione, incorrendo nell'I/O. In secondo luogo, un effetto collaterale di evitare la contesa nel pool di buffer è che l'esecuzione di una Query parallela non scaldi il pool di buffer. Di conseguenza, le esecuzioni consecutive della stessa Query parallela comporteranno il costo di I/O completo.

Ulteriori informazioni su Query parallela nella documentazione.

No. Al momento, questa funzionalità è compatibile solo con le istanze della famiglia R*.

Query parallela è disponibile per la versione di Amazon Aurora compatibile con MySQL 5.7 e MySQL 8.0.

Query parallela è compatibile con Aurora Serverless v2 e Backtrack.

No. Anche se Query parallela migliorerà la latenza delle query nella maggior parte dei casi, i costi di I/O saranno superiori. Consigliamo di testare un carico di lavoro con e senza la caratteristica. Una volta accertato che Query parallela sia la scelta giusta, è possibile utilizzare lo strumento di ottimizzazione delle query per decidere automaticamente a quali query applicare la funzionalità. Nella rara eventualità in cui lo strumento di ottimizzazione non sia la scelta ottimale, è possibile sovrascrivere l'impostazione.

La Query parallela di Aurora non costituisce un data warehouse e non fornisce le funzionalità tipiche di tali sistemi. È progettato per migliorare le prestazioni delle query su database relazionali ed è ideale per casi d'uso come l'analisi operativa, quando è necessario eseguire rapidamente query analitiche su dati aggiornati nel database.

Per un data warehouse su cloud su scala exabyte, prendi in considerazione Amazon Redshift.

Letture ottimizzate di Amazon Aurora disponibile per Aurora PostgreSQL è una nuova opzione in termini di rapporto tra prezzo e 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 conveniente in termini di prezzo e prestazioni per soddisfare gli SLA aziendali e sfruttare al massimo le proprie istanze.

Letture ottimizzate di Amazon Aurora è disponibile su istanze R6id basate su Intel e R6gd basate su Graviton. La disponibilità delle regioni per Aurora è indicata 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.

Letture ottimizzate di Amazon Aurora 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 configurate per utilizzare la versione ottimizzata per l'I/O di Aurora memorizzano automaticamente nella cache i dati rimossi dalla memoria su uno spazio di archiviazione 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 sulle 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 spazio di archiviazione 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à Oggetti temporanei e Memorizzazione nella cache a più livelli, 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 (Cluster Cache Management, 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 di Amazon Aurora compatibile con PostgreSQL.

È possibile utilizzare pgvector per archiviare, cercare, indicizzare e interrogare miliardi di embedding generati da modelli di machine learning (ML) e intelligenza artificiale (IA) nel database, come quelli di Amazon Bedrock o Amazon SageMaker. Un embedding vettoriale è una rappresentazione numerica del significato semantico di contenuti come testo, immagini e video.

Con pgvector, puoi interrogare gli incorporamenti nel tuo database Aurora PostgreSQL per eseguire efficienti ricerche di similarità semantica di questi tipi di dati, rappresentati come vettori, combinati con altri dati tabulari in Aurora. Ciò consente l'uso dell'IA generativa e di altri sistemi IA/ML per nuovi tipi di applicazioni, come consigli personalizzati basati su descrizioni o immagini di testo simili, abbinamento dei candidati basato sulle note del colloquio, chatbot e consigli sul servizio clienti sulle migliori azioni da intraprendere sulla base di trascrizioni o dialoghi di sessioni di chat di successo e altro ancora. 

Leggi il nostro blog sulle funzionalità dei database vettoriali e scopri come archiviare gli embedding utilizzando l'estensione pgvector in un database Aurora PostgreSQL, come creare un chatbot interattivo di risposta a domande e come utilizzare l'integrazione nativa tra pgvector e il machine learning di Aurora per l'analisi del sentiment.

Sì. Grazie all'esposizione dei modelli di ML come funzioni SQL, il machine learning (ML) di Aurora consente di utilizzare SQL standard per chiamare modelli di ML, passarvi dati e restituire previsioni sotto forma di risultati di query. pgvector richiede l'archiviazione degli embedding vettoriali nel database, il che implica l'esecuzione del modello di ML su dati di testo o immagine di origine per generare embedding e quindi spostarli in batch in Aurora PostgreSQL.

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

Sì. I metodi per integrare i database Amazon Aurora con Amazon Bedrock per alimentare le applicazioni di IA generativa sono due. Come primo metodo, il ML di Amazon Aurora fornisce l'accesso ai modelli di fondazione disponibili in Amazon Bedrock direttamente tramite SQL sia per Aurora MySQL che per Aurora PostgreSQL. Come secondo metodo, è possibile configurare Aurora come archivio vettoriale in Knowledge Base per Amazon Bedrock in un solo clic e archiviare gli embedding generati da Bedrock in Aurora. Knowledge Base per Amazon Bedrock supporta Aurora PostgreSQL come archivio vettoriale per casi d'uso come la generazione potenziata da recupero dati (RAG). Leggi il nostro blog e la documentazione su come utilizzare Aurora PostgreSQL come Knowledge Base per Amazon Bedrock.

Letture ottimizzate di Amazon Aurora per 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.

Leggi il nostro blog e la documentazione su come migliorare le prestazioni delle query per Aurora PostgreSQL con Letture ottimizzate di Aurora.

È 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 ML di Amazon Redshift con semplici comandi SQL.

L'integrazione Zero-ETL di Amazon Aurora con Amazon SageMaker consente di trasferire i dati dai database e dalle applicazioni operativi nel lakehouse quasi in tempo reale. Con l'architettura lakehouse di SageMaker, è possibile creare un lakehouse aperto sui propri investimenti nei dati esistenti, senza modificare l'architettura dei dati e utilizzare i propri strumenti di analisi e motori di query preferiti come SQL, Apache Spark, BI e strumenti IA/ML.

L'integrazione Zero-ETL di Aurora con Amazon Redshift è disponibile nell'edizione di Aurora compatibile con MySQL per Aurora MySQL versione 3.05.2 (compatibile con MySQL 8.0.32) e versioni successive. L'integrazione Zero-ETL di Aurora con Amazon Redshift è disponibile nell'edizione di Aurora compatibile con PostgreSQL per Aurora PostgreSQL versione 16.4 e successive.

L'integrazione Zero-ETL di Aurora con Amazon SageMaker è disponibile nell'edizione di Aurora compatibile con MySQL per Aurora MySQL versione 3.05.0 (compatibile con MySQL 8.0.32) e versioni successive. L'integrazione di Aurora Zero-ETL con Amazon SageMaker è disponibile su Aurora compatibile con PostgreSQL per Aurora PostgreSQL versione 16.4 e successive e Aurora PostgreSQL 17.4 e versioni successive.

Visita le funzionalità supportate in Aurora per regione AWS e il motore di database Aurora per saperne di più sulla disponibilità delle regioni AWS per l'integrazione Zero-ETL di Aurora.

L'integrazione Zero-ETL di Aurora con Amazon Redshift e Amazon SageMaker elimina la necessità di creare e gestire pipeline di dati complesse. È possibile consolidare i dati da più tabelle di diversi cluster di database Aurora in un unico cluster di database Amazon Redshift o nell'architettura lakehouse di SageMaker ed eseguire analisi e ML quasi in tempo reale sui dati operativi 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 dover gestire alcuna infrastruttura per le pipeline di dati. 

L'integrazione Zero-ETL di Aurora con Amazon SageMaker è compatibile con Aurora Serverless v2.

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

L'elaborazione continua delle modifiche dei dati tramite l'integrazione Zero-ETL viene offerta senza costi aggiuntivi. Si pagano le risorse esistenti utilizzate per creare ed elaborare i dati di modifica creati 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
• Archiviazione aggiuntiva per l'archiviazione dei dati replicati
• Elaborazione aggiuntiva per l'elaborazione della replica dei dati
• Costi di trasferimento dei dati tra zone di disponibilità (AZ) per lo spostamento dei dati dall'origine alla destinazione

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

Sì, è possibile gestire e automatizzare la configurazione e l'implementazione delle risorse necessarie per un'integrazione Zero-ETL di Aurora utilizzando AWS CloudFormation. Per avere ulteriori informazioni, visita modelli CloudFormation con l'integrazione Zero-ETL.

CloudWatch Database Insights è una soluzione di monitoraggio e metriche che semplifica e migliora la risoluzione dei problemi del database. Automatizza la raccolta della telemetria, incluse metriche, log e tracce, eliminando la necessità di installazione e configurazione manuali. Consolidando questa telemetria in Amazon CloudWatch, CloudWatch Database Insights fornisce una visione unificata delle prestazioni e dello stato del database.

I principali vantaggi di CloudWatch Database Insights includono:

1. Raccolta semplificata della telemetria: raccoglie automaticamente metriche, log e tracce del database, riducendo al minimo i tempi di configurazione.
2. Approfondimenti curati: fornisce dashboard, allarmi e approfondimenti predefiniti per il monitoraggio e l'ottimizzazione delle prestazioni del database, con una configurazione minima necessaria per iniziare.
3. Visualizzazione CloudWatch unificata: combina la telemetria di più database in un'unica vista per un monitoraggio semplificato.
4. Funzionalità IA/ML: utilizza IA/ML per rilevare le anomalie, riducendo gli sforzi manuali di risoluzione dei problemi.
5. Monitoraggio del contesto delle applicazioni: consente agli utenti di correlare le prestazioni del database e le prestazioni delle applicazioni.
6. Visualizzazioni a livello di parco e istanza: offre sia il monitoraggio di alto livello del parco sia visualizzazioni dettagliate delle istanze per l'analisi CA root.
7. Perfetta integrazione con AWS: si integra con Amazon CloudWatch Application Signals e AWS X-Ray, consentendo un'esperienza di osservabilità completa.

Amazon DevOps Guru per RDS è una funzionalità basata su ML per Amazon RDS (che include Amazon Aurora) progettata per rilevare e diagnosticare in automatico le prestazioni del database e i problemi operativi, così da consentire la risoluzione dei problemi in pochi minuti anziché in giorni.

Amazon DevOps Guru per RDS è una funzionalità di Amazon DevOps Guru 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 di rimedio intelligenti 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 rende l'amministrazione dei database più accessibile agli utenti non esperti e assiste gli esperti di database in modo che possano gestirne ancora di più.

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 dati archiviati nel database durante la sua analisi. PI misura il carico del database, una metrica che caratterizza come un'applicazione trascorre il tempo nel database e alcune metriche selezionate generate 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, è necessario assicurarsi che Approfondimenti sulle prestazioni sia abilitato attraverso la console RDS e poi abilitare semplicemente DevOps Guru per i database Amazon Aurora. Con DevOps Guru, è possibile scegliere che il limite di copertura dell'analisi sia l'intero account AWS, prescrivere gli stack specifici di AWS CloudFormation che DevOps Guru deve analizzare oppure utilizzare i tag AWS per creare il raggruppamento di risorse che DevOps Guru deve analizzare.

Amazon DevOps Guru per RDS identifica 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 funzionalità per l'ottimizzazione e il monitoraggio delle prestazioni del database che raccoglie e visualizza metriche di prestazioni del database di Amazon RDS e consente così di valutare rapidamente il carico sul database e determinare quando e dove agire. Amazon DevOps Guru per RDS è progettato per monitorare queste metriche, rilevare quando il database sta avendo problemi di prestazioni, analizzare le metriche e poi dire cosa non funziona e come agire al riguardo.

CloudWatch Database Insights monitora le risorse e le applicazioni Aurora in tempo reale e presenta i dati tramite dashboard personalizzabili. Al contrario, Amazon DevOps Guru è un servizio di machine learning (ML) che analizza le metriche di CloudWatch per comprendere il comportamento di un'applicazione nel tempo, rilevare anomalie e offrire approfondimenti e consigli per la risoluzione dei problemi. Inoltre, DevOps Guru analizza i dati provenienti da più fonti, tra cui AWS Config, AWS CloudFormation e AWS X-Ray. È possibile utilizzare le dashboard di CloudWatch per monitorare le informazioni su DevOps Guru tramite le metriche pubblicate nel namespace AWS/DevOps-Guru. Questo consente di visualizzare tutte le informazioni e le anomalie in un unico pannello di visualizzazione nella console CloudWatch.

Approfondimenti sulle prestazioni di RDS è una funzionalità per l’ottimizzazione e il monitoraggio delle prestazioni del database, che consente di valutare rapidamente il carico sul database e di determinare quando e dove agire. CloudWatch Database Insights è una nuova funzionalità di osservabilità del database che eredita tutte le funzionalità di Approfondimenti sulle prestazioni insieme al monitoraggio a livello di parco, all'integrazione con il monitoraggio delle prestazioni delle applicazioni e alla correlazione delle metriche del database con log ed eventi.

È consigliabile utilizzare l'API di 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 di 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 di dati per le istanze con provisioning di Aurora Serverless v2 e Aurora è riportata nella nostra documentazione.

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'API di dati per Aurora Serverless v2 e le istanze fornite da Aurora supportano le istanze di scrittura del Database globale Aurora.

Gli utenti possono invocare le operazioni dell'API di dati solo se sono autorizzati a farlo. Gli amministratori possono concedere a un utente l'autorizzazione a utilizzare l'API di dati collegando 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. Con una chiamata all'API di dati, è possibile passare le credenziali per il cluster database Aurora utilizzando un segreto in AWS Secrets Manager. 

Il prezzo dell'API di dati per le istanze con provisioning di Aurora Serverless v2 e Aurora viene calcolato in base al volume delle richieste API, come descritto nella pagina dei prezzi di Aurora. L'API di dati per le istanze con provisioning Aurora Serveless v2 e Aurora utilizza gli eventi del piano dati di AWS CloudTrail per registrare le attività anziché gli eventi di gestione.

È possibile abilitare la registrazione degli eventi dei dati tramite la console CloudTrail, la CLI o l'SDK per tenere traccia di questa attività. Ciò comporta i costi indicati nella pagina dei prezzi di CloudTrail. Inoltre, l'uso di AWS Secrets Manager comporta 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" (control-plane), 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 l'attività di log degli eventi di dati è abilitata.

Sì, il piano gratuito dell'API di 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 iniziano a pagare l'API di dati come descritto nella pagina dei prezzi di Aurora.

Le implementazioni blu/verdi di Amazon RDS sono disponibili per l'edizione di Amazon Aurora compatibile con MySQL versioni 5.6 e successive e l'edizione di 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. Ulteriori informazioni sulle versioni disponibili sono riportate 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. Per eseguire solo un aggiornamento di versione secondaria su Aurora, consigliamo di utilizzare Aurora Zero Downtime Patching (ZDP).

L'esecuzione dei 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 gli attuali prezzi standard per db.instance, il costo dell'archiviazione, il costo degli input/output (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 verrà pagato 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; per esempio, aggiornamenti di versioni principali o secondarie, modifiche dello schema, dimensionamento 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 è l'ambiente di staging che, dopo lo switchover, diventerà il 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 di 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 switchover delle implementazioni blu/verdi di Amazon RDS è quella di bloccare la scrittura sugli ambienti blu e verdi 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, lo switchover andrà in timeout.

Se l'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.

Sì, le implementazioni blu/verdi di Amazon RDS supportano Database globali Aurora. Per saperne di più, consultare la Guida per l'utente sulle implementazioni blu/verdi per Database globale Amazon Aurora.

No, le implementazioni blu/verdi di Amazon RDS non supportano Server proxy per Amazon RDS o repliche di lettura interregionali. 

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.

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 l'edizione di Amazon Aurora compatibile con 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.

È possibile 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, è possibile implementare le estensioni TLE usando il comando SQL CREATE EXTENSION da qualsiasi client PostgreSQL, come psql. Questo metodo è simile a quello applicabile 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 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.

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