¿Estrategias para determinar los requisitos de EC2 en función de la configuración física existente?

¿Estrategias para determinar los requisitos de EC2 en función de la configuración física existente?

Soy un informático solitario que intenta evaluar el costo de trasladar nuestro centro de datos físico existente a AWS (6 servidores de aplicaciones y 2 servidores MySQL replicados). La calculadora de costos que proporciona Amazon se basa en las necesidades de ancho de banda y las instancias de servidor que vienen en 3 tamaños. Sé cuáles son nuestras necesidades de ancho de banda, pero me cuesta tener una idea de qué tamaños de instancias de servicio EC2 corresponderían con nuestro hardware/carga particular. Nuestra carga varía mucho según el cronograma, por lo que imagino al menos una instancia "bajo demanda" durante las horas pico. ¿Qué herramientas/estrategias puedo utilizar para asignar nuestra configuración física a una configuración de AWS correspondiente (optimizada para la carga)?

Respuesta1

Personalmente, las calculadoras de costes que me proporcionaron me parecieron inadecuadas. Actualmente tengo una implementación que consta de 3 instancias de servidor m1.small, 2 x m1.large, 1 x m1.xlarge y 1 x c1.xlarge. Pasamos de la construcción de 3 servidores físicos en un centro de datos tradicional a esto hace poco más de 9 meses.

La parte más fácil de determinar del cálculo son los costos de instancia por hora. Descubrí que en su mayor parte los costos de mi S3 eran triviales debido al esquema de precios. Los volúmenes y las instantáneas de EBS en realidad son más que los costos de S3 y son bastante fáciles de calcular, aunque sugeriré sobreestimar las solicitudes de E/S, ya que descubrí que nuestro uso real es mayor de lo que estimamos originalmente.

El ancho de banda es complicado y está por debajo de las instancias del servidor en sí, lo que probablemente sea el segundo costo más grande a tener en cuenta. Pensé que teníamos una idea de los patrones de uso del ancho de banda, pero el uso real en AWS demostró que esas estimaciones iniciales eran incorrectas. Algunas cosas a tener en cuenta es que tiene ancho de banda público entrante y saliente, pero también ancho de banda interregional. Si tiene instancias ejecutándose en la misma región pero en diferentes zonas de disponibilidad (AZ), se le cobrará por el ancho de banda. Esto también cuenta cuando se consideran los volúmenes de EBS y también cuando se realizan en una zona de disponibilidad determinada. De hecho, hemos visto que el ancho de banda entre regiones es mayor que nuestro uso de ancho de banda público debido a la comunicación entre las propias instancias.

He creado mi propia hoja de cálculo que realiza la mayoría de los cálculos cuando intento dar estimaciones con fines presupuestarios. Actualmente estoy en el proceso de revisar la hoja de cálculo para obtener actualizaciones revisadas para el nuevo presupuesto. Sin embargo, esta vez puedo utilizar parte del historial de uso que proporciona Amazon para poder dar una mejor estimación.

En cuanto a qué mapas de instancia, ese ha sido un esfuerzo de suposición. Puede intentar hacer coincidir según la intensidad de la CPU y la memoria del propósito principal del servidor. De hecho, dividimos nuestra infraestructura más con AWS que con servidores físicos para poder satisfacer mejor las necesidades de las distintas partes y permitir una escalabilidad adicional.

información relacionada