Счёт за облако: что пришло после быстрого переезда
Компании, которые переехали в облако под давлением пандемии, теперь получают счета, которые никто не планировал. Разбор того, почему так происходит и что с этим делать.
С марта по май 2020 года многие компании сделали то, что откладывали годами - перевели инфраструктуру и команды в облако. Давление было понятным: нужно было быстро обеспечить доступ к системам для удалённых сотрудников, не было времени планировать.
Несколько месяцев спустя приходят счета. И они часто оказываются неожиданными.
Я не говорю о мошенничестве или ошибках провайдера. Я говорю о том, что быстрая миграция под давлением почти всегда создаёт несколько специфических паттернов расходов, которые потом удивляют.
Почему быстрая миграция дорого обходится
Когда переезжают быстро, берут "с запасом". Серверы, которые были on-premise, переводят один в один - или больше, на всякий случай. В облаке это работает иначе: там платишь за каждый час работы инстанса, независимо от того, есть на нём нагрузка или нет.
Второй паттерн - забытые ресурсы. Тестовые стенды, которые запустили "на пару дней", dev-окружения, которые не выключают на ночь и в выходные. В облаке у каждого из них есть счётчик.
Третий - трафик. Исходящий трафик из большинства облачных провайдеров тарифицируется. Компании, у которых раньше всё жило в одном ЦОД, теперь платят за каждый гигабайт, который уходит наружу.
Что обычно находят при аудите
Я несколько раз проводил аудит облачных затрат после таких "кризисных" миграций. Почти всегда находятся:
- инстансы, запущенные под нагрузку, которой уже нет - её перенесли или оптимизировали, а инстансы оставили;
- хранилище, в которое данные пишутся, но никогда не читаются;
- лицензии на managed-сервисы, которые дублируют то, что уже есть;
- несколько параллельных VPN-решений, запущенных разными командами независимо.
Суммарно это часто составляет 20-40% от счёта. Это не уникальные цифры - это типичный результат быстрой миграции без последующей оптимизации.
Как устроена оптимизация
Оптимизация облачных затрат - это не разовое мероприятие. Это процесс, у которого должен быть владелец.
Первый шаг - теггирование ресурсов. Каждый инстанс, каждый диск, каждый сервис должен быть помечен: кто владелец, какой проект, какое окружение. Без этого невозможно понять, что отключать.
Второй шаг - ревью использования. Ресурсы, которые потребляют меньше 20% от выделенного, - кандидаты на изменение типа или отключение.
Третий шаг - политики автоматического выключения. Dev- и test-окружения не должны работать 24/7. Это легко настраивается и даёт быстрый результат.
Вопрос к себе перед следующим решением
Облако стало нормой. Но "облако как default" не значит "облако без управления". Быстрый переезд был оправдан ситуацией - теперь наступило время разобраться, что именно работает, сколько это стоит и нужно ли оно.
Три вопроса для начала:
- Знает ли кто-то в вашей компании, какие облачные ресурсы запущены прямо сейчас и кто за каждый отвечает?
- Есть ли у вас политика выключения не-production-окружений в нерабочее время?
- Кто получает счёт от облачного провайдера и разбирает его по строкам?
Если ответ на первые два "не уверен" - это хорошее место для начала.