Usare Amazon Aurora Serverless v1 - Amazon Aurora
Disponibilità della regione e della versione per Aurora Serverless v1Vantaggi 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à.

Usare Amazon Aurora Serverless v1

Importante

AWS ha annunciato la data per end-of-life Aurora Serverless v1: 31 marzo 2025. Tutti Aurora Serverless v1 i cluster che non verranno migrati entro il 31 marzo 2025 verranno migrati in Aurora Serverless v2 durante la finestra di manutenzione. Se l'aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster di provisioning convertito in Amazon RDS Extended Support. Per ulteriori informazioni, consulta Supporto esteso di Amazon RDS con .

Amazon Aurora Serverless v1 (Amazon Aurora Serverless versione 1) è una configurazione di scalabilità automatica su richiesta per Amazon Aurora. Un Aurora Serverless v1 Il cluster DB è un cluster DB che aumenta e riduce la capacità di calcolo in base alle esigenze dell'applicazione. Ciò contrasta con i cluster DB forniti da 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, consulta la sezione Prezzi Serverless in MySQL Compatible Edition o PostgreSQL Compatible Edition nel Amazon Aurora pricing pagina.

Aurora Serverless v1 i cluster hanno lo stesso tipo di volume di storage ad alta capacità, distribuito e ad alta disponibilità utilizzato dai cluster DB assegnati.

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

Argomenti

Disponibilità di aree e versioni per Aurora Serverless v1

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, consulta Aurora Serverless v1.

Vantaggi di Aurora Serverless v1

Aurora Serverless v1 offre i seguenti vantaggi:

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

  • Scalabile: Aurora Serverless v1 ridimensiona senza interruzioni la capacità di calcolo e di memoria in base alle esigenze, senza interrompere le connessioni dei client.

  • Conveniente: quando si utilizza Aurora Serverless v1, paghi solo per le risorse di database che utilizzi, in base al secondo.

  • Storage ad alta disponibilità: Aurora Serverless v1 utilizza lo stesso sistema di storage distribuito con tolleranza ai guasti con replica a sei vie di Aurora per proteggere dalla perdita di 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 solo per le risorse di database che utilizzi al secondo.

  • Nuove applicazioni – Stai distribuendo una nuova applicazione e non sei sicuro delle dimensioni dell'istanza necessarie. Utilizzando Aurora Serverless v1, è possibile creare un endpoint del database e ridimensionare automaticamente il database 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. Con Aurora Serverless v1, non è più necessario predisporre la capacità di picco o media.

  • 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. Con Aurora Serverless v1, il database ridimensiona automaticamente la capacità per soddisfare le esigenze di picco di carico dell'applicazione e si ridimensiona nuovamente al termine del picco di attività.

  • 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 è in uso.

  • Applicazioni multi-tenant: con Aurora Serverless v1, non è necessario gestire individualmente la capacità del database per ogni applicazione del parco applicazioni. Aurora Serverless v1 gestisce la capacità del database individuale per te.

Limitazioni di Aurora Serverless v1

Le seguenti limitazioni si applicano a Aurora Serverless v1:

  • Importante

    AWS ha annunciato la end-of-life data per Aurora Serverless v1: 31 marzo 2025. Tutti Aurora Serverless v1 i cluster che non verranno migrati entro il 31 marzo 2025 verranno migrati in Aurora Serverless v2 durante la finestra di manutenzione. Se l'aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster di provisioning convertito in Amazon RDS Extended Support. Per ulteriori informazioni, consulta Supporto esteso di Amazon RDS con .

  • Aurora Serverless v1 non supporta le seguenti funzionalità:

    • 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 in AWS Management Console

  • Connessioni a un Aurora Serverless v1 Il cluster DB viene chiuso automaticamente se mantenuto aperto per più di un giorno.

  • Tutti Aurora Serverless v1 I cluster DB presentano le seguenti limitazioni:

    • Non puoi esportare Aurora Serverless v1 istantanee su bucket Amazon S3.

    • Non puoi usare AWS Database Migration Service e Change Data Capture (CDC) con Aurora Serverless v1 Cluster DB. Solo i cluster Aurora DB con provisioning supportano CDC AWS DMS come origine.

    • Non puoi salvare dati in file di testo in Amazon S3 o caricare dati di file di testo su Aurora Serverless v1 da S3.

    • Non è possibile associare un ruolo IAM a un Aurora Serverless v1 Cluster DB. Tuttavia, è possibile caricare dati su Aurora Serverless v1 da Amazon S3 utilizzando l'aws_s3estensione con la aws_s3.table_import_from_s3 funzione e il credentials parametro. 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.

  • Cluster DB Aurora basati su MySQL in esecuzione Aurora Serverless v1 non supportano quanto segue:

    • Richiamo di AWS Lambda funzioni dall'interno del cluster Aurora MySQL DB. Tuttavia, AWS Lambda le funzioni possono effettuare chiamate al Aurora Serverless v1 Cluster DB.

    • 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 è valida indipendentemente dal fatto che il cluster DB Aurora sia basato su MySQL Aurora Serverless v1 è l'origine o la destinazione della replica. Per replicare i dati in un Aurora Serverless v1 Prendi in considerazione l'utilizzo di un cluster DB da un'istanza DB MySQL esterna ad Aurora, ad esempio un'istanza in esecuzione su Amazon. EC2 AWS Database Migration Service Per ulteriori informazioni, consulta la AWS Database Migration Service Guida per l'utente di .

    • Creazione di utenti con accesso basato su host ('username'@'IP_address'). Questo è perché Aurora Serverless v1 utilizza una flotta di router tra il client e l'host del database per una scalabilità senza interruzioni. L'indirizzo IP che Aurora Serverless Il cluster DB vede è quello dell'host del router e non del tuo client. Per ulteriori informazioni, consulta Aurora Serverless v1 architecture.

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

  • Cluster DB basati su Aurora PostgreSQL in esecuzione Aurora Serverless v1 presentano 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 Aurora Serverless v1 Cluster DB.

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

