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

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

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

Архитектура, которая должна была меня защитить

Прежде чем кто‑то скажет: «Ты сложил все яйца в одну корзину», уточню: нет. Я использовал одного провайдера, но с, казалось бы, непробиваемой избыточностью:

• Мульти‑региональная репликация в пределах AWS Europe (полностью отделена от инфраструктуры США).

• «Выключатель мертвеца», настроенный для восстановления на случай аварии.

• Правильная резервная архитектура по руководствам самого AWS.

• Раздельное хранение ключей шифрования, которые были изолированы от данных.

Каков был единственный сценарий, который я не предусмотрел? Я не предусмотрел, что источником угрозы будет сам AWS.

Десять лет. Столько времени я был клиентом AWS. Я десятилетие использовал AWS как тестовую площадку: поднимал виртуальные машины, чтобы проверять развёртывание для поддерживаемых мной Ruby‑гемов вроде capistrano‑puma и capistrano‑sidekiq. Это не было каким-то критическим продуктом, но являлось жизненно важной частью моих Open Source-разработок.

В мой день рождения AWS сделал «подарок», который я никогда не забуду. В этот день AWS доказал, что любая избыточность бессмысленна, если сам провайдер действует против тебя.

20‑дневный кошмар поддержки: хронология

10 июля. AWS присылает запрос на верификацию. Крайний срок — через 5 дней (включая выходные).

14 июля. Форма истекла. Пишу в поддержку и задаю простой вопрос: «Что именно вам от меня нужно?»

16–20 июля. Четыре дня тишины. Потом ответ: «Мы эскалируем вопрос в соответствующую команду».

20 июля. Наконец присылают новую форму.

21 июля. Отправляю удостоверение личности и счёт за коммунальные услуги (читаемый PDF). Ответ приходит через 10 часов.

22 июля. AWS: «Документ нечитаем». А ведь это тот же PDF, который мой банк принимает без вопросов.

23 июля. Аккаунт закрывают. Вот он, «Подарок ко дню рождения».

24 июля. Задаю единственный важный для меня вопрос: «Мои данные ещё существуют?»

AWS: «Ваш случай рассматривается командой сервиса».

Прошу временный доступ только на чтение, чтобы успеть скопировать данные. Помните, если бы я был мошенником, я бы уже всё скачал до истечения срока верификации. Мне отказывают (потому что, вероятно, данных уже нет).

28 июля. После 4 дней шаблонных ответов мое терпение подходит к концу и происходит следующий диалог:

Я: «Мои данные в безопасности? Ответьте, "Да" или "Нет"?»
AWS: «Я персонально работаю над вашим случаем и хочу сообщить, что мы понимаем всю срочность».

29 июля. Сравниваю их уклончивость с политическим уходом от ответа:

Я: «Вы отвечаете так, будто я Пирс Морган (британский и американский журналист и редактор. Ведет свое вечернее шоу на канале CNN, — прим. пер.) и спрашиваю: “Вы осуждаете события 7 октября?”, а вы начинаете рассуждать о сложности истории с 1948 года».
AWS: «Мы искренне ценим вашу приверженность лучшим практикам резервного копирования».

В этот же день они наконец признают правду:

AWS: «Поскольку верификация не была завершена к указанной дате, ресурсы на аккаунте были уничтожены (в оригинале ответа от AWS используется именно слово "terminated", а не "deleted" или "cleaned", — прим. пер.)».

30 июля. Финальный ответ включает просьбу:

AWS: «Мы ценим вашу обратную связь. Пожалуйста, оцените данную переписку». ⭐⭐⭐⭐⭐

Двадцать дней. Ноль прямых ответов. И многократные просьбы поставить 5 звёзд — пока мои данные обращались в цифровой пепел.

Политика, которую они декларируют VS реальность, которую они демонстрируют

Вот что говорится в документации самого AWS о закрытии аккаунта:

«Послезаходный период — 90 дней: в это время аккаунт можно вновь открыть, а данные сохраняются».

«По истечении 90 дней аккаунт считается “навсегда закрытым”, и весь контент — включая снимки и резервные копии — удаляется».

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

Общепринятый стандарт у облачных провайдеров — хранить от 30 до 90 дней, если нет факта мошенничества или злоупотреблений. У AWS же другое мнение. Никаких тебе резервных дней. Никаких резервных часов. Никакой пощады.

Сложности с плательщиком

AWS списал удаление на проблему с «третьей стороной‑плательщиком». Консультант AWS, который некоторое время оплачивал мои счета, исчез, сославшись на потери из‑за краха криптобиржи FTX. Почти год до этого наша схема работала исправно — он переводил около 200 долларов в месяц за мою тестовую инфраструктуру. После его исчезновения я платил за AWS сам.

Когда AWS потребовал, чтобы пропавший плательщик подтвердил свою личность, я указал, что у меня уже есть собственная карта Wise в биллинге — той же картой я платил до появления плательщика-спонсора и держал её активной именно на случай, если он исчезнет, пока я в дороге или офлайн. AWS отказались просто переключить оплату обратно на неё в течение тех 20 дней, ссылаясь на «конфиденциальность», одновременно возложив на меня всю ответственность за последствия.

Но дело было не в оплате. Если бы дело было именно в платежах, они бы:

• Переключили оплату на мою привязанную карту.

• Приостановили услуги, а не удалили данные.

• Предоставили 90‑дневный льготный период, обещанный их же документацией.

Вместо этого они использовали проблему с плательщиком как прикрытие для настоящей причины — неудачного внутреннего тестирования.

Их лицемерие только росло

Плательщик был не случайным человеком или мошенником — это была компания, которую поддержал Y Combinator. Я видел это при привязке платежа. Если безопасность AWS MENA так надёжна, почему они целый год не видели никаких проблем?

Пытаясь всё уладить, AWS требовал от меня объяснить:

• Для чего я использую аккаунт.

• Какие у меня планы на будущее.

• Почему мне вообще нужны их сервисы.

Будто я подавал заявку на финансирование или должность. Это аккаунт десятилетней давности. Я не должен доказывать своё право пользоваться услугами, за которые плачу с 2015 года.

И вишенка на торте: разработчики AWS регулярно пишут мне с просьбами помочь с проблемами Ruby. Без вознаграждения. Без кредитов AWS. Даже без «спасибо» в коммитах. Просто: «Эй, поможешь отладить развёртывание Rails?»

Итак, получается:

• AWS пользуется моим открытым исходным кодом.

• Инженеры AWS ходят ко мне за бесплатными консультациями.

• AWS заставляет меня объяснять, почему я «заслуживаю» свой аккаунт.

• И удаляет всё, когда исчезает плательщик из компании, поддержанной YC (которого они сами год не смогли корректно отследить).

И при этом я должен проверять всех своих клиентов? Может, мне ещё проводить спецпроверку писем по верификации от самой AWS? Раз уж их собственный процесс не смог за год выявить никаких несоответствий.

Что именно AWS уничтожил

Большинство не понимает: AWS был для меня не просто резервной копией — это была «чистая комната» для моей Open Source-разработки.

Мой локальный рабочий стол — это хаос. Всегда. Файлы повсюду, полуготовые проекты, эксперименты. Но я обнаружил, что если копировать всё в AWS, начинать с чистого листа и возвращать обратно только нужное, получается делать чистые, сфокусированные гемы (gems — так рубисты называют свои библиотеки. По факту, речь идет о концентрированных проектах, которые выкристаллизовывались из рабоче-творческого хаоса автора, — прим.пер). Так я выпускал, например:

• BreakerMachines — шаблоны «предохранителя цепи» (circuit breaker) для Ruby.

• ChronoMachines — Time-based машины состояний.

• RailsLens — мониторинг производительности Rails.

• И десятки других.

Эти библиотеки экономят разработчикам сотни, а то и тысячи часов. Они используются в боевых системах по всему миру. AWS удалил не просто данные — он уничтожил инфраструктуру, благодаря которой этот вклад в сообщество вообще был возможен.

Но есть кое-что и похуже. Также исчезло:

• Полноценная книга по программированию, написанная в моей нарративной манере Chronicles.

• Учебные материалы по электронике на стыке «железо/софт».

• «Go для разработчиков на Ruby» — курс перехода с Ruby на Go.

• Годы неопубликованных материалов, которые могли помочь тысячам девелоперов по всему миру.

Я хочу сказать, что когда AWS удалил мой аккаунт, пострадал не только я. Пострадали все, кто использует мои разработки и гемы. Пострадал каждый студент, который мог бы учиться по этим материалам. Пострадала каждая будущая публикация, которая не случится, потому что мой центральный рабочий процесс был разрушен. (Звучит драматично, ведь понятно, что где-то остались публичные или частные копии. Но при этом очевидно, что автор не сможет работать в прежнем темпе, т.к. их как минимум нужно будет собрать и существует вопрос актуальности и связности. Тем более, все восстановить невозможно, — прим. пер.)

