Usare Amazon Aurora Serverless v1

PDFRSS

Importante

AWS ha annunciato la data per end-of-life Aurora Serverless v1: 31 marzo 2025. Consigliamo vivamente di aggiornarne uno Aurora Serverless v1 Cluster DB a Aurora Serverless v2 prima di tale data. L'aggiornamento può comportare una modifica del numero di versione principale del motore di database. Pertanto, è importante pianificare, testare e implementare questo passaggio prima della end-of-life data. A partire dall'8 gennaio 2025, i clienti non saranno più in grado di crearne di nuovi Aurora Serverless v1 cluster o istanze con o. AWS Management Console CLI Per informazioni sulla procedura di aggiornamento da Aurora Serverless v1 in Aurora Serverless v2, consulta Aggiornamento da un Aurora Serverless v1 cluster a Aurora Serverless v2.

Aurora Serverless v2 scala più rapidamente e in modo più granulare. Aurora Serverless v2 ha anche una maggiore compatibilità con altre funzionalità di Aurora, come le istanze Reader DB. Puoi saperne di più su Aurora Serverless v2 nella sezione Utilizzo Aurora Serverless v2.

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 nella sezione My -Compatible Edition o Postgre -Compatible Edition sul SQL SQL 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

• Vantaggi di Aurora Serverless v1

• Casi d'uso per Aurora Serverless v1

• Limitazioni di Aurora Serverless v1

• Requisiti di configurazione per Aurora Serverless v1

• Usare/con TLS SSL Aurora Serverless v1

• In che modo Aurora Serverless v1 funzionamento

• Creare un Aurora Serverless v1 cluster di database

• Ripristino di un Aurora Serverless v1 cluster di database

• Modificare un Aurora Serverless v1 cluster di database

• Dimensionamento Aurora Serverless v1 Capacità del cluster DB manualmente

• Visualizzazione Aurora Serverless v1 Cluster database

• Eliminazione di un Aurora Serverless v1 cluster di database

• Aurora Serverless v1 e versioni del motore di database Aurora

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 perfettamente la capacità di elaborazione e 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, 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. Consigliamo vivamente di aggiornarne uno Aurora Serverless v1 Cluster DB a Aurora Serverless v2 prima di tale data. L'aggiornamento può comportare una modifica del numero di versione principale del motore di database. Pertanto, è importante pianificare, testare e implementare questo passaggio prima della end-of-life data. A partire dall'8 gennaio 2025, i clienti non saranno più in grado di crearne di nuovi Aurora Serverless v1 cluster o istanze con o. AWS Management Console CLI

  Puoi saperne di più Aurora Serverless v2 nella sezione Utilizzo Aurora Serverless v2. Per informazioni sulla procedura di aggiornamento da Aurora Serverless v1 in Aurora Serverless v2, consulta Aggiornamento da un Aurora Serverless v1 cluster a Aurora Serverless v2.

• Aurora Serverless v1 non supporta le seguenti funzionalità:

  • Database globali di Aurora

  • Repliche di Aurora

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

  • Backtrack in Aurora

  • Flussi di attività di database

  • Autenticazione Kerberos

  • Approfondimenti sulle prestazioni

  • Proxy 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 modificare Data Capture () con CDC Aurora Serverless v1 Cluster DB. Solo i cluster Aurora DB forniti CDC supportano 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 assegnare un IAM ruolo 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 .

  • 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 SQL basati su Aurora My in esecuzione Aurora Serverless v1 non supportano quanto segue:

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

  • Ripristino di un'istantanea da un'istanza DB che non è Aurora My o for MySQL. RDS SQL

  • Replica dei dati mediante la replica basata su registri binari (binlog). Questa limitazione è valida indipendentemente dal fatto che il cluster DB SQL basato su Aurora My sia 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 SQL DB da un'istanza My DB esterna ad Aurora, ad esempio un'istanza in esecuzione su AmazonEC2. 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 una flotta di router tra il client e l'host del database per una scalabilità perfetta. L'indirizzo IP che il 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 Postgre in esecuzione SQL Aurora Serverless v1 presentano le seguenti limitazioni:

  • La gestione del piano di SQL query (apg_plan_managementestensione) di Aurora Postgree non è supportata.

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

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

  • Attualmente, alcune SQL query 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 Mia — SQL 3306

  • Aurora Postgre — SQL 5432

