AWS Notes
5.6K subscribers
443 photos
42 videos
10 files
2.8K links
AWS Notes — Amazon Web Services Educational and Information Channel

Chat: https://t.iss.one/aws_notes_chat

Contacts: @apple_rom, https://www.linkedin.com/in/roman-siewko/
Download Telegram
Перетащил на второй гравитрон пару старых кластеров.
Результат пока выглядит ок.
Предыдущие дни график был практически идентичен, а тут, при смене типа инстанса, словно и нагрузка на ЦПУ стала ниже.
Посмотрим как дальше будет это работать.
Экономия ~$73 доллара в месяц за один инстанс(в кластере их несколько).

#AWS #CostOptimization
👍27🔥7
Самая удивительная особенность, которая обнаружилась после перехода RDS(8.0.mysql_aurora.3.08.0) на Gravitron v2, это способность на высокий утилизации CPU не снижать эффективность/производительность.
А я не знаю как это точнее назвать, пусть будет слово эффективность.
Давайте к примерам.

Когда был db.r5.2xlarge, при CPU usage 85-100% длительностью больше 10-15 минут начиналась небольшая, но деградация работы с базой данных.
Из замеченного мной:
- небольшое отставание лага у read реплик
- timeout со стороны приложения к бд(для новых коннекшнов)
- slow query (честно говоря они появлялись примерно после 22-24 минут непрерывного CPU usage 85-100%)
- очереди запросов (самое больное по бизнес аппликейшн, почти везде real-time)
- binary log писался с небольшим лагом(используется для Debezium+Kafka для реалтайма)

Когда переключили на db.r6g.2xlarge при ровно таких же жёстких нагрузках:
- регулярные миграции
- по расписанию какие-то профилактические работы
- онбординг новых очень крупных клиентов (там прям DP-MySQL series в этот момент)
- запуск snowflake
- запуск retool,
база свободно выдерживает 85-100% в течении длительного времени 15-30 минут без снижения эффективности.
Никаких диких таймаутов, никаких слоулогов, даже репликация проходит без лагов.

Какая-то удивительная магия для меня.
Заставляет задуматься и даже скорректировать алёрты на такое поведение.
И да, я не знаю причина тому смена c5->r6 или же невероятная магия ARM у Gravitron.

* К сожалению графики Grafana, графики и логи у NewRelic в качестве доказательств не могу предоставить:
там если замазать, то будет совсем непонятно, а без замазки полный NDA, а потому без картиночек.
Trust me, Neo.


#AWS #CostOptimization
🔥18👍6💯3
Выбор 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
👍31🔥81
Есть база данных AWS RDS(8.0.mysql_aurora.3.08.0) + RDS Proxy.
К базе подключено N клиентов-приложений. Допустим их 10. Все подключены через прокси.

Появилась задача понять "кто из приложений кушает больше всего коннекшнов и отобразить это на графике".

Большее обсервабилити, большая детализация. Больше SRE👏
Однако штатно таких метрик не существует(ну или же я просто не нашёл).
Вариант с лямбдой и
SELECT usename, count(*) 
FROM pg_stat_activity
GROUP BY usename;

Мне показался туповатым.

Я не знаю как это делают правильные инженеры, опишу свой вариант решения, который сделал в выходные.

- создаем в базе данных 10 новых пользователей с нужными правами
- добавляем креды новых юзеров в secret manager
- добавляем аксесс этих юзеров на RDS proxy кредами из secret manager
resource "aws_db_proxy" "this" {
...
auth {
auth_scheme = "SECRETS"
iam_auth = "DISABLED"
client_password_auth_type = "MYSQL_NATIVE_PASSWORD"
secret_arn = aws_secretsmanager_secret.user1_credentials.arn
}
auth {
auth_scheme = "SECRETS"
iam_auth = "DISABLED"
client_password_auth_type = "MYSQL_NATIVE_PASSWORD"
secret_arn = aws_secretsmanager_secret.user2_credentials.arn
}
...
}


- создаем новые rds proxy endpoint для каждого из приложений/юзера
resource "aws_db_proxy_endpoint" "this" {
...
db_proxy_endpoint_name = "${var.project}-${var.environment}-user1"
target_role = "READ_WRITE"
...
}

resource "aws_db_proxy_endpoint" "this" {
...
db_proxy_endpoint_name = "${var.project}-${var.environment}-user2"
target_role = "READ_WRITE"
...
}

- переключаем каждое из приложение на свой собственный RDS proxy endpoint через переменные окружения

Отлично, теперь у нас каждый микросервис подключен к отдельному RDS proxy endpoint с отдельными кредами.
Теперь идём в AWS CloudWatch в Dashboards.
У нас есть метрики и мы их можем смело раскинуть по каждому из RDS proxy Endpoint
- ClientConnections 
- DatabaseConnections
- AvailableConnectionPercent
- ConnectionAttempts
- QueryRequests
- QueryRequestsPerSec

Смело строим графики и видим все интересующие параметры по каждому пользователю/приложению.

Итог:
На выходе у нас дашборд, который показывает массу деталей по конкретно каждому юзеру/приложению, что очень важно понять например кто больше делает нагрузки на БД.

Дополнительно:
- перед реализацией не забывайте про ограничения:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html
- всё тоже самое можно сделать создав несколько RDS proxy для каждого приложения, но и платить придётся сильно больше
- есть вы подключили в своей Grafana datasource=CloudWatch, то он пока не умеет выводить метрики дименшна по endpoint, только по отдельным RDS proxy. Пока красивые графики только в CloudWatch Dashboard.

#AWS #observability #cloudwatch
Please open Telegram to view this post
VIEW IN TELEGRAM
👍262
"хей Алекс, у нас закончилась демо версия Backup radar, теперь они хотят денег. Сможешь сделать аналог на AWS? Но денег и часов на задачу на один час. Нам просто надо ежедневно получать уведомления, что у нас успешно создаются бекапы. Сами снепшоты/бекапы создаются".

Ну один час, так один час.
EventBridge в чистом виде неудобен, я дольше буду читать про типы сорсов и полей, занимаясь фильтрацией.

1) Используем популярный модуль ИЛИ пилим те же ресурсы в чистом терраформе.
Выбор каждого.
- пример с модулем
module "aws-backup-notifications" {
source = "terraform-aws-modules/notify-slack/aws"
version = "6.5.1"
sns_topic_name = "aws-backup-notifications"
recreate_missing_package = false
slack_webhook_url = data.sops_file.sops_file.data.slack-webhook-aws-backup-notifications.url"]
slack_channel = "aws-backup-daily-notifications"
lambda_function_name = "aws-backup-notifications"
slack_username = "AWS Health Event"
}

- пример без модуля будет нечто типа того (в попытке обезличить мог чушь написать, но на то он и пример).
https://gist.github.com/kruchkov-alexandr/e9139d60658175a5a91c186bd7e0f6b3

Ок теперь у нас есть лямбда, роли, пермишны, SNS топик.
При отправке мессаджа в SNS лямбда отправляет сообщение с метаданными в Slack.

2) Теперь нам надо научиться подписываться на события:
# RDS and DocumentDB cluster snapshot events

resource "aws_db_event_subscription" "db_snapshot_events" {
name = "aws-backup-notifications"
sns_topic = "arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-backup-notifications"
source_type = "db-cluster-snapshot"
event_categories = []
source_ids = []
enabled = true
}


Если нам надо ещё и по Redis, то в существующих ресурсах добавить
resource "aws_elasticache_replication_group" "this" {
...
notification_topic_arn = "arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-backup-notifications"
...
}


Ок, делаем вручную снепшот, видим мессаджи в Slack - задача выполнена.

4) Так, сообщение от Redis(ElastiCache) короткое и удобно читать в слаке, а вот через лямбду некрасивое и много лишней метаданных, давайте порежем лямбду...

oh wait, а час и закончился, сдаём как есть🤣.

Кому хочется красоты и лаконичности, тот знает прайс.

5) Не забываем напомнить заказчику не мьютить сразу новый слак канал #aws-backup-daily-notifications 😁

#aws
Please open Telegram to view this post
VIEW IN TELEGRAM
👍123
* для этой задачи для этих условий
Плюсы с модулем:
- 18 строчек кода
Минусы с модулем:
- мессадж гигантский, занимает половину экрана

Плюсы без модуля:
- можно сделать лямбду с минимальным мессаджем в слак
Минусы без модуля:
- ну в час не успеть
- много кода, либо пилить свой модуль

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

