Amazon Web Services *

19–20 октября 2025 года в регионе us-east-1 произошёл каскадный сбой, повлиявший на доступность глобальных сервисов. Компания AWS опубликовала детальный разбор, в котором раскрыла первопричину — дефект в автоматизированной системе управления DNS для сервиса DynamoDB. В статье приводятся полная хронология событий, описание воздействия на смежные сервисы (EC2, NLB, Lambda) и список запланированных улучшений для предотвращения подобных инцидентов в будущем.

Представьте: утро 29 июля 2025 года, аэропорты по всей России в хаосе. Крупная российская авиакомпания вынуждена отменить десятки рейсов, в основном внутренних, из-за мощной кибератаки. Системы бронирования и управления полетами парализованы, пассажиры в панике, а компания теряет миллионы. Это не сценарий из фильма, а реальный инцидент, где хакеры продемонстрировали, насколько хрупка ИТ-инфраструктура даже у гигантов авиации.  Этот пример показывает, насколько важно иметь комплексный план реагирования и резервного копирования, чтобы минимизировать последствия подобных атак. Такие события напоминают: в эпоху, когда данные — это кровь бизнеса, отсутствие надежного плана на случай сбоя может стоить не только денег, но и репутации. Подобные атаки становятся ярким уроком, подчеркивающим, что без продуманного резервного копирования восстановление превращается в марафон, а не в спринт.

Мрачным утром 20 октября 2025 года мониторинг AWS был краснее некуда, его залило кровью сервисов. Пал крупнейший и по совместительству старейший регион, обрабатывающий 35–40% всего глобального трафика AWS — US-EAST-1. На его воскрешение чернокнижники из AWS потратили 13 часов.

В этой статье я хочу разобрать, что именно произошло, почему восстановление заняло так много времени, и самое главное — что мы можем сделать, чтобы наши системы пережили подобное в будущем. Ведь US-EAST-1 падает уже не первый раз, и явно не последний.

Terraform Actions — это новая концепция, представленная в Terraform 1.14, которая позволяет выполнять операции вне стандартного рабочего процесса CRUD (Create-Read-Update-Delete). Это расширяет возможности Terraform, позволяя взаимодействовать с ресурсами способами, для которых раньше требовались другие инструменты, например Ansible.

AWS Lambda — это серверлесс-платформа, у которой 1,5 млн активных клиентов и десятки триллионов вызовов ежемесячно, поэтому масштабируемость и надёжность — два важных ее принципа.

В этой статье я поделюсь рекомендациями и практическими наблюдениями по внедрению распределённых приложений — они основаны на опыте команды Lambda по построению надёжной системы асинхронной обработки событий. Мы разберем возможные проблемы, подходы к их решению и лучшие практики работы с «шумными соседями».

Всем привет! Меня зовут Роман, и я хочу поделиться своим опытом сдачи экзамена AWS DEA-C01: Data Engineer Associate. Когда сам готовился, то много искал реальных отзывов и заметок о том, как проходит экзамен, как лучше всего готовиться и на что обращать внимание. Поэтому надеюсь, что мой опыт будет полезен.

Немного о себе: сейчас я учусь на дата-инженера, и уже через несколько месяцев завершаю программу обучения. Параллельно начал задумываться о будущем трудоустройстве и изучал доступные вакансии. Довольно быстро стало очевидно, что учебная программа и реальные ожидания компаний пересекаются не во всём: последние делают большой упор на облака.

В IT у меня почти не нет опыта, так как вся моя предыдущая деятельность связана с аналитическим маркетингом: построение моделей работы рынка, прогнозирование цен, решение разных оптимизационных задач. То есть, по-хорошему, будущему работодателю надо показать как знания, так и практические результаты их применения, а именно пет-проекты.

Так у меня и появилась первая цель — подготовиться и успешно сдать экзамен DEA-C01.

От Kubernetes-хаоса к Infrastructure 2.0: опыт EXANTE, ошибки, неожиданные инсайты и новые подходы к современной инфраструктуре будущего

Работая в компании, которая занимается автоматизацией складских процессов, мы столкнулись с задачей прогнозирования нагрузки на склад. Это классическая задача предсказания временных рядов, в которой, имея достаточно большой объем исторических данных (минимум 1-2 года), нужно спрогнозировать, как эти данные будут меняться в будущем.

Для построения прогнозов на месяц мы использовали SARIMAX. Но на фоне развития нейросетевых технологий и нейросетей с архитектурой Transformer, мы решили, в качестве эксперимента, попробовать новый подход к решению поставленной задачи. И в процессе поиска наткнулись на очень интересный подход – использование трансформера совместно с дополнительной регрессионной моделью. Именно такую возможность предоставляет библиотека AutoGluon.

Я 10 лет был клиентом AWS и контрибьютором проектов с открытым исходным кодом, а они удалили мой аккаунт и все данные без какого‑либо предупреждения. Ниже — история о том, как «верификация» у AWS превратилась в цифровую казнь и почему нельзя доверять облачным провайдерам, если у вас нет копий данных вне облака.

На 23 июля 2025 года AWS удалил мой аккаунт, которому было 10 лет, и каждый байт данных, который я там хранил. Без предупреждения. Без льготного периода. Без возможности восстановления. Произошла полная цифровая аннигиляция.