Ирония в том, что некоторые из этих гемов наверняка работают в инфраструктуре самого AWS, делая её более надёжной. И они удалили среду, в которой эти вещи создавались.

Теория: как -dry вместо --dry мог уничтожить мой аккаунт

После того как моя история начала форситься в сообществе, ко мне обратился инсайдер из AWS. Он был возмущён, собирался уходить (из компании) и хотел поделиться тем, что знает — в том числе и по причине того, что AWS реально зависит от открытого кода, который я написал.

По его словам, в AWS MENA проводили тестирование какой-то новой концепции на «спящих» и «малоактивных» аккаунтах. Пострадало несколько учёток, не только моя. Технические подробности следующие.

Разработчик, запускавший проверку, набрал --dry, чтобы выполнить пробный прогон (dry run) — стандарт для современных утилит командной строки:

• ruby --version

• npm --version

• bun --version

• terraform --dry-run

Но внутренний инструмент был написан на Java. А для Java‑приложений традиционно используются одинарные дефисы в параметрах:

• java -version (а не --version)

• java -dry (а не --dry)

Если передать --dry приложению на Java, которое ждёт -dry, параметр просто игнорируется. Скрипт выполнился по‑настоящему и удалил аккаунты на продакшене.

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

Так ли всё было на самом деле? Я не могу это доказать. Инсайдер говорил расплывчато — боялся быть вычисленным. Но теория объясняет:

• Почему внезапно «всплыли» несколько низкоактивных аккаунтов (которые пострадали так же, как и мой).

• Откуда 4‑дневные задержки (попытки замести следы).

• Почему отказывались отвечать на простые вопросы.

• Почему агенты поддержки признавались, что «не могут принимать решения».

AWS MENA: почему люди готовы переплачивать, чтобы его избежать

Эта версия выглядит правдоподобней, если вспомнить репутацию AWS MENA. Годами я наблюдал, как разработчики на Reddit и Facebook отчаянно ищут биллинговые адреса в США или ЕС и готовы переплачивать 100+ долларов только чтобы не попадать в MENA по региону.

Когда я спросил почему, коллега предупредил: «AWS MENA работает иначе. Они могут отключить тебя случайно».

Я посмеялся. AWS же везде одинаковый, верно?

Четырёхдневная задержка для простой формы. Ответы раз в десять часов. Роботоподобные шаблоны поддержки. Это было не обычное «некомпетентное молчание» — тут происходило нечто иное.

Высшая ирония: безопасность стала моей слабостью

Я сделал всё «как надо». Ключи шифрования в хранилище, отделённом от основной инфраструктуры. Несколько контуров защиты. Архитектура «нулевой толерантности». Всё как по учебнику.

Моя модель безопасности была выстроена именно так, чтобы ни одна единичная ошибка не могла обрушить всё и сразу. Единственное, от чего я не защитился? От того, что сам AWS окажется той самой критической точкой отказа.

Я построил укреплённый бункер с несколькими путями отхода — а AWS просто сбросил на весь комплекс «ядерную бомбу».

Что это значит для вас

Вы можете подумать: «Каковы шансы, что они возьмутся за меня?» Но это неправильный вопрос. Я думал так же: с моим уровнем публичности и вкладов они могли бы просто записать моё имя и не тревожить меня глупыми запросами о том, существую ли я, ведь ответ очевиден.

Но проблема не в «таргетинге» — вас классифицирует алгоритм. И если алгоритм решает, что вы «расходный материал» — вас не существует.

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

Я пишу странные тексты. Мой стиль документации порой триггерит ИИ‑фильтры. Возьмём мой гем ActionMCP, добавляющий возможности MCP в Rails — Opus не может нормально прочитать документацию, его фильтры сбоят; Sonnet — спокойно справляется. (Проверьте сами: github.com/seuros/action_mcp.)

Если мой творческий технический текст сбивает с толку один ИИ, но не другой, представьте, что «видят» алгоритмы AWS по «выявлению мошенников», глядя на мой аккаунт. Аномалию, которая «не подходит» к их правильному шаблону. Они видят что‑то, что нужно устранить.

Единственный путь вперёд: нарушенное обещание

После 20 дней апелляций поддержка AWS выдала вот это: «Поскольку верификация не была завершена в установленный срок, ваши ресурсы были уничтожены».

Но посмотрите на дилемму, которую они создали: а если у вас петабайты данных? Как делать резервные копии для резервных копий? Что, если в них — персональные медицинские данные по HIPAA или клиентская информация? Ключевое обещание облачных вычислений сваливается тут в неуправляемое пике.

