Вопросы на собеседовании: AWS-инженер

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

• В VPC с сетью /16 можно зарезервировать по /20 на каждый тип подсети и зону, оставив адресное пространство для роста без перенумерации.
• Публичные подсети используются для внешних балансировщиков, приватные для приложений, а базы данных остаются в изолированных подсетях без маршрута в интернет по умолчанию.
• Каждая приватная подсеть выходит через NAT Gateway в своей зоне, чтобы отказ зоны не создавал межзональную зависимость для исходящего трафика.

AWS сначала выбирает самый специфичный совпавший префикс, а при одинаковых префиксах применяет правила приоритета маршрутов.

• Маршрут 10.20.4.0/24 выигрывает у 10.20.0.0/16 независимо от того, ведет ли он в Transit Gateway, peering-соединение или сетевой интерфейс.
• При одинаковом префиксе статический маршрут обычно выигрывает у распространяемого, а локальный маршрут VPC нельзя удалить или перекрыть менее специфичной записью.
• Я проверяю таблицы прямого и обратного пути, потому что stateful security groups не исправляют асимметричную маршрутизацию через stateful appliance.

Я использую gateway endpoints для приватного доступа к S3 или DynamoDB, а interface endpoints для сервисов, доступных через AWS PrivateLink.

• Gateway endpoint добавляет маршруты с prefix list в выбранные таблицы и не имеет почасовой платы за endpoint.
• Interface endpoint создает приватные IP-адреса в выбранных подсетях, использует security groups и private DNS, а также тарифицируется по часам и объему данных.
• Endpoint policy ограничивает доступные вызывающей стороне ресурсы, но IAM и resource policies по-прежнему определяют разрешение каждого API-вызова.

Я бы разместил сервис провайдера за Network Load Balancer и опубликовал VPC endpoint service для одобренных потребителей.

• Потребители создают interface endpoints в своих подсетях, поэтому сторонам не нужны маршрутизируемые CIDR, VPC peering или широкий сетевой доступ.
• Я требую явного принятия endpoint connection, если его нельзя безопасно автоматизировать списком разрешений, и по возможности ограничиваю сервис IAM-принципалами.
• Для private DNS нужно подтвердить владение доменом, а потребителю включить private DNS, чтобы имя сервиса разрешалось в IP-адреса endpoint.

Я бы разделил домены маршрутизации несколькими таблицами Transit Gateway и связал каждое подключение с таблицей его доверенной зоны.

• Подключения spoke распространяют маршруты в таблицу shared services только там, где нужна связность, вместо одной таблицы с полносвязной сетью.
• Таблица production может направлять префиксы общих сервисов к нужному подключению и не содержать маршрутов к development VPC, изолируя их отсутствием маршрута.
• Я проектирую симметричные пути через appliances в inspection VPC и включаю appliance mode, когда поток должен оставаться на одном зональном пути через firewall.

Я выбираю политику по требуемому решению о направлении трафика, а не по количеству endpoints.

• Weighted records распределяют трафик по заданным долям для canary, а latency records выбирают регион AWS с наименьшей измеренной сетевой задержкой.
• Failover records объединяют основной и резервный targets с проверкой здоровья, а geolocation records выбирают по географии клиента и требуют запись по умолчанию.
• DNS TTL определяет скорость появления изменений у клиентов, но кэш рекурсивных резолверов не позволяет Route 53 мгновенно остановить новые подключения.

Я бы использовал inbound и outbound endpoints Route 53 Resolver с правилами условной пересылки через Direct Connect или VPN.

• Локальный DNS пересылает запросы к приватным зонам AWS на IP-адреса inbound endpoints, размещенных минимум в двух зонах доступности.
• К VPC привязываются outbound rules, например для corp.example.com, которые через outbound endpoints отправляют запросы локальным DNS-серверам.
• Security groups разрешают UDP и TCP на порту 53 в нужном направлении, а stateless network ACL также должны пропускать DNS-запросы на порт назначения 53 и обратный трафик к ephemeral ports клиента.

