AWS, Tipos de instancias EC2 y forma de pago.

Muy buenas,

Como muchos de vosotros estáis empezando a conocer el mundo Amazon Web Services, vamos a comenzar por lo más básico, las Instancias de EC2 (Elastic Compute Cloud) o lo que es lo mismo, las máquinas virtuales sobre infraestructura Amazon Web Services.

Bien, empecemos por el principio, cuando decidimos desplegar una instancia por primera vez bajo plataforma AWS, tenemos que tener muy claras 2 premisas:

  • La primera, que sistema operativo deseamos que esa Instancia tenga, esta primera elección es relativamente fácil, simplemente tenemos que elegir la AMI (Amazon Machine Images) de la lista de AMIs disponibles separadas entre sistemas Windows y sistemas Linux. En Windows podremos elegir entre una gran variedad desde 2003R2 hasta 2016R2 con y sin SQL Server y en varias versiones. En Linux tenemos SLES, RHEL y Amazon Linux, siendo esta última una distribución propia de AWS.
  • La segunda, pero no menos importante, es el tamaño/propósito de la misma, para ello Amazon nos las subdivide en diferentes propósitos, y dentro de esos propósitos, en diferentes tamaños, como por ejemplo “General Purpose” o propósito general, se trata de instancias balanceadas a nivel de recursos, ubicándose dentro de ellas las familias “T” y “M” , las “Compute Optimized” orientadas a consumo elevado de computación que son las familias “C” , “Memory Optimized” orientadas a consumo de memoria que son las familias “R” y “X” , las “Storage Optimized” orientadas a consumo intensivo de almacenamiento como las familias “I” y “D” y las “Accelerated Computing” orientadas a la utilización de las GPU’s como las familias “G” y “F” .

Por supuesto dentro de todas estas familias se diferencian en la cantidad de recursos entregados a la instancia y los valores que podemos seleccionar oscilan entre “nano” (el menor posible)  y en algunas familias hasta “16xlarge”, variando el precio tanto en el tipo de familia como en el tamaño que seleccionemos.

Después de esta introducción vamos a desgranar los modelos de pago, donde veremos algunos ejemplos de uso:

  • On-Demand, en este modelo pagaremos por el consumo de los recursos/capacidad de nuestras instancias EC2  en fragmentos horarios, es decir, por cada hora de uso de las mismas hasta el 02 de Octubre de 2017 y evolucionando a la facturación por segundos desde esta fecha, novedad presentada en este último AWS SUMMIT , además, EC2 no será el único servicio beneficiado por este gran cambio, también los servicios EBS (Almacenamiento tipo Bloque), y EMR entre otros se beneficiarán de este cambio. Éste modelo presenta como principal ventaja que no afrontamos ningún compromiso de “permanencia” ni pago por adelantado, pagas por lo que usas, por lo que es óptimo para cargas a corto plazo, picos de trabajo, testeos, etc.
  • Spot Instances, en este modelo lo que haremos será un Biding o subasta por los recursos no utilizados de EC2 pudiendo ahorrar hasta un 90% del precio en comparación con las instancias On-Demand. Aquí podéis ver un ejemplo grafico del precio  http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/SpotInstance_spotinstancepricinghistory-gwt.png para hacernos una idea aproximada. Éste modelo es óptimo por ejemplo para procesos batch.
  • Reserved Instances, en este modelo lo que haremos es reservar una capacidad especifica durante un periodo de tiempo específico que puede ser de 1 o 3 años para un tipo de instancia, éste modelo nos permite un ahorro de hasta un 75% comparativamente con el mismo tipo de instancia On-Demand y en la misma Región, dado que en cualquiera de los modelos anteriormente citados, los precios variaran en función de la Región en donde se realice el despliegue. Éste modelo es óptimo para nuestras cargas productivas que ya las tenemos debidamente medidas, localizadas y controladas, evidentemente los precios variarán en función de la “permanencia” que reservemos, 1 o 3 años.
  • Dedicated Hosts, en este modelo lo que hacemos es reservar físicamente un servidor físico de EC2 para nosotros, proporcionándonos un mayor aislamiento de nuestras aplicaciones si por ejemplo es un requisito para ciertas reglas de compliance corporativo e incluso poder aportar nuestras propias licencias  de nuestro software. Éste modelo se suele usar por aislamiento.

Para finalizar con este post, a continuación tendréis disponible una serie de links muy útiles sobre éste tema:

https://aws.amazon.com/es/tco-calculator/

http://calculator.s3.amazonaws.com/index.html

http://www.cloudping.info/

Espero que os haya gustado y hasta la próxima.

 

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *