D: Cos'è Amazon Aurora?

Amazon Aurora è un motore di database relazionale che unisce la velocità e la disponibilità dei database commerciali di fascia alta alla semplicità e alla tariffa ridotta dei database open source. Amazon Aurora MySQL è in grado di offrire prestazioni cinque volte superiori rispetto a MySQL senza la necessità di modificare la maggior parte delle applicazioni MySQL; analogamente, Amazon Aurora PostgreSQL offre prestazioni tre volte superiori rispetto a PostgreSQL. Amazon RDS gestisce i database di Amazon Aurora per quanto riguarda le attività dispendiose a livello di tempo quali, ad esempio, il provisioning, l'applicazione di patch, il backup, il recupero, il rilevamento degli errori e la riparazione. Viene applicata una tariffa mensile per ogni istanza di database di Amazon Aurora usata. Non sono previste tariffe minime né impegni a lungo termine.

D: Cosa significa "compatibile con MySQL"?

Significa che la maggior parte di codice, applicazioni, driver e strumenti usati con i database MySQL può essere usata con Aurora con modifiche minime o senza alcuna modifica. Il motore di database Amazon Aurora è stato progettato per essere wire-compatible con MySQL 5.6 mediante il motore di storage InnoDB. Alcune funzionalità MySQL, ad esempio il motore di storage MyISAM, non sono disponibili con Amazon Aurora.

D: Cosa significa "compatibile con PostgreSQL"?

Significa che la maggior parte di codice, applicazioni, driver e strumenti usati con i database PostgreSQL può essere usata con Aurora con modifiche minime o senza alcuna modifica. Il motore di database Amazon Aurora è progettato per essere wire-compatible con PostgreSQL 9.6 e supporta lo stesso set di estensioni PostgreSQL supportate con RDS per PostgreSQL 9.6, facilitando lo spostamento di applicazioni tra i due motori.  

D: Com'è possibile provare a usare Amazon Aurora?

Per provare Amazon Aurora, accedi alla Console AWS, seleziona RDS nella categoria Database e quindi scegli Amazon Aurora come motore di database.

D: Quanto costa Amazon Aurora?

Consulta la pagina dei prezzi per informazioni aggiornate.

D: Amazon Aurora replica ogni blocco del volume del database sei volte sulle tre zone di disponibilità. Ciò significa che il prezzo effettivo dello storage sarà moltiplicato per tre o per sei rispetto a quanto riportato nella pagina dei prezzi?

La replica di Amazon Aurora è inclusa nel prezzo. Il costo verrà addebitato in base allo storage consumato dal database nel layer di database e non in base allo storage consumato dal layer di storage virtualizzato di Amazon Aurora.

D: In quali regioni AWS è disponibile Amazon Aurora?

Consulta la pagina dei prezzi per informazioni su tariffe e regioni.

D: Com'è possibile eseguire la migrazione da MySQL ad Amazon Aurora e viceversa?

Sono disponibili numerose opzioni. È possibile usare la utility mysqldump standard per esportare i dati da MySQL e la utility mysqlimport per importare i dati in Amazon Aurora e viceversa. È inoltre possibile usare la funzionalità di migrazione di snapshot DB di Amazon RDS per eseguire la migrazione di uno snapshot DB MySQL RDS in Amazon Aurora usando la Console di gestione AWS. Nella maggior parte dei casi, il processo di migrazione 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.

D: In che modo è possibile eseguire una migrazione da PostgreSQL ad Amazon Aurora e viceversa?

Sono disponibili numerose opzioni. È possibile usare la utility pg_dump standard per esportare i dati da PostgreSQL e la utility pg_restore per importare i dati in Amazon Aurora e viceversa. È inoltre possibile usare la funzionalità di migrazione di snapshot DB di Amazon RDS per eseguire la migrazione di uno snapshot DB PostgreSQL 9.6 RDS in Amazon Aurora usando la Console di gestione AWS. Nella maggior parte dei casi, il processo di migrazione viene completato in meno di un'ora; la durata effettiva dipende tuttavia dal formato e dalle dimensioni del set di dati.

D: Amazon Aurora partecipa al piano gratuito di AWS?

No, al momento no. Il piano gratuito di AWS per Amazon RDS offre vantaggi per micro-istanze di database. Attualmente, Amazon Aurora non offre alcun supporto per le micro-istanze di database. Consulta la pagina dei prezzi per informazioni aggiornate.

D: Cosa sono gli I/O in Amazon Aurora e come vengono calcolati?

Gli I/O sono operazioni di input/output eseguite dal motore di database Aurora nel relativo layer di storage 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 nella cache del buffer. La dimensione di ogni pagina del database è pari a 16 KB in Aurora MySQL e pari a 8 KB in Aurora PostgreSQL.

