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. Вибір робиться для кожного клієнта і залишається перегляданим.