Я выбираю ALB для маршрутизации с пониманием HTTP, а NLB для производительности четвертого уровня, статических IP или протоколов помимо HTTP.

• ALB маршрутизирует по host, path, header или query string и интегрируется с WAF, а NLB передает TCP, TLS, UDP или TCP_UDP потоки.
• Завершение TLS на балансировщике централизует ACM-сертификаты и политики, а повторное шифрование до HTTPS targets защищает участок до приложения.
• TLS passthrough на NLB сохраняет end-to-end завершение в приложении, но лишает возможности инспекции запросов ALB и управляемой HTTP-маршрутизации.

Trust policy определяет, кто может принять роль, а permissions policies определяют действия, доступные сессии принятой роли.

• Trust policy является resource-based policy роли и задает principals и условия, например ExternalId, исходный аккаунт или OIDC claims.
• Для IAM user или role из того же аккаунта, прямо указанного как principal, trust policy может быть достаточно для AssumeRole без отдельного разрешения в identity policy при выполнении ее условий.
• Cross-account принятие роли обычно требует sts:AssumeRole в identity policy вызывающей стороны и совпадающего доверия целевой роли; permissions boundaries, SCP, session policies и любой explicit deny могут ограничить принятие роли или полученную сессию.

Role chaining создает новую сессию роли из временных учетных данных, а session policy может только сузить разрешения новой сессии.

• Продолжительность сессии при chaining ограничена одним часом, даже если целевая роль допускает более долгую сессию.
• Итоговые разрешения являются пересечением policies роли и inline либо managed session policies, переданных в STS.
• Я передаю session tags для атрибутного контроля и делаю transitive только те теги, которые действительно нужны следующей роли в цепочке.

Я использую permissions boundary как максимальный набор разрешений при делегированном создании ролей или пользователей, а не как policy, которая сама выдает доступ.

• Платформенная роль может позволить команде создавать прикладные роли только при наличии предписанной boundary у каждой новой роли.
• Итоговые identity permissions являются пересечением attached identity policies и boundary, поэтому AdministratorAccess не может выйти за ее пределы.
• Resource policies, SCP, session policies и explicit denies участвуют отдельно, поэтому полный путь авторизации я проверяю через Policy Simulator или CloudTrail.

SCP задает максимум доступных разрешений для principals в member accounts, но сам не разрешает ни одного API-действия.

• Действие должно быть разрешено применимым SCP и IAM, а explicit deny на любом из этих уровней имеет приоритет.
• Permissions boundary ограничивает конкретный principal, а SCP ограничивает затронутые аккаунты или organizational units, включая создаваемые в них роли.
• SCP не ограничивает management account и не изменяет напрямую resource-based permissions для principals за пределами организации.

Я предпочитаю роль в целевом аккаунте с узкой trust policy и минимальными permissions, которую принимает именованный principal исходного аккаунта.

• Исходному principal нужен доступ sts:AssumeRole, а целевая trust policy ограничивает principal и добавляет условия вроде aws:PrincipalOrgID там, где это уместно.
• Для стороннего клиента я требую уникальный ExternalId против confused deputy, но не считаю его секретом или заменой ограничения principal.
• Прямая resource policy подходит для S3 или KMS, но принятая роль дает единообразные временные credentials и ясную session identity в CloudTrail.

Envelope encryption шифрует данные сгенерированным data key, а сам data key шифруется ключом KMS.

• Приложение вызывает GenerateDataKey, локально шифрует payload открытым data key, хранит зашифрованный data key рядом с ciphertext и удаляет открытый ключ.
• При расшифровке зашифрованный data key отправляется в KMS, после чего возвращенный открытый ключ используется локально без KMS-вызова для каждого блока данных.
• Key policy KMS должна разрешать principal или делегирование через IAM, а условия encryption context могут привязать Decrypt к конкретному приложению или ресурсу.