Aurora è stato sviluppato in modo da eliminare le operazioni di I/O non necessarie e pertanto ridurre i costi e garantire la disponibilità delle risorse per la gestione del traffico di lettura/scrittura. Gli I/O di scrittura vengono usati solo durante l'invio dei record del log delle transazioni al layer di storage con lo scopo di rendere durevoli le letture. Gli I/O di scrittura vengono conteggiati in base a unità da 4 KB. Ad esempio, un record del log delle transazioni la cui dimensione è pari a 1024 byte verrà considerato come un'operazione di I/O. Tuttavia, le operazioni di scrittura simultanee i cui log delle transazioni hanno dimensioni minori di 4 KB possono essere raggruppate in batch dal motore di database Aurora per ottimizzare il consumo degli I/O. A differenza dei motori di database tradizionali, Amazon Aurora non esegue mai il push delle pagine di database modificate nel layer di storage. Ciò consente di ridurre ulteriormente il consumo degli I/O.

È possibile visualizzare il numero di I/O consumati da un'istanza di Aurora nella Console AWS. Per verificare il consumo degli I/O, passa alla sezione RDS della console, controlla l'elenco delle istanze, seleziona le istanze di Aurora e quindi verifica le metriche “Billed read operations” e “Billed write operations” nella sezione relativa al monitoraggio.

D: È necessario modificare i driver del client per utilizzare Amazon Aurora PostgreSQL?

No, Amazon Aurora è compatibile con i driver standard del database PostgreSQL.

D: Cosa significa "prestazioni cinque volte superiori rispetto a MySQL"?

Amazon Aurora garantisce incrementi significativi a livello di prestazioni rispetto a MySQL grazie all'integrazione avanzata del motore di database con un layer di storage virtualizzato basato su SSD appositamente sviluppato per i carichi di lavoro del database, alla riduzione delle operazioni di scrittura nel sistema di storage, 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 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 Amazon Aurora MySQL Performance Benchmarking Guide.

D: Cosa significa "prestazioni tre volte superiori rispetto a PostgreSQL"?

Amazon Aurora garantisce incrementi significativi a livello di prestazioni rispetto a PostgreSQL grazie all'integrazione avanzata del motore di database con un layer di storage virtualizzato basato su SSD appositamente sviluppato per i carichi di lavoro del database, alla riduzione delle operazioni di scrittura nel sistema di storage, 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 Amazon Aurora PostgreSQL Performance Benchmarking Guide.

D: Come si ottimizza il carico di lavoro del database per Amazon Aurora MySQL?

Amazon Aurora è compatibile con MySQL 5.6, 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 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.

D: Come si ottimizza il carico di lavoro del database per Amazon Aurora PostgreSQL?

Amazon Aurora è compatibile con PostgreSQL 9.6, 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.

D: Quali sono i limiti di storage minimi e massimi di un database Amazon Aurora?

Lo storage minimo è pari a 10 GB. In base all'utilizzo del database, la capacità di storage di Amazon Aurora aumenterà automaticamente fino a 64 TB, in incrementi di 10 GB senza alcuna conseguenza per le prestazioni del database. Non è necessario effettuare il provisioning di ulteriori quantità di storage.

D: Come viene eseguito il dimensionamento delle risorse di elaborazione associate all'istanza di database Amazon Aurora?

È possibile eseguire il dimensionamento delle risorse di elaborazione allocate all'istanza di database nella Console di gestione AWS selezionando l'istanza di database desiderata, quindi facendo clic sul pulsante Modify. Per modificare le risorse di memoria e CPU, modificare la classe dell'istanza di database.

Quando la classe dell'istanza di database viene modificata, le modifiche richieste verranno applicate durante la finestra di manutenzione specificata. In alternativa, è possibile utilizzare il flag "apply-immediately" per rendere subito effettive le richieste di dimensionamento. 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.

D: Come vengono abilitati i backup per l'istanza di database?

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

D: È possibile creare snapshot DB e conservarli per tutto il tempo necessario?

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 di database.

D: Se si verifica un errore del database, qual è il percorso di ripristino?

Amazon Aurora conserva automaticamente sei copie dei dati in tre zone di disponibilità e tenterà automaticamente di ripristinare il database in una zona di disponibilità integra senza alcuna perdita di dati. Nel caso improbabile che i dati non siano disponibili nello storage di Amazon Aurora, è possibile eseguire il ripristino da uno snapshot DB 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.

D: Cosa accade ai backup e agli snapshot DB quando viene eliminata l'istanza di database?

È possibile scegliere di creare uno snapshot DB finale quando viene eliminata l'istanza di database. 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 DB vengono conservati dopo l'eliminazione dell'istanza di database, ovvero i backup automatici creati per il ripristino point-in-time non vengono conservati.

D: È possibile condividere uno snapshot con un altro account AWS?

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.

