Выбор AWS региона в Европе

В Stockholm eu-north-1 завезли Graviton 4 C8g инстансы. Как обычно, самые дешёвые в Европе.

https://aws.amazon.com/about-aws/whats-new/2025/01/amazon-ec2-c8g-instances-aws-europe-stockholm

Теперь в Европе уже целый набор регионов и если у вас проект для EU, то не всегда очевидно, что ж выбрать. Понятно, что если только одна страна и/или требования хранить данные локально, то тут понятно, где нужно, тот и регион. Но если просто EU/UK или вообще Европа? Вот некоторые критерии.

Исторически самый первый регион — Ireland. Многие по привычке считают, что это самый дешёвый и что там больше всего разных типов виртуалок. Уже нет. Для старых ещё актуально, для новых нет.

Самый дешёвый регион (речь про EC2) — Stockholm. Дешевле самого дорогого Frankfurt eu-central-1 на 10-15%. Однако несмотря на цену, Frankfurt очень важный (особенно по части сети и локальных зон) и, скажем так, "передовой" регион, куда и сервисы завозят быстрее и виртуалки новые.

Второй по дешевизне (чуть-чуть дешевле Ireland или столько же) и при этом наличии современных типов виртуалок — Spain eu-south-2.

Эти четыре региона — Ireland, Frankfurt, Stockholm, Spain рекомендую рассматривать в первую очередь при прочих равных.

#AWS_Regions #EC2 #cost_optimization

Банально и эффективно — остановка EC2 инстансов по расписанию:

https://aws.amazon.com/blogs/publicsector/reduce-it-costs-by-implementing-automatic-shutdown-for-amazon-ec2-instances/

#EC2 #cost_optimization

ECR to ECR pull through cache

Вместо репликации для мульти-аккаунт/мульти-регионов, теперь можно включить кэширование:

https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html

То есть первый раз качается образ из другого региона, после используется лишь кэш из текущего.

Отличная замена предыдущим костылям на синхронизацию плюс экономия на стоимости (когда приходилось всё дублировать).

#ECR #cost_optimization

MCP сервер для Cost Explorer:

https://github.com/aarora79/aws-cost-explorer-mcp-server

Даёт доступ Claude к Cost Explorer, что позволяет запрашивать и рисовать все расходы с помощью обычных текстовых запросов. Опционально также есть возможность подключения расходов на Bedrock.

По умолчанию работает локально, но можно запустить и в качестве виртуалки на AWS, чтобы использовать роль для доступа.

#MCP #cost_optimization

Intel vs AMD vs Graviton: Performance & Price

https://www.youtube.com/watch?v=kV6YizoFuPU

TL;DR:

▫️ Graviton is the best
▫️ AMD is the fastest
▫️ Intel is Intel

#cost_optimization

🎈 RDS Extended Support или обладателям RDS PostgreSQL 11 и PostgreSQL 12 в 2025-м году посвящается.

Вдруг вы заходите раз в год в старые проекты. Радуетесь, что у вас не EKS и делать там особо нечего — работает себе и работает.

Однако стоит обратить на колонку стоимости за базу данных. За этот год счастливые обладатели PostgreSQL 12 обнаружат, что вместо привычных 50$/мес. за смешную db.t3.medium набегает как за "взрослую" — 200$/мес.

Ещё более счастливые обладатели PostgreSQL 11 (не) заметили это ещё в прошлом году. А вам только сейчас (не) повезло.

https://aws.amazon.com/rds/postgresql/pricing/

RDS Extended Support начал действовать в 2024-м году и его действие аналогично тому, как это действует для EKS — старые версии PostgreSQL и MySQL будут дополнительно взимать существенную дополнительную плату.

В результате получается в разы больше обычного счета за поддержку старых версий баз данных.

Пока это касается лишь только PostgreSQL и MySQL баз данных.

Кому приготовиться?

Обладателям PostgreSQL 13 осталось мучаться полгода и их ожидает такое же счастье.

https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html

Не менее счастливые обладатели MySQL 5.7 тоже уже второй год зарабатывают на значок почётного спонсора AWS, а в следующем году к ним присоединятся и обладатели MySQL 8.0. Дополнительный повод переехать на MariaDB, у которой нет таких проблем (RDS Extended Support к ней не применяется).

#RDS #cost_optimization

CloudFront + Flat-rate pricing plans 🎉

https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-flat-rate-pricing-plans-with-no-overages/

Теперь можно выбрать фиксированную цену 0/15$/200$/1000$/+ для нужного CloudFront. Выбирается конкретный CloudFront, поэтому можно иметь и "обычный" и фиксированный план для разных дистрибуций.

https://aws.amazon.com/cloudfront/pricing/

Свыше лимита запросы будут тротлиться, а не биллиться.

Дистрибуций с бесплатным фиксированным планом можно иметь лишь 3 на аккаунт.

В общем это реально крутой вариант, когда можно получить гарантию, что ты не получишь сюрприз в биллинге, если тебя вдруг задидосят.

⚠️ Фиксированная цена неприменима в случае использования Lambda@Edge и некоторых других специфичных фич:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html#pricing-plan-unsupported-features

#CloudFront #cost_optimization