12 вопросов по AWS, которые реально спрашивают на собеседованиях — и что за ними стоит

Один из авторов Dev.to провёл более 40 собеседований по AWS-сетевым технологиям и собрал 12 самых частых вопросов. Разбираем каждый — не ради заучивания, а чтобы понять, что на самом деле проверяет интервьюер.

Интервьюер спрашивает не «что такое NAT-шлюз», а «почему эта EC2-инстанция не выходит в интернет». Диагностика — это навык, отличный от перечисления определений, и именно его слушают.

Зачем это нужно

Статья опубликована на Dev.to автором, который использует платформу LastRound AI для тренировки собеседований. Стоит сразу уточнить: текст содержит скрытую рекламу этого сервиса — автор упоминает статистику платформы и ссылается на их продукт в конце. Но сам по себе список вопросов и разбор логики интервьюера полезен независимо от того, пользуетесь вы этим инструментом или нет.

По данным автора, за период с января 2025 по июль 2026 года на платформе было проведено 1393 собеседования, из которых 464 пришлись на DevOps-инженерию — больше, чем на бэкенд, фронтенд и фулстек вместе взятые. Конкуренция за такие позиции реальна, и планка постоянно растёт.

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

1. Почему нельзя изменить размер CIDR-блока VPC после создания?

Укоротить — нельзя. Можно добавить вторичные CIDR-блоки, и именно это большинство людей подразумевают, когда говорят «изменить размер».

Здесь проверяется не знание документации, а привычка планировать адресное пространство заранее. Блок /16 даёт 65 536 адресов и не стоит ни цента больше, чем /24 с его 251 полезным адресом. Правильная стратегия — выделять с запасом, а подсети нарезать консервативно.

Автор приводит реальный случай: команда потратила две недели на миграцию рабочих нагрузок, потому что кто-то изначально выбрал /24 для «маленького внутреннего сервиса», который вырос.

Слабый ответ — просто «добавляете ещё один CIDR». Это правда, но неполная. Сильный ответ упоминает, что вторичные CIDR-блоки не должны пересекаться ни с существующими, ни с пировыми VPC. Именно эта ловушка и кусается потом на продакшене.

2. Что на самом деле делает подсеть публичной?

Маршрут к интернет-шлюзу (Internet Gateway) в таблице маршрутизации. Ничего больше.

Не имя. Не галочка «автоматически назначать публичный IP» — хотя она влияет на то, получат ли инстанции адрес. Подсеть с красивым названием public-subnet-1a, но без маршрута к IGW — это приватная подсеть с обманчивым именем. Автор говорит, что дважды отлаживал именно такую ситуацию.

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

3. Security Group и Network ACL: когда разница принципиальна?

Security Group — stateful (запоминает состояние) и работает на уровне инстанса. Network ACL (NACL) — stateless (не запоминает) и работает на границе подсети.

Ключевое слово — «stateless». Если вы разрешите входящий трафик на порт 443 в NACL, но забудете прописать исходящий диапазон эфемерных портов, запрос дойдёт, а ответ никогда не отправится. Выглядит это как таймаут, а не как отказ — и именно поэтому такие баги съедают часы отладки.

Security Group по умолчанию запрещает всё и не имеет явного правила «deny». NACL обрабатывает правила по номерам и останавливается на первом совпадении — так что широкий запрет на позиции 100 делает правило на позиции 200 бесполезным.

Если кандидат может объяснить, зачем вообще нужен NACL при наличии Security Group, он, скорее всего, что-то реальное эксплуатировал. Честный ответ: редко, в основном для массовых блокировок IP на границе подсети.

4. Проведите диагностику: почему EC2 в приватной подсети не выходит в интернет?

Это главный вопрос, и отвечать на него нужно как цепочку — вслух, по порядку:

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

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

5. NAT Gateway или NAT Instance?

NAT Gateway — почти всегда. Управляется AWS, масштабируется автоматически, не нужно патчить.

Интереснее вопрос цены. Многие воспринимают стоимость NAT Gateway как неизбежные расходы — и зря. Вы платите почасово плюс за каждый гигабайт обработанных данных. Именно стоимость за гигабайт удивляет команды, которые тянут через NAT-шлюз контейнерные образы или отправляют логи.