Зачем замазывал event id я не знаю🤣

#aws
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
#aws #eks #sqs #CostOptimization
Материал уровня middle.

Снова про экономию.

У нас есть AWS SQS.
В него прилетает миллион вебхуков с полезным и важным payload.
Бывают пики, бывают нет.
У нас есть AWS EKS и приложение в POD-e, который вычитывает SQS, процессит и всё ок.
Нам надо настроить масштабирование не за счёт CPU/memory usage, а за счёт количества сообщений.
В этом нам помогает KEDA. Опустим этапы установки/настройки/прав и авторизации.
У нас есть готовый манифест scaledobject.
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
cooldownPeriod: 300
maxReplicaCount: 50
minReplicaCount: 2
pollingInterval: 30
scaleTargetRef:
name: application
triggers:
- authenticationRef:
name: keda-aws-credentials
metadata:
awsRegion: us-east-1
identityOwner: operator
queueLength: "500"
queueURL: https://sqs.us-east-1.amazonaws.com/123456789/sqsname
type: aws-sqs-queue

Всё работает, всё скейлится, всё ок.
В HPA некрасиво выглядят цифры, хочется видеть точное количество мессаджем. Добавляем metricType
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
...
metricType: Value

И теперь в kubectl get hpa blablabla видим точное количество мессаджей в TARGETS(а не системы счисления инопланетян).
Этого нам мало, нужна точная подстройка.
Читаем дальше доку, у нас есть адвансед настройки.
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
advanced:
horizontalPodAutoscalerConfig:
behavior:
scaleDown:
policies:
- periodSeconds: 15
type: Pods
value: 1
stabilizationWindowSeconds: 300
scaleUp:
policies:
- periodSeconds: 15
type: Pods
value: 1
selectPolicy: Max
stabilizationWindowSeconds: 60
... (остальное так же)

Теперь у нас всё динамически скейлится, прописаны все триггеры, трешхолды.
Всё отлично и бизнес ликует(не вру, прям ликует, сильно помогло).

Однако меня, как рьяного и верного пса девопс церкви, напрягает, что в период высокой нагрузки всё упирается в максимум реплик. Да, можно поставить не 50, а 100, но я думаю, что настройка неверная.
Углубляемся дальше в доку(вру, я ничо не понял и просто спросил ребят-гуру-AWS-технологий в телеге) и вспоминаем про визибл/анвизибл настройки у sqs.
https://keda.sh/docs/2.14/scalers/aws-sqs/
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

Окончательно пилим манифест.
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
advanced:
...(тут тоже самое)
metadata:
...
scaleOnInFlight: "false" << - - вот это вот важное нам
...


Отлично. Теперь самая точная и потрясающая настройка.
👍14
#aws #eks #sqs #CostOptimization

scaleOnInFlight
- Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)

Благодаря точной настройке мы неслабо экономим:
- во время нагрузки мы не скейлим так много реплик
- нет большого лишнего скейла реплик - нет и скейла нод кластера AWS EKS
- нет скейла нод - платим серьёзно меньше

Всего один параметр и в разы снижаем нагрузку и косты.

Прежде чем делать подобное, уточните у девелоперов и бизнеса - подойдёт ли это вам и продукту.
Не все процессинги можно переключить только на инфлайт режим.

Полный пример манифеста(код в телеге неудобно читать).
https://gist.github.com/kruchkov-alexandr/e6328137107e49c6a5e7c05c40851680
👍14🔥1
#aws #aurora #terraform #finops
Материал уровня senior

Мы умеем определять тип инстанса - по нагрузке на CPU/Memory и другим факторам.
Но насколько эффективно мы выбрали Cluster storage configuration Авроры вашего проекта?
Эффективно ли это спустя год или два?
А никто не знает, давайте разбираться.

