Domande frequenti su Amazon EBS

Se collegati a istanze ottimizzate per EBS, in un anno i volumi SSD con capacità di IOPS allocata (io2 Block Express e io1) forniscono le prestazioni assegnate con un margine del 10% per il 99,9% del tempo. Le prestazioni esatte dipenderanno dai requisiti di I/O dell'applicazione.

Quando sono associati a istanze ottimizzate per EBS, i volumi con capacità di IOPS allocata io2 Block Express possono raggiungere latenze inferiori al millisecondo e i volumi io1 possono raggiungere una latenza di millisecondi a una cifra. Le prestazioni esatte dipenderanno dai requisiti di I/O dell'applicazione.

Sì, lo fa. Quando si esegue il provisioning IOPS per i volumi io2 Block Express, il volume di IOPS dipende dal volume di I/O in lettura e scrittura dell'applicazione. I volumi Provisioned IOPS hanno una dimensione base di I/O di 16 KB. Quindi, se è stato effettuato il provisioning di un volume con 40.000 IOPS per una dimensione I/O di 16KB, otterrete fino a 40.000 IOPS a quella dimensione. Se il volume di I/O viene aumentato a 256 KB, si otterranno fino a 16.000 IOPS, poiché la velocità di trasmissione effettiva massima di 4000 MiB/s viene raggiunta a 16.000 IOPS. Per ulteriori dettagli, consulta la documentazione tecnica sui volumi con capacità di IOPS allocata. Per monitorare la velocità di trasmissione effettiva e i volumi di I/O, è possibile utilizzare Amazon CloudWatch.

Quando vengono collegati a istanze ottimizzate per EBS, in un anno i volumi SSD con capacità di IOPS allocata (io2 Block Express e io1) forniscono le prestazioni assegnate con un margine del 10% per il 99,9% del tempo. Per la massima costanza delle prestazioni con i nuovi volumi creati da uno snapshot, si consiglia di abilitare il ripristino da snapshot veloce (FSR) sugli snapshot. I volumi EBS ripristinati da snapshot con FSR abilitato ricevono istantaneamente le prestazioni complete.

Un altro fattore che può influenzare le prestazioni è che l'applicazione potrebbe non inviare abbastanza richieste I/O. Puoi tenere sotto controllo questo dato monitorando la profondità della coda del volume. La profondità della coda corrisponde al numero di richieste di I/O in sospeso dall'applicazione al volume. Per ottenere prestazioni costanti, il valore medio della profondità della coda di un volume Provisioned IOPS deve essere pari a uno (approssimato al numero intero più vicino) per ogni 1000 IOPS assegnati al minuto. Ad esempio, per un volume a cui sono state assegnate 3000 operazioni al secondo, la profondità della coda media deve essere 3. Per ulteriori informazioni su come ottenere prestazioni costanti per i volumi, consulta Increasing EBS Performance.

Se collegati a istanze ottimizzate per EBS, in un anno i volumi Throughput Optimized HDD (st1) e Cold HDD (sc1) permettono prestazioni costanti, offrendo il throughput previsto con un margine del 10% per il 99% del tempo. Le prestazioni esatte dipenderanno dai requisiti di I/O dell'applicazione e dalle prestazioni dell'istanza EC2.

Sì. Il throughput dipende dalle dimensioni I/O in lettura e scrittura dell'applicazione. I volumi HDD elaborano le operazioni di lettura e scrittura in dimensioni I/O di 1 MB. Le operazioni I/O sequenziali vengono unite ed elaborate in unità da 1 MB, mentre quelle non sequenziali vengono elaborate in unità da 1 MB anche se le loro dimensioni sono effettivamente inferiori. Di conseguenza, mentre un carico di lavoro transazionale con operazioni I/O discontinue di piccole dimensioni come un database avrebbe prestazioni mediocri su volumi HDD, carichi di lavoro con operazioni I/O sequenziali e di grandi dimensioni otterranno prestazioni elevate con le opzioni st1 e sc1 per periodi di tempo prolungati.

