Best practice operative per il servizio OpenSearch di Amazon - Amazon OpenSearch Service

Best practice operative per il servizio OpenSearch di Amazon

In questo capitolo vengono affrontate alcune best practice sulla gestione dei domini Amazon OpenSearch Service e vengono fornite linee guida generali che si applicano a molti casi d'uso. Ogni carico di lavoro è unico, con caratteristiche uniche, quindi nessun suggerimento generico è esattamente giusto per ogni caso d'uso. La best practice generale consiste nell'implementare, testare e ottimizzare i domini in un ciclo continuo per trovare la configurazione, la stabilità e il costo ottimali per il carico di lavoro.

Monitoraggio e avvisi

Le seguenti best practice si applicano al monitoraggio dei domini del servizio OpenSearch.

Configurare gli allarmi CloudWatch

Il servizio OpenSearch invia parametri relativi alle prestazioni ad Amazon CloudWatch. Controlla con regolarità i parametri di cluster e istanza e configura gli allarmi CloudWatch consigliati in base alle prestazioni del carico di lavoro.

Abilitare la pubblicazione dei registri

Il servizio OpenSearch espone i registri di errore, i registri di ricerca lenti, i registri di indice lenti e i registri di audit in File di log Amazon CloudWatch. I log di ricerca lenti, i log di indicizzazione lenti e i log di errore sono utili per la risoluzione dei problemi relativi alle prestazioni e alla stabilità. I registri di audit, disponibili solo se abiliti il controllo granulare degli accessi, tengono traccia dell'attività dell'utente.

I registri di ricerca lenti e i registri di indice lenti sono uno strumento importante per comprendere e risolvere i problemi delle prestazioni delle operazioni di ricerca e indicizzazione. Abilita la distribuzione di registri lenti di ricerca e di indice per tutti i domini di produzione. Devi anche configurare le soglie dei registri, altrimenti CloudWatch non acquisirà i registri.

Strategia di partizione

Le partizioni distribuiscono il carico di lavoro tra i nodi di dati nel dominio del servizio OpenSearch. Gli indici configurati correttamente possono contribuire a migliorare le prestazioni complessive del dominio.

Quando invii dati al servizio OpenSearch, invii tali dati a un indice. Un indice è analogo a una tabella di database, con documenti come le righe e campi come le colonne. Quando crei l'indice, indichi a OpenSearch quante partizioni primarie vuoi creare. Le partizioni primarie sono partizioni indipendenti del set di dati completo. Il servizio OpenSearch distribuisce automaticamente i tuoi dati tra le partizioni primarie di un indice. Puoi inoltre configurare le repliche dell'indice. Ogni replica comprende un set completo di copie delle partizioni primarie per quell'indice.

Il servizio OpenSearch mappa le partizioni per ogni indice tra i nodi di dati del cluster. Questo assicura che le partizioni primarie e di replica per l'indice risiedano su nodi di dati diversi. La prima replica garantisce la presenza di due copie dei dati nell'indice. Dovresti sempre usare almeno una replica. Le repliche aggiuntive forniscono ridondanza e capacità di lettura aggiuntive.

OpenSearch invia richieste di indice e ricerca a tutti i nodi di dati che contengono partizioni appartenenti all'indice nella richiesta. Invia le richieste di indicizzazione prima ai nodi dati contenenti partizioni primarie e poi ai nodi di dati contenenti partizioni di replica. Ad esempio, per un indice con cinque partizioni primarie e una replica, ogni richiesta di indicizzazione utilizza 10 partizioni. Le query di ricerca, invece, vengono inviate a n partizioni, dove n è il numero di partizioni primarie. Per un indice con cinque partizioni primarie e una replica, ogni query di ricerca utilizza cinque partizioni (primarie o di replica) da quell'indice.

Utilizza le seguenti best practice per determinare il numero di partizioni e nodi di dati per il tuo dominio:

Dimensione delle partizioni: la dimensione dei dati su disco è il risultato diretto della dimensione dei dati di origine e cambia man mano che indicizzi più dati. Il rapporto origine/indice può variare notevolmente, da 1:10 a 10:1 o più, ma di solito è di circa 1:1.10. Puoi utilizzare tale rapporto per prevedere la dimensione dell'indice su disco o indicizzare alcuni dati e recuperare le dimensioni effettive dell'indice per determinare il rapporto per il tuo carico di lavoro. Una volta ottenuta una dimensione dell'indice prevista, imposta un conteggio delle partizioni in modo che ogni partizione sia compresa tra 10 e 30 GiB (per i carichi di lavoro di ricerca) o tra 30 e 50 GiB (per i carichi di lavoro dei registri). 50 GiB dovrebbe essere il massimo; assicurati di pianificare la crescita.

