servidores pricing prices precios glacier calculadora aws amazon-s3 amazon-ec2 cloud

amazon s3 - pricing - ¿Utiliza los servicios de Amazons Cloud para su empresa?



aws s3 pricing (8)

Almacenamos los archivos de nuestra compañía en S3 para que puedan ser accesibles a los empleados en el camino. Extremadamente barato y fácil. Un montón de aplicaciones para acceder a tus archivos en S3. El que usamos es un buen administrador de archivos en línea: S3fm .

Leí mucho sobre las posibilidades de la computación en la nube de Amazon, como S3 o EC2 y me pregunté si alguien realmente usa esto para aplicaciones de misión crítica. ¿Hospedas el sitio web de tu compañía en la nube? ¿Almacena archivos ahí? ¿Ejecutas tus servidores de compilación en la nube?

Ya hay algunos servicios como Scalr o WeoCeo que podrían ayudarlo con esta tarea, pero no sé si la administración ya está en el punto en que esto es un problema real ...

editar Me gustaría agregar otro punto: ¿Cree que hay problemas ocultos en las licencias de AWS que lo mantendrían a usted (y / oa su empresa) fuera de las aplicaciones de externalización o incluso partes de las aplicaciones en la nube?

editar ¿Conoces algunas estadísticas que comparan los tiempos de interrupción general de S3 o EC2 y tus propios o terceros servicios de alojamiento?


Configuré dos instancias de mi aplicación en EC2 y utilicé S3 como respaldo de AWS local y entrega de activos de medios. Pasamos de aproximadamente el 15% del contenido / tráfico de nuestras aplicaciones a EC2 a mediados de junio. El resultado es mixto, y estamos trasladando la instancia de uso de contenido pesado a nuestro centro de datos alojado, y ahora estamos investigando otras opciones de entrega de contenido.

Ten en cuenta que:

  1. Mi aplicación está hambrienta de ancho de banda (comenzando en 100mbps por instancia)
  2. Mi empresa y yo tenemos su sede en Suiza y eso seguramente ha tenido un impacto en nuestra evaluación.
  3. Defino el ancho de banda como una tasa de flujo (mbps, etc.) y el tráfico como volumen (mb, gb, etc.)

Pros:

  • Los costos de tráfico para volúmenes bajos a medios, suponiendo menos de tal vez un terabyte por mes. Supera esa línea difusa y hazlo tú mismo o encuentra un CDN adecuado
  • Comunidad de usuarios activa
  • Ancho de banda efectivamente ilimitado con contenido entregado por S3 / CloudFront
  • Flexibilidad (patear una instancia y ejecutarla en minutos)
  • El poder de CPU disponible en una instancia, incluso el tipo de instancia pequeña, siempre fue suficiente para mi aplicación. Hay otros tipos de instancias de alta CPU para quienes lo necesitan.

Contras:

  • Tuvimos una instancia inaccesible (una ocurrencia no desconocida) y tuvimos que ejecutar nuestro procedimiento de recuperación de desastres. 12h.
  • La latencia de red, tanto para S3 como para EC2, puede ser inaceptablemente alta (100 s de ms)
  • El ancho de banda de instancia EC2 es limitado. A pesar de las horas de búsqueda, nunca encontré una declaración oficial con números duros, uno lo que los usuarios pueden esperar. Inicialmente vimos un máximo de ~ 250mpbs en las pruebas, pero parece haber mejorado dramáticamente.
  • El ancho de banda de la conexión HTTP puede ser inaceptablemente bajo. 1-2mbps desde incluso nuestro centro de datos suizo con una conexión de 800mpbs y peering de calidad. EDITAR: Recientemente hemos visto las tasas entre nuestro centro de datos y EC2 en el rango 3-4mpbs.
  • S3 no es un sistema de archivos ''normal'' y se requiere un software especial. Elegimos JungleDisk, que ahora considero inapropiado para un entorno de servidores de conjuntos de datos de tamaño mediano las 24 horas, los 7 días de la semana. Cosas extrañas sucederían (archivo enumerado dos veces con un comando ''ls'') y bloqueos inesperados. Use EBS para datos persistentes, aunque eso no está exento de advertencias .
  • S3 no es un CDN. Mi compañía, como muchas otras, ha intentado utilizar Amazon S3 como CDN. Hay otras alternativas de bajo costo por ahí. (Akamai, voxel.net, easycache.com)