I volumi Throughput Optimized HDD (st1) e Cold HDD (sc1) collegati a istanze ottimizzate per EBS sono progettati per offrire prestazioni costanti, offrendo il throughput previsto con un margine del 10% per il 99% del tempo. I fattori che incidono sulla costanza delle prestazioni sono molteplici. Ad esempio, le prestazioni possono essere influenzate dal rapporto tra operazioni I/O randomiche e sequenziali. Un numero troppo elevato di operazioni I/O randomiche di piccole dimensioni possono esaurire rapidamente il credito I/O e provocare una riduzione delle prestazioni sotto la soglia di base. Anche il throughput può diminuire a seconda dell'istanza selezionata. Sebbene i volumi st1 possono ottenere throughput di 500 MB/s, le prestazioni possono essere limitate da limitazioni a livello di istanza per il traffico con EBS. Un altro fattore di cui tenere conto sono gli snapshot, perché riducono le prestazioni di scrittura finché non viene completata l'acquisizione. Questa condizione si verifica particolarmente con i volumi st1 e sc1.

Le prestazioni possono anche essere influenzate dall'applicazione, che potrebbe non inviare un numero sufficiente di richieste I/O. Per monitorare questo parametro, verifica la profondità della coda e le dimensioni I/O del volume in uso. La profondità della coda corrisponde al numero di richieste di I/O in sospeso dall'applicazione al volume. Per la massima consistenza, i volumi basati su HDD devono mantenere una profondità media della coda (arrotondata al numero intero più vicino) di 4 o più per ogni I/O sequenziale da 1 MB. Per ulteriori informazioni su come ottenere prestazioni costanti per i volumi, consulta Increasing EBS Performance.

Sì. Puoi combinare più volumi insieme per ottenere fino a 400.000 IOPS o 12.500 Mbps quando sono collegati a istanze EC2 di maggiori dimensioni. Consigliamo di utilizzare i volumi io2 Block Express per requisiti di prestazioni più elevati senza la necessità della gestione operativa dello striping di più volumi. Le prestazioni per le opzioni st1 e sc1 si adattano in modo lineare con le dimensioni dei volumi, perciò lo striping potrebbe non portare grandi benefici.

EBS è un servizio di storage di blocco multi-tenant. Applichiamo dei limitatori di frequenza per evitare i conflitti tra risorse. Ciò comincia con il definire criteri di prestazione per i volumi: i nostri tipi di volumi (gp2, PIOPS, st1 e sc1) hanno tutti caratteristiche di prestazione definite in termini di IOPS e throughput. La fase successiva è definire la prestazione a livello di istanza. Ogni istanza ottimizzata EBS possiede una prestazione ottimizzata (sia throughput che IOPS) per l'insieme dei volumi EBS collegati all'istanza. Un cliente può, pertanto, dimensionare le istanze e i volumi per ottenere il livello desiderato di performance. Inoltre, i clienti possono utilizzare i nostri parametri riportati per osservare la prestazione del livello di istanza e del livello di volume. Possono impostare allarmi per determinare se ciò che stanno vedendo non corrisponde alla prestazione attesa: i parametri possono inoltre aiutare a determinare se i clienti sono configurati con il giusto tipo di istanza e con la giusta quantità di performance a livello di volume o meno. Per quanto riguarda il lato EBS, utilizziamo la prestazione configurata per fornire informazioni su come allochiamo l'istanza appropriata e l'infrastruttura EBS per supportare i volumi. Allocando in modo appropriato l'infrastruttura, evitiamo i conflitti fra risorse. Inoltre, monitoriamo la nostra infrastruttura in continuazione. Tale controllo ci permette di individuare il guasto dell'infrastruttura (o il suo imminente guasto) e, pertanto, di spostare proattivamente i volumi verso hardware funzionante, mentre l'infrastruttura viene riparata o sostituita secondo necessità.

Se collegati a istanze ottimizzate per EBS, in un anno i volumi General Purpose SSD (gp3 e gp2) forniscono le prestazioni provisioned IOPS con un margine del 10% per il 99% del tempo. Le prestazioni esatte dipenderanno dai requisiti di I/O dell'applicazione.

Se collegati a istanze ottimizzate per EBS, i volumi General Purpose SSD (gp3 e gp2) forniscono livelli di latenza nell'ordine dei millisecondi. Le prestazioni esatte dipenderanno dai requisiti di I/O dell'applicazione.

No. Tutti i volumi General Purpose SSD (gp3) includono 3.000 IOPS e 125 MB/s di prestazioni costanti senza costi aggiuntivi. I volumi possono supportare per intero 3.000 IOPS e 125 MB/s in modo indefinito.

