Cost Optimization для Serverless проектов:

https://blog.ecrazytechnologies.com/optimize-with-aws-cost-explorer

#serverless #cost_optimization

Очистка S3 multipart uploads:

https://aws.amazon.com/blogs/aws-cost-management/discovering-and-deleting-incomplete-multipart-uploads-to-lower-amazon-s3-costs/

If the complete multipart upload request isn’t sent successfully, Amazon S3 will not assemble the parts and will not create any object. The parts remain in your Amazon S3 account until the multipart upload completes or is aborted, and you pay for the parts that are stored in Amazon S3.

#S3 #cost_optimization

​​Если настраиваете S3 Lifecycle configuration rules для того, чтобы объекты переезжали в Glacier и Glacier Deep Archive, то стоит учесть допиздержки:

▪️ For each object archived to S3 Glacier or S3 Glacier Deep Archive, Amazon S3 uses 8 KB of storage for the name of the object and other metadata. Amazon S3 stores this metadata so that you can get a real-time list of your archived objects by using the Amazon S3 API. For more information, see Get Bucket (List Objects). You are charged Amazon S3 Standard rates for this additional storage.
▪️ For each object that is archived to S3 Glacier or S3 Glacier Deep Archive, Amazon S3 adds 32 KB of storage for index and related metadata. This extra data is necessary to identify and restore your object. You are charged S3 Glacier or S3 Glacier Deep Archive rates for this additional storage.

Это значит, что для мелких файлов - (меньше 10KB для Glacier Deep Archive и 16 для Glacier Deep Archive) стоимость файла на "обычном" S3 получается дешевле (и это не считая ещё траты за Lifecycle Transition requests).

В том числе поэтому S3 Intelligent-Tiering не работает с объектами меньше 128 KB:

The S3 Intelligent-Tiering storage class is suitable for objects larger than 128 KB that you plan to store for at least 30 days. If the size of an object is less than 128 KB, it is not eligible for auto-tiering.

#S3 #cost_optimization

Выбор между Aurora и Aurora Serverless v2:

https://medium.com/trackit/aurora-or-aurora-serverless-v2-which-is-more-cost-effective-bcd12e172dcf

#Aurora #cost_optimization

Всегда актуальные пояснения, как формируется (почему так много !?!😀) стоимость трафика в AWS:

https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/

▪️ Avoid routing traffic over the internet when connecting to AWS services from within AWS by using VPC endpoints:
▫️ VPC gateway endpoints allow communication to Amazon S3 and Amazon DynamoDB without incurring data transfer charges.
▫️ VPC interface endpoints are available for some AWS services. This type of endpoint incurs hourly service charges and data transfer charges.
▪️ Use Direct Connect instead of the internet for sending data to on-premises networks.
▪️ Traffic that crosses an Availability Zone boundary typically incurs a data transfer charge. Use resources from the local Availability Zone whenever possible.
▪️ Traffic that crosses a Regional boundary will typically incur a data transfer charge. Avoid cross-Region data transfer unless your business case requires it.

#EC2 #cost_optimization

​​Сравнение производительности Lambda-x86 vs Lambda-arm64:

https://blog.thundra.io/a-performance-perspective-for-graviton-based-lambda-functions

In conclusion, we can see the benefit of AWS Graviton2 for both price and performance. 

#Lambda #cost_optimization

Как посчитать расходы на передачу данных для RDS, DynamoDB, Redshift и DocumentDB:

https://aws.amazon.com/blogs/architecture/exploring-data-transfer-costs-for-aws-managed-databases/

This blog post is intended to help you make informed decisions for designing your workload using managed databases in AWS. Note that service charges and charges related to network topology, such as AWS Transit Gateway, VPC Peering, and AWS Direct Connect, are out of scope for this blog but should be carefully considered when designing any architecture.

#cost_optimization

DynamoDB Standard-IA:

https://aws.amazon.com/blogs/aws/new-dynamodb-table-class-save-up-to-60-in-your-dynamodb-costs/

Отличная возможность сэкономить в два с половиной раза на стоимости редко используемых объёмных таблиц DynamoDB.

Важно отметить, что данный тариф для большого объёма данных, ибо на малых и часто востребованных данных можно лишь потерять, т.к. запросы записи-чтения дороже, а первые 25 ГБ не бесплатны для нового тарифа Standard-IA.

DynamoDB Standard table class
▪️ First 25 GB stored per month is free using the DynamoDB Standard table class
▪️ $0.25 per GB-month thereafter

DynamoDB Standard-Infrequent Access (DynamoDB Standard-IA) table class
▪️ $0.10 per GB-month

#DynamoDB #cost_optimization

aws-amicleaner — a cost-saving tool for deleting unused AMIs and EBS snapshots.

https://github.com/widdix/aws-amicleaner

#EC2 #AMI #cost_optimization

​​📊 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