Forwarded from Make. Build. Break. Reflect.
#aws #aurora #terraform #finops
Материал уровня senior
Мы умеем определять тип инстанса - по нагрузке на CPU/Memory и другим факторам.
Но насколько эффективно мы выбрали
Эффективно ли это спустя год или два?
А никто не знает, давайте разбираться.
- сперва пилим Dashboard к нашему существующему кластеру
https://gist.github.com/kruchkov-alexandr/d9335d7927e58d06557b994dc9f194de
- применяем, видим панель в CloudWatch
Сверху у нас панель чтения/записи хранилища, снизу размер базы данных (+снепшоты?).
Разделение нужно из-за разницы масштабов и удобства экспорта.
- выбираем период три месяца и кликаем на трех точках у обоих панелей и выбираем
- заходим в 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/
Материал уровня 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🤔2❤1👏1
Forwarded from Make. Build. Break. Reflect.
#aws #rds
Короткий материал на уровне senior+
Нырни на самое дно. Без страховки.
Иногда, когда проект достиг своего максимума на данный момент, приходится оптимизировать уже не софт и не пайплайны, а саму инфраструктуру.
Например параметры движка или базу.
Так и вышло в этот раз.
Традиционные параметры типа CPU/memory usage, connections, memory usage, latency, IOPS, lags, cache, CRUD throughput, slow logs и прочее мы научились мониторить и алёртить, что заставило нас оптимизировать запросы к бд и серьёзно снизило нагрузку.
Совсем недавно мы нырнули глубже и поменяли пару параметров в ущерб потери 1 секунды данных в случае аутейджа со стороны Амазон.
Данный проект не использует критически важные операции для транзакций типа финансовых операций, так что мы имеем право это включить. Если у вас финансовые операции или любые критичные операции вам НЕЛЬЗЯ это включать. Нельзя и запомните это.
Значение 2 означает, что журнал транзакций (redo log) записывается в буфер операционной системы при каждой фиксации (commit), но сброс на диск происходит только раз в секунду
- Улучшает производительность, так как уменьшает операции ввода-вывода диска
- Снижает надежность: возможна потеря транзакций последней секунды при сбое сервера/ОС
- Компромисс между производительностью (выше) и надежностью (ниже) по сравнению со значением 1
Значение 1 означает, что система разрешает возможную потерю данных для увеличения производительности
- Значительно ускоряет операции фиксации транзакций
- Снижает гарантии сохранности данных
- Может привести к потере транзакций при сбоях
Результат дал о себе знать почти сразу, но нам явно придётся ещё несколько раз нырять для более точного тюнинга. Будем наблюдать и изменять под себя.
DevOps это не всегда общение, ямлоделие, пайплайны и кубер.
Иногда это тюнинг БД, когда все остальные элементы уже исчерпаны или нет на это бюджета(выше тип инстанса, gravitron v4, больше read реплик, RDS proxy, queries tuning etc).
Ну и код для примера:
Короткий материал на уровне 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👍4❤3
Новый будущий 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
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🔥4❤2
Новый AWS Region — Тайвань: 🎉
https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-taipei-region/
Идентификатор
✅ Итого на теперь всего — 37 регионов.
#AWS_Regions
https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-taipei-region/
Идентификатор
ap-east-2, имеет 3 AZ.✅ Итого на теперь всего — 37 регионов.
#AWS_Regions
Amazon
Now open – AWS Asia Pacific (Taipei) Region | Amazon Web Services
Today, Amazon Web Services (AWS) announced that AWS Asia Pacific (Taipei) Region is generally available with three Availability Zones and Region code ap-east-2. The new Region brings AWS infrastructure and services closer to customers in Taiwan. Skyline of…
🔥19❤7😁1👌1
Forwarded from Make. Build. Break. Reflect.
#aws #tampermonkey
Мне очень нравятся shortcuts сервисов AWS.
Однако очень бесит, что они стали длинные и мне не очень удобно "листать" вправо/влево в избранном или вводить в строке поиска.
Хочется короткий текст для линков для быстрого перемещения.
Мог поправить через динамику, но у AWS очень строгий CSP.
Давайте попробуем фиксануть без CSP.
Я уже не в первый писал про плагин для браузера
- ставим, если ещё нет https://www.tampermonkey.net/
- добавляем и включаем новый скрипт
- код крадём у меня и кастомизируйте под себя https://gist.github.com/kruchkov-alexandr/525a5166b7a55e2982b1015ba77a3456 (строчки 12-47)
- сохраняем скрипт
- обновляем страницу с AWS console
- радуемся мелким приятностям (скрин)
Переименование только в шапке и только на https://*.console.aws.amazon.com/*.
Всё остальное это не аффектит.
Мне очень нравятся 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/*.
Всё остальное это не аффектит.
👍15❤5👎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 и другие привычно глобальные ресурсы, которые обычно живут в единственном регионе
По реализации повторит вариант китайского AWS и AWS GovCloud.
Пока всё ещё в планах сдать первый регион в Германии до конца 2025 года.
#AWS_Regions #AWS_EU_Regions
https://aws.eu/
Европейский AWS будет иметь свой отдельный IAM, Route 53, CloudFront и другие привычно глобальные ресурсы, которые обычно живут в единственном регионе
N.Virginia.По реализации повторит вариант китайского AWS и AWS GovCloud.
Пока всё ещё в планах сдать первый регион в Германии до конца 2025 года.
#AWS_Regions #AWS_EU_Regions
Amazon
AWS GovCloud (US) - Amazon Web Services
Amazon's cloud regions designed to host sensitive data, regulated workloads, and address the most stringent U.S. government security and compliance requirements. AWS GovCloud (US) is available to vetted government customers and organizations in government…
🔥17😁2
Новый AWS Region — Новая Зеландия: 🎉
https://aws.amazon.com/pt/blogs/aws/now-open-aws-asia-pacific-new-zealand-region/
Идентификатор
✅ Итого на теперь всего — 38 регионов.
#AWS_Regions
https://aws.amazon.com/pt/blogs/aws/now-open-aws-asia-pacific-new-zealand-region/
Идентификатор
ap-southeast-6, имеет 3 AZ.✅ Итого на теперь всего — 38 регионов.
#AWS_Regions
Amazon
Now Open — AWS Asia Pacific (New Zealand) Region | Amazon Web Services
AWS has launched its first New Zealand Region with three Availability Zones, marking its 16th Region in Asia Pacific and enabling local data residency for New Zealand organizations.
🔥22😱3🐳3❤1
Начиная с версии AWS CLI v2.30.3 можно генерить/обновлять креды для IAM юзеров с MFA без сторонних утилит с помощью команды:
aws configure mfa-login
Для удобства лучше сразу добавить имя генерируемого профиля с помощью
#
#
p.s. IAM юзеры зло — используйте SSO (IAM Identity Center).
#aws_cli
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-iPhoneMFA 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 ls2018-11-18 16:17:32 aws-notes-test
p.s. IAM юзеры зло — используйте SSO (IAM Identity Center).
#aws_cli
GitHub
aws-cli/CHANGELOG.rst at v2 · aws/aws-cli
Universal Command Line Interface for Amazon Web Services - aws/aws-cli
👍14💯2
Roman Siewko
AWS European Sovereign Cloud https://aws.eu/ Европейский AWS будет иметь свой отдельный IAM, Route 53, CloudFront и другие привычно глобальные ресурсы, которые обычно живут в единственном регионе N.Virginia. По реализации повторит вариант китайского AWS…
Вышел официальный документ, описывающий AWS European Sovereign Cloud:
https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/introduction.html
Значит можно предположить, что откроют ещё до re:Invent 2025.
#AWS_EU_Regions
https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/introduction.html
Значит можно предположить, что откроют ещё до re:Invent 2025.
#AWS_EU_Regions
Amazon
Introduction - Overview of the AWS European Sovereign Cloud
In November 2022, AWS introduced the AWS Digital Sovereignty Pledge, our commitment to offering all AWS customers the most advanced set of sovereignty controls and features available in the cloud. The AWS European Sovereign Cloud is a direct result of that…
🔥3👏1
Поздравляем Виктора Ведмича с новой должностью! 🎉
Теперь он ,больше не Developer Advocate, аDeveloper Prosecutor Senior Solutions Architect (AWS).
Теперь он ,больше не Developer Advocate, а
Linkedin
#dayone #aws #solutionsarchitect #cloud #kubernetes #generativeai #awscommunity | Viktor Vedmich | 237 comments
I’m happy to share that I’m starting a new position as Senior Solutions Architect at Amazon Web Services (AWS)! Day One (again). New role. New chapter.
Today I’m starting as a Senior Solutions Architect at AWS.
For the past four years I was building and…
Today I’m starting as a Senior Solutions Architect at AWS.
For the past four years I was building and…
👍46🔥24🍾8❤5💩5🎉3🦄3😁2
Вы хотите как было 20 октября 2025-го?
Нет?
Тогда срочно мигрируйте на AWS European Sovereign Cloud — полностью независимый от остального AWS, новый
#реклама #AWS_EU_Regions
Нет?
Тогда срочно мигрируйте на AWS European Sovereign Cloud — полностью независимый от остального AWS, новый
eusc регион!#реклама #AWS_EU_Regions
🤣45😁15🤡5❤3