Utilizzo di Amazon Aurora Serverless v1 - Amazon Aurora
Disponibilità di regioni e versioniVantaggi di Aurora Serverless v1Casi d'uso per Aurora Serverless v1Limitazioni di Aurora Serverless v1Requisiti di configurazione per Aurora Serverless v1Utilizzo di TLS/SSL con Aurora Serverless v1

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo di Amazon Aurora Serverless v1

Amazon Aurora Serverless v1 (Amazon Aurora Serverless versione 1) è una configurazione con scalabilità automatica on demand di Amazon Aurora. Un cluster di databaseAurora Serverless v1 è un cluster di database che consente di scalare la capacità di calcolo verso l'alto e verso il basso in base alle esigenze dell'applicazione. Ciò è in contrasto con i cluster database con provisioning di Aurora, per i quali è possibile gestire manualmente la capacità. Aurora Serverless v1 offre un'opzione relativamente semplice ed economica per carichi di lavoro poco frequenti, intermittenti o imprevedibili. È economico perché avvia e dimensiona automaticamente la capacità di calcolo in base all'uso dell'applicazione e si chiude quando non viene utilizzato.

Per ulteriori informazioni sui prezzi, consultare Prezzi di Serverless in Edizione compatibile con MySQL o Edizione compatibile con PostgreSQL nella pagina Amazon Aurora pricing.

I cluster Aurora Serverless v1 hanno lo stesso tipo di volume di archiviazione ad alta capacità, distribuito e ad alta disponibilità utilizzato dai cluster database sottoposti a provisioning.

I cluster Aurora Serverless v2 permettono di scegliere se crittografare o meno il volume cluster.

Il volume cluster di un cluster Aurora Serverless v1 è sempre crittografato. Puoi scegliere la chiave di crittografia, ma non puoi disabilitare la crittografia. Ciò significa che è possibile eseguire le stesse operazioni su uno snapshot Aurora Serverless v1 crittografato. Per ulteriori informazioni, consulta Aurora Serverless v1 e snapshot.

Argomenti
Importante

Aurora mette a disposizione due generazioni di tecnologia serverless: Aurora Serverless v2 e Aurora Serverless v1. Se l'applicazione può essere eseguita su MySQL 8.0 o PostgreSQL 13, ti consigliamo di utilizzare Aurora Serverless v2. Aurora Serverless v2 scala più rapidamente e in modo più granulare. Aurora Serverless v2 garantisce anche una maggiore compatibilità con altre funzionalità Aurora come le istanze database di lettura. Pertanto, se hai già familiarità con Aurora, con Aurora Serverless v2 dovrai apprendere un numero minore di procedure nuove o limitazioni di utilizzo rispetto a Aurora Serverless v1.

Per maggiori informazioni su Aurora Serverless v2, consulta Uso di Aurora Serverless v2.

Disponibilità di regioni e versioni

La disponibilità e il supporto della funzionalità varia tra le versioni specifiche di ciascun motore di database Aurora e tra Regioni AWS. Per ulteriori informazioni sulla disponibilità di versioni e regioni con Aurora e Aurora Serverless v1, consultare Regioni supportate e motori Aurora DB per la versione 1 Aurora Serverless.

Vantaggi di Aurora Serverless v1

Aurora Serverless v1 offre i vantaggi riportati di seguito:

  • Più semplice del provisioning: Aurora Serverless v1 rimuove gran parte della complessità della gestione delle istanze e della capacità del database.

  • Scalabile: Aurora Serverless v1 scala perfettamente la capacità di calcolo e memoria in base alle necessità, senza alcuna interruzione alle connessioni client.

  • Conveniente: quando utilizzi Aurora Serverless v1, paghi soltanto le risorse del database utilizzate su base al secondo.

  • Archiviazione ad alta disponibilità: Aurora Serverless v1 utilizza lo stesso sistema di archiviazione tollerante ai guasti e distribuito con replica in sei direzioni utilizzato da Aurora per la protezione dalla perdita dei dati.