I volumi General Purpose SSD (gp2) inferiori a 1.000 GB ottengono un burst in termini di prestazioni IOPS raggiungendo fino a 3.000 IOPS per almeno 30 minuti di prestazione continua. Inoltre, i volumi gp2 offrono prestazioni costanti pari a 3 IOPS per ogni GB assegnato. Ad esempio, un volume da 500 GB è in grado di gestire 1.500 IOPS in modo costante e di raggiungere 3.000 IOPS per 60 minuti (3.000 IOPS * 60 secondi * 30 minuti / 1.500 IOPS / 60 secondi).

I volumi io2 offrono un'archiviazione a blocchi ad alte prestazioni per tutte le istanze EC2. Per le applicazioni che richiedono prestazioni ancora più elevate, è possibile collegare i volumi io2 alle istanze Amazon EC2 che funzionano su Block Express e fornisce prestazioni 4 volte superiori rispetto a io2. Ciò ti consentirà di raggiungere una capacità fino a 64 TiB, 256.000 IOPS e 4.000 MB/s di velocità di trasmissione effettiva tramite un singolo volume io2, con una latenza media di I/O inferiore al millisecondo.

EBS Block Express è la nuova generazione di architettura di Amazon EBS per i server di storage creata appositamente per garantire i massimi livelli di prestazioni, con una latenza inferiore al millisecondo, per lo storage a blocchi a livello di cloud. Block Express raggiunge tali prestazioni avvalendosi di Scalable Reliable Datagrams (SRD), un protocollo di rete a bassa latenza e ad alte prestazioni, per comunicare con le istanze EC2 basate sul sistema Nitro. Si tratta della stessa interfaccia di rete ad alte prestazioni e bassa latenza utilizzata per la comunicazione tra istanze in Elastic Fabric Adapter (EFA) per carichi di lavoro HPC (High Performance Computing) e di machine learning (ML). Inoltre, Block Express offre componenti hardware e software modulari che possono essere assemblati in molti modi diversi, offrendo la flessibilità necessaria per progettare e fornire prestazioni migliori, insieme a nuove funzionalità e a una maggiore velocità.

io2 Block Express è adatto a carichi di lavoro con requisiti elevati in termini di capacità e prestazioni, che possono trarre vantaggio da una minore latenza, da una velocità effettiva e da IOPS più elevati o da una capacità maggiore in un unico volume. Questi carichi di lavoro includono database relazionali e NoSQL come SAP HANA, Oracle, MS SQL, PostgreSQL, MySQL, MongoDB e Cassandra, carichi di lavoro di operazioni aziendali critiche come SAP Business Suite, NetWeaver, Oracle eBusiness, PeopleSoft e Siebel, e carichi di lavoro ERP come Infor LN e Infor M3.

Se un volume io2 è collegato alle istanze Amazon EC2, allora viene eseguito su Block Express, che offre una latenza inferiore al millisecondo e la capacità di gestire fino a 256.000 IOPS e 4.000 MB/s di velocità di trasmissione effettiva, e fino a 64 TiB di dimensione per un singolo volume. I volumi io2 collegati a tutte le altre istanze non vengono eseguiti su Block Express e offrono una latenza di una sola cifra al millisecondo e la capacità di gestire fino a 64K IOPS e 1 GB/s di velocità di trasmissione effettiva, e fino a 16 TiB di dimensione per un singolo volume.
 

Questa funzionalità è disponibile tramite le seguenti API richiamabili mediante l'interfaccia a riga di comando (CLI) o i SDK di AWS.

• List Snapshot Blocks: il funzionamento dell'API ListSnapshotBlocks restituisce gli indici e i token dei blocchi dello snapshot specificato.
• List Changed Blocks: il funzionamento dell'API ListChangedBlocks restituisce gli indici e i token dei blocchi diversi tra due snapshot specificati dello stesso volume/derivazione dello snapshot.
• Get Snapshot Blocks: il funzionamento dell'API GetSnapshotBlock restituisce i dati di un blocco per l'ID snapshot, l'indice blocco e il token di blocco specificati.
• Start Snapshot: L'operazione StartSnapshot aggiunge uno snapshot, sia che si tratti di un incremento da uno snapshot già esistente sia che se ne debba creare uno nuovo. Lo snapshot inizializzato rimane in stato pending fino a quando non si completa grazie all'azione CompleteSnapshot.
• Blocco Put Snapshot: L'operazione PutSnapshot aggiunge dati come blocchi individuali per inizializzare uno snapshot che si trova in stato pending. Devi specificare un checksum SHA256 codificato con Base64 per il blocco dei dati trasmesso. Il servizio valida il checksum dopo che la trasmissione è completata. La richiesta fallisce se il checksum elaborato dal servizio non corrisponde a ciò che hai richiesto.
• Complete Snapshot: L'operazione CompleteSnapshot completa uno snapshot inizializzato che si trova in stato pending. Lo snapshot viene quindi segnato come completato.

