Terraform читает state, но не может снять S3 lock Чтение и запись state работают, а завершение CI упирается в AccessDenied на lockfile. В S3 backend блокировка включается отдельно через use_lockfile=true, по умолчанию она выключена. Права на state и на блокировку тоже различаются. Для <key>.tflock нужны s3:GetObject, s3:PutObject и s3:DeleteObject. Для самого state default workspace достаточно GetObject/PutObject, право удаления ему не требуется. У других workspaces собственные пути и права, включая удаление workspace state. Также нужен ListBucket на соответствующие пути. DynamoDB locking помечен deprecated. При миграции можно временно задать оба механизма, но сначала проверьте поддержку lockfile всеми CI-клиентами. Рекомендован Bucket Versioning для восстановления state. Эти условия относятся к Terraform и Amazon S3, для других реализаций совместимость нужно проверять отдельно. На отдельном state запустите конкурирующие операции и проверьте, что вторая ждёт, а штатное завершение первой удаляет lockfile. Оставшийся файл не доказывает мёртвый процесс и не оправдывает force-unlock. Права и миграция backend.

Потерянные события Hubble не доказывают потерю пакетов В Hubble пропали наблюдения, но приложение продолжает отвечать. Счётчик hubble_lost_events_total показывает потерю событий телеметрии. Приравнивать его рост к packet drops или проценту недоступности нельзя. Смотрите label source. perf_event_ring_buffer означает, что userspace agent не успевает за datapath. observer_events_queue указывает на полную очередь observer. При hubble_ring_buffer читатель не забрал событие до перезаписи буфера. Это разные места потери и разные причины неполной картины. В stable-документации Cilium 1.20.3 lost-events включается вместе с любой другой Hubble metric. Сначала подтвердите экспорт и scrape, нулевой счётчик без сбора ничего не доказывает. Сопоставьте рост по source с реальными сетевыми ответами и drop metrics. После настройки ёмкости или читателя проверьте полноту наблюдений и задержки приложения. Метрики и условия сбора.

Бесплатный gateway endpoint ещё не означает бесплатный путь к S3 В VPC создали gateway endpoint для S3, но bytes платного interface endpoint продолжают расти. Проверьте private DNS: наличие маршрута не доказывает, что запросы выбирают именно его. Если на interface endpoint включён private DNS без режима only for inbound Resolver endpoint, через interface могут идти и on-premises, и VPC-запросы. В комбинированной схеме с этим режимом on-premises использует interface, а VPC получает публичные S3 IP и идёт через gateway route. За сам gateway endpoint дополнительной платы нет, это не нулевой счёт за S3. Gateway не расширяется за пределы VPC и своего Region. DNS record IP type двух endpoints должен совпадать либо быть service-defined у gateway. Перед изменением проверьте DNS и route tables, затем реальные GET/PUT из обеих сетей и bytes interface endpoint. Смена маршрутов может оборвать TCP, поэтому проверьте переподключение в согласованном окне. Схема AWS и ограничения.