Casi d'uso per Aurora Serverless v1

Aurora Serverless v1 è progettato per i seguenti casi d'uso:

  • Applicazioni poco utilizzate – Hai un'applicazione che viene usata soltanto per pochi minuti diverse volte al giorno o alla settimana, come il sito di un blog a volume ridotto. Con Aurora Serverless v1 paghi soltanto le risorse del database utilizzate su base al secondo.

  • Nuove applicazioni – Stai distribuendo una nuova applicazione e non sei sicuro delle dimensioni dell'istanza necessarie. Con Aurora Serverless v1, puoi creare un endpoint del database e far sì che il database venga dimensionato automaticamente in base ai requisiti di capacità dell'applicazione.

  • Carichi di lavoro variabili – Esegui un'applicazione poco utilizzata, con picchi che vanno da 30 minuti a diverse ore poche volte al giorno o diverse volte all'anno. Esempi di questo tipo sono le applicazioni per le risorse umane, la redazione del budget e la creazione di report operativi. Grazie a Aurora Serverless v1, non dovrai più effettuare il provisioning per la capacità media o di picco.

  • Carichi di lavoro imprevedibili – Esegui carichi di lavoro giornalieri con aumenti improvvisi e imprevedibili dell'attività. Un esempio può essere quello di un sito sul traffico in cui c'è un aumento dell'attività quando inizia a piovere. Grazie a Aurora Serverless v1, il database aumenta automaticamente la capacità per soddisfare le esigenze del picco di carico dell'applicazione e la riduce quando il picco è terminato.

  • Database di sviluppo e test – Gli sviluppatori utilizzano i database durante l'orario di lavoro, ma non ne hanno bisogno nelle notti o nei fine settimana. Con Aurora Serverless v1, il database si spegne automaticamente quando non viene utilizzato.

  • Applicazioni multi-tenant: grazie a Aurora Serverless v1, non devi gestire individualmente la capacità del database per ogni applicazione utilizzata nel parco istanze. Aurora Serverless v1 gestisce la capacità del database a livello individuale per tuo conto.

Limitazioni di Aurora Serverless v1

