Шлюз S3 или интерфейсная конечная точка для локального клиента?

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

Разделите типы конечных точек по тому, где начинается запрос

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

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

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Читайте столбец Type, а не имя. Одна VPC обычно содержит оба типа для одной и той же службы, и запись, нужная вашему локальному приложению, — интерфейсная.

Постройте путь к адресу интерфейса до того, как тестировать S3

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

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

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

Первая команда показывает, какой интерфейс использовал бы клиент. Вторая доказывает рукопожатие TCP. Третья доказывает, что TLS завершается сертификатом, действительным для имени конечной точки, и именно эта проверка ловит неверный адрес до того, как вы обвините разрешения.

Решите, какой ответ DNS получает приложение

Наличие интерфейсной конечной точки в VPC само по себе не перенаправляет локальный SDK. Клиент использует либо имя, специфичное для конечной точки, которое AWS публикует для неё, либо частную размещённую зону, которую вы намеренно сделали разрешимой из офиса.

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

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

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

Достижимость — не авторизация

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

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

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