12 вопросов по сетям AWS на собеседовании: что на самом деле слушает интервьюер

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

Задача интервьюера — не проверить, выучили ли вы определение NAT-шлюза, а понять, сможете ли вы починить связь, когда она неожиданно отвалится.

Каждый, кто пытается устроиться на позицию инженера по эксплуатации или DevOps в компании, использующей AWS, рано или поздно сталкивается с блоком вопросов по облачным сетям. И многие готовятся к ним, как к экзамену — зубрят термины и схемы. Однако интервьюеры зачастую смотрят не на то, что вы отвечаете, а на как вы это делаете: строите ли вы логическую цепочку или просто перечисляете факты из документации.

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

Планирование прежде всего: адресное пространство и его границы

Почему нельзя изменить размер CIDR-блока VPC после создания? Здесь кроется классическая ловушка. Да, «уменьшить» уже выделенный диапазон IP-адресов нельзя, но можно добавить дополнительные блоки. Суть вопроса не в техническом ограничении, а в вашем подходе к планированию. Хороший инженер будет закладываться с запасом (например, сразу выбирать /16 вместо /24), потому что переезд сервисов из-за нехватки адресов — это больно, долго и дорого. Если кандидат упоминает, что новые блоки не должны пересекаться с существующими или с пированными VPC, это явный плюс.

Что на самом деле делает подсеть публичной? Некоторые путают настройки и названия. Публичность подсети определяется исключительно наличием в её таблице маршрутов записи, ведущей к интернет-шлюзу (Internet Gateway). Никакие другие настройки — даже автоматическое назначение публичного IP — её не создают. Вопрос отлично отделяет тех, кто видел консоль AWS, от тех, кто только изучал схему в презентации.

Диагностика: когда нужно не назвать, а найти

Security Group и Network ACL: в чем разница и когда это важно? Тут ключевое слово — «stateful» (отслеживает состояние) для Security Group и «stateless» (не отслеживает) для NACL. Это фундаментально. Если вы на NACL разрешите входящий трафик на порт 443, но забудете открыть исходящие «эфемерные» порты для ответов, соединение просто зависнет. Вопрос проверяет, понимаете ли вы эту модель. А если кандидат может внятно объяснить, зачем вообще использовать NACL при наличии Security Group (например, для массовой блокировки IP на границе подсети), это верный признак реального опыта.

«Проведите меня через причину, почему EC2-инстанс в приватной подсети не имеет доступа к интернету». Это центральный вопрос, и его нужно пройти вслух, как цепочку. Слабый ответ — перечислить «NAT-шлюз, таблица маршрутов». Сильный ответ — последовательно:

1. В таблице маршрутов приватной подсети есть запись 0.0.0.0/0, указывающая на NAT-шлюз.
2. NAT-шлюз сам расположен в публичной подсети.
3. В таблице маршрутов этой публичной подсети есть запись 0.0.0.0/0, ведущая к интернет-шлюзу.
4. У NAT-шлюза есть эластичный IP.
5. Security Group инстанса разрешает исходящий трафик.
6. NACL обеих подсетей (и приватной, и публичной) разрешают и исходящий запрос, и входящий ответ на эфемерный порт.
7. DNS-резолвинг работает (это отдельная, часто незаметная точка отказа).

Умение пройти этот путь — это именно то, что отличает отладчика от гадателя.

Стоимость и выбор правильного инструмента

NAT Gateway или NAT Instance? Для большинства случаев ответ — управляемый NAT Gateway. Но здесь испытывают ваше понимание экономики облака. Люди воспринимают плату за NAT Gateway как неизбежность, но она состоит из почасовой ставки и платы за каждый гигабайт. Если ваш сервис постоянно тянет образы контейнеров или отправляет логи, счет может удивить. Кандидат, который упомянет VPC Endpoint для трафика к S3 и ECR, показывает, что он не только строил, но и оплачивал счета.

