S3 факапы Чтобы вы не впадали в жар при мысли о стоимости S3, как я на концерте Lorna Shore, приготовил для вас пост. Разберем разные типовые и не очень ошибки конфигурации. 🐈Но прежде чем к этому перейдем, отвечаю на ожидаемый вопрос: “чувак, мы не живем в aws, зачем нам это?” Короткий ответ: S3-API стал индустриальным стандартом. Когда ты используешь Yandex Object Storage, Selectel S3, или любого другого провайдера, ты работаешь с тем же протоколом. Провайдеры копируют логику AWS не из любви к Amazon, а потому что все библиотеки (boto3, s3cmd, rclone) написаны под этот стандарт. Следовательно, и архитектурные особенности во многих случаях перекочевали к нам почти без изменений. Мертвые данные в Standard классе Объекты годами лежат в дорогом классе Standard, хотя к ним никто не обращается. ✅Решение: Настройте S3 Lifecycle Policies для автоматического перехода в Glacier Instant Retrieval или Deep Archive через 30–90 дней. API-ошибки, незаметно сжигающие бюджет Бесконечные ретраи при ошибках 4xx/5xx могут генерировать миллиарды запросов. Даже если данных там нет ✅Решение: Внедрите Exponential Backoff с джиттером и настройте алерты в CloudWatch Metrics на всплески ошибок. ✅ В 2024 политику обработки ошибок поменяли, но до этого любой в интернете мог тратить ваш бюджет. Версионирование Включенное версионирование без правил удаления заставляет вас платить за каждую когда-либо созданную версию файла. ✅Решение: Добавьте правило NoncurrentVersionExpiration, чтобы хранить только N последних версий или удалять их спустя 30 дней. Архивация мелких файлов (Ловушка 128 КБ) Классы IA (Infrequent Access) и Glacier имеют минимальный расчетный размер объекта 128 КБ. Если ваш файл весит 1 КБ, вы все равно платите за 128 КБ. Плюс, переход (transition) каждого объекта стоит денег. ✅Решение: Агрегируйте мелкие файлы в TAR/ZIP архивы перед отправкой в холодное хранилище. Бессмысленные Lifecycle Transitions Загрузка данных в Standard на 1 день с последующим переходом в другой класс. Вы платите и за PUT в Standard, и за переход. ✅Решение: Сразу определяйте нужный класс хранения на уровне приложения при загрузке. Незавершенные Multipart Uploads Если загрузка большого файла оборвалась, куски остаются в бакете. Они не видны в консоли как объекты, но за их хранение выставляется счет. ✅Решение: Обязательно добавьте в Lifecycle Policy правило AbortIncompleteMultipartUpload (например через 7 дней). Игнорирование S3 Gateway Endpoint Трафик между EC2 и S3 через NAT Gateway стоит много ✅Решение: Настройте бесплатный S3 Gateway Endpoint. Это направит трафик по внутренней сети AWS, сделав его бесплатным и более быстрым. Использование S3 как файловой системы Создание множества бакетов вместо использования префиксов ведет к быстрому достижению лимитов аккаунта ✅Решение: Используйте структуру префиксов. Помните, что лимиты производительности (3500 PUT / 5500 GET запросов в сек) работают на уровне префикса, а не всего бакета. S3 Tar Tool вместо ручного пережатия Многие качают данные на EC2, архивируют и заливают обратно, тратя деньги на трафик ✅Решение: Используйте инструменты вроде amazon-s3-tar-tool , которые используют API UploadPartCopy для объединения объектов прямо внутри инфраструктуры S3. Удаление бакетов с публичными именами После удаления бакета его имя может занять кто угодно. Если на это имя завязаны ваши старые конфиги или ссылки, это путь к Subdomain Takeover. ✅Решение: Вместо удаления бакета очищайте его содержимое через Lifecycle Rules и оставляйте пустым. Логирование в себя Настройка S3 Access Logs в тот же самый бакет, который логируется. Это создает бесконечный цикл логов, которые логгируют логи, экспоненциально увеличивая стоимость. ✅Решение: Всегда выделяйте отдельный выделенный бакет для хранения логов