Per ulteriori informazioni, consulta la documentazione tecnica.

Le API GetSnapshotBlock e PutSnapshotBlock supportano blocchi da 512 KiB.

No, gli snapshot sono disponibili solo tramite l'API di Amazon EC2.

No, gli snapshot possono essere effettuati in tempo reale mentre il volume è collegato e operativo. Tuttavia, gli snapshot acquisiscono solo i dati scritti nel tuo volume Amazon EBS, che potrebbe escludere i dati salvati localmente nella cache dalla tua applicazione o dal sistema operativo. Per garantire snapshot costanti su volumi collegati a un'istanza, consigliamo di distaccare il volume, inviare il comando di snapshot e quindi di ricollegare il volume. Per i volumi Amazon EBS che fungono da dispositivi root, raccomandiamo di spegnere la macchina per effettuare uno snapshot "pulito".

Uno snapshot EBS di un volume da 16 TB non richiede più tempo rispetto a uno snapshot di un volume da 1 TB. Tuttavia, il tempo effettivamente richiesto per creare uno snapshot dipende da diversi fattori, tra cui la quantità di dati modificata dall'ultimo snapshot del volume EBS.

Ad ogni snapshot viene assegnato un identificatore unico e i clienti possono creare volumi in base a uno qualsiasi dei loro snapshot già esistenti.

Puoi trovare gli snapshot condivisi con te selezionando Private Snapshots dal menu a discesa nella sezione Snapshots della Console di gestione AWS. In questa sezione sono elencati sia gli snapshot di tua proprietà sia quelli condivisi con te.

Puoi trovare gli snapshot condivisi a livello globale selezionando Private Snapshots dal menu a discesa nella sezione Snapshots della Console di gestione AWS. Inoltre, è possibile limitare l'accesso pubblico agli snapshot in un account abilitando il Blocco dell'accesso pubblico per snapshot EBS.

Per cercare set di dati pubblici memorizzati come snapshot, puoi utilizzare la Console di gestione AWS. Accedi alla console, seleziona Amazon EC2 Service, quindi Snapshot e quindi filtra secondo Public Snapshots. Tutte le informazioni sui set di dati pubblici sono disponibili nnel centro risorse di Set di dati pubblici AWS.

Puoi abilitare FSR sugli snapshot se ti preoccupa la latenza relativa all'accesso ai dati quando li ripristini da uno snapshot a un volume e desideri evitare il picco iniziale di prestazioni durante l'inizializzazione. FSR è progettato per aiutare nei casi d'uso come l'infrastruttura desktop virtuale (VDI), il backup e il ripristino, le copie di volume test/dev e il booting da AMI personalizzate. Abilitando l'FSR sullo snapshot, otterrai prestazioni prevedibili e migliorate ogni volta che dovrai ripristinare i dati da quello snapshot.

No. Gli snapshot con FSR abilitato migliorano il ripristino dei dati di backup dallo snapshot ai volumi. Gli snapshot con FSR abilitato non diminuiscono il tempo di creazione degli snapshot.

Per utilizzare questa funzionalità, invoca l'API enable-fast-snapshot-restores su uno snapshot all'interno della zona di disponibilità (AZ) dove i volumi inizializzati devono essere ripristinati.

Lo snapshot con FSR abilitato può trovarsi in uno dei seguenti stati: abilitazione in corso, ottimizazione in corso, abilitato, disabilitazione in corso, disabilitato. Le transizioni di stato vengono pubblicate sotto forma di eventi CloudWatch e lo stato FSR può essere controllato tramite l'API describe-fast-snapshot-restores.

L'abilitazione di FSR su uno snapshot non modifica alcuna interazione API dello snapshot e i flussi di lavoro esistenti non dovranno subire modifiche. FSR può essere abilitato o disabilitato solo su snapshot di proprietà dell'account. FSR non può essere applicato su snapshot condivisi. È possibile visualizzare l'elenco di snapshot con FSR abilitato tramite API o console.

I volumi creati da uno snapshot con FSR abilitato sono completamente inizializzati. Tuttavia, esistono delle limitazioni sul numero di volumi che possono essere creati con prestazioni complete immediate. Queste limitazioni si presentano sotto forma di bucket di credito associato con uno snapshot con FSR abilitato in una determinata zona di disponibilità. La cosa importante da sapere sui crediti:

1. Una singola operazione di creazione di un volume consuma un singolo credito
2. Il numero di crediti è una funzione della dimensione dello snapshot con FSR abilitato
3. I crediti si ricaricano nel tempo
4. La dimensione massima del bucket di credito è 10

Per ottenere una stima delle dimensioni del tuo bucket di crediti e la sua velocità di ricarica, dividi 1.024 per la dimensione del tuo bucket. Per esempio, uno snapshot con FSR abilitato da 100 GiB avrà l'equilibrio massimo di 10 crediti con una velocità di ricarica di 10 crediti all'ora. Uno snapshot da 4 TiB avrà l'equilibrio massimo di 1 con una velocità di ricarica di 1 credito ogni 4 ore.

È importante sapere che la dimensione del bucket di credito è una funzione della dimensione dello snapshot con FSR abilitato, non la dimensione dei volumi che vengono creati. Per esempio, è possibile creare fino a 10 volumi da 1 TiB da uno snapshot di 100 GiB alla volta.

Infine, ogni zona di disponibilità nella quale lo snapshot è abilitato per FSR ottiene il proprio bucket di credito indipendentemente dalle altre zone di disponibilità.

La dimensione del bucket di credito di creazione rappresenta il numero massimo e l'equilibrio del bucket di credito rappresenta il numero di creazioni disponibili. Quando carico, possono essere creati fino a 10 volumi inizializzati da uno snapshot con FSR abilitato alla volta. Sia la dimensione massima del bucket di credito e l'equilibrio del bucket di credito vengono pubblicati sotto forma di parametri di CloudWatch. Le creazioni di volume inferiore al limite verranno elaborate come se FSR non fosse abilitato sullo snapshot.

Quando utilizzi FSR, un nuovo attributo specifico di EBS (fastRestored) viene aggiunto all'API DescribeVolumes per mostrare lo stato nel momento della creazione. Quando un volume viene creato da uno snapshot con FSR abilitato senza crediti di creazione del volume sufficienti, la creazione verrà eseguita ma il volume non verrà inizializzato.

Quando elimini uno snapshot, l'FSR per lo snapshot viene automaticamente disabilitato e la fatturazione dell'FSR verrà terminata.

Sì, puoi abilitare FSR per gli snapshot pubblici e per tutti gli snapshot privati condivisi con il tuo account. Per abilitare FSR per gli snapshot condivisi, puoi utilizzare lo stesso set di chiamate API utilizzato per abilitare FSR negli snapshot di tua proprietà.

Quando abiliti FSR sul tuo snapshot condiviso, ti saranno addebitate le tariffe FSR standard (consulta le pagine dei prezzi). Ricorda che solo il tuo account verrà fatturato per l'FSR dello snapshot condiviso. Il proprietario dello snapshot non verrà addebitato quando abiliti l'FSR sullo snapshot condiviso.

Quando il proprietario dello snapshot condiviso elimina lo snapshot o interrompe la sua condivisione revocando le autorizzazioni per creare volumi da tale snapshot, l'FSR per lo snapshot condiviso viene automaticamente disabilitato e la fatturazione dell'FSR per lo snapshot verrà terminata.

Puoi utilizzare Amazon Data Lifecycle Manager e AWS Systems Manager (SSM) per coordinare il blocco, il flush I/O e lo sblocco dell'applicazione o del database, nonché l'inizializzazione degli snapshot EBS. Dovrai fornire i comandi per eseguire le azioni specifiche dell'applicazione o del database. Puoi anche fare riferimento alla nostra documentazione per il codice fornito da AWS e i documenti SSM per le applicazioni MySQL, PostgreSQL e Windows.

Amazon EBS consente di crittografare in modo integrato i volumi e gli snapshot, eliminando la necessità di creare e gestire un'infrastruttura di gestione delle chiavi sicura. La funzione di crittografia di EBS protegge i dati in locale codificandoli tramite chiavi gestite da Amazon oppure create e gestite dall'utente con AWS Key Management Service (KMS). La crittografia viene implementata a livello del server che ospita le istanze EC2, perciò viene applicata anche ai dati in trasferimento tra le istanze EC2 e lo storage EBS. Per ulteriori informazioni, consulta il capitolo relativo alla crittografia di Amazon EBS nella Amazon EC2 User Guide.