Soy un fanático del concepto de nube, y continuaremos ejecutando una instancia de EC2, pero nos pareció inadecuado para nuestras principales necesidades de producción en su forma actual. AWS tiene algunos problemas que resolver.


Descargo de responsabilidad: Sería un estudiante de posgrado en UCSB, que saca el software que estoy a punto de mencionar.

Si le preocupa la propiedad de la nube (p. Ej., No poseer físicamente sus casillas en la nube), es posible que desee ver Eucalyptus . Es compatible con EC2 API y le permite usar sus servidores, y es de código abierto para que pueda ver exactamente lo que está sucediendo.

Pero a la pregunta real, no, no alojamos nuestro sitio web en la nube, aunque ciertamente tenemos muchas ideas para cosas que hacer en él.


Estoy usando S3 para el alojamiento de imágenes (actualmente más de 5 millones de archivos) y para las copias de seguridad del servidor. Utilicé EC2 para el procesamiento de imágenes y SQS para coordinar estas tareas. Debo decir que he eliminado EC2 ya que para esa tarea específica, el servidor no virtualizado demostró ser 10 veces más rápido. Y escribí mi propia solución de colas usando mysql, que resultó ser mucho más rápido y no vinculó estrechamente con AWS.

Hay una publicación importante en Coding Aloud [ http://www.codingaloud.com/2008/01/going-bankrupt-with-amazon-s3.html] llamada Going Bankrupt With Amazon S3, echa un vistazo.


Para su segunda edición, consulte CloudStatus . Supervisa las cosas de AWS y Google App Engine en busca de interrupciones y rendimiento. Amazon también rastrea sus interrupciones en http://status.aws.amazon.com/ .


Un grupo de amigos y yo estamos trabajando en una aplicación que vive en la nube. Sin embargo, la parte de la nube en la que vive está bajo nuestro control. Nunca confío en que un tercero haga ese tipo de levantamiento para mi aplicación, porque no tengo control sobre ella. La reciente interrupción de Amazon S3 es una excelente ilustración de por qué.

Y, absolutamente, positivamente, nunca pondría ninguna parte de mi infraestructura en (por ejemplo) los servidores de Amazon. Los servidores de compilación, el código fuente, etc., siempre están estrechamente controlados. No solo por la posible falta de fiabilidad, sino porque considero que las licencias de estos servicios son excesivamente permisivas para el proveedor del servicio. Además de eso, un host inescrupuloso * podría tomar mi código fuente y usarlo para sus propios fines, incluso si algo como eso no está legalizado por el acuerdo de licencia que tendría que aceptar para usar el servicio.

* Probablemente no se aplica a Amazon, pero nunca he oído hablar de los otros dos que mencionaste, y hasta que estén por alrededor de diez años más o menos, probablemente no confíe en ellos ni en ningún servicio como ellos.


En cuanto a la fiabilidad

No tengo nada ejecutándose en un servicio en la nube, pero me gustaría abordar el problema de confiabilidad.

Estoy seguro de que el equipo de Amazon tiene mucha más experiencia y recursos disponibles para ejecutar un sitio web de trabajo pesado que yo. Estuvieron inactivos durante un par de horas la semana pasada, pero creo que, en general, su tiempo de actividad será mejor que si lo hubiéramos tenido nosotros solos, con nuestro nivel actual de experiencia y recursos.


Actualmente estoy usando S3 para el alojamiento de videos y me encanta. Si usa .NET, concédase un poco de tiempo para integrar la configuración en su sitio. Recomiendo encarecidamente sus servicios.

Lo único que encontré difícil fue que tuviste que gastar> 100 para obtener un nivel de servicio plateado, nuestro sitio lo gastará con el tiempo pero todavía no estamos en versión beta. No tenía una pregunta, solo quería ver cómo era su apoyo.

El soporte fue excelente y muy útil; sin embargo, me hubiera gustado poder hacer algunas preguntas sin tener que ir a buscarme en el bolsillo (mejor dicho, al bolsillo del jefe).

Oh, no me he encontrado con ningún problema de licencia.

Comparativamente, por el dinero, elegiría S3 por encima de otros servicios de hosting porque su alcance es muy amplio y el precio es tan bajo.