D: Quali costi vengono addebitati per gli snapshot condivisi?

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. Per ulteriori informazioni, consulta la pagina dei prezzi di Aurora.

D: È possibile condividere snapshot in modo automatico?

La condivisione automatica di snapshot di database non è attualmente supportata. Per condividere automaticamente snapshot, è necessario crearne una copia e condividerla manualmente.

D: Con quanti account è possibile condividere snapshot?

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

D: In quali regioni è possibile condividere gli snapshot di Aurora?

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

D: È possibile condividere gli snapshot di Aurora tra regioni diverse?

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

D: È possibile condividere uno snapshot di Aurora crittografato?

Sì, puoi condividere snapshot di Aurora crittografati.

D: In che modo Amazon Aurora migliora la tolleranza ai guasti del database in caso di errori del disco?

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.

D: In che modo Aurora migliora i tempi di ripristino dopo un arresto anomalo del database?

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

D: Che tipi di replica sono supportati da Aurora?

Amazon Aurora MySQL e Amazon Aurora PostgreSQL supportano le repliche di Amazon Aurora che condividono lo stesso volume sottostante come istanza primaria. Gli aggiornamenti eseguiti dall'istanza primaria sono visibili in tutte le repliche di Amazon Aurora. Con Amazon Aurora MySQL, è inoltre possibile creare repliche di lettura MySQL 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:

Caratteristica Repliche di Amazon Aurora Repliche di MySQL
Numero di repliche Fino a 15 Fino a 5
Tipo di replica Asincrona (millisecondi) Asincrona (secondi)
Impatto sulle prestazioni dell'istanza primaria Basso Alto
Funge da target di failover Sì (nessuna perdita di dati) Sì (potenziale perdita di alcuni minuti di dati)
Failover automatico No
Supporto del ritardo di replica definito dall'utente No
Supporto di dati o schemi diversi rispetto all'istanza primaria No

D: È possibile creare repliche in più regioni con Amazon Aurora?

Sì, con Aurora MySQL puoi configurare repliche di Aurora su più regioni dalla console di RDS. La replica su più regioni 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. Aurora PostgreSQL attualmente non supporta la replica in più regioni.

D: È possibile creare repliche di lettura di Aurora su un cluster di replica su più regioni?
Sì, puoi aggiungere repliche di Aurora sul cluster che condividerà lo stesso storage sottostante della replica su più regioni. La 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.

D: È possibile configurare il failover di un'applicazione dalla replica principale a una su più regioni?
Sì, puoi promuovere la replica su più regioni a replica principale tramite la console RDS. La durata del processo 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.

D: È possibile fornire una priorità maggiore ad alcune repliche in quanto target di failover?

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 2 o più repliche hanno pari priorità, Amazon RDS promuoverà una replica con le stesse dimensioni dell'istanza da sostituire. Per ulteriori informazioni sulla logica di failover, consulta la Amazon Aurora User Guide.

D: È possibile modificare i livelli di priorità per le istanze dopo la loro creazione?

I livelli di priorità possono essere modificati in qualsiasi momento. La modifica dei livelli di priorità non attiverà un failover.

D: È possibile impedire ad alcune repliche di essere promosse a istanza primaria?

È possibile assegnare alle repliche che non desideri usare 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.

D: In che modo è possibile migliorare la disponibilità di un database di Amazon Aurora?

È possibile aggiungere repliche di Amazon Aurora. Le repliche di Amazon Aurora condividono lo stesso storage sottostante dell'istanza primaria. Qualsiasi replica di Amazon Aurora può essere alzata di livello e impostata come replica primaria senza alcuna perdita di dati e quindi essere usata per migliorare 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.

D: Quali operazioni vengono eseguite durante un failover e con quale durata?

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

  • Se è disponibile una replica di Amazon Aurora nella stessa zona di disponibilità o in una zona diversa, in caso di failover Amazon Aurora fa in modo che il record di nome canonico (CNAME) dell'istanza di database punti alla replica integra, che a sua volta 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.
  • Se non si dispone di una replica di Amazon Aurora (istanza singola), Aurora tenterà di creare una nuova istanza di database nella stessa zona di disponibilità dell'istanza originale. Se risulta impossibile eseguire questa operazione, Aurora tenterà di creare una nuova istanza di database in una zona di disponibilità diversa. L'esecuzione completa dell'intero processo di failover in genere impiega meno di 15 minuti.

L'applicazione deve tentare di ristabilire le connessioni al database in caso di perdita della connessione.

D: In presenza di un database primario e di una replica di Amazon Aurora che gestisce attivamente il traffico di lettura, cosa succede se si verifica un failover?

