Fatturazione per Amazon Redshift Serverless

Fatturazione per la capacità di calcolo

Puoi acquistare capacità per Amazon Redshift Serverless in due modi:

• Puoi acquistare capacità su richiesta: quando scegli la capacità di elaborazione su richiesta, paghi le risorse man mano che utilizzi. Questa è la scelta migliore se stai appena iniziando a usare Amazon Redshift Serverless o se non hai ancora una buona idea dei tuoi modelli di utilizzo costanti. On-demand offre la massima flessibilità. Per ulteriori informazioni, consulta Fatturazione per la capacità di elaborazione su richiesta.

• Puoi acquistare prenotazioni: una prenotazione offre uno sconto quando acquisti una quantità preimpostata di risorse di elaborazione per un periodo di tempo specifico, ad esempio per un anno. È una buona idea quando sai che utilizzerai una quantità di capacità in modo costante. È utile per risparmiare denaro quando è possibile prevedere alcune delle esigenze di capacità. Per ulteriori informazioni, consulta Fatturazione per prenotazioni senza server.

Puoi utilizzare contemporaneamente prenotazioni e risorse on-demand. Non è necessario utilizzare l'uno o l'altro.

Per informazioni dettagliate sui prezzi, consulta i prezzi di Amazon Redshift.

Fatturazione per l'archiviazione

La capacità di archiviazione principale viene fatturata come Redshift Managed Storage (RMS). L'archiviazione è fatturata per GB/mese. La fatturazione dell'archiviazione è separata dalla fatturazione per le risorse di elaborazione. Lo storage utilizzato per gli snapshot degli utenti viene fatturato alla tariffa di fatturazione di backup standard.

I costi di trasferimento dati e di machine learning si applicano separatamente, così come quelli dei cluster sottoposti a provisioning. La replica delle istantanee e la condivisione dei dati tra AWS le regioni vengono fatturate alle tariffe di trasferimento indicate nella pagina dei prezzi. Per ulteriori informazioni sui prezzi, consultare Prezzi di Amazon Redshift.

Visualizzazione dell'utilizzo della fatturazione con CloudWatch

La metricaSnapshotStorage, che tiene traccia dell'utilizzo dello storage delle istantanee, viene generata e inviata a. CloudWatch Per ulteriori informazioni su CloudWatch, consulta What is Amazon CloudWatch?

Usare la prova gratuita di Amazon Redshift Serverless

Amazon Redshift Serverless offre una versione di prova gratuita. Se partecipi alla prova gratuita, puoi visualizzare il saldo del credito di prova gratuito nella console di Redshift e controllare l'utilizzo della prova gratuita nella visualizzazione di sistema SYS_SERVERLESS_USAGE. Tieni presente che i dettagli di fatturazione per l'utilizzo di prova gratuito non vengono visualizzati nella console di fatturazione. Puoi visualizzare l'utilizzo nella console di fatturazione solo dopo la fine della prova gratuita. Per ulteriori informazioni sulla prova gratuita di Amazon Redshift Serverless, consulta Prova gratuita di Amazon Redshift Serverless.

Note di utilizzo nella fatturazione

• Utilizzo della registrazione - Una query o una transazione viene misurata e registrata solo dopo il completamento, il rollback o l'arresto della transazione. Ad esempio, se una transazione viene eseguita per due giorni, l'utilizzo della RPU viene registrato dopo il completamento. È possibile monitorare l'uso continuo in tempo reale eseguendo query sys_serverless_usage. La registrazione delle transazioni può riflettere la variazione di utilizzo della RPU e influire sui costi per orari specifici e per l'uso quotidiano.

• Scrittura di transazioni esplicite - È importante come best practice per porre fine alle transazioni. Se non interrompi o ripristini una transazione aperta, Amazon Redshift Serverless continua a utilizzarla. RPUs Ad esempio, se scrivi un esplicito BEGIN TRAN, è importante avere il corrispondente COMMITe le istruzioni ROLLBACK.

• Query annullate - Se si esegue una query e la si annulla prima che finisca, ti verrà fatturato il tempo di esecuzione della query.

