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à.
# Personalizzazione della flotta
## Tipo di parco
Quando creano una flotta, i clienti devono scegliere un tipo di flotta. Ogni tipo di flotta offre diversi vantaggi in termini di esperienza utente, costi e spese generali di manutenzione. Indipendentemente dal tipo di parco macchine scelto, ogni opzione supporta sia i tipi di piattaforma Windows e Linux, sia Desktop View o Application View.
I clienti possono ora scegliere tra i seguenti tipi di flotta:
+ **Always-On**— Questo tipo di flotta offre agli utenti l'accesso immediato alle proprie app. Ti verranno addebitati costi per tutte le istanze in esecuzione nel tuo parco istanze anche se nessun utente utilizza app in streaming.
+ **On-Demand**— Seleziona questo tipo di flotta per ottimizzare i costi di streaming. Con una flotta on-demand, gli utenti avranno un tempo di inizio di circa uno o due minuti per la sessione. Tuttavia, ti verranno addebitate le tariffe delle istanze di streaming solo quando gli utenti sono connessi e una piccola tariffa oraria per ogni istanza del parco istanze che non sono app di streaming.
+ **Elastico**: le flotte elastiche possono essere utilizzate per applicazioni che non richiedono installazione e possono essere eseguite da un disco rigido virtuale (VHD). Le flotte elastiche non supportano WorkSpaces le immagini delle applicazioni e non richiedono politiche di scalabilità. Ti viene addebitato solo per la durata di una sessione di streaming.
*Tabella 2 — Tipi di flotte di Amazon WorkSpaces Applications*
| Tipo di parco | Quando utilizzare | Esperienza utente | Modello tariffario | Note |
| --- | --- | --- | --- | --- |
| **Always-On** | Gli utenti richiedono l'accesso immediato alle applicazioni all'avvio di una sessione. Non avrete un eccesso di capacità significativo nella vostra flotta, forse perché i modelli di utilizzo sono prevedibili e potete controllare in modo affidabile i costi con politiche di scalabilità. | Accesso istantaneo alle applicazioni | Paghi il prezzo pieno per ogni istanza disponibile nel tuo parco istanze (indipendentemente dal fatto che venga utilizzata per una sessione). | Supporta politiche di immagine e ridimensionamento personalizzate. |
| **On-Demand** | È necessario mantenere una notevole capacità in eccesso nei parchi veicoli. Desiderate l'ambiente più ottimizzato in termini di costi e non volete pagare il prezzo pieno per la capacità inutilizzata. Gli utenti possono attendere uno o due minuti prima di accedere alle loro applicazioni dopo l'avvio di una sessione.State utilizzando tipi di istanze più grandi. Il costo orario di un'istanza in esecuzione è molto più costoso della tariffa per le istanze interrotte. | Gli utenti attendono da uno a due minuti per accedere alle proprie applicazioni dopo l'avvio di una sessione. | Pagherai il prezzo pieno solo per le istanze di streaming con una sessione attiva e poi un piccolo costo orario per le istanze inattive. | Supporta politiche di immagine e ridimensionamento personalizzate. |
| **Elastic** | L'applicazione e le sue dipendenze sono inferiori a \~ 1,5 GB. Ogni volta che un utente avvia una sessione in una flotta Elastic, il file del disco rigido virtuale (VHD) deve essere scaricato da Amazon S3 nella sessione. Di conseguenza, file VHD più grandi (ovvero di dimensioni superiori a 1,5 GB) comporteranno un'esperienza utente finale scadente. L'applicazione è portabile. Cioè, la tua applicazione e tutte le sue dipendenze possono essere collocate su un disco rigido virtuale e avviate dalle istanze di streaming che VHD.You non richiedono l'aggiunta al dominio (l'aggiunta al dominio non è attualmente disponibile con le flotte Elastic). Vuoi pagare solo per le sessioni attive (ovvero non paghi per la capacità inutilizzata del tuo parco) .I tuoi utenti possono attendere 45 secondi o più per accedere alle loro applicazioni dopo l'avvio di una sessione.Vuoi che AWS gestisca la scalabilità per te (no politiche da gestire). | L'utente attende da 45 secondi a 3 minuti per accedere alle applicazioni dopo l'avvio della sessione (il tempo di attesa dipende dalla dimensione del disco rigido virtuale). | Ti viene addebitato solo per la durata di una sessione di streaming. Poiché non esiste il concetto di istanze inattive con le flotte Elastic, non è previsto alcun addebito per le istanze non utilizzate. | Non supporta immagini personalizzate (il cliente fornisce VHD con le applicazioni) o politiche di scalabilità. Attualmente supporti `stream.standard.small` e istanze. `stream.standard.medium` Se il tuo caso d'uso richiede un tipo di istanza diverso, contatta il team AWS del tuo account. |
## Dimensionamento della flotta
### Capacità minima e scalabilità programmata
Quando si ridimensiona il parco WorkSpaces applicazioni, ci sono diverse considerazioni che si traducono direttamente in termini di esperienza utente e costi. Il valore inserito per **Capacità minima** garantisce che il numero di istanze di WorkSpaces Applications sia raramente inferiore a questo valore. Al termine di una sessione WorkSpaces Applications, se il totale WorkSpaces delle istanze di Applications è inferiore al valore di **capacità minima**, viene avviata una nuova istanza del parco istanze. Come sempre, è importante ricordare che un'istanza di WorkSpaces Applications viene mappata direttamente su una sessione utente, influendo direttamente sul valore della capacità **minima**.
L'immissione di un valore per la **capacità minima** superiore alla concorrenza prevista comporta un aumento dei costi, sebbene l'esperienza utente non ne risenta. Un valore troppo basso comporta costi bassi, ma influisce sull'esperienza utente quando le richieste totali superano la capacità disponibile. Gli amministratori osserveranno gli errori di «Capacità insufficiente» in questo tipo di situazione. Ad esempio, waiting for `PendingCapacity` become `AvailableCapacity` è un uso inefficiente del tempo dell'utente quando il numero di connessioni previste all'inizio della giornata è un valore prevedibilmente costante.
Inizia con una capacità minima adatta alle tipiche ore non di punta, quindi utilizza una [https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) per ripristinare efficacemente la capacità minima prima dell'inizio della giornata lavorativa. Non dimenticare di creare un'altra politica di scalabilità pianificata per riportare la capacità minima alle ore non di punta. Per ulteriori informazioni sulle politiche di scalabilità e su come implementarle, consulta la sezione [*Fleet auto-scaling strategies*](fleet-auto-scaling-strategies.md) di questo documento.
### Capacità massima e quote di servizio
L'impostazione della capacità massima può sembrare un valore arbitrario, ma se prevista e impostata correttamente, ottimizza il consumo e i costi totali delle risorse. Un valore immesso superiore alla [https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html)utente Account AWS può sembrare valido, ma, quando gli eventi di auto scaling tentano di scalare le risorse fino alla capacità massima, non riescono ad avviarsi, poiché il valore della capacità massima supera la quota di servizio disponibile. Assicuratevi che venga effettuata una richiesta di quota di servizio per la capacità massima desiderata per garantire che la scalabilità automatica funzioni come previsto dall'organizzazione.
Un'altra considerazione importante quando si imposta un valore massimo di capacità è il costo. Per ulteriori informazioni, consulta la sezione [*Ottimizzazione dei costi con la scelta del tipo di flotta*](cost-optimization.md#optimizing-costs-with-fleet-type-choice) di questo documento.