Le seguenti limitazioni si applicano a Aurora Serverless v1:

  • Aurora Serverless v1 non supporta le seguenti caratteristiche:

    • Database globali di Aurora

    • Repliche di Aurora

    • AWS Identity and Access Management Autenticazione del database (IAM)

    • Backtrack in Aurora

    • Flussi di attività di database

    • Autenticazione Kerberos

    • Approfondimenti sulle prestazioni

    • Server proxy per RDS

    • Visualizzazione dei log nella AWS Management Console

  • Le connessioni a un cluster di database Aurora Serverless v1 vengono chiuse automaticamente se mantenute aperte per più di un giorno.

  • Tutti i cluster database Aurora Serverless v1 presentano le seguenti limitazioni:

    • Non è possibile esportare snapshot Aurora Serverless v1 in bucket Simple Storage Service (Amazon S3).

    • Non è possibile utilizzare AWS Database Migration Service e CDC (Change Data Capture) con cluster database Aurora Serverless v1. Solo i cluster database Aurora con provisioning supportano CDC con AWS DMS come origine.

    • Non è possibile salvare i dati in file di testo in Amazon S3 o caricare i dati di file di testo in Aurora Serverless v1 da S3.

    • Non è possibile collegare un ruolo IAM a un cluster database Aurora Serverless v1. Tuttavia, è possibile caricare i dati su Aurora Serverless v1 da Simple Storage Service (Amazon S3) utilizzando l'estensione aws_s3 con la funzione aws_s3.table_import_from_s3 e il parametro credentials. Per ulteriori informazioni, consulta Importazione di dati da Amazon S3 in un cluster database Aurora PostgreSQL.

    • Quando si utilizza l'editor di query, viene creato un segreto Secrets Manager con le credenziali per accedere al database. Eliminando le credenziali dall'editor di query, anche il segreto associato viene eliminato da Secrets Manager. Una volta eliminato, però, questo segreto non può essere recuperato.

  • I cluster database basati su Aurora MySQL che eseguono Aurora Serverless v1non supportano quanto segue:

    • Richiamo delle funzioni AWS Lambda dal cluster database Aurora MySQL. Tuttavia, le funzioni AWS Lambda possono effettuare chiamate al cluster di database Aurora Serverless v1.

    • Ripristino di uno snapshot da un'istanza database che non è Aurora MySQL o RDS for MySQL.

    • Replica dei dati mediante la replica basata su registri binari (binlog). Questa limitazione vale indipendentemente dal fatto che Aurora Serverless v1 del cluster database basato su Aurora MySQL sia l'origine o la destinazione della replica. Per replicare i dati in un cluster database Aurora Serverless v1 da un'istanza database MySQL esterna a Aurora, ad esempio da una istanza che viene eseguita su Amazon EC2, si consiglia di prendere in considerazione l'utilizzo di AWS Database Migration Service. Per ulteriori informazioni, consulta la Guida per l'utente AWS Database Migration Service.

    • Creazione di utenti con accesso basato su host ('username'@'IP_address'). Questo perché Aurora Serverless v1 utilizza un parco istanze router tra il client e l'host del database per un dimensionamento senza interruzioni. L’indirizzo IP visto dal cluster database Aurora Serverless è quello dell'host del router e non del client. Per ulteriori informazioni, consulta Architettura di Aurora Serverless v1.

      Utilizzare, invece, il carattere jolly ('username'@'%').

  • I cluster database basati su Aurora PostgreSQL che eseguono Aurora Serverless v1 hanno le seguenti limitazioni:

    • La gestione del piano di query di Aurora PostgreSQL (apg_plan_management) non è supportata.

    • La funzionalità di replica logica disponibile in Amazon RDS PostgreSQL e Aurora PostgreSQL non è supportata.

    • Le comunicazioni in uscita come quelle abilitate dalle estensioni Amazon RDS for PostgreSQL non sono supportate. Ad esempio, non è possibile accedere ai dati esterni con l'estensione postgres_fdw/dblink. Per ulteriori informazioni sulle estensioni PostgreSQL di RDS, consulta PostgreSQL su Amazon RDS nella Guida per l'utente di RDS.

    • Al momento, alcune query SQL e comandi non sono consigliati. Questi includono blocchi di consulenza a livello di sessione, relazioni temporanee, notifiche asincrone (LISTEN) e cursori con hold (DECLARE name ... CURSOR WITH HOLD FOR query). Inoltre, i comandi NOTIFY impediscono il dimensionamento e non sono consigliati.

      Per ulteriori informazioni, consulta Scalabilità automatica per Aurora Serverless v1.

  • Non è possibile impostare la finestra di backup automatico preferita per un cluster di database Aurora Serverless v1.

  • Puoi impostare la finestra di manutenzione per un cluster di database Aurora Serverless v1. Per ulteriori informazioni, consulta Impostazione della finestra di manutenzione preferita del cluster database.

Requisiti di configurazione per Aurora Serverless v1

