# GPU выключен, публичный IP остался: как сверить ресурсы

Почему после выключения GPU остаётся публичный IP: независимый ресурс адреса, Elastic IP AWS, Azure Public IP, DNS и проверка остаточных расходов.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/cloud-public-ip-lifetime-billing/
Language: ru

После выключения или удаления GPU VM публичный IP может остаться отдельным ресурсом и продолжить создавать расходы. Проверяйте тип адреса, его привязку и условия оплаты провайдера. Не освобождайте нужный адрес вслепую: от него могут зависеть DNS, разрешённые списки и доступ к другим сервисам.

## Найдите тип адреса

В облаках встречаются временные адреса интерфейса и отдельно выделяемые статические объекты. Их поведение отличается. Начните с ID ресурса, региона, привязки и владельца проекта. Само наличие IP в старой SSH-команде не объясняет, сохраняется ли он после остановки.

[Документация AWS Elastic IP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) описывает адрес, выделенный аккаунту до освобождения, и отдельные начисления за публичный IPv4. Следовательно, отсоединение от EC2 не следует считать автоматическим завершением услуги адреса.

## Сравните реальные модели ресурсов

[Документация Azure Public IP](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-addresses) рассматривает публичный адрес как ресурс с собственными свойствами. Его связь с VM не означает полного совпадения жизненных циклов. Конкретный SKU и правила оплаты нужно сверять отдельно.

| Пример | Что подтверждено документацией |
| --- | --- |
| AWS Elastic IP | Выделяется аккаунту и существует до release |
| AWS public IPv4 | Начисления не ограничиваются простаивающими EIP |
| Azure Public IP | Самостоятельный ресурс Azure Resource Manager |
| Любой адрес проекта | Нужны проверка привязки и зависимостей |

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

## Пример завершения демонстрационного стенда

Команда удаляет временную GPU VM после показа, но оставляет адрес, указанный в DNS. Ответственный сначала проверяет, нужен ли домен следующему стенду. Если нет, убирает зависимость и освобождает адрес по документированному процессу. Если нужен, назначает владельца и срок хранения.

Сохраните решение в ведомости проекта. Через месяц другой сотрудник должен понимать, почему адрес существует без VM. Без такого комментария его легко либо забыть оплачиваемым, либо удалить в момент, когда от него зависит новый ресурс.

## Проверьте зависимости до освобождения

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

Не предполагайте, что освобождённый публичный адрес удастся получить обратно. Для восстановления сервиса подготовьте процедуру обновления клиентов и имён. Это особенно важно, если тест постепенно стал рабочим инструментом команды и его инфраструктура уже не вполне временная.

В ведомости адресов добавьте ссылку на зависимый ресурс и причину сохранения. Если назначение неизвестно, сначала найдите владельца проекта. Адрес без работающей VM может обслуживать другой согласованный сценарий, поэтому очистку лучше вести по подтверждённой связи, а не только по внешнему виду списка.

## Включите IP в итоговый аудит

После завершения пилота просмотрите адреса во всех использованных регионах и проектах. Сверьте каждый с владельцем, назначением и ожидаемыми расходами. Пустой список VM не доказывает, что сетевые компоненты исчезли.

Для дальнейшего чтения доступны [остаточные расходы Azure VM](/ru/journal/azure-gpu-deallocated-cost-components/) и [общий аудит ресурсов](/ru/journal/cloud-gpu-resource-cleanup-audit/). Укажите статический адрес, ограничения подключения и ответственного: это поможет обсудить реальную эксплуатационную возможность оборудования.