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

Регион AWS представляет собой отдельную географическую область, в которой AWS управляет несколькими зонами доступности.

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

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

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

Пограничные точки присутствия приближают отдельные сервисы AWS к пользователям без развертывания всей нагрузки в каждой точке.

• CloudFront кэширует контент в пограничных точках, что сокращает задержку и нагрузку на источник.
• Route 53 и AWS Shield также используют глобальную пограничную сеть для ответов DNS и защиты трафика.
• Пограничная точка не является зоной доступности, поэтому вычисления и базу данных приложения я по-прежнему размещу в регионе.

AWS защищает инфраструктуру облака, а клиент отвечает за безопасность того, что он настраивает и запускает в облаке.

• AWS отвечает за площадки, физическое оборудование, базовые сетевые и виртуализационные уровни.
• Клиент управляет учетными данными, доступом к данным, сетевыми правилами и обновлениями гостевой ОС на EC2.
• Граница зависит от уровня управляемости сервиса: AWS обновляет хост RDS, а я управляю пользователями базы, шифрованием и настройками.

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

• Создание бакета S3, изменение политики IAM или запуск инстанса EC2 выполняются через API плоскости управления.
• Чтение объекта S3 или обработка запроса приложения на инстансе относятся к плоскости данных.
• Я разделяю их права и мониторинг, потому что оператору может быть нужен деплой ресурса без доступа к обрабатываемым данным клиентов.

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

• Группа может выдать нескольким пользователям IAM одинаковые рабочие политики, но принять группу как роль нельзя.
• EC2, Lambda, федеративные сотрудники и субъекты из других аккаунтов должны принимать роли вместо хранения ключей доступа.
• Для сотрудников я предпочту IAM Identity Center, а пользователей IAM оставлю только для случаев, где они действительно необходимы.

AWS разрешает запрос, только если подходящая политика разрешает его и ни одна применимая политика явно не запрещает его.

• Изначально действует неявный запрет, поэтому без подходящего оператора Allow доступ будет отклонен.
• Явный Deny имеет приоритет над Allow из политики идентичности или политики ресурса.
• Границы разрешений и политики организации могут ограничить Allow, но сами по себе разрешений не выдают.

Принцип минимальных привилегий означает выдачу только тех действий и ресурсов, которые нужны для конкретной задачи.

• Я заменю широкое действие вроде s3:* точными операциями, например s3:GetObject для одного префикса бакета.
• При необходимости я добавлю условия, например обязательный запрос через определенный VPC endpoint или наличие тега ресурса.
• Я буду проверять события CloudTrail и результаты IAM Access Analyzer, чтобы удалять неиспользуемые нагрузкой права.

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

• Централизованный корневой доступ в AWS Organizations позволяет удалить корневые учетные данные аккаунтов-участников; в остальных случаях у root не должно быть ключей доступа, для него нужна надежно хранимая MFA, а использовать его следует только для root-задач.
• IAM Identity Center позволяет централизованно требовать MFA для входа сотрудников вместо настройки отдельных пользователей IAM.
• MFA снижает ущерб от украденного пароля, но рабочие нагрузки должны использовать роли, а не интерактивную MFA или постоянные ключи.

AWS Security Token Service выдает временные учетные данные для принятой роли или федеративной сессии.

• В них входят идентификатор ключа доступа, секретный ключ, токен сессии и срок действия.
• Сервис, пользователь или внешняя учетная запись принимает роль и получает только права, назначенные этой сессии.
• Истекающие учетные данные сокращают полезный срок утечки и позволяют не раздавать постоянные ключи инстансам EC2 или задачам CI.

CIDR-блок VPC определяет диапазон частных IP-адресов, из которого подсети получают свои адреса.

• Я выберу диапазон с запасом для ожидаемых подсетей и роста, потому что каждая подсеть занимает его часть.
• Я исключу пересечение с офисными сетями, другими VPC и планируемыми сетями партнеров, чтобы позже можно было настроить маршрутизацию.
• Для IPv4 я обычно возьму частный диапазон RFC 1918, например 10.20.0.0/16, и разделю его на меньшие CIDR подсетей.

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