- сперва пилим Dashboard к нашему существующему кластеру
https://gist.github.com/kruchkov-alexandr/d9335d7927e58d06557b994dc9f194de
- применяем, видим панель в CloudWatch
Сверху у нас панель чтения/записи хранилища, снизу размер базы данных (+снепшоты?).
Разделение нужно из-за разницы масштабов и удобства экспорта.
- выбираем период три месяца и кликаем на трех точках у обоих панелей и выбираем Download as .csv и качаем оба файла
- заходим в cost explorer и экспортируем дату за три месяца по кластеру
- заходим в вашу любимую AI(я спрашивал у клаудии, перплексити и грок3, все платные) и пилим промт нечто типа(можете писать свой, если мой вам кажется тупым):
"Help me decide if we should switch to Amazon Aurora I/O-Optimized. Use the attached billing screenshot/csv, three-month IOPS data from the CSV, and the IOPS/storage graphs to analyze our costs. Calculate our current I/O expenses, compare them to I/O-Optimized costs and check if our I/O costs exceed AWS’s 25% threshold for switching. Look at IOPS and storage trends, then recommend whether to switch, including specific cost figures. I’ve attached all files (billing, CSV, graphs).
based on this article
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/"

- ждём ответа и все 4 нейронки мне выдали на 95% одинаковый подробнейший расчёт ответ. Вкратце "Переходить пока рано".
- пишем менеджеру/боссу
I've analyzed our infrastructure costs over the last three months billing and IOPS data, to see if switching to Amazon Aurora I/O-Optimized makes sense. Right now, it's not cost-effective. Our I/O costs an average of $******* monthly (************ I/Os at $**** per million). Moving to I/O-Optimized would increase instance costs by ***%, from $******* to $******* - a $******* jump, which is $415.21 more than our current I/O expenses.
Our IOPS trends show peaks up to *** but no major growth, averaging ~** Write and ~**** Read IOPS hourly in February. Storage usage is growing at *** GB/month, but that doesn't impact the I/O-Optimized cost comparison.
AWS suggests I/O-Optimized when I/O costs exceed **% of total Aurora spend, but ours ($******) are only **% of the $******* total, so we're below that threshold.
I recommend sticking with our standard configuration for now. We should keep monitoring I/O activity -if it exceeds **** I/Os monthly or I/O costs reach **% of our Aurora spend, we can revisit I/O-Optimized.

Прикладываем все файлы,скрины,расчёты.
- закрываем таску и трекаем время

Всё вышеописанное заняло у меня минут 15, а вот подготовительные работы(чтение про фичу, особенности, лимиты, как считать, написание борды, особенности биллинга и тп) почти половину дня.
* Если не верите ИИ, можете пересчитать вручную🐒

Дополнительные полезные ссылки(а вдруг вы мне не верите):
- анонс фичи
https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-aurora-i-o-optimized/
- обзор менеджер уровня
https://aws.amazon.com/awstv/watch/b9bfc040ac5/
- пример расчётов (там руками считают, без ИИ)
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍3🤔21👏1
#aws #rds
Короткий материал на уровне senior+

Нырни на самое дно. Без страховки.

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

Традиционные параметры типа CPU/memory usage, connections, memory usage, latency, IOPS, lags, cache, CRUD throughput, slow logs и прочее мы научились мониторить и алёртить, что заставило нас оптимизировать запросы к бд и серьёзно снизило нагрузку.

Совсем недавно мы нырнули глубже и поменяли пару параметров в ущерб потери 1 секунды данных в случае аутейджа со стороны Амазон.
Данный проект не использует критически важные операции для транзакций типа финансовых операций, так что мы имеем право это включить. Если у вас финансовые операции или любые критичные операции вам НЕЛЬЗЯ это включать. Нельзя и запомните это.

innodb_flush_log_at_trx_commit
Значение 2 означает, что журнал транзакций (redo log) записывается в буфер операционной системы при каждой фиксации (commit), но сброс на диск происходит только раз в секунду
- Улучшает производительность, так как уменьшает операции ввода-вывода диска
- Снижает надежность: возможна потеря транзакций последней секунды при сбое сервера/ОС
- Компромисс между производительностью (выше) и надежностью (ниже) по сравнению со значением 1

innodb_trx_commit_allow_data_loss
Значение 1 означает, что система разрешает возможную потерю данных для увеличения производительности
- Значительно ускоряет операции фиксации транзакций
- Снижает гарантии сохранности данных
- Может привести к потере транзакций при сбоях

Результат дал о себе знать почти сразу, но нам явно придётся ещё несколько раз нырять для более точного тюнинга. Будем наблюдать и изменять под себя.