Я бы хранил учетные данные в Secrets Manager и использовал rotation Lambda, которая последовательно меняет secret по документированным staging labels.

• Функция создает AWSPENDING, обновляет пользователя базы, проверяет ожидающие credentials и переносит AWSCURRENT только после успешного теста.
• Ротация с чередующимися пользователями уменьшает промежуток конфликта старых подключений и новых данных, если привилегии пользователей одинаковы.
• Приложения получают текущий secret во время работы с ограниченным кэшем и при ошибке авторизации повторяют запрос после обновления кэша, а не встраивают значение при деплое.

Я бы задал несколько совместимых типов инстансов и объединил стабильную базу On-Demand с диверсифицированной Spot capacity.

• Attribute-based instance selection или явные overrides сохраняют совместимость vCPU, памяти и архитектуры с образом приложения.
• Capacity-optimized распределение Spot снижает риск прерываний, а база On-Demand покрывает минимальную capacity для постоянной нагрузки.
• Масштабирование опирается на целевую метрику вроде ALB requests per target, а instance refresh раскатывает версии с сохранением заданного процента здоровых инстансов.

Я бы считал каждую номерную версию launch template неизменяемым артефактом релиза и при каждом продвижении явно закреплял Auto Scaling group за конкретной версией.

• Pipeline создает новую номерную версию с протестированными AMI и конфигурацией, записывает ее номер вместе с релизом и обновляет ASG только после проверки; production никогда не ссылается на `$Latest` или `$Default`.
• При каждом продвижении запускается instance refresh с заданной минимальной долей здоровых инстансов, временем прогрева, alarms и checkpoints после небольших долей замены, чтобы pipeline проверял здоровье сервиса во время каждой паузы и останавливал неудачную раскатку.
• Если checkpoint или alarm отклоняет релиз, я откатываю refresh к последней заведомо исправной закрепленной версии и сверяю с ней каждый инстанс; automatic rollback может выполнять тот же сценарий, поскольку ни одно состояние ASG не использует динамическую ссылку на версию.

Lifecycle hooks приостанавливают запуск или завершение инстанса, чтобы автоматизация успела закончить работу до продолжения Auto Scaling.

• Launch hook может установить конфигурацию, зарегистрировать внешний агент или прогреть большой кэш перед ответом CONTINUE.
• Termination hook может завершить прием задач или выгрузить локальное состояние, а deregistration delay балансировщика отдельно обслуживает текущие запросы.
• EventBridge или SNS доставляет событие автоматизации, а heartbeat продлевает timeout только для ограниченной работы, а не скрывает зависший процесс.

Я выбираю Fargate, когда важны изоляция задач и минимум работы с хостами, а ECS на EC2, когда контроль хоста или постоянная загрузка оправдывают управление fleet.

• Fargate тарифицирует заказанные task vCPU и память, снимает патчинг узлов и поддерживает простые capacity providers для serverless tasks.
• EC2 может быть дешевле при плотной постоянной нагрузке и поддерживает специальные AMI, GPU, daemon-агенты и больший выбор инстансов.
• Оба варианта используют ECS services, task definitions, IAM task roles и балансировку, поэтому я сохраняю переносимость deployment artifacts там, где позволяют возможности платформы.

AWS запускает высокодоступные Kubernetes API server и etcd control plane, а я отвечаю за доступ к кластеру, workloads, сеть, add-ons и worker capacity.

• Control plane работает в нескольких зонах доступности и имеет настраиваемые публичный и приватный API endpoints, а audit и API logs можно отправить в CloudWatch.
• Я по-прежнему настраиваю EKS access entries и access policies, RBAC, Pod Security controls, network policies и работу с secrets.
• Основным add-ons VPC CNI, CoreDNS и kube-proxy нужны совместимые версии и плановые обновления, даже если они установлены как EKS managed add-ons.