Utilizzo di 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 v1UsareTLS/SSLcon 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, consulta la sezione Prezzi Serverless nella sezione My SQL -Compatible Edition o Postgre SQL -Compatible Edition 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 la tua applicazione può essere eseguita su My SQL 8.0 o Postgre SQL 13, ti consigliamo di utilizzarla. Aurora Serverless v2 Aurora Serverless v2scala più rapidamente e in modo più granulare. Aurora Serverless v2ha anche una maggiore compatibilità con altre funzionalità di Aurora, come le istanze Reader DB. 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à della regione e della versione 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, consultare Regioni supportate e motori Aurora DB per Aurora Serverless v1.

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 (IAM) autenticazione del database

    • Backtrack in Aurora

    • Flussi di attività di database

    • Autenticazione Kerberos

    • Approfondimenti sulle prestazioni

    • RDSProxy

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

    • 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 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 cluster Aurora Serverless v1 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 Aurora Serverless v1 sia l'origine o la destinazione della replica. Per replicare i dati in un cluster Aurora Serverless v1 DB da un'istanza My SQL DB esterna ad Aurora, ad esempio un'istanza in esecuzione su EC2 Amazon, prendi in considerazione l'utilizzo. 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 DB SQL basati su Aurora Postgre in esecuzione presentano le seguenti limitazioni: Aurora Serverless v1

    • 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 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 Mia — SQL 3306

    • Aurora Postgre — SQL 5432

  • Crea il tuo cluster Aurora Serverless v1 DB in un cloud privato virtuale (VPC) basato sul VPC servizio Amazon. Quando crei un cluster Aurora Serverless v1 DB nel tuoVPC, 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. AWS Support Per ulteriori informazioni, consulta la sezione VPCQuote Amazon.

  • Non puoi assegnare al cluster database Aurora Serverless v1 un indirizzo IP pubblico. Puoi accedere a un cluster Aurora Serverless v1 DB solo dall'interno di unVPC.

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

  • È possibile accedere a un cluster Aurora Serverless v1 DB da AWS Lambda. A tale scopo, è necessario configurare la funzione Lambda in modo che venga eseguita nello VPC stesso cluster Aurora Serverless v1 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 il cluster DB. Aurora Serverless v1 Supporta SSL le versioniTLS/1.0, 1.1 e 1.2. Non è necessario configurare il cluster Aurora Serverless v1 DB per utilizzareTLS/SSL.

Si applicano le seguenti limitazioni:

  • TLS/SSLil supporto per i cluster Aurora Serverless v1 DB non è attualmente disponibile in Cina (Pechino) Regione AWS.

  • Quando crei utenti del database per un cluster Aurora Serverless v1 DB SQL basato su Aurora My, 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 utilizzato per connettersi al cluster Aurora Serverless v1 DB, potrebbe non essere necessario specificareTLS/per SSL ottenere una connessione crittografata. Ad esempio, per utilizzare il Postgre SQL Client per connetterti a un cluster Aurora Serverless v1 DB che esegue Aurora Postgre SQL -Compatible Edition, connettiti come fai normalmente. 

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 v1utilizza il protocollo Transport Layer Security/Secure Sockets Layer (TLS/SSL) per crittografare le connessioni per impostazione predefinita a meno che/non sia disabilitato dall'applicazione client. SSL TLS La SSL connessioneTLS/termina presso il parco 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 del client per verificare se la connessione a Aurora Serverless v1 è TLS SSL /crittografata. SQLpg_stat_sslPostgre, le pg_stat_activity tabelle e la relativa ssl_is_used funzione non mostrano SSL lo statoTLS/per la comunicazione tra l'applicazione client e. Aurora Serverless v1 Allo stesso modo, lo SSL statoTLS/non può essere derivato dall'istruzione My SQLstatus.

I parametri del cluster Aurora force_ssl per Postgre SQL e My in SQL precedenza non require_secure_transport erano supportati per la v1. Aurora Serverless 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 cluster Aurora Serverless v1 DB che esegue Aurora My SQL -Compatible Edition, specifichiTLS/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 My SQL monitor 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 v1supporta 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 con caratteri jolly. 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:

PerLinux, omacOS: 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 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 consentire per proteggere le connessioni client/client al database. TLS SSL 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 v1I 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 delle suite di crittografia per le connessioni ai cluster Aurora My DB SQL.

Aurora Serverless v1I cluster DB basati su Aurora SQL Postgre non supportano le suite di crittografia.