#aws #devops #longread #longstory #msk #apigateway #cloudfront

Суббота, отличная погода и великолепное настроение - идеальный момент для меня, чтобы написать новую историю.

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

https://telegra.ph/My-maiden-magnum-opus-08-01

#aws #costoptimization #devops

А иногда вообще ничего из существующих финансовых алертов не помогает.
Нужен глубокий, живой человеческий анализ.

Был случай: проект, всё на AWS, стартап.
Постепенно рос, изменялся, но изначально у всех всюду был root-доступ (а как иначе в стартапе из 4 человек?). Набирались люди, улучшались процессы, разграничивались доступы, всё заносилось в IaC.
В целом стоимость услуг AWS была сравнительно небольшой, от 2к до 5к долларов, и держалась года полтора-два.
Раунд за раундом, компания выросла, трафика и сервиса стало больше, увеличился и счет.
Затем начали оптимизировать затраты: внедрили RI, SP (Reserved Instances, Savings Plans) и другие методы.
Обвешали обычным алертингом и FinOps-инструментами вроде Cost Anomaly Detection.
Каждые 1-3 месяца проводились Cost Review meetings, на которых обсуждались траты, предстоящий рост и многое другое. Каждая, повторюсь, позиция в биллинге детально разбиралась и для каждого участника команды и руководителя была очевидна, понятна и разумна.

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

Каждый месяц счет всё рос и рос. Где-то разумно за Compute - воркеры в EKS, где увеличилось количество реплик.
Где-то за RDS, потому как и размер БД увеличивается, и инстансы примерно раз в полгода-год увеличивали, да бэкапы (snapshots) также увеличивают стоимость хранения.
Где-то CloudFront, потому как количество клиентов и трафика стало больше.

Приходили и письма от Cost Anomaly Detection: "сервис А увеличился на 20% - теперь 21 доллар", "сервис Б увеличился на 47% и теперь 11 долларов".
И такие письма приходили регулярно.
Визуально - всё разумно и понятно:
- увеличивается количество кастомеров
- увеличивается трафик и нагрузка
- немного растет стоимость услуг

Однако пришел момент, когда счет за услуги CloudFront вырос до умопомрачительной отметки в 1000 долларов в месяц.
На очередном Cost meeting поставили задачу проверить корректность настроек, везде ли правильно включено кэширование, заголовки и так далее.
Триггернулись лишь потому, что на старте компании платили порядка 30 баксов, спустя год 150, затем 400 через два года, а тут сразу $1000 - слишком большой скачок.

Задачу поручили мне, и я начал копать.
Признаюсь - я ничего на тот момент не понял.
Ну ALB, CloudFront да API Gateway.
Много ресурсов, разные.
Поверхностно изучил еще раз - да, вроде очевиден рост как клиентов, так и трафика и биллинга.
Отписался "да всё норм", закрываю таску.

Спустя месяц счет стал уже 1250 долларов, и это напрягло всех.
Руководство попросило сделать анализ: как тут можно сэкономить, ведь ожидали рост клиентов x20, а это значит, что потенциально счет будет невероятно огромным.
Требовалось исследование альтернативных архитектурных решений.

Начал я повторно изучать, уже в процессе расписывая куда какой трафик идет, спрашивая разработчиков, смотря DNS, балансировщик, все файлы веб-страницы и многое другое.
Я это изучал лишь чтобы понять, как сейчас что работает, чтобы понять, как и на что мне надо заменить, чтобы снизить косты.

В процессе анализа для переноса архитектуры мне пришел неожиданный вопрос в голову:
а счет за CloudFront это с одного Distribution или с разных?
Начал включать аналитику и овервью.
Определились, что траты лишь с двух Distribution из 25.
Вопреки тому, что все думали изначально, что с 10-15.

Ок, копаю дальше, стало интересно, ведь именно у этих двух Distribution было несколько источников (Origins) и несколько правил поведения (Behaviors).
Мне же надо их на что-то менять, надо копнуть глубже.

#kubernetes #devops

Последнюю неделю на работе игрался с KRO, AWS ACK и CrossPlane.
- https://github.com/crossplane/crossplane
- https://github.com/aws-controllers-k8s/community
- https://github.com/kubernetes-sigs/kro

Ну что я могу сказать.
Мне одновременно и очень понравилось - инструменты хороши.
Это потрясающие инструменты, выводящие инфраструктурную часть и операционную на совершенно иной уровень.
Не плохой, не хороший, он новый. Не буду приводить аналогий, это просто иной уровень для меня.
Да охрененный, если честно, буду честен.
И одновременно не понравилось - самостоятельно, в одиночку, в одно лицо, без помощи AI ассистентов я разобрался бы в лучшем случае через недели 3-4. Возможно бы и через месяц.

Сложность в том, что эти инструменты создают десятки уровней абстракций - от CRD в Kubernetes до специфических API провайдеров (AWS, GCP). Чтобы отладить ошибку, нужно пройти путь от kubectl describe до логов ACK controller, а потом до настоящего события в облаке. Рисуешь сперва диаграммы, зависимости, порядки деплоя - это колоссальная работа.

