marzo 7, 2025|10:14 AM
Ya sea operaciones de TI, migración a la nube o innovación impulsada por IA – exploremos cómo podemos ayudarte a tener éxito.
Con el lanzamiento de la región eu-north-1 de AWS Estocolmo, quería echar un vistazo rápido a los precios. Ha habido rumores de que la región de Estocolmo tendría un precio más bajo que muchas otras, así que comparemos.
He comparado Estocolmo con N. Virginia, Fráncfort e Irlanda con EC2, Aurora, S3 y DynamoDB. A continuación se indican los precios de cada una por región y la diferencia con respecto a Estocolmo.
Comparación de precios de AWS
Precios de las instancias AWS EC2
AWS Región UE (Estocolmo) – m5.2xlarge 0,408 $ por hora
AWS US Este (N. Virginia) – m5.2xgrande 0,384 $/hora -6
AWS EU (Fráncfort) – m5.2xlarge 0,46 $ por hora +13
AWS EU (Irlanda) – m5.2xlarge 0,428 $ por hora +5
AWS Precios de Amazon Aurora
(Ten en cuenta que comparo r5 con r4)
AWS EU (Estocolmo) – db.r5.2xlarge 1,20 $ por hora
AWS US East (N. Virginia)- db.r4.2xlarge 1,16 $ por hora -3
UE (Fráncfort)- db.r4.2xlarge 1,40 $ por hora +17
UE (Irlanda) – db.r4.2xlarge 1,28 $ por hora +7%.
AWS Precios del almacenamiento estándar de Amazon S3
UE (Estocolmo) – Primeros 50 TB / Mes 0,023 $ por GB
US Este (N. Virginia) – Primeros 50 TB / Mes 0,023 $ por GB
UE (Fráncfort) – Primeros 50 TB / mes 0,0245 $ por GB +7%.
UE (Irlanda) – Primeros 50 TB / Mes 0,023 $ por GB
AWS Amazon DynamoDB Precios bajo demanda
UE (Estocolmo) – Unidades de solicitud de escritura 1,343 $ por millón de unidades de solicitud de escritura
EE.UU. Este (N. Virginia) – Unidades de solicitud de escritura 1,25 $ por millón de unidades de solicitud de escritura -7
UE (Fráncfort) – Unidades de solicitud de escritura 1,525 $ por millón de unidades de solicitud de escritura +14%
UE (Irlanda) – Unidades de solicitud de escritura 1,414 $ por millón de unidades de solicitud de escritura +5
Aunque todo esto empezó con la inyección de latencia, como en los artículos de Yan Cui, la latencia está lejos de ser el único fallo posible que podemos tener en nuestras aplicaciones sin servidor. En fallo-lambda, fallo-azurefunctions y fallo-cloudfunctions hay ahora cinco modos de fallo diferentes entre los que elegir:
Inyecta latencia a la función ejecutada, controlada mediante un intervalo mínimo y máximo de milisegundos. Esto puede utilizarse, por ejemplo, para simular la latencia del servicio o para probar y ayudar a establecer tus valores de tiempo de espera.
Lanza una excepción en la función. Te ayuda a probar cómo tu aplicación y tu código gestionan las excepciones.
Tu función devolverá un código de estado a elegir, por ejemplo 502 o 404 en lugar del normal 200. Esto te da la posibilidad de probar qué ocurre cuando hay errores.
Llenará tu disco temporal de archivos para crear un fallo. Si utilizas un disco para almacenar archivos temporales, puedes probar cómo se comporta tu aplicación si ese disco se llena o no puedes almacenar en él.
Bloquea las conexiones a los hosts especificados. Utilízalo para simular que los servicios o terceros no están disponibles.
Todos estos modos de fallo pueden utilizarse junto con un índice de fallo que tú establezcas. Por defecto, se inyecta un fallo en cada invocación, pero en realidad, es probable que, por ejemplo, un tercero no esté disponible en el 50% de las llamadas realizadas a ese host o que se lance una excepción en una cuarta parte de las invocaciones. Fijar la tasa te permitirá conseguirlo.