Conteggio partizioni: la distribuzione delle partizioni sui nodi di dati ha un grande impatto sulle prestazioni di un dominio. Quando disponi di indici con più partizioni, prova a rendere il conteggio delle partizioni un multiplo pari del conteggio dei nodi di dati per garantire che le partizioni siano distribuite uniformemente tra i nodi di dati e per evitare nodi hot. Ad esempio, se disponi di 12 partizioni primarie, il numero di nodi di dati deve essere 2, 3, 4, 6 o 12. Tuttavia, il conteggio delle partizioni è secondario rispetto alla dimensione delle partizioni; se disponi di 5 GiB di dati, dovresti comunque usare una singola partizione.

Partizioni per nodo di dati: il numero totale di partizioni che un nodo può contenere è proporzionale alla memoria heap JVM del nodo. Punta a 25 partizioni o meno per GiB di memoria heap. Ad esempio, un nodo con 32 GiB di memoria heap non deve contenere più di 800 partizioni. Sebbene la distribuzione delle partizioni possa variare in base ai modelli di carico di lavoro, esiste un limite di 1.000 partizioni per nodo. L'API cat/allocation fornisce una visualizzazione rapida del numero di partizioni e dello storage totale delle partizioni tra i nodi di dati.

Rapporto partizione/CPU: quando una partizione è coinvolta in una richiesta di indicizzazione o ricerca, utilizza una vCPU per elaborare la richiesta. Come best practice, utilizza un punto di scala iniziale di 1,5 vCPU per partizione. Se il tuo tipo di istanza presenta 8 vCPU, imposta il conteggio dei nodi di dati in modo che ogni nodo non abbia più di sei partizioni. Si tratta di un'approssimazione. Assicurati di testare il carico di lavoro e dimensionare il cluster di conseguenza.

Per suggerimenti sul volume di storage, la dimensione delle partizioni e il tipo di istanza, vedi le seguenti risorse:

Evitare l'asimmetria di storage

L'asimmetria di storage si verifica quando uno o più nodi all'interno di un cluster detengono una percentuale maggiore di storage per uno o più indici rispetto agli altri. L'utilizzo non uniforme della CPU, la latenza intermittente e irregolare e l'accodamento non uniforme tra i nodi di dati sono tutte indicazioni di asimmetria di storage. Per determinare se sono presenti problemi di asimmetria, consulta le seguenti sezioni sulla risoluzione dei problemi:

Stabilità

Le seguenti best practice si applicano al mantenimento di un dominio del servizio OpenSearch stabile e integro.

Tenersi aggiornati con OpenSearch

Aggiornamenti del software del servizio

Il servizio OpenSearch rilascia regolarmente aggiornamenti software che aggiungono funzionalità o comunque migliorano i domini. Gli aggiornamenti non modificano la versione del motore OpenSearch o Elasticsearch. Si consiglia di pianificare un orario ricorrente per l'esecuzione dell'operazione API di descrizione del dominio e di attivare un aggiornamento del software di servizio se lo UpdateStatus è ELIGIBLE. Se non aggiorni il dominio entro un determinato periodo di tempo (generalmente due settimane), il servizio OpenSearch esegue automaticamente l'aggiornamento.

Aggiornamenti della versione OpenSearch

Il servizio OpenSearch aggiunge regolarmente il supporto per le versioni di OpenSearch gestite dalla comunità. Esegui sempre l'aggiornamento alle ultime versioni di OpenSearch quando sono disponibili. Il servizio OpenSearch aggiorna simultaneamente sia OpenSearch che OpenSearch Dashboards (o Elasticsearch e Kibana se il tuo dominio esegue un motore legacy). Se il cluster dispone di nodi master dedicati, gli aggiornamenti vengono completati senza tempi di inattività. In caso contrario, il cluster potrebbe non rispondere per alcuni secondi dopo l'aggiornamento mentre elegge un nodo master. OpenSearch Dashboards potrebbe non essere disponibile durante una parte o tutto l'aggiornamento.

Ci sono due modi per aggiornare un dominio:

