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à. # Come funziona la fatturazione in Aurora DSQL Con Amazon Aurora DSQL, paghi solo ciò che usi senza costi iniziali. Questa sezione spiega come Aurora DSQL misura l'attività del database e la traduce in addebiti sulla fattura. AWS Per i prezzi correnti per regione, consulta la pagina dei prezzi di [ Aurora DSQL. ](https://aws.amazon.com/rds/aurora/dsql/pricing/) **Topics** + [Come funziona la misurazione](#billing-how-metering-works) + [Spiegazione della misurazione dei componenti DPU](#billing-dpu-components) + [Multi-Region fatturazione](#billing-multiregion-write-dpu) + [Monitoraggio dell'utilizzo della DPU con CloudWatch](#billing-cloudwatch-monitoring) + [Utilizzo di EXPLAIN ANALYZE VERBOSE per la consapevolezza dei costi](#billing-explain-analyze) + [Le migliori pratiche per la stima dei costi](#billing-best-practices) ## Come funziona la misurazione A differenza dei database tradizionali che addebitano la capacità assegnata, Aurora DSQL addebita solo il lavoro effettivo svolto. Aurora DSQL misura due componenti principali: l'attività del database, misurata in unità di elaborazione distribuita (DPU) e lo storage, misurato in. GiB-month Le DPU misurano il lavoro svolto dal sistema per eseguire il carico di lavoro SQL e sono composte da tre componenti per i cluster a regione singola: Compute DPU, Read DPU e Write DPU. Multi-Region i cluster sono dotati di un componente Write DPU aggiuntivo. MultiRegion Per ulteriori informazioni sulla fatturazione, vedi Multi-Region fatturazione. [ Multi-Region ](#billing-multiregion-write-dpu) I cluster con Change Data Capture (CDC) abilitato sono dotati di un componente Stream DPU aggiuntivo. Per ulteriori informazioni sulla fatturazione CDC, consulta Stream DPU. [Streaming DPU](#billing-stream-dpu) La tabella seguente riassume i componenti utilizzati da Aurora DSQL per misurare l'attività del database. Sulla fattura vengono visualizzate solo due voci: una per lo storage e una per la DPU, che è la somma di ciascuno dei singoli componenti. | Unità di misurazione | Tipo di attività | Misura | | --- | --- | --- | | DPU di calcolo | Elaborazione query | Tempo di CPU | | Leggi DPU | Leggi i dati dal tuo database | Byte letti dallo storage | | Scrivi DPU | Scrivi dati nel tuo database | Byte scritti nell'archivio | | DPU in streaming | Streaming CDC (se abilitato) | Byte trasmessi in streaming | | Archiviazione | Archiviazione dei | GiB-month | ## Spiegazione della misurazione dei componenti DPU Per ogni transazione, Aurora DSQL calcola la DPU totale come somma di tre componenti: Compute DPU, Read DPU e Write DPU. Le sezioni seguenti spiegano come Aurora DSQL misura ogni componente. ``` Total DPU = ComputeDPU + ReadDPU + WriteDPU ``` ### CPU calcolata Le DPU di calcolo vengono misurate utilizzando il tempo totale di elaborazione impiegato per l'esecuzione della query, inclusi join, funzioni, aggregazioni, ordinamento e pianificazione delle query. Poiché alcune parti della query possono essere elaborate in parallelo, la DPU di calcolo riflette la somma di tutto il tempo di elaborazione, non il tempo limite della query. La formula seguente riassume come calcolare le DPU di calcolo: ``` ComputeDPU = Total Compute time (in seconds) ``` ### WritedPU Per ogni transazione, Aurora DSQL misura le DPU di scrittura in base al totale dei byte scritti nello storage. Le DPU di scrittura includono il totale dei dati scritti nella tabella di base e gli eventuali indici secondari. Aurora DSQL fattura ogni riga scritta nella tabella di base e negli indici secondari inferiori a 128 byte come se fosse 128 byte. Aurora DSQL fattura una transazione di scrittura che scrive meno di 1.024 byte come se ne scrivesse 1.024. **Nota** Le operazioni di scrittura comportano anche costi di ReadDPU perché Aurora DSQL legge l'indice della chiave primaria per verificarne l'unicità prima della scrittura. Le seguenti formule mostrano i passaggi per calcolare le DPU di scrittura: **Fase 1: Calcola i byte scritti ** ``` Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written ``` **Passaggio 2: calcola WritedPU ** ``` WriteDPU = max(Bytes Written, 1024) × 0.00004883 ``` ### Leggi DPU Per ogni transazione, Aurora DSQL misura le DPU di lettura in base al totale dei byte letti dallo storage. Le DPU di lettura includono i dati letti dalla tabella di base e gli eventuali indici secondari. **Per-partition minimo: ** Aurora DSQL misura i byte letti per partizione di storage, non per riga. Se una richiesta di lettura a una partizione di archiviazione restituisce meno di 128 byte, Aurora DSQL la arrotonda a 128 byte. Ad esempio, se la query legge da 4 partizioni, 200 byte da una partizione e 50 byte da ciascuna delle altre tre, le tre letture da 50 byte vengono arrotondate ciascuna a 128 byte, per un totale di 200 \+ 128 \+ 128 \+ 128 = 584 byte fatturati. **Transazione minima: ** Aurora DSQL fattura una transazione di lettura che legge meno di 2.048 byte in totale come se leggesse 2.048 byte. Le seguenti formule mostrano i passaggi per calcolare le DPU di lettura: **Passaggio 1: calcola i byte letti ** ``` Bytes Read = # of rows read × size of each row ``` **Nota** I byte effettivi letti dipendono da come i dati vengono distribuiti tra le partizioni di archiviazione, poiché per partizione viene applicato il minimo di 128 byte per partizione. Se tutte le dimensioni delle righe sono superiori a 128 byte, puoi semplicemente moltiplicare il numero di righe lette per la dimensione di ogni riga. **Passaggio 2: calcola ReadDPU ** ``` ReadDPU = max(Bytes Read, 2048) × 0.00000183105 ``` ### Streaming DPU Le DPU di streaming si applicano solo quando abiliti l'acquisizione dei dati di modifica (CDC) sul cluster. Aurora DSQL misura le DPU di streaming in base ai byte totali trasmessi allo stream Amazon Kinesis Data Streams di destinazione. Se non vengono apportate modifiche allo streaming, non è previsto alcun addebito per la DPU Stream. La formula seguente mostra come calcolare le DPU Stream: ``` StreamDPU = Bytes Streamed × 0.0000023283 ``` Aurora DSQL fattura le DPU Stream alla stessa tariffa di tutti gli altri componenti DPU. Per ulteriori informazioni sugli stream CDC, consulta. [Modifica i flussi di acquisizione dei dati](cdc-streams.md) ### Esempi di fatturazione Gli esempi seguenti dimostrano come Aurora DSQL calcola le DPU per operazioni comuni. I valori di costo in questi esempi utilizzano il prezzo della regione us-east-1. Per i prezzi in altre regioni, consulta la pagina dei prezzi di [ Aurora DSQL. ](https://aws.amazon.com/rds/aurora/dsql/pricing/) #### Esempio: ricerca semplice dei punti (lettura) Questo esempio dimostra un calcolo ReadDPU con ricerca puntuale in cui si applica il minimo della transazione. **Schema: ** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Interrogazione: ** ``` SELECT * FROM orders WHERE customer_id = 'cust-12345'; ``` **Scenario: ** la query restituisce 5 righe, ciascuna di circa 100 byte. Supponendo che tutte le righe risiedano in una partizione di archiviazione, il totale dei byte letti è 5 × 100 = 500 byte. Poiché 500 byte superano il minimo di 128 byte per partizione, non si applica alcun valore minimo per partizione. **Calcola ReadDPU: ** ``` ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375 ``` Il valore minimo di transazione di 2.048 byte si applica poiché 500 < 2.048. **Costo totale della transazione: ** Supponendo un tempo di esecuzione della query di 3 ms (0,003 secondi): ``` ComputeDPU: 0.003 ReadDPU: 0.00375 WriteDPU: 0.0 ------------------- Total DPU: 0.00675 ``` #### Esempio: scansione dell'intervallo filtrato (lettura) **Schema: ** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes -- Table contains 100 orders for customer 'cust-12345' ``` **Interrogazione: ** ``` SELECT * FROM orders WHERE customer_id = 'cust-12345' AND total_amount > 500.00; ``` **Scenario: ** la query analizza 100 righe alla ricerca del cliente 'cust-12345', ma il `total_amount > 500.00` filtro riduce il risultato a sole 10 righe restituite. Aurora DSQL fattura tutte le 100 righe scansionate. Supponendo che tutte le righe risiedano in una partizione di archiviazione, il totale dei byte letti è 100 × 100 = 10.000 byte. **Calcola ReadDPU: ** ``` ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831 ``` Poiché 10.000 byte superano il minimo di 2.048 byte di transazione, vengono utilizzati i byte effettivamente letti. **Costo totale della transazione: ** Supponendo un tempo di esecuzione della query di 8 ms (0,008 secondi): ``` ComputeDPU: 0.008 ReadDPU: 0.01831 WriteDPU: 0.0 ------------------- Total DPU: 0.02631 ``` **Importante** Per ridurre al minimo i costi di ReadDPU, progetta query e indici in modo da scansionare solo le righe necessarie. In questo esempio, l'aggiunta di un indice `(customer_id, total_amount)` potrebbe consentire alla query di scansionare un numero inferiore di righe. #### Esempio: inserimento singolo (lettura e scrittura) **Schema: ** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Interrogazione: ** ``` INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-67890', 150.00, 'pending'); ``` **Scenario: ** inserire 1 riga, circa 100 byte. **Calcolo scritto della CPU: ** *Fase 1 - Calcola i byte scritti: * ``` 1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes ``` *Fase 2 - Calcola WritedPU: * ``` WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05 ``` La transazione minima di 1.024 byte si applica poiché 128 < 1.024. **ReadDPU (controllo della chiave primaria): ** Aurora DSQL legge l'indice della chiave primaria per verificarne l'unicità prima della scrittura. Ciò comporta il costo minimo di lettura della transazione. ``` ReadDPU = 0.00375 (transaction minimum) ``` **Costo totale della transazione: ** Supponendo un tempo di esecuzione della query di 8 ms (0,008 secondi): ``` ComputeDPU: 0.008 ReadDPU: 0.00375 WriteDPU: 0.05 ------------------- Total DPU: 0.06175 ``` #### Esempio: inserimento in blocco (lettura e scrittura) **Schema: ** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Interrogazione: ** ``` INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-001', 100.00, 'pending'), ('cust-002', 150.00, 'pending'), ... -- 100 rows total ('cust-100', 200.00, 'pending'); ``` **Scenario: ** inserire 100 righe, ciascuna di circa 100 byte. **Calcolo WritedPU: ** *Fase 1 - Calcola i byte scritti: * ``` 100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes ``` *Fase 2 - Calcola WritedPU: * ``` WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625 ``` **ReadDPU (controlli della chiave primaria): ** Aurora DSQL legge l'indice della chiave primaria per ogni riga per verificarne l'unicità. Supponendo che tutte le 100 ricerche di chiavi risiedano in una partizione di archiviazione, il totale dei byte letti è 100 × 16 byte (UUID) = 1.600 byte: ``` ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375 ``` La transazione minima di 2.048 byte si applica poiché 1.600 < 2.048. **Costo totale della transazione: ** Supponendo un tempo di esecuzione della query di 80 ms (0,08 secondi): ``` ComputeDPU: 0.08 ReadDPU: 0.00375 WriteDPU: 0.625 ------------------- Total DPU: 0.70875 ``` ## Multi-Region fatturazione Multi-Region i cluster prevedono un componente DPU di MultiRegion scrittura aggiuntivo oltre alle DPU di elaborazione, lettura e scrittura standard. Questa sezione si applica solo ai cluster multiregionali. Single-Region i cluster non sono soggetti a questo costo. Multi-Region Le DPU di scrittura misurano i byte totali scritti nella regione peering. Aurora DSQL addebita questa DPU nella regione in cui ha avuto origine la scrittura, non nella regione peering. Ad esempio, in una configurazione peering con due Region e Witness attive, Aurora DSQL addebita la DPU di scrittura della transazione di origine per ogni regione peering attiva nel calcolo del. `MultiRegionWriteDPU` Ciò significa che una transazione che matura 8 comporta un ulteriore 8% per questa configurazione. `WriteDPU` `MultiRegionWriteDPU` Si tratta di 8 per la regione di origine, 8 per la regione peering e non comporta alcun costo per la regione Witness. Aurora DSQL addebita tutti gli addebiti alla regione che ha originato la transazione. Tutti i cluster nella configurazione multiregionale comportano un costo per le dimensioni di archiviazione. Poiché Aurora DSQL replica in modo sincrono i dati scritti nella regione peering, il costo delle dimensioni di archiviazione si applica singolarmente a tutti i cluster nella configurazione multiregionale. Ciò vale anche per i cluster in stato Pending Delete. ** ** Per ulteriori informazioni sullo ** stato ** Pending Delete, consultate la pagina del ciclo di vita del cluster [ Aurora DSQL. ](cluster-lifecycle.md#dsql-cluster-statuses.title) ``` MultiRegionWriteDPU = WriteDPU ``` ## Monitoraggio dell'utilizzo della DPU con CloudWatch Aurora DSQL pubblica le metriche di utilizzo su Amazon CloudWatch, consentendoti di monitorare il consumo quasi in tempo reale. ### Metriche DPU disponibili **Metriche DPU** | CloudWatch parametro | Description | Dimensione | | --- | --- | --- | | WriteDPU | Componente di utilizzo della scrittura | ClusterId | | ReadDPU | Componente di utilizzo in lettura | ClusterId | | ComputeDPU | Componente di elaborazione delle interrogazioni | ClusterId | | MultiRegionWriteDPU | Multi-Region replica (solo cluster multiregionali) | ClusterId | | StreamDPU | Streaming CDC (solo cluster con CDC abilitato) | ClusterId, StreamId | | TotalDPU | Somma di tutti i componenti della DPU | ClusterId | ### Visualizzazione delle metriche DPU **Per visualizzare le metriche DPU in CloudWatch** 1. Apri la [CloudWatch console](https://console.aws.amazon.com/cloudwatch). 1. Passa a ** Metrics**, quindi ** ** AuroraDSQL, quindi. ** ClusterId ** 1. Seleziona il tuo cluster e le metriche DPU che desideri monitorare. **Suggerimento** Utilizza la ** statistica ** Sum per le metriche DPU per visualizzare l'utilizzo totale in un periodo di tempo. Aggiungi l'**etichetta ** LAST per visualizzare il valore più recente. ### Metriche di osservabilità aggiuntive Per un elenco completo delle metriche e delle funzionalità di monitoraggio di Aurora DSQL, consulta. [Monitoraggio e registrazione dei log per Aurora DSQL](monitoring-overview.md) **Parametri di osservabilità** | Metrica | Description | | --- | --- | | ClusterStorageSize | Dimensione attuale dello storage in byte | | TotalTransactions | Transazioni totali eseguite | | ReadOnlyTransactions | Read-only transazioni eseguite | | QueryTimeouts | Interrogazioni che hanno superato il limite di tempo | | OccConflicts | Transazioni interrotte a causa di conflitti OCC | | BytesWritten | Byte non elaborati scritti nell'archivio | | BytesRead | Byte grezzi letti dalla memoria | ## Utilizzo di EXPLAIN ANALYZE VERBOSE per la consapevolezza dei costi Aurora DSQL si estende fino `EXPLAIN ANALYZE VERBOSE` a includere una stima dell'utilizzo della DPU a livello di dichiarazione alla fine dell'output. Ciò fornisce una visibilità immediata dei costi delle query, aiutandovi a identificare i fattori di costo del carico di lavoro, ottimizzare le prestazioni delle query e prevedere meglio l'utilizzo delle risorse. **Nota** È necessario utilizzare `EXPLAIN ANALYZE VERBOSE` (con VERBOSE) per visualizzare le stime della DPU. Un piano `EXPLAIN ANALYZE` senza VERBOSE non mostra le informazioni sulla DPU. ### Esempio 1: interrogazione SELECT ``` EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table; ``` ``` QUERY PLAN ---------------------------------------------------- Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1) Output: id, context -> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1) Projections: id, context -> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1) Query Identifier: qymgw1m77maoe Planning Time: 11.415 ms Execution Time: 4.528 ms Statement DPU Estimate: Compute: 0.01607 DPU Read: 0.04312 DPU Write: 0.00000 DPU Total: 0.05919 DPU ``` In questo esempio, l'istruzione SELECT esegue una scansione solo indicizzata, pertanto la maggior parte del costo proviene da Read DPU (0.04312), che rappresenta i dati recuperati dallo storage, e da Compute DPU (0.01607), che riflette le risorse di calcolo utilizzate per elaborare e restituire i risultati. Non esiste una DPU di scrittura poiché la query non modifica i dati. La DPU totale (0,05919) è la somma di Compute \+ Read \+ Write. ### Esempio 2: interrogazione INSERT ``` EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3'); ``` ``` QUERY PLAN ---------------------------------------------------- Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1) -> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1) Output: "*VALUES*".column1, "*VALUES*".column2 Query Identifier: jtkjkexhjotbo Planning Time: 0.068 ms Execution Time: 0.543 ms Statement DPU Estimate: Compute: 0.01550 DPU Read: 0.00307 DPU (Transaction minimum: 0.00375) Write: 0.01875 DPU (Transaction minimum: 0.05000) Total: 0.03732 DPU ``` Questa istruzione esegue principalmente scritture, quindi la maggior parte del costo è associata a Write DPU. La Compute DPU (0.01550) rappresenta il lavoro svolto per elaborare e inserire i valori. La DPU di lettura (0,00307) riflette le letture di sistema minori (per ricerche nel catalogo o controlli degli indici). Notate i valori minimi di transazione indicati tra parentesi accanto alle DPU di lettura e scrittura. Questi valori minimi si applicano a livello di transazione, il che significa che la DPU totale di lettura o scrittura per un'intera transazione non è mai inferiore a questi valori. Se si utilizza `EXPLAIN ANALYZE VERBOSE` per prevedere i costi e questa è l'unica dichiarazione contenuta nella transazione, utilizzare i valori minimi della transazione anziché le stime grezze del rendiconto. Se la transazione contiene più rendiconti, i valori minimi si applicano all'aggregato di tutti i rendiconti. Poiché `EXPLAIN ANALYZE VERBOSE` riporta le stime a livello di estratto conto mentre la fatturazione applica i valori minimi a livello di transazione, i valori potrebbero non corrispondere esattamente alle metriche o ai dati di fatturazione. CloudWatch ### Utilizzo delle informazioni sulla DPU per l'ottimizzazione Per-statement Le stime della DPU offrono un modo efficace per ottimizzare le query oltre il semplice tempo di esecuzione. Casi di utilizzo comune comprendono: + **Consapevolezza dei costi: ** scopri quanto è costosa una query rispetto alle altre. + **Ottimizzazione dello schema: ** confronta l'impatto degli indici o delle modifiche allo schema sulle prestazioni e sull'efficienza delle risorse. + **Pianificazione del budget: ** stima il costo del carico di lavoro in base all'utilizzo osservato della DPU. + **Confronto delle query: ** valuta approcci alternativi alle interrogazioni in base al consumo relativo di DPU. ### Interpretazione delle informazioni sulla DPU Tieni a mente le seguenti best practice quando utilizzi i dati DPU provenienti da: `EXPLAIN ANALYZE VERBOSE` + **Usalo in modo direzionale: ** considera la DPU riportata come un modo per comprendere il * costo * relativo di una query piuttosto che una corrispondenza esatta con le CloudWatch metriche o i dati di fatturazione. Le differenze sono prevedibili perché `EXPLAIN ANALYZE VERBOSE` riporta i costi a livello di rendiconto, mentre aggrega l'attività a livello di transazione. CloudWatch CloudWatch include anche le operazioni in background (come ANALYZE o compattazioni asincrone) e il sovraccarico delle transazioni (/) che esclude intenzionalmente. `BEGIN` `COMMIT` `EXPLAIN ANALYZE VERBOSE` + **Esegui test con dati rappresentativi per una dimostrazione dei concetti: ** quando esegui un proof of concept per valutare i costi, assicurati che le tabelle contengano volumi di dati e distribuzioni simili al carico di lavoro di produzione previsto. Le stime DPU, provenienti da `EXPLAIN ANALYZE VERBOSE` o CloudWatch metriche, basate su tabelle vuote o scarsamente popolate non rifletteranno i costi reali. + **La variabilità della DPU tra le esecuzioni è normale ** nei sistemi distribuiti e non indica errori. Fattori come la memorizzazione nella cache, le modifiche al piano di esecuzione, la concorrenza, le operazioni in background come l'analisi asincrona o i cambiamenti nella distribuzione dei dati possono far sì che la stessa query consumi risorse diverse da un'esecuzione all'altra. + **Operazioni in batch su piccole dimensioni: ** se il carico di lavoro genera molte istruzioni di piccole dimensioni, valuta la possibilità di raggrupparle in più operazioni di scrittura all'interno di una singola transazione (le modifiche non devono superare i 10 MB per transazione, sebbene le letture siano limitate solo dal timeout di 5 minuti della transazione). In questo modo si ammortizzano i minimi di transazione in base a una maggiore quantità di lavoro e si ottengono stime dei costi più significative. + **Utilizzabile per l'ottimizzazione, non per la fatturazione: i dati ** DPU in ingresso sono progettati per la consapevolezza dei costi, `EXPLAIN ANALYZE VERBOSE` l'ottimizzazione delle query e l'ottimizzazione. Non è una metrica di livello di fatturazione. Affidati sempre alle CloudWatch metriche o ai report di fatturazione mensili per dati autorevoli su costi e utilizzo. ## Le migliori pratiche per la stima dei costi + **Monitora prima dell'ottimizzazione: ** utilizza le CloudWatch metriche per comprendere il modello di utilizzo corrente prima di prendere decisioni di ottimizzazione. Per informazioni dettagliate, vedi [Monitoraggio dell'utilizzo della DPU con CloudWatch](#billing-cloudwatch-monitoring). + **Concentrati sull'efficienza delle transazioni: ** poiché i valori minimi si applicano a livello di transazione, raggruppa le operazioni correlate per ammortizzare le spese minime. + **Usa EXPLAIN ANALYZE VERBOSE durante lo sviluppo: ** `EXPLAIN ANALYZE VERBOSE` esegui domande critiche durante lo sviluppo per comprenderne le caratteristiche di costo. Quando esegui un proof of concept per valutare i costi, esegui dei test confrontandoli con tabelle con volumi e distribuzioni di dati rappresentativi: le stime basate su tabelle vuote o scarsamente popolate non rifletteranno i costi di produzione. Per informazioni dettagliate, vedi [Utilizzo di EXPLAIN ANALYZE VERBOSE per la consapevolezza dei costi](#billing-explain-analyze). + **Imposta CloudWatch allarmi: ** crea allarmi sulle metriche DPU per ricevere notifiche di picchi di utilizzo imprevisti.