Компания использует общий аккаунт AWS для подключения к локальным центрам обработки данных. Частные внутренние веб-сервисы работают в нескольких аккаунтах AWS, и доступ к ним осуществляется сотрудниками офиса с использованием DNS-имен в локальной зоне с именем example.internal. Регистрация нового сервиса, размещенного в AWS, в настоящее время требует ручного изменения внутреннего DNS с участием нескольких команд. Компания хочет, чтобы владельцы сервисов могли регистрировать свои DNS-записи напрямую, с минимальными изменениями конфигурации и низкими затратами. Какую комбинацию шагов должен реализовать сетевой инженер? (Выберите три.)

Для централизованного управления DNS и обеспечения доступа к сервисам в AWS из локальной сети необходимо создать частную хост-зону Route 53 aws.example.internal в общем аккаунте AWS. В этой зоне будут храниться записи для всех сервисов AWS. Для каждого аккаунта AWS, где размещены сервисы, создается подзона (например, account1.aws.example.internal) в общем аккаунте и связывается с VPC сервиса и VPC общего аккаунта. Это позволяет владельцам сервисов создавать записи в своих подзонах. Для разрешения этих имен из локальной сети создается входящая конечная точка Route 53 Resolver в VPC общего аккаунта. На локальных DNS-серверах настраивается условный перенаправитель для aws.example.internal, который направляет запросы на IP-адреса этой конечной точки. Неправильные варианты: Создание DNS-записи для каждого сервиса в его локальной частной хост-зоне не обеспечивает централизованное управление и требует ручного распространения записей. Создание правила Route 53 Resolver для onprem.example.internal не относится к решению задачи разрешения имен AWS-сервисов из локальной сети. Запуск экземпляров EC2 с BIND является более сложным и дорогим решением по сравнению с использованием Route 53 Resolver.