• Dimensionamento: l'istanza Amazon Redshift Serverless può avviare la scalabilità per la gestione di periodi di carico più elevato, al fine di mantenere prestazioni costanti. La fatturazione Amazon Redshift Serverless include sia la capacità di calcolo di base che la capacità scalata alla stessa tariffa RPU.

• Ridimensionamento verso il basso: Amazon Redshift Serverless aumenta la scalabilità rispetto alla sua capacità RPU di base per gestire periodi di carico più elevato. In alcuni casi, la capacità RPU può rimanere a un livello superiore per un periodo dopo il calo del carico delle query. Si consiglia di impostare il valore massimo delle ore RPU nella console per evitare costi imprevisti.

• Tabelle di sistema - Quando si esegue una query su una tabella di sistema, viene fatturato il tempo della query.

• Redshift Spectrum: quando disponi di Amazon Redshift Serverless ed esegui query, non è previsto un costo separato per le query di data-lake. Per le query sui dati archiviati in Amazon S3, l'addebito è lo stesso, in base al tempo della transazione, delle query sui dati locali.

• Query federate: le query federate vengono addebitate in base all'utilizzo in un intervallo di RPUs tempo specifico, allo stesso modo delle query sul data warehouse o sul data lake.

• Storage - Lo storage viene fatturato separatamente, in GB/mese.

• Costo minimo: il costo minimo è di 60 secondi per l'utilizzo delle risorse di calcolo, misurato su base al secondo.

• Fatturazione snapshot - La fatturazione snapshot non cambia. Viene addebitata in base allo spazio di archiviazione, fatturata a una tariffa di GB/mese. È possibile ripristinare il data warehouse in punti specifici nelle ultime 24 ore con una granularità di 30 minuti, gratuitamente. Per ulteriori informazioni sui prezzi, consultare Prezzi di Amazon Redshift.

Best practice di Amazon Redshift Serverless per mantenere la fatturazione prevedibile

Di seguito sono riportate le best practice e le impostazioni integrate che aiutano a mantenere la fatturazione coerente.

• Assicurati di terminare ogni transazione. Quando si utilizza BEGIN per iniziare una transazione, è importante anche END.

• Usa la gestione degli errori con le best practice per rispondere con grazia agli errori e terminare ogni transazione. La riduzione al minimo delle transazioni aperte aiuta a evitare l'uso inutile della RPU.

• Usa SESSION TIMEOUT per terminare le transazioni aperte e le sessioni inattive. Fa scadere qualsiasi sessione inattiva per più di 3600 secondi (1 ora). Fa scadere qualsiasi transazione mantenuta aperta e inattiva per più di 21600 secondi (6 ore). Questa impostazione di timeout può essere modificata esplicitamente per un utente specifico, ad esempio quando si desidera mantenere aperta una sessione per una query di lunga durata. L'argomento CREA UTENTE mostra come regolare SESSION TIMEOUT per un utente.

  • Nella maggior parte dei casi, si consiglia di non estendere il valore SESSION TIMEOUT, a meno che non si disponga di un caso d'uso che lo richiede specificamente. Se la sessione rimane inattiva, con una transazione aperta, è possibile che RPUs vengano utilizzati fino alla chiusura della sessione. Ciò comporterà costi inutili.

  • Il tempo massimo per una query in esecuzione in Amazon Redshift serverless è di 86.399 secondi (24 ore). Il periodo massimo di inattività per una transazione aperta prima che Amazon Redshift serverless termini la sessione associata alla transazione è sei ore. Per ulteriori informazioni, consulta Quote per gli oggetti Amazon Redshift Serverless.

Fatturazione senza server di Amazon Redshift con pool di connessioni

Amazon Redshift Serverless considera tutte le query in entrata come attività utente fatturabili, incluse le query leggere di controllo dello stato inviate dai pool di connessioni. Questo comportamento si applica indipendentemente dal fatto che la query provenga da un'applicazione, un driver o un framework di pool di connessioni. JDBC/ODBC Ogni query di controllo dello stato di salute attiva l'utilizzo del calcolo e vengono addebitati costi indipendentemente dallo scopo o dall'origine della query. Di conseguenza, la manutenzione di pool di connessioni aperti può generare costi anche quando non è in esecuzione alcun carico di lavoro effettivo degli utenti.