Gateway Endpoint vs Interface Endpoint? Здесь снова вопрос понимания архитектуры и ограничений. Gateway Endpoint (для S3 и DynamoDB) бесплатен, но работает только в пределах VPC — через VPC Peering или из он-према через Direct Connect он не пройдет. Interface Endpoint (PrivateLink) платный, но более универсален. Уловить это различие в гибридных сценариях — настоящий навык.

VPC Peering или Transit Gateway? Ключевое здесь — «нетранзитивность» (non-transitive) пиринга. Если A пирует с B, а B — с C, то A не видит C. Для связи 10 VPC вам понадобится уже 45 пиринговых связей — это математическая формула, которая и объясняет рождение Transit Gateway как «хаба». Вопрос проверяет не столько знание сервисов, сколько понимание топологий сетей и способность оценить компромисс между простотой, стоимостью и масштабируемостью.

Нюансы, которые ловят на опыте

Что происходит при пересечении записей в таблице маршрутов? В таблице маршрутов побеждает наиболее длинный префикс (longest prefix match). Правило для /24 будет приоритетнее, чем для /16, даже если оно идет вторым. Это отличается от NACL, где правила читаются по порядку. Три разные модели оценки (для Security Group, NACL и маршрутов) в одном сетевом стеке — это действительно сложно, и честное признание этого — хороший знак.

Почему DNS иногда не работает внутри VPC, даже когда маршрутизация в порядке? Ответ лежит в атрибутах VPC: enableDnsSupport и enableDnsHostnames. Их значения по умолчанию могут различаться в зависимости от того, создавали ли вы VPC через консоль или через Terraform. Эта «мелочь» приводит к тому, что всё прекрасно работает в одной среде и таинственным образом ломается в другой. Такие детали знают только те, кто с ними «обжигался».

Как трафик между зонами доступности (AZ) влияет на стоимость и дизайн? Трафик между AZ взимается в обе стороны, в то время как внутри одной AZ он бесплатен. Это заставляет принимать непростое решение: иногда связные между собой сервисы, которые должны быть в одной зоне отказа, выгоднее поместить в одну AZ, жертвуя отказоустойчивостью ради экономии. Любой, кто дает универсальный ответ «всегда используйте три AZ», скорее всего, не смотрел детальную разбивку счета за Data Transfer.

Когда сети встречаются с Kubernetes

Почему кластеры EKS сначала исчерпывают лимит подов, а не ресурсы CPU? Это вопрос на стыке облачных и контейнерных технологий. В AWS VPC CNI каждый под получает настоящий IP-адрес из подсети, который привязывается к Elastic Network Interface (ENI) на ноде. Каждый тип инстанса поддерживает ограниченное количество ENI и IP на каждом из них. Например, t3.medium может запустить не более 17 подов — сколько бы свободного CPU у вас ни было. Вопрос также поднимает проблему правильного размера подсети. Решение — Prefix Delegation, но оно быстрее «съедает» адресное пространство. Здесь и требуется глубокое понимание обеих систем.

Решение конфликтов и переосмысление задач

Можно ли соединить пирингом две VPC с пересекающимися CIDR-блоками? Нет, запрос просто не пройдет. Но собеседование на этом не заканчивается. Что вы предложите? Самый простой, но самый сложный путь — изменить адресацию одной из VPC. Самый гибкий, но самый дорогой — использовать NAT-слой. А самый элегантный и правильный в современных архитектурах — использовать PrivateLink, чтобы не объединять сети, а сделать нужный сервис доступным из другой VPC. Этот ответ показывает, что вы умеете переосмысливать задачу, а не просто искать «костыль».

Как подготовиться? Просто прочитать эти вопросы — мало. Нужно уметь озвучить свои ответы, выстраивая логическую цепочку, как в четвертом пункте. Попробуйте объяснять вслух, стоя, записывая себя на таймер. Только так вы поймете, где знания на самом деле «спотыкаются». В реальном интервью именно умение сохранять спокойствие и мыслить структурированно, когда вас прерывают уточняющим вопросом, и становится решающим фактором. Это не проверка памяти, а проверка инженерного мышления в действии.