S3: конечная точка шлюза или интерфейса для доступа из локальной сети

Два типа конечных точек S3 выглядят взаимозаменяемыми при обзоре проекта и ведут себя совершенно по-разному, как только клиент оказывается за пределами площадки. Конечная точка шлюза — это интеграция с таблицей маршрутов внутри VPC, поэтому запрос из VPN площадки никогда не приходит к ней как к частному пункту назначения. Конечная точка интерфейса размещает частные адреса на сетевых интерфейсах, и до неё гибридный путь действительно может добраться. Всё дальнейшее зависит от того, какой из двух вариантов вы выбрали.

Решайте по сетевому входу, а не по имени сервиса

Начните с того места, где возникает трафик, потому что именно на этот вопрос отвечает тип конечной точки. Рабочая нагрузка в поддерживаемом контексте VPC может использовать конечную точку шлюза и никогда не нуждается в собственном частном адресе. Рабочей нагрузке на площадке нужен частный адрес, на который она может маршрутизировать, и именно это обеспечивает конечная точка интерфейса. Если проект смешивает оба варианта, оба типа конечных точек могут сосуществовать в одной VPC, и это нормальная схема, а не дублирование.

Их смешивание — не проблема. Проблема — предполагать, что один тип покрывает другой.

Классифицируйте клиента, прежде чем что-либо выбирать. Рабочее пространство внутри VPC, контейнер за шлюзом NAT и приложение в филиале — это три разных источника, и только последний вынуждает использовать гибридный вход. Запишите эту классификацию рядом с перечнем конечных точек, чтобы следующий проверяющий видел, почему существует каждая конечная точка.

Что требует интерфейсный путь от начала до конца

Конечная точка интерфейса даёт достижимость частных адресов, и достижимость — лишь одно из четырёх требований. Локальной сети нужен маршрут к этим адресам, стороне VPC нужен обратный путь, группа безопасности конечной точки должна пропускать диапазон источника, а любое средство проверки между ними должно разрешать поток. Маршрут к любому экземпляру в VPC не доказывает ни одного из четырёх.

Работайте от дальнего конца назад. Убедитесь, что сетевые интерфейсы конечной точки существуют в ожидаемых подсетях, затем убедитесь, что её группа безопасности пропускает реальный локальный диапазон, а не заполнитель. После этого проверьте, несёт ли туннель или канал обратный путь в том же направлении. Проверка — это шаг, который люди пропускают, потому что промежуточное устройство, разрешающее соединение, всё ещё может отбросить более крупное тело ответа, и это выглядит как проблема пропускной способности, а не политики.

Тестируйте самой маленькой доступной разрешённой операцией, а не большой загрузкой. Сбой проявляется раньше и с меньшим объёмом трафика, который нужно объяснять.

DNS следует за источником запроса, а не за VPC

Существующая конечная точка сама по себе ничего не перенаправляет. Приложение получает то имя, которое вернул его распознаватель, а распознаватель отвечает согласно представлению, которое ему разрешено видеть. Экземпляр внутри VPC и ноутбук в офисе задают два разных вопроса, и оба могут получить правильные, но разные ответы. Проверить одно и сделать вывод о другом — это путь, которым пройденный тест превращается в провальное развёртывание.

Читайте частную настройку DNS конечной точки как часть проекта, а не как флажок, который включают после запуска.

Если распознаватель офиса должен видеть представление VPC, этот путь нужно построить намеренно, обычно через входящую конечную точку распознавателя. Запрашивайте из собственного контекста приложения и отмечайте, какой распознаватель ответил. Результат, собранный на бастионном хосте внутри VPC, описывает представление бастиона и ничего больше.

Разрешение отделено от достижимости

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

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

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Записывайте имя конечной точки, разрешённый пункт назначения и контекст политики рядом с каждым результатом, потому что одно последующее изменение DNS может аннулировать весь вывод. Сравните текущую стоимость и операционную нагрузку обоих типов конечных точек, прежде чем что-либо разворачивать. Конечная точка интерфейса покупает гибридный частный вход, это не универсальное требование, и путь через шлюз часто остаётся лучшим ответом для рабочих нагрузок внутри VPC. Выбор делается для каждого клиента и остаётся пересматриваемым.