DevOps это не всегда общение, ямлоделие, пайплайны и кубер.
Иногда это тюнинг БД, когда все остальные элементы уже исчерпаны или нет на это бюджета(выше тип инстанса, gravitron v4, больше read реплик, RDS proxy, queries tuning etc).

Ну и код для примера:
resource "aws_rds_cluster_parameter_group" "this" {
...
parameter {
apply_method = "immediate"
name = "innodb_flush_log_at_trx_commit"
value = "2"
}
parameter {
apply_method = "immediate"
name = "innodb_trx_commit_allow_data_loss"
value = "1"
}
}
🔥20👍43
Новый будущий AWS Region — Чили:

https://aws.amazon.com/blogs/aws/coming-soon-aws-south-america-chile-region/

Регион планируется к открытию в конце 2026-го года.

На момент официального анонса AWS строит следующие новые регионы:

▫️ Германия (AWS European Sovereign Cloud)
▫️ Новая Зеландия (обещали в 2024-м)
▫️ Саудовская Аравия (в 2026-м)
▫️ Тайвань (обещали в начале 2025-го)
▫️ Чили

#AWS_Regions
👍15🔥42
#aws #tampermonkey

Мне очень нравятся shortcuts сервисов AWS.
Однако очень бесит, что они стали длинные и мне не очень удобно "листать" вправо/влево в избранном или вводить в строке поиска.
Хочется короткий текст для линков для быстрого перемещения.
Мог поправить через динамику, но у AWS очень строгий CSP.
Давайте попробуем фиксануть без CSP.

Я уже не в первый писал про плагин для браузера tampermonkey.
- ставим, если ещё нет https://www.tampermonkey.net/
- добавляем и включаем новый скрипт
- код крадём у меня и кастомизируйте под себя https://gist.github.com/kruchkov-alexandr/525a5166b7a55e2982b1015ba77a3456 (строчки 12-47)
- сохраняем скрипт
- обновляем страницу с AWS console
- радуемся мелким приятностям (скрин)

Переименование только в шапке и только на https://*.console.aws.amazon.com/*.
Всё остальное это не аффектит.
👍155👎2🔥2
AWS Notes
​​AWS-EU — новая будущая отдельная часть AWS European Sovereign Cloud и новый будущий AWS-EU регион в Германии: https://aws.amazon.com/blogs/aws/in-the-works-aws-european-sovereign-cloud/ AWS-EU будет физически располагаться только на территории Евросоюза…
AWS European Sovereign Cloud

https://aws.eu/

Европейский AWS будет иметь свой отдельный IAM, Route 53, CloudFront и другие привычно глобальные ресурсы, которые обычно живут в единственном регионе N.Virginia.

По реализации повторит вариант китайского AWS и AWS GovCloud.

Пока всё ещё в планах сдать первый регион в Германии до конца 2025 года.

#AWS_Regions #AWS_EU_Regions
🔥17😁2
Начиная с версии AWS CLI v2.30.3 можно генерить/обновлять креды для IAM юзеров с MFA без сторонних утилит с помощью команды:

aws configure mfa-login

Для удобства лучше сразу добавить имя генерируемого профиля с помощью --update-profile , иначе сгенерит автоматически, а также --duration-seconds , максимум на 36 часов и ARN устройства --serial-number, чтобы не вводить отдельно:

# aws --profile=aws-notes-s3-user configure mfa-login --update-profile=mfa-aws-notes-s3-user --duration-seconds=129600 --serial-number=arn:aws:iam::984475386489:mfa/My-iPhone

MFA token code: 969969
Temporary credentials written to profile 'mfa-aws-notes-s3-user'
Credentials will expire at 2025-09-18T19:50:40+00:00
To use these credentials, specify --profile mfa-
aws-notes-s3-user when running AWS CLI commands


# aws --profile mfa-aws-notes-s3-user s3 ls

2018-11-18 16:17:32 aws-notes-test


p.s. IAM юзеры зло — используйте SSO (IAM Identity Center).

#aws_cli
👍14💯2
Вы хотите как было 20 октября 2025-го?

Нет?

Тогда срочно мигрируйте на AWS European Sovereign Cloud — полностью независимый от остального AWS, новый eusc регион!

#реклама #AWS_EU_Regions
🤣45😁15🤡53