Quando crei un cluster database Aurora Serverless v1, presta attenzione ai seguenti requisiti:

  • Utilizza i seguenti numeri di porta specifici per ogni motore database:

    • Aurora MySQL – 3306

    • Aurora PostgreSQL – 5432

  • Crea il tuo cluster database Aurora Serverless v1 in un Virtual Private Cloud (VPC) basato sul servizio Amazon VPC. Quando si crea un cluster di database Aurora Serverless v1 nel VPC, si utilizzano due (2) dei cinquanta (50) endpoint di interfaccia e Gateway Load Balancer assegnati al VPC. Questi endpoint vengono creati automaticamente per l'utente. Per aumentare la quota, puoi contattare AWS Support. Per ulteriori informazioni, consulta la pagina relativa alle quote di Amazon VPC.

  • Non puoi assegnare al cluster database Aurora Serverless v1 un indirizzo IP pubblico. Puoi accedere a un cluster database Aurora Serverless v1 solo da un VPC.

  • Crea sottoreti in zone di disponibilità diverse per il gruppo di sottoreti database utilizzato per il cluster database Aurora Serverless v1. In altre parole, non è possibile avere più di una sottorete nella stessa zona di disponibilità.

  • Le modifiche a un gruppo di sottoreti utilizzato da un cluster database Aurora Serverless v1 non vengono applicate al cluster.

  • Puoi accedere a un cluster database Aurora Serverless v1 da AWS Lambda. Per far ciò, dovrai configurare la funzione Lambda per l'esecuzione nello stesso VPC del cluster database Aurora Serverless v1. Per ulteriori informazioni sull'utilizzo di AWS Lambda, consulta Configurazione di una funzione Lambda per accedere alle risorse in un Amazon VPC nella Guida per gli sviluppatori di AWS Lambda.

Utilizzo di TLS/SSL con Aurora Serverless v1

Per impostazione predefinita, Aurora Serverless v1 utilizza il protocollo TLS/SSL (Transport Layer Security/Secure Sockets Layer) per crittografare le comunicazioni tra i client e il cluster database Aurora Serverless v1. Supporta TLS/SSL versione 1.0, 1.1 e 1.2. Non è necessario configurare il cluster database Aurora Serverless v1 per utilizzare TLS/SSL.

Si applicano le seguenti limitazioni:

  • Il supporto TLS/SSL per i cluster database Aurora Serverless v1 al momento non è disponibile nella Regione AWS Cina (Pechino).

  • Quando crei utenti di database per un cluster database Aurora Serverless v1 basato su Aurora MySQL, non utilizzare la clausola REQUIRE per le autorizzazioni SSL. In questo modo si impedisce agli utenti di connettersi all'istanza database Aurora.

  • Per i programmi di utilità MySQL Client e Client PostgreSQL, le variabili di sessione che possono essere utilizzare in altri ambienti non hanno alcun effetto quando si utilizza TLS/SSL tra client e Aurora Serverless v1.

  • Per MySQL Client, quando ti connetti con la modalità VERIFY_IDENTITY di TLS/SSL, devi utilizzare il comando mysql compatibile con MySQL 8.0. Per ulteriori informazioni, consulta Connessione a un'istanza database che esegue il motore del database MySQL.

A seconda del client utilizzato per connettersi al cluster database Aurora Serverless v1, potrebbe non essere necessario specificare TLS/SSL per ottenere una connessione crittografata. Ad esempio, per utilizzare PostgreSQL Client per connettersi a un cluster database Aurora Serverless v1 che esegue l'edizione compatibile con PostgreSQL di Aurora, è sufficiente connettersi come si fa normalmente. 

psql -h endpoint -U user

Dopo aver inserito la password, PostgreSQL Client mostra i dettagli della connessione, tra cui la versione TLS/SSL e il codice. 

psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1), server 10.12)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
Importante

Aurora Serverless v1 utilizza il protocollo TLS/SSL (Transport Layer Security/Secure Sockets Layer) per crittografare le connessioni di default, a meno che SSL/TLS non sia disabilitato dall'applicazione client. La connessione TLS/SSL termina al parco istanze del router. La comunicazione tra il parco istanze del router e il cluster di database Aurora Serverless v1 avviene entro il limite della rete interna del servizio.

È possibile controllare lo stato della connessione client per verificare se la connessione a Aurora Serverless v1 è crittografata con TLS/SSL. PostgreSQL pg_stat_ssl, le tabelle pg_stat_activity e la relativa funzione ssl_is_used non mostrano lo stato TLS/SSL per la comunicazione tra l'applicazione client e Aurora Serverless v1. Allo stesso modo, lo stato TLS/SSL non può essere derivato dall'istruzione status MySQL.