Requisiti di configurazione per Aurora Serverless v1

Quando si crea un Aurora Serverless v1 Cluster DB, 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 Aurora Serverless v1 Cluster DB in un cloud privato virtuale (VPC) basato sul servizio Amazon VPC. Quando crei un Aurora Serverless v1 Nel cluster DB del tuo VPC, utilizzi due (2) dei cinquanta (50) endpoint Interface e Gateway Load Balancer assegnati al tuo VPC. Questi endpoint vengono creati automaticamente per l'utente. Per aumentare la tua quota, puoi contattare. Supporto Per ulteriori informazioni, consulta la pagina relativa alle quote di Amazon VPC.

  • Non puoi dare un Aurora Serverless v1 Cluster DB con un indirizzo IP pubblico. È possibile accedere a un Aurora Serverless v1 Cluster DB solo dall'interno di un VPC.

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

  • Modifiche a un gruppo di sottoreti utilizzato da un Aurora Serverless v1 Il cluster DB non viene applicato al cluster.

  • È possibile accedere a un Aurora Serverless v1 Cluster DB da AWS Lambda. A tale scopo, è necessario configurare la funzione Lambda in modo che venga eseguita nello stesso VPC del Aurora Serverless v1 Cluster DB. Per ulteriori informazioni su come lavorare con AWS Lambda, consulta Configurazione di una funzione Lambda per accedere alle risorse in un Amazon VPC nella Developer Guide.AWS Lambda

Usare TLS/SSL con Aurora Serverless v1

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

Si applicano le seguenti limitazioni:

  • Supporto TLS/SSL per Aurora Serverless v1 I cluster DB non sono attualmente disponibili in Cina (Pechino). Regione AWS

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

  • Sia per le utilità MySQL Client che PostgreSQL Client, le variabili di sessione che è possibile 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 a cui ti connetti Aurora Serverless v1 Cluster DB, potrebbe non essere necessario specificare TLS/SSL per ottenere una connessione crittografata. Ad esempio, per utilizzare il client PostgreSQL per connettersi a un Aurora Serverless v1 Cluster DB che esegue Aurora PostgreSQL Compatible Edition, connettiti 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 le terminazioni di Security/Secure Sockets Layer (TLS/SSL) protocol to encrypt connections by default unless SSL/TLS is disabled by the client application. The TLS/SSL connessione Transport Layer nel parco router. La comunicazione tra il parco router e il Aurora Serverless v1 Il cluster DB si verifica all'interno dei confini della rete interna del servizio.

È possibile controllare lo stato della connessione del client per verificare se la connessione a Aurora Serverless v1 è crittografato con TLS/SSL. pg_stat_sslPostgreSQL e le tabelle pg_stat_activity e la ssl_is_used sua funzione 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 MySQL. status

I parametri del cluster Aurora per force_ssl PostgreSQL e per MySQL in precedenza non erano supportati per require_secure_transport 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 il client MySQL per connettersi a un Aurora Serverless v1 Cluster DB che esegue Aurora MySQL Compatible Edition, specifichi 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 (), incluse quelle elencate nella tabella seguente. psql

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 wildcard. 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:

In Linux, macOS, oppure 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 Aurora Serverless v1 Cluster database

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.

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

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