Ниже я расскажу историю о катастрофической внутренней ошибке в AWS MENA, 20 днях кошмарного общения с поддержкой, в ходе которого я так и не получил прямого ответа на вопрос «Мои данные ещё существуют?», и о том, что всё это показывает в отношении доверия облачным провайдерам.

Много JavaScript‑фреймворков назад, в 2009 году, Джеффри Дин, будучи инженером в Google, представил знаменитые «числа, которые должен знать каждый программист».

Немного предыстории, прежде чем начать — о том, что у меня за проект такой — Talkvio. Уже два года я в свободное от основной работы время разрабатываю свой пет-проект — Talkvio, альтернативу Пикабу, где всё должно быть лампово и плюшево.

Проект уже довольно сильно развился: там есть нейросети для проверки орфографии, автотегов и помощи в формировании контента и заголовков. Есть Android-клиент, а iOS-версия находится в разработке. Реализована похожая система кармы, как на Хабре, есть даже минусы (привет администрации Пикабу), и многое-многое другое.

У нас на ресурсе пользователи больше фокусируются на авторском контенте — всевозможных интересных статьях и т.п., помимо юмористического. То есть казалось, что ничего не предвещает беды.

Забегая вперед, чтобы читателю было интересно, ресурс НЕ использовал Cloudflare.

Обработка счетов — важная и рутинная часть документооборота, которую всё чаще доверяют AI-моделям. Наша компания часто занимается интеллектуальной обработкой счетов для клиентов, а значит мы постоянно ищем лучший способ для их распознавания. Поэтому мы провели практическое исследование и сравнили, как с этой задачей справляются разные решения: от популярных open-source моделей до коммерческих API.

Исследование включало несколько этапов: мы собрали разнообразный датасет из реальных счетов, привели его к единому формату, определили метрики и протестировали 7 популярных на наш взгляд моделей, чтобы понять:

В статье рассматривается практический опыт использования инструмента Warp для нагрузочного тестирования S3-совместимых хранилищ. Делимся примерами запуска тестов, объясняет ключевые параметры и помогает интерпретировать результаты. Материал будет полезен тестировщикам, работающим с объектным хранилищем и желающим проверить его производительность и стабильность под реальной нагрузкой.

OIDC GitHub Actions может запрашивать временные токены, действительные только на время выполнения workflow, что значительно повышает безопасность и упрощает управление доступом.

В этом посте я расскажу, как на практике за пару часов реализовал serverless OCR-сервис на AWS, используя AWS Lambda и модель из Amazon Bedrock. Статья ориентирована на опытных AWS-архитекторов, поэтому мы углубимся в архитектуру, покажу код (Terraform для инфраструктуры и Python для Lambda), обсудим масштабирование, ограничения и прикинем стоимость решения в регионе eu-central-1 (Франкфурт).

TL;DR: KIP‑1150 (Diskless Topics) предлагает Kafka писать сообщения сразу в облачное хранилище (S3 и аналоги), минуя диски брокеров. Это сильно экономит деньги и упрощает масштабирование в облаке, но увеличивает задержки и делает Kafka зависимой от облачных сервисов. Отлично для дешёвых, «толстых» потоков логов, но плохо подходит для real‑time систем с миллисекундными требованиями.

Для целого ряда задач полезно использовать Serverless подход.

В этой статье мы кратко рассмотрим основные решения, их достоинства, и главное, недостатки. А также рассмотрим несколько интересных Open Source решений.

Эта статья станет интересной не только специалистам по TypeScript, но и всем разработчикам, ищущим лучшие практики работы с ошибками в современном программировании.

Вы узнаете, почему традиционный подход к работе с ошибками может тормозить разработку и как правильное разделение ожидаемых ошибок и критических дефектов значительно упрощает жизнь.

Я подробно описываю, как моя реализация решает сложности AWS SDK и делает его использование более надежным.

Буду рад узнать ваш подход к работе с ошибками, пишите в комментарии. Спасибо!

Представьте, что вы создали пустую, приватную корзину (их ещё называют «бакетами» — от «bucket») AWS S3 в выбранном вами регионе. Каким будет счёт за услуги AWS на следующее утро?

Несколько недель назад я начал работу над прототипом системы индексирования документов для моего клиента. Я создал одну корзину S3 в регионе eu-west-1 и загрузил туда несколько файлов для тестирования. Через два дня я проверил мою страницу выставления счетов AWS, заглянув туда, преимущественно, для того, чтобы проверить, что то, чем я занимаюсь, нормально укладывается в лимиты бесплатного тарифного плана. Но, судя по тому, что я там увидел, ни о какой нормальности речи не шло. Мой счёт превышал $1300, а в консоли выставления счетов были видны сто миллионов PUT-запросов к корзине S3, выполненных всего за один день!

Сегодня поговорим о граблях, на которые наступает каждый второй стартапер или владелец уже действующего бизнеса. Нет, не про то, как нанимать друзей или доверять партнёрам без договора — это тема для отдельной драмы😀 Сегодня разберем, как не прос... просадить весь бюджет на серверах, когда ваш стартап наконец-то начал взлетать.