Amazon RDS rileverà automaticamente un problema a livello di istanza primaria e procederà a instradare il traffico di lettura/scrittura verso una replica di Amazon Aurora. In media questo tipo di failover viene completato in 30 secondi. Inoltre, il traffico di lettura gestito dalle repliche di Amazon Aurora verrà brevemente interrotto.

D: Qual è il ritardo delle repliche rispetto all'istanza primaria?

Dal momento che le repliche di Amazon Aurora condividono lo stesso volume di dati dell'istanza primaria, virtualmente non si verifica alcun ritardo di replica. In genere sono stati rilevati ritardi nell'ordine di decine di millisecondi. Per le repliche di lettura di MySQL, il ritardo di replica 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.

D: Cos'è Amazon Aurora Multi-Master?

In occasione di re:Invent 2017, abbiamo annunciato l'anteprima per Amazon Aurora Multi-Master, una nuova funzionalità della versione di Aurora compatibile con MySQL che aggiunge la possibilità di dimensionare le prestazioni di scrittura in più zone di disponibilità, consentendo l'indirizzamento di carichi di lavoro di lettura/scrittura da parte delle applicazioni a più istanze in un cluster di database e operazioni a disponibilità più elevata.

D: Che cosa occorre per cominciare a utilizzare Amazon Aurora Multi-Master?

Amazon Aurora Multi-Master è ora disponibile in anteprima per la versione di Amazon Aurora compatibile con MySQL. Puoi registrarti per richiedere la partecipazione. Annunceremo la disponibilità generale in data futura.

D: È possibile usare Amazon Aurora in Amazon Virtual Private Cloud (Amazon VPC)?

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.

D: I dati in transito o inattivi vengono crittografati da 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 AWS Key Management Service (KMS). In un'istanza di database eseguita con crittografia Amazon Aurora, i dati inattivi memorizzati nello storage 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 KMS con Amazon Aurora, consulta la Amazon RDS User's Guide.

D: È possibile crittografare un database non crittografato esistente?

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.

D: Com'è possibile accedere al database di Amazon Aurora?

L'accesso ai database di Amazon Aurora deve essere eseguito mediante la porta di database specificata durante la creazione del database. In questo modo viene fornito un layer di sicurezza aggiuntivo per i dati. Per istruzioni dettagliate sulle modalità di collegamento al database di Amazon, consulta la Amazon Aurora Connectivity Guide.

D: È possibile usare Amazon Aurora con applicazioni che richiedono la conformità HIPAA?

Sì, le edizioni di Aurora compatibili con MySQL e PostgreSQL sono idonee per HIPAA, quindi è possibile usarle per creare applicazioni conformi allo standard HIPAA e archiviare informazioni sanitarie, fra cui i dati sanitari protetti (PHI) da un Business Associate Agreement (BAA) stipulato con AWS. Se è già stato stipulato un contratto BAA, non è necessaria alcuna operazione per iniziare a usare questi servizi negli account coperti dal contratto BAA. Se non è ancora stato stipulato un contratto BAA con AWS, oppure per qualsiasi altra domanda in merito alle applicazioni conformi allo standard HIPAA in AWS, contattaci.

D: Cos'è Amazon Aurora Serverless?

Amazon Aurora Serverless è una configurazione a dimensionamento automatico on-demand, per la versione di Amazon Aurora compatibile con MySQL. Un cluster DB Aurora Serverless si avvia, si spegne e scala automaticamente la capacità in base alle esigenze dell'applicazione. Aurora Serverless offre un'opzione relativamente semplice ed economica per carichi di lavoro poco frequenti, intermittenti o imprevedibili. Per ulteriori informazioni, leggere la Amazon Aurora User Guide.

D: Quali versioni di Amazon Aurora sono supportate per Aurora Serverless?

Aurora Serverless è attualmente disponibile per Aurora con compatibilità MySQL 5.6.

D: Posso migrare un cluster DB Aurora esistente in Aurora Serverless?

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

D: Come posso connettermi a un cluster DB Aurora Serverless?

Puoi accedere a un cluster DB Aurora Serverless dall'interno di un'applicazione client eseguita nello stesso Amazon Virtual Private Cloud (VPC). Non puoi assegnare un indirizzo IP pubblico a un cluster DB Aurora Serverless.

D: Posso impostare esplicitamente la capacità di un cluster 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, CLI AWS o API RDS.

D: Perché il mio cluster DB Aurora Serverless non si dimensiona automaticamente?

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.

D: Come mi viene fatturato Aurora Serverless?

In Aurora Serverless, la capacità del database viene misurata in unità di capacità di Aurora o ACU (Aurora Capacity Unit). Viene addebitata una tariffa flat al secondo di utilizzo di ACU, con un minimo di 5 minuti di utilizzo ogni volta che il database viene attivato. Le tariffe di storage e I/O sono le stesse per le configurazioni assegnate e Serverless. Visualizza un esempio di prezzi per Aurora Serverless .