Это не отказ системы. Архитектура и публичные обещания в целом звучат логично. AWS не теряет данные — у них есть «резервные копии резервных копий», хранящиеся в закрытых хранилищах куда дольше, чем декларируемые 90 дней, недоступные никаким «скриптам‑убийцам».

Здесь всё проще: команды в MENA пытаются скрыть крупную ошибку. Восстановление данных из глубоких хранилищ потребует объяснений. Отчётов об инциденте. Разборов полётов. Ответа на вопрос: «Почему пришлось открывать сейфы?»

Вся их коммуникация кричит: «Он никто. Скоро сдастся. До руководства дело не дойдёт».

Но они связались не с тем разработчиком.

Сейчас я делаю бесплатный инструмент, который поможет людям устроить исход из AWS. Разумеется, он не будет хоститься на AWS. Мои клиенты — а это суммарно более 400 тысяч долларов в месяц расходов на AWS — уже согласились мигрировать на Oracle OCI, Azure и Google Cloud.

Потому что если AWS способен удалить десятилетнего клиента, не моргнув глазом, то на что они пойдут, когда ставки выше?

Горькая правда

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

Но всё это не оправдывает «цифровую казнь» десятилетнего тестового аккаунта из‑за сбоя формы верификации и счета менее чем на 200 долларов. К счастью, это была не продуктовая инфраструктура, а скорее «стартовая площадка» для патча других систем. Теперь я трачу дни на ротацию ключей шифрования между множеством систем, потому что мой центральный тестовый контур исчез.

Системный сбой

Речь не только о моём аккаунте. Речь о том, что происходит, когда:

1. Региональные подразделения выходят из подчинения: AWS MENA работает вне глобальных правил.

2. Поддержка превращается в театр: агенты могут лишь вставлять шаблоны и просить «поставьте 5 звёзд».

3. Девиз Цукерберга «Делай быстро исправляй на ходу» сталкивается с реальностью боевых данных и продакшена: внутренние инструменты с парсингом параметров а‑ля 1995 год на Java управляют удалением клиентских ресурсов.

4. Нулевая ответственность: 20 дней увиливания вместо одного честного ответа.

Признаки дисфункции:

• Сотни людей, готовых доплачивать, лишь бы избежать биллинга в MENA (рынок проголосовал рублём).

• 4‑дневные задержки даже для простых форм.

• Вопрос о восстановлении данных превращается в беседу уровня геополитических дискуссий.

• Автоматические письма «оцените поддержку на пять звёзд» в то время, когда они уничтожают ваши данные.

Реальная цена

AWS позиционирует себя как позвоночник интернета, надёжного партнёра вашей инфраструктуры. Они спонсируют проекты с открытым исходным кодом, проводят re:Invent и выступают союзниками разработчиков.

Но когда их внутренние системы дают сбой — когда кто‑то вводит --dry, а Java игнорирует это — они удалят десятилетие вашей работы, не моргнув глазом. А затем потратят 20 дней, убеждая вас, что ничего страшного не произошло.

Тем временем настоящие злоумышленники, создающие фишинговые сайты и занимающиеся криптомошенничеством, неделями работают безнаказанно. Потому что они приносят выручку. А малоактивный разработчик с открытым кодом, тестирующий Ruby‑гемы? Просто сопутствующий ущерб.

Извлечённые уроки

1. Никогда не доверяйте одному провайдеру — даже если реплицируете данные по нескольким регионам.

2. «Лучшие практики» бессмысленны, когда сам провайдер действует против вас.

3. Документируйте всё — скриншоты, письма, отметки времени.

4. Поддержка это ширма — они буквально не могут вам помочь.

5. Иметь план выхода, исполнимый за часы, а не за дни.

AWS не признает ошибку. Не подтвердит, что проводились какие-то там тестирования новых концепций. Не объяснит, почему MENA работает иначе, чем весь остальной сервис. И даже не ответит, существуют ли ваши данные.

Но они непременно попросят поставить 5 звёзд.

Облако — вам не друг. Это бизнес. И когда интересы бизнеса вступают в конфликт с существованием ваших данных, угадайте, что победит?

Делайте выводы заранее.

Примечание переводчика: после поднятия волны в сообществе и через X, AWS восстановил аккаунт автора 6 августа (оригинальная публикация вышла 2 августа). Видимо, были подняты те самые "холодные хранилища", благодаря которым AWS "ничего не теряет". Об этом был написан отдельный обширный пост.

---

Самое важное в нашем ТГ-канале. Без лишнего спама.