I parametri del cluster Aurora force_ssl per PostgreSQL e require_secure_transport per MySQL non erano precedentemente supportati per Aurora Serverless v1. Questi parametri sono ora disponibili per Aurora Serverless v1. Per un elenco completo dei parametri supportati da Aurora Serverless v1, chiama l'operazione API. DescribeEngineDefaultClusterParameters Per ulteriori informazioni sui gruppi di parametri e su Aurora Serverless v1, consulta Gruppi di parametri per Aurora Serverless v1.

Per utilizzare MySQL Client per connettersi a un cluster database Aurora Serverless v1 che esegue l'edizione compatibile con MySQL di Aurora, devi specificare TLS/SSL nella richiesta. L'esempio seguente include il trust store principale di Amazon CA 1 scaricato da Amazon Trust Services, necessario per la riuscita della connessione. 

mysql -h endpoint -P 3306 -u user -p --ssl-ca=amazon-root-CA-1.pem --ssl-mode=REQUIRED

Specifica la password, quando richiesto. Verrà avviato il monitor MySQL. Puoi verificare che la sessione è crittografata utilizzando il comando status. 

mysql> status
--------------
mysql  Ver 14.14 Distrib 5.5.62, for Linux (x86_64) using readline 5.1
Connection id:          19
Current database:
Current user:           ***@*******
SSL:                    Cipher in use is ECDHE-RSA-AES256-SHA
...

Per maggiori informazioni sulla connessione al database Aurora MySQL con MySQL Client, consulta Connessione a un'istanza database che esegue il motore del database MySQL.

Aurora Serverless v1 supporta tutte le modalità TLS/SSL disponibili per MySQL Client (mysql) e PostgreSQL Client (psql), incluse quelle elencate nella tabella seguente.

Descrizione della modalità TLS/SSL mysql psql

Connettiti senza utilizzare TLS/SSL.

DISABLED

disattiva

Prova prima la connessione utilizzando TLS/SSL, ma se necessario, torna all'uso senza SSL.

PREFERRED

prefer (impostazione predefinita)

Applica l'uso di TLS/SSL.

REQUIRED

require

Applica TLS/SSL e verifica la CA.

VERIFY_CA

verify-ca

Applica TLS/SSL, verifica la CA e verifica il nome host della CA.

VERIFY_IDENTITY

verify-full

Aurora Serverless v1 utilizza certificati con caratteri jolly. Se specifichi l'opzione "verifica CA" o "verifica CA e nome host CA" quando utilizzi TLS/SSL, scarica innanzitutto il trust store CA 1 radice di Amazon da Amazon Trust Services. Dopo aver fatto ciò, puoi identificare questo file in formato PEMA nel comando client. Per farlo utilizzando PostgreSQL Client:

PerLinux, o: macOS Unix

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Per ulteriori informazioni sull'utilizzo del database Aurora PostgreSQL utilizzando Postgres Client, consulta Connessione a un'istanza database che esegue il modulo di motore del database PostgreSQL.

Per informazioni generali sulla connessione ai cluster database Aurora, consulta Connessione a un cluster database Amazon Aurora.

Suite di crittografia supportate per connessioni a cluster di database Aurora Serverless v1

Utilizzando suite di cifratura configurabili, è possibile avere maggiore controllo sulla sicurezza delle connessioni al database. È possibile specificare un elenco di suite di crittografia che si desidera abilitare per proteggere le connessioni TLS/SSL client al database. Con le suite di cifratura, è possibile controllare la crittografia di connessione accettata dal server di database. In questo modo si impedisce l'uso di sistemi di crittografia non sicuri o obsoleti.

I cluster di database Aurora Serverless v1 basati su Aurora MySQL supportano le stesse suite di crittografia dei cluster di database con provisioning di Aurora MySQL. Per informazioni su queste suite di crittografia, consulta Configurazione di suite di cifratura per connessioni ai cluster di database Aurora MySQL.

I cluster di database Aurora Serverless v1 basati su Aurora PostgreSQL non supportano le suite di crittografia.