Estratégias para determinar os requisitos do EC2 com base na configuração física existente?

Estratégias para determinar os requisitos do EC2 com base na configuração física existente?

Sou um cara de TI solitário tentando avaliar o custo de mover nosso data center físico existente para a AWS (6 servidores de aplicativos e 2 servidores MySQL replicados). A calculadora de custos fornecida pela Amazon é baseada nas necessidades de largura de banda e instâncias de servidor que vêm em três tamanhos. Eu sei quais são nossas necessidades de largura de banda, mas estou tendo dificuldade em ter uma ideia de quais tamanhos de instância de serviço EC2 corresponderiam ao nosso hardware/carga específico. Nossa carga varia muito de acordo com a programação, então imagino pelo menos uma instância "sob demanda" durante horários de pico. Quais ferramentas/estratégias posso usar para mapear nossa configuração física para uma configuração AWS correspondente (otimizada para carga)?

Responder1

Achei as calculadoras de custos fornecidas inadequadas para mim pessoalmente. Atualmente, tenho uma implantação que consiste em 3 instâncias de servidor m1.small, 2 x m1.large, 1 x m1.xlarge e 1 x c1.xlarge. Passamos de uma construção de três servidores físicos em um data center tradicional para isso há pouco mais de 9 meses.

A parte mais fácil de determinar do cálculo são os custos de instância por hora. Descobri que, na maior parte, meus custos do S3 eram triviais devido ao esquema de preços. Os volumes e instantâneos do EBS são, na verdade, maiores do que os custos do S3 e muito fáceis de calcular, embora eu sugira estimar demais as solicitações de E/S, pois descobri que nosso uso real é maior do que o estimado originalmente.

A largura de banda é complicada e curta em relação às próprias instâncias do servidor, provavelmente sendo o segundo maior custo a ser levado em consideração. Achei que tínhamos uma ideia dos padrões de uso da largura de banda, mas o uso real na AWS provou que essas estimativas iniciais estavam incorretas. Algumas coisas a ter em mente é que você tem largura de banda pública de entrada e saída, mas também largura de banda entre regiões. Se você tiver instâncias em execução na mesma região, mas em zonas de disponibilidade (AZ) diferentes, você será cobrado pela largura de banda. Isso também conta quando você considera os volumes do EBS, assim como eles são feitos em uma determinada AZ. Na verdade, vimos que a largura de banda entre regiões é maior do que o uso da largura de banda pública devido à comunicação entre as próprias instâncias.

Criei minha própria planilha que realiza a maioria dos cálculos ao tentar fornecer estimativas para fins orçamentários. No momento, estou revisando a planilha para obter atualizações revisadas para o novo orçamento. Desta vez, porém, posso usar parte do histórico de uso fornecido pela Amazon para poder dar uma estimativa melhor.

Quanto a quais instâncias mapeiam, esse foi o melhor esforço para adivinhar. Você pode tentar combinar com base na intensidade da CPU e da memória da finalidade principal do servidor. Na verdade, dividimos nossa infraestrutura mais com AWS do que com servidores físicos, para que pudéssemos atender melhor às necessidades das diversas partes e permitir escalabilidade adicional.

informação relacionada