Indipendentemente dal processo di aggiornamento utilizzato, ti consigliamo di mantenere un dominio destinato esclusivamente allo sviluppo e al test e di aggiornarlo alla nuova versione prima di aggiornare il dominio di produzione. Scegli Development and testing (Sviluppo e test) per il tipo di distribuzione quando crei il dominio di test. Assicurati di aggiornare tutti i client alle versioni compatibili subito dopo l'aggiornamento del dominio.

Esecuzione del backup dei dati

Puoi eseguire snapshot manuali per il ripristino del cluster o spostare i dati da un cluster a un altro. Devi avviare o pianificare gli snapshot manuali. Gli snapshot vengono archiviati nel bucket Amazon S3. Per istruzioni su come eseguire e ripristinare uno snapshot, vedi Creazione di snapshot di indici in Amazon OpenSearch Service.

Abilitare nodi principali dedicati

I nodi principali dedicati migliorano la stabilità del cluster. Un nodo principale dedicato esegue attività di gestione del cluster ma non conserva dati di indice né risponde a richieste del client. L'offload delle attività di gestione del cluster aumenta la stabilità del dominio e consente alcune modifiche alla configurazione senza tempi di inattività.

Abilita e utilizza tre nodi principali dedicati per una stabilità ottimale del dominio in tre zone di disponibilità. Per suggerimenti sul tipo di istanza, vedi Scelta dei tipi di istanza per nodi principali dedicati.

Eseguire l'implementazione in più zone di disponibilità

Per prevenire la perdita di dati e ridurre al minimo i tempi di inattività del cluster in caso di interruzione del servizio, puoi distribuire i nodi tra due o tre zone di disponibilità nella stessa Regione AWS. Le zone di disponibilità sono più posizioni isolate all'interno di ogni regione . Con una configurazione a due zone di disponibilità, perdere una zona di disponibilità significa perdere metà della capacità totale del dominio. Il passaggio a tre zone di disponibilità riduce ulteriormente l'impatto della perdita di una singola zona di disponibilità.

Implementa domini mission-critical in tre zone di disponibilità e due partizioni di replica per indice. Questa configurazione consente al servizio OpenSearch di distribuire partizioni di replica in zone di disponibilità differenti rispetto alle partizioni primarie corrispondenti. Non sono previsti costi di trasferimento dei dati tra zone di disponibilità per le comunicazioni dei cluster tra zone di disponibilità.

Controllare il flusso di importazione e il buffering

Si consiglia di limitare il conteggio complessivo delle richieste utilizzando l'operazione API _bulk. È più efficace inviare una richiesta _bulk contenente 5.000 documenti anziché inviare 5.000 richieste contenenti un singolo documento.

Per una stabilità operativa ottimale, a volte è necessario limitare o addirittura sospendere il flusso upstream delle richieste di indicizzazione. Limitare la percentuale di richieste di indicizzazione è un meccanismo importante per gestire picchi imprevisti o occasionali nelle richieste che potrebbero altrimenti sovraccaricare il cluster. Valuta la possibilità di creare un meccanismo di controllo del flusso nella tua architettura upstream.

Il diagramma seguente mostra più opzioni di componenti per un'architettura di importazione dei registri. Configura il livello di aggregazione per avere spazio sufficiente per il buffering dei dati in ingresso per picchi di traffico improvvisi e brevi interventi di manutenzione del dominio.

Creare mappature per i carichi di lavoro di ricerca

Per i carichi di lavoro di ricerca, crea mappature che definiscono in che modo OpenSearch memorizza e indicizza i documenti e i relativi campi. Imposta dynamic su strict per evitare l'aggiunta accidentale di nuovi campi:

PUT my-index { "mappings": { "dynamic": "strict", "properties": { "title": { "type" : "text" }, "author": { "type" : "integer" }, "year": { "type" : "text" } } } }

Utilizzare modelli di indici

Un modello di indice è un modo per indicare a OpenSearch come configurare un indice quando viene creato. Configura i modelli di indice prima di creare gli indici. Quindi, quando crei un indice, l'indice eredita le impostazioni e le mappature dal modello. Puoi applicare più di un modello a un singolo indice, quindi puoi specificare le impostazioni in un modello e le mappature in un altro. Questa strategia consente un modello per le impostazioni comuni su più indici e modelli separati per impostazioni e mappature più specifiche.