• Crea il tuo Aurora Serverless v1 Cluster DB in un cloud privato virtuale (VPC) basato sul VPC servizio Amazon. Quando crei un Aurora Serverless v1 Il tuo VPC cluster DB utilizza 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 le VPCquote Amazon.

• 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 unVPC.

• 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 modo VPC in cui 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 VPC Amazon nella AWS Lambda Developer Guide.

Usare/con TLS SSL 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 SSL le versioniTLS/1.0, 1.1 e 1.2. Non è necessario configurare il Aurora Serverless v1 Cluster DB da usareTLS/SSL.

Si applicano le seguenti limitazioni:

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

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

• Sia per le utilità My SQL Client che Postgre SQL Client, le variabili di sessione che è possibile utilizzare in altri ambienti non hanno alcun effetto quando si utilizza/tra client e TLS SSL Aurora Serverless v1.

• Per My SQL Client, quando ci si connette con SSL la VERIFY_IDENTITY modalitàTLS/, attualmente è necessario utilizzare il comando compatibile con My SQL 8.0. mysql Per ulteriori informazioni, vedere Connessione a un'istanza DB che esegue il motore di database My SQL.

A seconda del client a cui ti connetti Aurora Serverless v1 Cluster DB, potrebbe non essere necessario specificareTLS/SSLper ottenere una connessione crittografata. Ad esempio, per utilizzare il SQL client Postgre per connettersi a un Aurora Serverless v1 Cluster DB che esegue Aurora Postgre SQL -Compatible Edition, connettiti come al solito.

psql -h endpoint -U user

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

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 è TLS SSL /crittografato. SQLpg_stat_sslPostgre e pg_stat_activity le tabelle e la relativa ssl_is_used funzione non mostrano SSL lo statoTLS/per la comunicazione tra l'applicazione client e Aurora Serverless v1. Analogamente, lo SSL statoTLS/non può essere derivato dall'SQLstatusistruzione My.

I parametri del cluster Aurora force_ssl per Postgre SQL e per My in SQL precedenza non erano supportati require_secure_transport per Aurora Serverless v1. Questi parametri sono ora disponibili per Aurora Serverless v1. Per un elenco completo dei parametri supportati da Aurora Serverless v1, chiamate l'operazione. DescribeEngineDefaultClusterParametersAPI Per ulteriori informazioni sui gruppi di parametri e su Aurora Serverless v1, consulta Gruppi di parametri per Aurora Serverless v1.

Per utilizzare My SQL Client per connettersi a un Aurora Serverless v1 Cluster DB che esegue Aurora My SQL -Compatible Edition, si specificaTLS/SSLnella 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. Presto, il SQL monitor My si apre. 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 ulteriori informazioni sulla connessione ad Aurora My SQL database con My SQL Client, consulta Connessione a un'istanza DB che esegue il motore di SQL database personale.

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

Descrizione della modalità/TLSSSL	mysql	psql
Connect senza usareTLS/SSL.	DISABLED	disattiva
Prova SSL prima la connessione usandoTLS/, ma torna a non- SSL se necessario.	PREFERRED	prefer (impostazione predefinita)
Imponi usandoTLS/SSL.	REQUIRED	require
ApplicaTLS/SSLe verifica la CA.	VERIFY_CA	verify-ca
ApplicaTLS/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 usiTLS/SSL, scarica prima il trust store Amazon root CA 1 da Amazon Trust Services. Dopo averlo fatto, puoi identificare questo file in PEM formato elettronico nel tuo comando client. Per farlo utilizzando il client SQL Postgres:

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 SQL database Aurora Postgre utilizzando il client Postgres, vedere Connessione a un'istanza DB che esegue il motore di database Postgre. SQL

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 consentire per proteggere le SSL connessioni TLS client/i 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 SQL My supportano le stesse suite di crittografia dei cluster DB forniti da Aurora SQL My. 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 SQL Postgre non supportano le suite di crittografia.