​​📊 Get powerful visuals and deep insights to optimize costs on AWS with Cloud Intelligence Dashboards.

https://catalog.workshops.aws/awscid/en-US/dashboards

Foundational

▪️ CUDOS Dashboard
▪️ Cost Intelligence Dashboard
▪️ KPI Dashboard

Advanced

▪️ Compute Optimizer Dashboard
▪️ Trusted Advisor Organizational Dashboard
▪️ Cost Anomaly Dashboard
▪️ Extended Support - Cost Projection
▪️ Graviton Opportunities Dashboard

Additional

▪️ Trends Dashboard
▪️ DataTransfer Cost Analysis Dashboard
▪️ AWS Marketplace Single Pane of Glass Dashboard
▪️ Kubecost Containers Cost Allocation Dashboard
▪️ SCAD Containers Cost Allocation Dashboard

#Cost_Optimization #QuickSight

Интересные цифры по загрузке контейнеров. Получается, что в среднем контейнеры загружены чуть более, чем на половину (17/29=59%).

Однако из-за общего оверпровизионинга кластеров это даёт всего лишь 17% загрузки.

Итого.

Fargate на бумаге на 20-30% дороже EC2.
А на деле — в 2-3 раза выгоднее!

#Fargate #EC2 #cost_optimization

AWS Reserved Instances purchasing recommendations

𝗧𝗟;𝗗𝗥 Use Savings Plans unless you're running a museum of static workloads.

1️⃣ Go for no-upfront payment unless you're enjoy making your CFO cry.

2️⃣ Stick to one-year terms unless you have a crystal ball.

3️⃣ Aim for 80% RI coverage and 100% utilization in your RI utilization report unless you're a premium sponsor of Jeff Bezos' next space adventure.

4️⃣ Workload: Think in aggregates unless you have an unhealthy obsession with individual instances.

5️⃣ Choose Convertible EC2 RIs over Standard RIs unless your workload is more static than a statue.

6️⃣ Leverage RDS instance size and deployment type flexibility unless you have a phobia of change and optimization.

7️⃣ Opt for regional RIs unless you have a compelling reason to lock into a specific Availability Zone.

8️⃣ Steer clear of 3d-party RI management products unless you enjoy paying for features AWS already provides.

9️⃣ Consider RI impact on internal chargeback unless you want to create accounting chaos.

🔟 RI Marketplace: No way.

https://www.duckbillgroup.com/blog/the-duckbill-guide-to-aws-reserved-instances/

What are your best RI money-burning techniques?

#cost_optimization #ReservedInstances

🆕 Invoice Configuration — возможность выставлять счета отдельно по аккаунтам:

https://aws.amazon.com/blogs/aws-cloud-financial-management/configuring-your-aws-invoices-using-invoice-configuration/

Крайне востребованная фича, когда по любой причине нет возможности поднимать окружение у заказчика, а он хочет просто платить за AWS аккаунт, что крутится в нашей AWS Organization. Теперь это можно будет делать без костылей.

#cost_optimization

Custom Billing Views

В дополнение к возможности выставлять инвойс отдельно на какой-то "кусочек" AWS Organizations, теперь можно давать доступ к группе аккаунтов для отдельных команд (или клиентов), владеющих несколькими AWS аккаунтами:

https://aws.amazon.com/blogs/aws-cloud-financial-management/introducing-custom-billing-views-tailored-cost-and-usage-view-relevant-for-your-stakeholders/

То есть, если у вас есть Dev-Test-Stage-Prod аккаунты (а если нет — читайте multi-account best practices), вы теперь можете дать определённому аккаунту доступ к биллингу на эти четыре аккаунта и видеть это в одном месте, а не бегать по каждому аккаунту.

Другая крутая фича, что позволяет custom billing views, это возможность дать какому-то аккаунту доступ чисто к биллингу. Стандартная ситуация — просят помочь разобраться с биллингом, чтобы порезать косты, но сделать это просто так не получается, т.к. для этого приходилось давать доступ в главный Management аккаунт со всеми вытекающими.

Теперь же можно выдать отдельный пустой аккаунт, где не будет ничего, кроме доступа к биллингу всей (или части) организации. Так и безопасники довольны, и косты можно посоветовать, как порезать.

P.S. А порезать можно примерно всегда. Проверено на живых людях. Причём процесс оптимизации даже может быть бесплатным, когда клиент платит % от сэкономленного.

#billing #cost_optimization

Выбор 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