AWS лишила аудиторов мартовской статистики по сбоям в дата-центре в ОАЭ
Amazon Web Services неожиданно "вычистила" из отчётности данные о потреблении и стоимости облачных ресурсов за март в регионе ME-CENTRAL-1 (зона Ближнего Востока, куда входит и Бахрейн, где расположен один из ключевых дата-центров компании). Речь идёт о детализированных отчётах Cost and Usage Report (CUR), на которые традиционно опираются аудиторы, команды FinOps и подразделения информационной безопасности.
Клиенты AWS в этом регионе получили уведомления о том, что все начисления за март будут полностью аннулированы. При этом никаких технических или юридических обоснований компания не предоставила - только констатация факта: плата за соответствующий период взиматься не будет.
Контекст ситуации уже известен: ранее Amazon официально подтвердила, что работа дата-центра в Бахрейне была нарушена из‑за активности беспилотников в регионе. Инцидент произошёл на фоне обострившегося конфликта между Ираном и Израилем и привёл к реальным перебоям в работе инфраструктуры.
По имеющимся данным, сбои затронули 109 клиентов, которым пришлось в срочном порядке переносить свои рабочие нагрузки в другие регионы AWS. Для части компаний это означало незапланированные расходы, риски несоответствия требованиям отказоустойчивости, а также временную деградацию сервисов для конечных пользователей.
Особенность нынешней ситуации в том, что отчёты CUR, которые считаются "золотым стандартом" учёта потребления облака, за март по региону ME-CENTRAL-1 оказались пустыми. При попытке выгрузить данные за этот период аудиторы и финансовые специалисты видят "дыру" в статистике, что серьёзно осложняет контроль, планирование бюджета и подтверждение корректности начислений.
Для крупных организаций такие отчёты - не просто вспомогательный инструмент, а формальная часть внутренних и внешних проверок. На CUR опираются при подготовке к финансовому аудиту, при разборе инцидентов, в том числе связанных с безопасностью, а также при обосновании затрат для руководства и акционеров. Отсутствие данных за целый месяц автоматически создаёт вопросы у комплаенс- и риск-менеджеров.
Amazon официально не объяснила, почему приняла решение удалить или скрыть мартовскую статистику по этому региону. Одна из возможных версий - технический сбой в собственных системах биллинга и учёта, который возник параллельно с проблемами основной инфраструктуры дата-центра. Если подсистема метрик и тарификации зависла или работала нестабильно, корректно восстановить постфактум покомпонентное потребление ресурсов могло оказаться затруднительно или слишком дорого.
Ещё один вероятный сценарий связан с тем, что значительная часть виртуальных машин и сопутствующих сервисов могла простаивать неделями или работать в аномальном режиме. В этом случае стандартные модели расчёта стоимости и алгоритмы распределения расходов между услугами могут дать некорректный результат. Для избегания споров с клиентами и потенциальных претензий проще обнулить выставленные счета и "обрезать" спорный период из детальных отчётов.
С практической точки зрения для клиентов ситуация выглядит двойственно. С одной стороны, полное списание мартовских начислений снижает расходы и формально компенсирует часть неудобств, связанных с миграцией рабочих нагрузок и простоями сервисов. С другой стороны, компании теряют прозрачную картину того, что именно происходило в их облачной инфраструктуре в момент кризиса и каковы были реальные объёмы потребления.
Для команд FinOps исчезновение части истории потребления - серьёзная проблема. Нарушается непрерывность аналитики, ломаются дашборды и прогнозные модели, ухудшается точность планирования бюджетов на инфраструктуру. Любые тренды, в которых март должен был быть контрольной точкой (например, переход на новый тип инстансов или изменение архитектуры), теперь искажены или вовсе становятся непригодными для анализа.
Аудиторам и службам комплаенса теперь придётся фиксировать в своих отчётах, что данные за март по региону ME-CENTRAL-1 недоступны по причинам, зависящим от поставщика облака. Для компаний, работающих в строго регулируемых отраслях - банковском секторе, телекоммуникациях, госсекторе, - это может стать отдельным риском. В некоторых юрисдикциях требуется сохранять полную финансовую и эксплуатационную историю ИТ-систем, а отсутствие данных по внешнему провайдеру усложняет доказательство соблюдения норм.
Данный инцидент также поднимает вопрос о прозрачности облачных провайдеров. Когда провайдер в одностороннем порядке удаляет ключевые метрики, пусть даже в интересах клиентов, это ставит под сомнение предсказуемость и воспроизводимость отчётности. Для компаний, опирающихся на облако как на критически важную часть инфраструктуры, подобные шаги усиливают мотивацию развивать мультиоблачные или гибридные стратегии, чтобы снижать зависимость от одного поставщика.
С точки зрения операционного риска кейс с ME-CENTRAL-1 ярко демонстрирует, что геополитические и военные факторы становятся вполне реальной угрозой даже для глобальных облачных платформ. Формальные гарантии в сервисных соглашениях и уровни доступности, декларируемые в документации, уступают место объективной реальности: физическая безопасность дата-центров не всегда может быть обеспечена на сто процентов.
Для архитекторов и инженеров это ещё один аргумент в пользу проектирования систем с учётом отказа целого региона, а не только одной зоны доступности. Репликация критических данных в другой географический регион, использование независимых каналов связи и продуманные планы аварийного восстановления перестают быть "хорошей практикой" и становятся обязательным элементом минимизации рисков.
С юридической точки зрения обнуление начислений и отсутствие отчётов могут трактоваться как негласная форма компенсации за несоблюдение ожидаемого уровня сервиса. Вместо сложных переговоров о неустойках и компенсациях по SLA поставщик фактически признаёт, что корректно посчитать и выставить стоимость услуг за спорный период трудно или невозможно, и предпочитает снять вопрос финансовой претензии "в зародыше".
В долгосрочной перспективе эта история, вероятно, станет примером для обсуждения на уровне регуляторов и крупных корпоративных клиентов. Можно ожидать, что в будущих договорах на использование облака появятся более жёсткие формулировки о доступности биллинговых и аналитических данных, а также отдельные пункты, касающиеся порядка действий провайдера в случае форс-мажорных обстоятельств, затрагивающих не только инфраструктуру, но и отчётность.
Для ИТ-директоров и финансовых директоров данный кейс - повод пересмотреть внутренние процедуры контроля за облачными расходами. Одним из следствий может стать внедрение независимых систем сбора метрик и логов, дублирующих или дополняющих данные самого провайдера. Если организация располагает собственными средствами мониторинга и учёта (например, на уровне приложений и сетевой инфраструктуры), она становится менее уязвимой к "пропаданию" данных в отчётах поставщика.
Наконец, с точки зрения репутации для AWS ситуация остаётся неоднозначной. С одной стороны, компания демонстрирует готовность взять на себя финансовые последствия инцидента и не взимать плату за потенциально проблемный период. С другой стороны, отсутствие публичных технических подробностей и ясных объяснений, почему именно были удалены CUR-данные, усиливает ощущение непрозрачности происходящего и порождает дополнительные вопросы у бизнеса и специалистов по рискам.
Таким образом, история с мартовскими сбоями в Бахрейне вышла за рамки обычного инцидента в дата-центре и превратилась в показательный пример того, как один форс-мажор может одновременно затронуть инфраструктуру, финансы, аудит и доверие к облачной экосистеме в целом.
