As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Personalização da frota
## Tipo de frota
Ao criar uma frota, os clientes devem escolher um tipo. Cada tipo de frota oferece benefícios diferentes para a experiência do usuário, custos e despesas gerais de manutenção. Independentemente do tipo de frota escolhido, cada opção é compatível com os tipos de plataforma Windows e Linux, bem como o Desktop View ou o Application View.
Os clientes já podem escolher entre os seguintes tipos de frota:
+ **Always-On**— Esse tipo de frota fornece aos usuários acesso instantâneo aos seus aplicativos. Você será cobrado por todas as instâncias em execução na frota, mesmo se nenhum usuário estiver fazendo streaming de aplicativos.
+ **On-Demand**— Selecione esse tipo de frota para otimizar seus custos de streaming. Com uma frota sob demanda, os usuários terão um horário de início de aproximadamente um a dois minutos para a sessão. No entanto, você só pagará as taxas da instância de streaming quando os usuários estiverem conectados e uma pequena taxa horária para cada instância da frota que não seja um aplicativo de streaming.
+ **Elástica**: as frotas elásticas podem ser usadas para aplicativos que não exigem instalação e podem ser executados a partir de um disco rígido virtual (VHD). As frotas elásticas não oferecem suporte a imagens de WorkSpaces aplicativos, nem exigem políticas de escalabilidade. Você será cobrado apenas pela duração de uma sessão de streaming.
*Tabela 2 — Tipos de frota de WorkSpaces aplicativos da Amazon*
| Tipo de frota | Quando usar | Experiência do usuário | Modelo de definição de preços | Observações |
| --- | --- | --- | --- | --- |
| **Always-On** | Os usuários precisam de acesso instantâneo aos aplicativos quando iniciam uma sessão. Você não terá excesso significativo de capacidade em sua frota, talvez porque os padrões de uso sejam previsíveis e seja possível controlar os custos de modo confiável com políticas de ajuste de escala. | Acesso instantâneo aos aplicativos | Você paga o preço total por cada instância disponível na frota (independentemente de ser usada para uma sessão). | Oferece suporte a políticas personalizadas de imagem e de ajuste de escala. |
| **On-Demand** | Você deve manter um excesso significativo de capacidade em suas frotas. Você quer o ambiente mais econômico e não quer pagar o preço total pela capacidade não utilizada. Os usuários podem esperar de um a dois minutos para acessar os aplicativos depois de iniciar uma sessão. Você está usando tipos de instância maiores. O custo por hora de uma instância em execução é muito mais caro do que a taxa de instância interrompida. | Os usuários esperam de um a dois minutos para acessar os aplicativos depois de iniciar uma sessão. | Você paga o preço total somente pelas instâncias de streaming com uma sessão ativa e, em seguida, um pequeno custo por hora pelas instâncias ociosas. | Oferece suporte a políticas personalizadas de imagem e escalabilidade. |
| **Elástica** | O aplicativo e suas dependências têm menos de \~1,5 GB. Sempre que um usuário inicia uma sessão em uma frota elástica, seu arquivo de disco rígido virtual (VHD) deve ser baixado do Amazon S3 para a sessão. Como resultado, arquivos de VHD maiores (ou seja, com mais de 1,5 GB) resultarão em uma experiência inadequada para o usuário final. O aplicativo é portátil. Ou seja, seu aplicativo e todas as suas dependências podem ser colocados em um VHD e lançados a partir de instâncias de streaming VHD.You não obrigatórias associadas ao domínio (atualmente, a união de domínios não está disponível com frotas da Elastic). Você deseja pagar somente pelas sessões ativas (ou seja, você não paga pela capacidade não utilizada em sua frota) .Seus usuários podem esperar 45 segundos ou mais para acessar seus aplicativos após iniciar uma sessão.Você quer que a AWS gerencie a escalabilidade para você (sem escalabilidade) políticas para gerenciar). | O usuário espera de 45 segundos a três minutos para acessar os aplicativos após iniciar a sessão (o tempo de espera depende do tamanho do disco rígido virtual). | Você será cobrado apenas pela duração de uma sessão de streaming. Como não existe o conceito de instâncias ociosas com frotas elásticas, você não incorre em cobranças por instâncias não utilizadas. | Não há suporte a imagens personalizadas (o cliente fornece aplicativos ao VHD) nem a políticas de ajuste de escala. Atualmente, dá suporte para instâncias de `stream.standard.small` e `stream.standard.medium`. Se seu caso de uso exigir um tipo de instância diferente, entre em contato com a equipe da sua AWS conta. |
## Dimensionamento da frota
### Capacidade mínima e ajuste da escala programado
Ao dimensionar sua frota de WorkSpaces aplicativos, há várias considerações que se traduzem diretamente na experiência e no custo do usuário. O valor inserido para **Capacidade mínima** garante que o número de instâncias de WorkSpaces aplicativos raramente seja menor que esse valor. Após o término de uma sessão de WorkSpaces aplicativos, se o total de instâncias de WorkSpaces aplicativos for menor que o valor **mínimo da capacidade**, uma nova instância de frota será iniciada. Como sempre, é importante lembrar que uma instância de WorkSpaces aplicativos é mapeada diretamente para uma sessão de usuário, influenciando diretamente o valor da **capacidade mínima**.
Inserir um valor para a **capacidade mínima** que esteja além da simultaneidade prevista resulta em aumento de custo, embora a experiência do usuário não seja afetada. Um valor muito baixo resulta em custos reduzidos, mas afeta a experiência do usuário quando o total de solicitações excede a capacidade disponível. Os administradores observarão erros de “Capacidade insuficiente” nesse tipo de situação. Por exemplo, esperar `PendingCapacity` se tornar `AvailableCapacity` é um uso ineficiente do tempo do usuário quando o número de conexões previstas no início do dia é um valor previsivelmente consistente.
Comece com uma capacidade mínima que acomode os horários típicos fora de pico e, em seguida, use a [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) para redefinir efetivamente a capacidade mínima antes do início do dia de trabalho. Não se esqueça de criar outra política de ajuste de escala programada para reverter a capacidade mínima para os horários fora do pico. Para obter mais informações sobre políticas de ajuste de escala e como implementá-las, consulte a seção [*Estratégias de ajuste de escala automático de frotas*](fleet-auto-scaling-strategies.md) neste documento.
### Capacidade máxima e cotas de serviço
A definição da capacidade máxima pode parecer um valor arbitrário, mas quando previsto e definido adequadamente, otimiza o consumo e o custo total dos recursos. Um valor inserido que seja maior do que a [https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html) em sua Conta da AWS pode parecer válido, mas, quando eventos de auto scaling tentam escalar recursos até a capacidade máxima, eles não são iniciados, pois o valor da capacidade máxima excede a cota de serviço disponível. Garanta que uma solicitação de cota de serviço exista para a capacidade máxima desejada, garantindo as funções de ajuste de escala automático conforme previsto pela sua organização.
Outra consideração importante ao definir um valor máximo de capacidade é o custo. Para obter mais informações, consulte a seção [*Como otimizar custos com a escolha do tipo de frota*](cost-optimization.md#optimizing-costs-with-fleet-type-choice) deste documento.