• Ресурсу в публичной подсети также нужен публичный IPv4-адрес или IPv6-адрес и подходящие правила безопасности.
• Публичные балансировщики я размещу в публичных подсетях, а инстансы приложения и базы данных в приватных.
• Приватные ресурсы могут устанавливать исходящие IPv4-соединения через NAT-шлюз, не принимая незапрошенный входящий трафик из интернета.

Таблица маршрутов сопоставляет CIDR назначения с целями вроде локального пути VPC, интернет-шлюза или NAT-шлюза.

• Каждая подсеть связана с одной таблицей явно либо через главную таблицу маршрутов VPC.
• Встроенный локальный маршрут позволяет подсетям одного VPC обмениваться данными, если трафик не блокируют средства безопасности.
• Если подходят несколько маршрутов, AWS выбирает самый конкретный префикс, поэтому 10.0.1.0/24 имеет приоритет над 10.0.0.0/16.

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

• Я подключаю один интернет-шлюз к VPC и добавляю маршрут вроде 0.0.0.0/0 в таблицы публичных подсетей.
• Для IPv4 он выполняет преобразование между публичным и частным адресом инстанса, которому назначен публичный IPv4-адрес.
• Сам по себе он не открывает порты, поскольку трафик по-прежнему контролируют группы безопасности, сетевые ACL и межсетевой экран хоста.

NAT-шлюз позволяет ресурсам приватной подсети устанавливать исходящие IPv4-соединения, не становясь напрямую доступными из интернета.

• Публичный NAT-шлюз я размещу в публичной подсети, назначу ему Elastic IP, а маршрут 0.0.0.0/0 приватной подсети направлю к нему.
• Ответный трафик установленного соединения пройдет, но интернет-клиент не сможет начать соединение через этот шлюз.
• Для отказоустойчивой многозональной схемы я использую NAT-шлюз в каждой зоне, учитывая почасовую оплату и стоимость обработки данных.

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

• Группы безопасности содержат только разрешающие правила, а ответный трафик принятого соединения разрешается автоматически.
• Сетевые ACL поддерживают Allow и Deny, обрабатывают нумерованные правила по порядку и требуют явных правил для обратного трафика.
• Группы безопасности я использую как основной контроль нагрузки, а NACL оставляю более широким защитным уровнем подсети, когда он нужен.

Я использую размещенные зоны Route 53: публичные зоны для интернет-DNS и приватные зоны для выбранных VPC.

• В публичной зоне можно направить app.example.com на ALB с помощью alias-записи.
• Приватная зона разрешается только из связанных VPC и подходит для внутренних имен вроде db.internal.example.com.
• Поддержку DNS и DNS-имен хостов в VPC нужно настроить правильно, чтобы нагрузки использовали предоставленный Amazon резолвер и создаваемые имена.

Elastic IP представляет собой статический публичный IPv4-адрес, который можно связать с поддерживаемым ресурсом в одном регионе.

• Он полезен, когда списку разрешений нужен стабильный исходящий адрес, например для трафика через NAT-шлюз.
• Я не буду назначать его каждому инстансу EC2, потому что балансировщики и DNS обычно дают более удобные адреса приложений.
• Публичные IPv4-адреса оплачиваются и являются дефицитным ресурсом, поэтому ненужный Elastic IP следует сразу освободить.

Пиринговое соединение VPC дает двум VPC связь по частным IP-адресам через сеть AWS.

• Я создаю и принимаю соединение, добавляю маршруты в обоих VPC и разрешаю трафик в средствах безопасности.
• Диапазоны CIDR этих VPC не должны пересекаться, потому что AWS нужны однозначные маршруты между ними.
• Трафик остается в инфраструктуре AWS, но плата за межзональную и межрегиональную передачу данных все равно может применяться.

Пиринг VPC не является транзитивным, поэтому одно пиринговое соединение нельзя использовать как маршрутизатор к другому VPC.

• Если VPC A соединен с B, а B с C, то A не сможет обращаться к C через B.
• Для небольшой сети я создам необходимые прямые соединения и буду поддерживать явные маршруты для каждого из них.
• Если многим VPC нужна узловая схема маршрутизации, я рассмотрю AWS Transit Gateway вместо большой сети пиринговых соединений.