Il pool di connessioni mantiene un pool di connessioni persistenti tra le applicazioni e l'endpoint Serverless Amazon Redshift. Per garantire che queste connessioni rimangano integre e disponibili, i meccanismi di pooling spesso inviano query leggere o vuote (ad esempio) a intervalli regolari. SELECT 1 Queste interrogazioni automatiche verificano lo stato della connessione.

Quando utilizzi il pool di connessioni, prendi in considerazione queste best practice per ridurre al minimo gli addebiti non intenzionali:

• Regola la frequenza dei controlli di integrità esaminando e ottimizzando la frequenza delle query di health check o keep-alive nella configurazione del pool di connessioni.

• Ottimizza le impostazioni del sistema inattivo configurando il pool di connessioni per ridurre al minimo le interruzioni di connessione non necessarie o le attività di interrogazione in background durante i periodi di inattività del sistema.

• Implementa il pooling a livello di applicazione o una migliore gestione del ciclo di vita della connessione se è possibile ridurre il sovraccarico.

• Disattiva l'heartbeat o le query di convalida se la configurazione del pool di connessioni lo consente. Controllate i parametri specifici della stringa di connessione o i file di configurazione per modificare queste impostazioni.

• Ottimizza le impostazioni TCP keepalive: se non riesci a disabilitare i meccanismi di heartbeat interni del driver, modifica le impostazioni keepalive del Transmission Control Protocol (TCP) a livello di sistema operativo o di applicazione per risolvere i problemi di timeout della connessione. Per ulteriori informazioni, consulta la documentazione del sistema operativo, del JDBC/ODBC driver o del pool di connessioni.

• Ottimizza il pool di connessioni al database: configura il tuo pool di connessioni (HikariCP, Apache Database Connection Pool) per gestire le connessioni e ridurre al minimo il sovraccarico di connessione. Concentrati su parametri come il numero massimo di connessioni, il timeout di inattività e le query di convalida (se necessario). Questa ottimizzazione aiuta ad allineare l'utilizzo dell'elaborazione Serverless di Amazon Redshift alla domanda effettiva del carico di lavoro, riducendo potenzialmente i costi.

Ottimizzazione dei costi per Amazon Redshift Serverless con Zero-ETL

Per ottimizzare i costi eseguendo integrazioni zero-ETL su Amazon Redshift Serverless, puoi dimensionare correttamente i tuoi ambienti e regolare le impostazioni di aggiornamento in base alle esigenze del carico di lavoro. Valuta la possibilità di apportare le seguenti modifiche:

• Utilizza la capacità RPU di base inferiore di 8 RPU, se disponibile, per i carichi di lavoro.

• Configura il REFRESH_INTERVAL dell'istanza Redshift di destinazione per bilanciare freschezza e costi. Intervalli più brevi garantiscono aggiornamenti quasi in tempo reale, ma aumentano i costi di elaborazione. Intervalli più lunghi (5 minuti o più) riducono i costi per i carichi di lavoro in cui l'aggiornamento immediato non è fondamentale, come la reportistica o l'analisi storica. Per modificare il target di Redshift REFRESH_INTERVAL, consulta la clausola refresh interval nella descrizione di ALTER DATABASE.

• Massimizza l'utilizzo del tuo ambiente Amazon Redshift Serverless eseguendo contemporaneamente carichi di lavoro di analisi mentre vengono acquisiti dati zero-ETL. Ciò garantisce che la capacità di elaborazione serva attivamente a molteplici scopi aziendali.

• Per ridurre al minimo l'elaborazione inattiva e ottimizzare il costo totale di proprietà, rivedi le attuali integrazioni zero-ETL e aumenta REFRESH_INTERVAL laddove l'aggiornamento dei dati non sia fondamentale per l'azienda, allineando al contempo la capacità RPU alla domanda del carico di lavoro.