Вообще прикольно, конечно, один манифест и фигак, у тебя целые регионы, кластера, роли, рут таблицы, натгейтвеи и миллион сущностей в кубернетисах. Миллионы объектов и сущностей на сотнях уровней абстракций.
Круто. Мне понравилось.

Про KRO/ACK/CrossPlane я ещё напишу не одну глубокую техническую заметку/отзыв, а пока лишь общий отзыв - они хороши.

#devops #security #nginx #tls #privacy

Тихо и незаметно (для меня) NGINX 1.29.4 официально добавил поддержку Encrypted Client Hello (ECH).
Для инженеров, которые следят за приватностью трафика, это важная новость.

Что такое ECH и почему это важно.
ECH - расширение TLS 1.3, которое шифрует полностью весь ClientHello, включая Server Name Indication (SNI).
Раньше SNI передавался открытым текстом: любой наблюдатель на сети видел, к какому домену вы коннектитесь, даже если содержимое соединения зашифровано. ECH устраняет этот пробел.

ECH использует два ClientHello:
- ClientHelloOuter - видимый, с "dummy" SNI
- ClientHelloInner - зашифрованный, с реальным SNI и другими параметрами

Шифрование происходит через HPKE (Hybrid Public Key Encryption).
Если сервер не может расшифровать inner, он завершает handshake с outer и сообщает клиенту актуальный ключ для повторной попытки.

Важные требования:
- DNS-over-HTTPS обязателен - без него публикация ключа в DNS небезопасна
- Частая ротация - рекомендуется ротировать ключи каждый час (как Cloudflare)
- HTTPS-записи -должны быть корректно настроены с параметром ech=

Для инженера это значит:
- провайдер или DPI-бокс не увидит, куда идёт трафик из вашей инфраструктуры
- метаданные перестают быть источником утечек
- комплаенс с требованиями privacy-by-design становится проще

Что уже работает:
- NGINX принимает директиву ssl_ech_file /path/to/ech-keys.pem
В контексте http/server - она указывает PEM‑файл с ECHConfig и ключами, необходимыми для включения TLS 1.3 ECH в shared‑режиме.
​- поддержка HTTP и Stream модулей
​- ротация ключей через несколько файлов и nginx -s reload - директива ssl_ech_file может указываться несколько раз для разных файлов, что позволяет операционно ротировать ECH‑ключи.
​- мониторинг через переменные $ssl_ech_status и $ssl_ech_outer_server_name - они дают статус обработки ECH
​
Чего мне пока не хватает для продакшена:
- стабильная версия OpenSSL с ECH
ECH поддерживается только в экспериментальном бранче feature/ech OpenSSL.
Хотя OpenSSL 3.5 LTS вышел в апреле 2025, ECH не вошел в основной релиз и требует сборки из специального бранча.
- отсутствие интеграции с инфраструктурой
Let’s Encrypt и другие CA пока не выдают ECH‑ключи через ACME‑протокол - механизм не стандартизирован. Обычные TLS‑сертификаты работают с ECH без изменений, но получить и автоматически обновить ECHConfig‑ключи придётся вручную.
Публикация ключей в DNS (через HTTPS/SVCB‑записи) требует ручного управления или кастомных скриптов.
- ограниченная поддержка клиентами
Хотя Chrome и Firefox поддерживают ECH, некоторые корпоративные библиотеки еще не обновлены.

Как же это плюсы для для девопс-команд?
1) Privacy-focused сервисы🔥🔥🔥

server {
    listen 443 ssl http2;
    ssl_ech_file /etc/nginx/ech-keys.pem;
    # Теперь SNI не виден провайдеру!
}

2) Мультитенант платформы
- скрываете имена клиентских доменов от внешних наблюдателей
- полезно при shared infrastructure с чувствительными данными

3) Корпоративные VPN-шлюзы 🔥🔥🔥
- скрываете конечные точки внутри корпоративной сети
- провайдер видит только коннект к VPN-шлюзу, не к конкретным сервисам

Что делал я для домашней лаборатории:

git clone -b feature/ech https://github.com/openssl/openssl.git
./config --prefix=/opt/openssl-ech && make && sudo make install

./configure --with-openssl=/opt/openssl-ech \
            --with-http_ssl_module \
            --with-stream_ssl_module
make && sudo make install

/opt/openssl-ech/bin/openssl ech_keygen -out /etc/nginx/ech-keys.pem

+ крайне важно не забыть добавить DNS публикацию ECH-ключей.
Ключи ECH не работают изолированно - их обязательно нужно опубликовать в DNS через HTTPS-записи (SVCB/HTTPS-тип).
Без этого клиенты не узнают, что сервер поддерживает ECH.

_443._https.example.com. IN HTTPS 1 . ech=AEj+DQBE..