AWS KMS è un servizio gestito che semplifica la creazione e il controllo di chiavi di crittografia per la codifica dei dati. AWS Key Management Service è integrato con altri servizi AWS tra cui Amazon EBS, Amazon S3 e Amazon Redshift, rendendo più facile codificare i dati con chiavi di crittografia gestite da te. AWS Key Management Service è integrato anche con AWS CloudTrail, per fornire i registri dell'utilizzo di tutte le chiavi e consentire di soddisfare i requisiti normativi e di conformità. Per ulteriori informazioni su KMS, visita la pagina del prodotto AWS Key Management Service.

È possibile usare la funzione di crittografia di Amazon EBS per soddisfare i requisiti di sicurezza e di conformità crittografica per i dati a riposo nel cloud. Per rendere più solida la strategia di sicurezza aziendale, puoi impiegare la crittografia insieme alle policy di controllo degli accessi di IAM.

La funzione di crittografia di Amazon EBS gestisce le chiavi per tuo conto. Ogni nuovo volume ottiene una chiave AES a 256 bit; i volumi creati da snapshot crittografate ne condividono la chiave. Queste chiavi sono protette nella nostra infrastruttura di gestione delle chiavi, che implementa controlli di sicurezza sia logici sia fisici molto severi per evitare accessi non autorizzati. I tuoi dati e le relative chiavi sono crittografati usando un algoritmo AES a 256 bit standard di settore.

Sì.

Sì, utilizzando le chiavi master del cliente (CMK) gestite da AWS o dal cliente. Puoi specificare i dettagli di volume e crittografia mediante una chiamata API RunInstances con il parametro BlockDeviceMapping o mediante l'assistente di avvio nella console EC2.

Sì, è possibile creare volumi di dati crittografati con crittografia predefinita o CMK personalizzata al momento dell'avvio dell'istanza. È possibile specificare i dettagli e la crittografia del volume mediante un oggetto BlockDeviceMapping in una chiamata API RunInstances o mediante la procedura guidata di avvio nella console EC2.

Sì. Per maggiori informazioni, consulta la documentazione tecnica.

Sì. È possibile condividere snapshot e AMI crittografati attraverso una chiave master gestita dal cliente (CMK) con altri account AWS. Per maggiori informazioni, consulta la documentazione tecnica.

Sì, è possibile abilitare la crittografia EBS per default con una singola impostazione per regione. Questo assicura la crittografia costante di tutti i nuovi volumi. Consulta la documentazione tecnica, per ulteriori dettagli. 

Sì, quando un volume Provisioned IOPS viene scollegato da un'istanza, vengono addebitati i costi per le operazioni al secondo assegnate. Per ridurre i costi, quando un volume viene scollegato consigliamo di crearne uno snapshot ed eliminare il volume. Per ulteriori informazioni, consulta la verifica di ottimizzazione dei costi di "Underutilized Amazon EBS Volumes" in Trusted Advisor.  Si tratta di un elemento che verifica le configurazioni dei tuoi volumi di Amazon Elastic Block Store (Amazon EBS) e ti avverte quando un volume risulta sottoutilizzato.

Salvo diversamente specificato, i prezzi sono al netto di eventuali tasse e imposte doganali, inclusa l'IVA ed eventuali imposte sulle vendite. Per i clienti con indirizzo di fatturazione in Giappone, l'utilizzo dei servizi AWS è soggetto all'imposta sul consumo giapponese. Ulteriori informazioni.

No. È possibile abilitare Multi-Attach su volumi con capacità di IOPS allocata EBS e vi saranno addebiti per l'archiviazione (GB al mese) e IOPS (IOPS al mese) con provisioning.

No.

Il comportamento deleteOnTermination del volume dipende dalla configurazione dell'ultima istanza collegata che viene terminata. Per assicurare un'eliminazione prevedibile riguardo al comportamento di terminazione, abilita o disabilita 'deleteOnTermination' per tutte le istanze alle quali è collegato il volume.

Se vuoi che il volume venga eliminato quando le istanze collegate vengono terminate, abilita 'deleteOnTermination' per tutte le istanze alle quali il volume è collegato. Se vuoi conservare il volume dopo che le istanze collegate sono state terminate, disabilita 'deleteOnTermination' per tutte le istanze collegate. Per ulteriori informazioni, consulta la documentazione tecnica di Multi-Attach.

L'applicazione può utilizzare Multi-Attach se è basata su un cluster di failover di Windows Server, coordina l'accesso sicuro all’archiviazione condivisa utilizzando le prenotazioni NVMe o coordina l'accesso sicuro a livello di applicazione.