Le seguenti impostazioni sono particolarmente utili per la configurazione nei modelli:

  • Numero di partizioni primarie e di replica

  • Intervallo di aggiornamento (con quale frequenza aggiornare e rendere disponibili per la ricerca le modifiche recenti all'indice)

  • Controllo dinamico delle mappature

  • Mappature di campi esplicite

Il seguente modello di esempio contiene ognuna di queste impostazioni:

{ "index_patterns":[ "index-*" ], "order": 0, "settings": { "index": { "number_of_shards": 3, "number_of_replicas": 1, "refresh_interval": "60s" } }, "mappings": { "dynamic": false, "properties": { "field_name1": { "type": "keyword" } } } }

Anche se cambiano raramente, avere impostazioni e mappature definite a livello centrale in OpenSearch è più semplice da gestire rispetto all'aggiornamento di più client upstream.

Gestire gli indici con Index State Management

Se gestisci registri o dati di serie temporali, ti consigliamo di utilizzare Index State Management (ISM). ISM consente di automatizzare attività regolari di gestione del ciclo di vita degli indici. Con ISM, puoi creare policy che attivano i rollover degli alias degli indici, eseguire snapshot degli indici, spostare gli indici tra i livelli di storage ed eliminare gli indici precedenti. Puoi persino usare le operazioni di rollover di ISM come strategia alternativa di gestione del ciclo di vita dei dati per evitare asimmetrie di partizioni.

In primo luogo, configura una policy ISM. Per esempi, consulta Policy di esempio. Quindi, collega la policy a uno o più indici. Se includi un campo ISM template (Modello ISM) nella policy, il servizio OpenSearch della policy applica automaticamente la policy a qualsiasi indice che corrisponda al modello specificato.

Rimuovere gli indici inutilizzati

Esamina regolarmente gli indici nel tuo cluster e identifica quelli che non sono in uso. Esegui uno snapshot di questi indici in modo che siano archiviati in S3, quindi eliminali. La rimozione degli indici inutilizzati riduce il numero di partizioni e consente una distribuzione dello storage e un utilizzo delle risorse più bilanciati tra i nodi. Anche quando sono inattivi, gli indici consumano alcune risorse durante le attività interne di manutenzione degli indici.

Anziché eliminare manualmente gli indici inutilizzati, puoi utilizzare ISM per eseguire automaticamente un'istantanea ed eliminare gli indici dopo un certo periodo di tempo.

Utilizzare più domini per un'elevata disponibilità

Per ottenere un'elevata disponibilità oltre un tempo di attività del 99,9% in più regioni, prendi in considerazione l'utilizzo di due domini. Per set di dati piccoli o che cambiano lentamente, puoi configurare la replica tra cluster per mantenere un modello attivo-passivo in cui è scritto solo il dominio leader, ma da cui possono essere letti entrambi i domini. Per set di dati più grandi e dati che cambiano rapidamente, configura la distribuzione doppia nella pipeline di importazione, in modo che tutti i dati vengano scritti indipendentemente in entrambi i domini in un modello attivo-attivo.

Progetta le tue applicazioni upstream e downstream tenendo presente il failover. Assicurati di testare il processo di failover insieme ad altri processi di ripristino di emergenza.

Prestazioni

Le seguenti best practice si applicano all'ottimizzazione dei domini per ottenere prestazioni ottimali.

Ottimizzare le dimensioni e la compressione delle richieste in blocco

Il dimensionamento in blocco dipende dai dati, dall'analisi e dalla configurazione del cluster, ma un buon punto di partenza è 3-5 MiB per ciascuna richiesta in blocco.

Invia richieste e ricevi risposte dai tuoi domini OpenSearch usando la compressione gzip per ridurre le dimensioni di payload di richieste e risposte. Puoi utilizzare la compressione gzip con il client OpenSearch Python oppure includendo le seguenti intestazioni dal lato client:

  • 'Accept-Encoding': 'gzip'

  • 'Content-Encoding': 'gzip'

Per ottimizzare le dimensioni delle richieste in blocco, inizia con una richiesta in blocco di 3 MiB, quindi aumenta lentamente le dimensioni della richiesta fino a quando le prestazioni di indicizzazione non smettono di migliorare.

Nota

Per abilitare la compressione gzip sui domini che eseguono Elasticsearch versione 6.x, devi impostare http_compression.enabled a livello di cluster. Questa impostazione è vera per valore predefinito in Elasticsearch versione 7.x e in tutte le versioni di OpenSearch.

Ridurre le dimensioni delle risposte alle richieste in blocco

Per ridurre le dimensioni delle risposte di OpenSearch, escludi i campi non necessari con il parametro filter_path. Assicurati di non filtrare i campi necessari per identificare o riprovare le richieste non riuscite. Per maggiori informazioni ed esempi, vedi Riduzione delle dimensioni della risposta.

Ottimizzare gli intervalli di aggiornamento

Gli indici OpenSearch hanno una consistenza di lettura finale. Un'operazione di aggiornamento rende disponibili per la ricerca tutti gli aggiornamenti eseguiti su un indice. L'intervallo di aggiornamento predefinito è di un secondo, il che significa che OpenSearch esegue un aggiornamento ogni secondo durante la scrittura di un indice.

Meno frequentemente si aggiorna un indice (intervallo di aggiornamento più elevato), migliori sono le prestazioni complessive di indicizzazione. L'aumento dell'intervallo di aggiornamento comporta un ritardo maggiore tra l'aggiornamento dell'indice e la disponibilità dei nuovi dati per la ricerca. Imposta l'intervallo di aggiornamento al livello più alto che puoi tollerare per migliorare le prestazioni complessive.

Consigliamo di impostare il parametro refresh_interval per tutti gli indici su 30 secondi o più.

Abilitare la regolazione automatica

La regolazione automatica utilizza i parametri relativi alle prestazioni e all'utilizzo del cluster OpenSearch per suggerire modifiche alle dimensioni della coda, alle dimensioni della cache e alle impostazioni JVM (Java Virtual Machine) sui nodi. Queste modifiche facoltative migliorano la velocità e la stabilità del cluster. È possibile ripristinare le impostazioni di default di OpenSearch Service in qualsiasi momento. La regolazione automatica è abilitata per impostazione predefinita sui nuovi domini a meno che non venga esplicitamente disabilitata.

Ti consigliamo di abilitare la regolazione automatica su tutti i domini e di impostare una finestra di manutenzione ricorrente o di rivedere periodicamente i relativi suggerimenti.

Sicurezza

Le seguenti best practice si applicano alla protezione dei domini.

Abilitare il controllo granulare degli accessi

Il controllo granulare degli accessi ti consente di controllare chi può accedere a determinati dati all'interno di un dominio del servizio OpenSearch. Rispetto al controllo degli accessi generalizzato, il controllo granulare degli accessi fornisce a ciascun cluster, indice, documento e campo la propria policy specifica per l'accesso. I criteri di accesso possono essere basati su una serie di fattori, tra cui il ruolo della persona che richiede l'accesso e l'azione che intende eseguire sui dati. Ad esempio, potresti concedere a un utente l'accesso per scrivere su un indice, mentre a un altro potrebbe essere concesso l'accesso solo per leggere i dati sull'indice senza apportare alcuna modifica.

Il controllo granulare degli accessi consente ai dati con requisiti di accesso diversi di esistere nello stesso spazio di storage senza incorrere in problemi di sicurezza o conformità.

Si consiglia di abilitare il controllo granulare degli accessi sui domini.

Distribuire domini all'interno di un VPC

Inserendo il dominio del servizio OpenSearch all'interno di un cloud privato virtuale (VPC) consenti la comunicazione sicura tra il servizio OpenSearch e altri servizi nel VPC, senza la necessità di un gateway Internet, un dispositivo NAT o una connessione VPN. Tutto il traffico rimane sicuro all'interno di AWS Cloud. Grazie a loro isolamento logico, i domini che si trovano all'interno di un VPC hanno un ulteriore livello di sicurezza rispetto ai domini che usano gli endpoint pubblici.

Consigliamo di creare domini all'interno di un VPC.

Applicare una policy di accesso restrittiva

Anche se il tuo dominio è distribuito all'interno di un VPC, è meglio implementare la sicurezza a più livelli. Assicurati di controllare la configurazione delle tue attuali policy di accesso.

Applica una policy di accesso basata sulle risorse restrittiva al dominio e segui il principio del privilegio minimo quando concedi l'accesso all'API di configurazione e alle API OpenSearch. Come regola generale, evita di utilizzare il principale utente anonimo"Principal": {"AWS": "*" } nelle policy di accesso. Esistono tuttavia alcune situazioni in cui è accettabile utilizzare una policy di accesso aperto, ad esempio quando abiliti il controllo degli accessi granulare. Una policy di accesso aperto può consentirti di accedere al dominio nei casi in cui la firma delle richieste è difficile o impossibile, ad esempio da determinati client e strumenti.

Abilitare la crittografia dei dati a riposo

I domini del servizio OpenSearch offrono la crittografia dei dati a riposo, per impedire l'accesso non autorizzato ai dati. La crittografia dei dati a riposo utilizza AWS Key Management Service (AWS KMS) per archiviare e gestire le chiavi di crittografia e l'algoritmo Advanced Encryption Standard con chiavi a 256 bit (AES-256) per eseguire la crittografia.

Se il dominio archivia i dati sensibili, abilita la crittografia dei dati a riposo.

Abilitare la crittografia da nodo a nodo

La crittografia da nodo a nodo fornisce un livello di sicurezza aggiuntivo alle funzionalità di sicurezza predefinite del servizio OpenSearch. Implementa Transport Layer Security (TLS) per tutte le comunicazioni tra nodi forniti all'interno di OpenSearch. La crittografia da nodo a nodo garantisce che tutti i dati inviati al dominio del servizio OpenSearch tramite HTTPS rimangano crittografati durante il transito mentre vengono distribuiti e replicati tra i nodi.

Se il dominio archivia i dati sensibili, abilita la crittografia da nodo a nodo.

Ottimizzazione dei costi

Le seguenti best practice si applicano all'ottimizzazione e al risparmio sui costi del servizio OpenSearch.

Utilizzare tipi di istanza di ultima generazione

Il servizio OpenSearch adotta sempre nuovi tipi di istanza di Amazon EC2 che offrono prestazioni migliori a un costo inferiore. Si consiglia di utilizzare sempre istanze di ultima generazione.

Non utilizzare istanze T2 o t3.small per i domini di produzione, in quanto possono diventare instabili in presenza di carichi pesanti sostenuti. Le istanze t3.medium sono un'opzione per piccoli carichi di lavoro di produzione (sia come nodi di dati che come nodi principali dedicati).

Utilizzare UltraWarm e lo storage a freddo per dati di registro di serie temporali

Se utilizzi OpenSearch per l'analisi dei registri, sposta i tuoi dati su UltraWarm o storage a freddo per ridurre i costi. Utilizza Index State Management (ISM) per migrare i dati tra livelli di storage e gestire la conservazione dei dati.

UltraWarm offre un modo conveniente per archiviare grandi quantità di dati di sola lettura nel servizio OpenSearch. UltraWarm utilizza Amazon S3 per lo storage, il che significa che i dati sono immutabili ed è necessaria solo una copia. Paghi solo per lo storage equivalente alla dimensione delle partizioni primarie negli indici. Le latenze per le query UltraWarm aumentano con la quantità di dati S3 necessari per soddisfare la query. Una volta che i dati sono stati memorizzati nella cache sui nodi, le query agli indici UltraWarm si comportano in modo simile alle query agli indici hot.

Lo storage a freddo è supportato anche da S3. Quando è necessario eseguire query sui dati a freddo, è possibile collegarli in modo selettivo ai nodi UltraWarm esistenti. I dati a freddo comportano gli stessi costi dello storage gestito di UltraWarm, ma gli oggetti nello storage a freddo non consumano risorse del nodo UltraWarm e quindi forniscono una quantità virtualmente illimitata di capacità di storage senza influire sulle dimensioni o sul numero di nodi UltraWarm.

UltraWarm diventa conveniente quando si dispone di circa 2,5 TiB di dati nello storage hot. Monitora la tua velocità di riempimento e pianifica di spostare gli indici su UltraWarm prima di raggiungere quel volume di dati.

Rivedere i suggerimenti per le istanze riservate

Considera l'acquisto di istanze riservate (RI) dopo aver ottenuto una buona linea guida sulle prestazioni e sul consumo di calcolo. Gli sconti partono dal 30% circa per prenotazioni di 1 anno senza anticipo e possono aumentare fino al 50% per tutti gli impegni anticipati di 3 anni.

Dopo aver osservato un funzionamento stabile per almeno 14 giorni, rivedi la sezione relativa ai suggerimenti sulle istanze riservate in Esplorazione dei costi. L'intestazione del servizio OpenSearch di Amazon mostra i suggerimenti per gli acquisti specifici delle RI e i risparmi previsti.