Настройка сети SageMaker для доступа к внешним службам со строгими правилами входящего трафика

Обычно SageMaker ожидает, что обучающие данные будут размещены на S3. Большинство проблем машинного обучения в реальном мире требуют частого пересмотра данных и перемаркировки данных из-за дрейфа концепций. В таких случаях необработанные данные и аннотации могут быть слабо связаны. Это означает, что необработанные данные, такие как изображения, трехмерные облака точек или аудиофайлы, могут храниться в облачном хранилище, таком как S3 (и, возможно, с межрегиональной репликацией), а аннотации могут храниться в отдельной базе данных NoSQL или SQL. В этом случае, если пользователь запрашивает определенный набор данных, необработанные изображения загружаются из облачного хранилища, а аннотации запрашиваются с сервера данных. Эти серверы данных могут использовать несколько мер авторизации и аутентификации, а также дополнительные сетевые правила, чтобы разрешить доступ к ним только определенным диапазонам IP-адресов.

Если это так, вы можете настроить сеть SageMaker следующим образом.

Разрушение вещей:

  • Создайте виртуальное частное облако (VPC) с общедоступной и частной подсетями. Предположим, что у нас есть только одна частная и одна общедоступная подсеть в одной зоне доступности (AZ).
  • SageMaker будет работать в частной подсети.
  • Создайте шлюз NAT в общедоступной подсети. Эластичный IP-адрес должен быть создан и подключен к шлюзу NAT.
  • В таблице маршрутов обновите маршрут, чтобы исходящий трафик от SageMaker направлялся на шлюз NAT.
  • Настройте конечную точку S3 VPC, чтобы весь трафик SageMaker, связанный с S3, направлялся через нее.

В группе безопасности (SG) сервера данных измените правило для входящего трафика, чтобы разрешить IP-адрес эластичного IP-адреса, подключенного к шлюзу NAT.

Если вам необходимо безопасно хранить учетные данные для авторизации учебного задания SageMaker на сервере данных, вы можете сохранить эти учетные данные в AWS Secrets Manager и добавить функцию в сценарий ввода SageMaker для считывания учетных данных из Secrets Manager.

Зачем нам нужна конечная точка S3 VPC?

Если вы решите использовать управляемый шлюз NAT, предоставляемый AWS, с вас будет взиматься плата за каждый час, в течение которого ваш шлюз NAT доступен, и за каждый гигабайт данных, которые он обрабатывает, как только вы предоставляете шлюз NAT. Если вы загружаете большие объемы необработанных данных из S3, вы будете много платить за эти передачи данных. Вот когда S3 VPC Endpoint пригодится. Если вы подключите конечную точку S3 VPC к своему VPC, весь входящий и исходящий трафик S3 (в том же регионе) не будет проходить через шлюз NAT (и сэкономит вам деньги).

При запуске задания SageMaker

Запишите идентификатор частной подсети, который вы назначили для запуска задания SageMaker. При создании объекта SageMaker Estimator укажите следующие идентификаторы:

estimator = Estimator(
                      ......,
                      subnets=['subnet_id_1', 'subnet_id_2'],
                      .......)

Если бы

Чего до сих пор не хватает AWS, так это конечной точки шлюза VPC для ECR. Образы Docker могут быть довольно большими (особенно для проектов глубокого обучения из-за огромных библиотек глубокого обучения + материалов, связанных с CUDA). В настоящее время трафик для загрузки образов ECR будет проходить через NAT Gateway. Я бы хотел, чтобы в ближайшем будущем AWS добавила конечную точку шлюза VPC для ECR.