¿Por qué Amazon AWS no tiene precios fuera de horas punta para el ancho de banda?

Así que aquí está la cosa …

Precios de ancho de banda en dos métricas: tamaño de tubería y flujo.

El tamaño de la tubería (es una conexión de 100 Mbps, 1 Gbps, 10 Gbps, 100 Gbps, etc.) es todo un costo fijo. Pagas por el hardware, pagas por la reserva en la capacidad, pagas por energía, espacio, ingeniería, todo eso 24/7/365. Decir que no debe pagarlo cuando “no lo está usando” es como decir que solo debe pagar el alquiler de su oficina por las horas que realmente está en ella.

Flujo, eso es diferente. Y obtienes beneficios en eso.

En los años 90, la observación sin tránsito en su mayoría murió. Todos, incluso los operadores de primer nivel, todavía tienen que “señalar por defecto” algo, o simplemente hay paquetes que nunca se entregan. Así que terminas teniendo que comprar el tránsito, como un servicio comercial, de otros operadores.

Y eso cuesta dinero. El último precio en vivo que tuve fue que en el volumen de Facebook, podría bajar a aproximadamente medio centavo por gigabyte enviado. Eso se suma a los costos de pagar por toda la infraestructura necesaria para que ese tránsito suceda, y toda la ingeniería de la red para minimizar la cantidad que realmente usa.

Por lo tanto, su precio de ancho de banda en AWS es completamente consistente con la forma en que tienen que comprarlo. Hay un costo fijo para operar, que promedian según la cantidad de usuarios y flujos que tienen, y es por eso que sus precios han bajado con el tiempo.

Y hay un “costo variable” basado en la cantidad de datos que está enviando. Es por eso que toman una contribución de la parte de costo fijo, la expresan en términos de “gigabytes enviados” en lugar de “tarifa base mensual”, y la agregan a su costo real para enviar bytes (más margen) y le dan lo que es en realidad, un precio más bajo por gigabyte enviado de lo que probablemente podría negociar por su cuenta.

En resumen, de lo que estás hablando es de pura fantasía. No hay un “período de inactividad” para estas cosas. Ese es el punto. Está encendido, todo el tiempo. Y si lo usas, pagas por ello.

Escuché una historia sobre una conversación que ocurrió dentro de las oficinas de AWS, y fue algo así.

—Aviso legal: los números aquí no son oficiales—

Eng1: Entonces, tenemos todos estos excelentes servidores ejecutándose, ¡y más de la mitad del espacio en disco no se usa! Me temo que incluso mirar la utilización de la CPU se estaba desperdiciando.

Eng2: Bueno, nuestros clientes están pagando nuestro servicio durante todo el día, no solo cuando lo están utilizando, ¿por qué es importante?

Eng1: ¡Oh chico, solo mira el tiempo de inactividad de la CPU! ¡Apenas superamos el 25% de utilización!

Eng1: ¿Por qué no creamos un nuevo servicio donde las personas no tienen que pagar 24/7 por una máquina, sino que solo pagan por ella cuando la usan?

Y así nació AWS lambda. Esto no es exactamente lo que está buscando en términos de precios durante las horas pico frente a las horas no pico. Aunque de alguna manera funciona para un usuario de Lambda.

Un usuario de lambda solo paga por los segundos que su código se ejecuta en máquinas Amazon. Cualquier tiempo de inactividad, también conocido como tiempo no pico en relación con una aplicación, ¡no tiene costos! Stan Hanks Creo que aquí es donde puede lograr ahorros pico / no pico, al contrario de su respuesta bien escrita.

Es el modelo perfecto de pago por uso para la informática, y ahora se conocerá como Serverless Computing.

No voy a entrar en detalles, ¡pero Software Engineering Daily tiene un gran podcast aquí!

Marco sin servidor con Austen Collins – Software Engineering Daily

¡Debe echar un vistazo a lambda y ver si el patrón de micro servicio y los precios más justos que se obtienen de Lambda satisfacen sus necesidades!