Кандидат, который упоминает VPC Endpoints как способ направить трафик к S3 и ECR в обход NAT-шлюза, видел счёт. Это настоящий сигнал, потому что означает реальный опыт.

6. Gateway Endpoints и Interface Endpoints

Gateway Endpoints покрывают S3 и DynamoDB, привязываются к таблице маршрутов и бесплатны. Interface Endpoints используют PrivateLink, создают сетевой интерфейс (ENI) в вашей подсети, работают с большинством других сервисов и стоят денег — почасово плюс за гигабайт.

Ловушка, на которой спотыкаются: Gateway Endpoints не работают через VPC Peering и через Direct Connect из онпрема — потому что это конструкции таблицы маршрутов, локальные для VPC. Interface Endpoints через эти каналы проходят. Если кто-то уверенно говорит «просто используйте эндпоинт» для гибридной инфраструктуры — вот пробел в знаниях.

7. VPC Peering или Transit Gateway?

Пиринг — точка-к-точке и нетранзитивный. Три VPC, которым нужно общаться друг с другом, — три пиринговых соединения. Десять VPC — сорок пять.

Рост по формуле n(n-1)/2 — и есть весь аргумент в пользу Transit Gateway, который работает как концентратор и маршрутизирует между подключениями. Компромисс — плата за каждое подключение плюс за гигабайт, так что для двух-трёх VPC пиринг обычно дешевле и проще.

«Нетранзитивный» — слово, которое важно. Если A пирует с B, а B пирует с C, то A не может достучаться до C. Кандидаты часто повторяют «нетранзитивный» как заученную фразу, не умея объяснить, что это значит на практике. Попросите нарисовать — и сразу станет ясно.

8. Что происходит, когда записи в таблице маршрутов перекрываются?

Побеждает наиболее длинное совпадение префикса. Маршрут для 10.0.1.0/24 в приоритете над маршрутом для 10.0.0.0/16 для трафика к 10.0.1.5 — вне зависимости от порядка записей.

Люди часто думают, что правила оцениваются сверху вниз, как в NACL. Это не так. В одном сетевом стеке AWS — три модели обработки: таблицы маршрутов работают по длине префикса, NACL — по порядку номеров, Security Groups — без порядка, только разрешающие. Признать вслух, что это запутанно, — нормально. Это показывает, что вы понимаете модели, а не зубрили одну из них.

9. Почему DNS иногда не работает внутри VPC, даже когда маршрутизация правильная?

Два атрибута VPC управляют этим: enableDnsSupport и enableDnsHostnames. Первый включает Route 53 Resolver по адресу .2 в вашем CIDR. Второй определяют, получают ли инстансы публичные DNS-имена.

Выключите поддержку — резолвинг сломается полностью. Оставьте hostnames выключенными — приватные зоны начнут вести себя так, будто проблема в маршрутизации. Оба параметра по умолчанию ведут себя по-разному в зависимости от того, создавался ли VPC через консоль или через Terraform. Поэтому всё работает в первом окружении и ломается во втором.

Последняя деталь — из тех, что знаешь только если наступил.

10. Как меж-AZ-трафик влияет на стоимость и архитектуру?

Трафик между зонами доступности (Availability Zones) тарифицируется в обе стороны. Внутри одной зоны — бесплатно.

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

Универсального правила, где проходит граница, не существует. Зависит от того, насколько сервис «разговорчив» и какова ваша реальная цель по доступности. Кто-то, кто предлагает универсальный ответ, — что-то продаёт.

11. Почему кластеры EKS исчерпывают лимит подов раньше, чем процессор?

AWS VPC CNI назначает каждому поду реальный IP из подсети через сетевые интерфейсы (ENI), прикреплённые к ноде. Каждый тип инстанса поддерживает фиксированное количество ENI и фиксированное число IP на каждый ENI — так что плотность подов ограничена типом инстанса, а не только ресурсами.

t3.medium поддерживает 3 ENI по 6 IP каждый, минус один адрес для ноды. Итого — 17 подов, сколько бы свободного процессора ни было.

Вторая половина ответа — размер подсети. /24 даёт 251 полезный адрес, а кластер, который масштабируется до 200 подов, исчерпает