Почему программный VPN не использует преимущества уже существующего соединения Direct Connect?

Question

Официальный образец вопросов по AWS Advanced Networking Specialty содержит вопрос о наиболее экономичном соединении между вашим локальным центром обработки данных и AWS, обеспечивающим конфиденциальность и целостность данных, передаваемых в ваш VPC (вопрос № 7).

Правильный ответ подразумевает установление управляемого VPN-соединения между клиентским шлюзом и виртуальным частным шлюзом через соединение Direct Connect.

Однако один из возможных вариантов в списке ответов предлагает программное решение VPN ("Настройте туннель IPsec между шлюзом клиента и программным VPN на Amazon EC2 в VPC"). Объяснение, почему этот ответ неверен, гласит:

он не будет использовать преимущества уже существующего соединения Direct Connect

У меня вопрос: почему бы этому программному VPN-подключению не воспользоваться уже существующим подключением постоянного тока? В чем тут принципиальная разница?

Answer 1

Вариант 1. Вопрос некорректен.

Если вы построили туннель между клиентским устройством шлюза и экземпляром EC2 с маршрутизацией трафика через соединение Direct Connect, то вы совершенно правы - этот трафик будет использовать существующее соединение Direct Connect.

Если, с другой стороны, вы построили туннель от клиентского шлюза до экземпляра EC2 через Интернет, то, конечно, этот трафик не будет использовать маршрут Direct Connect.

Похоже, существует неявное предположение, что туннель между устройством на стороне клиента и экземпляром EC2 обязательно будет проходить через Интернет, и это ошибочное предположение.

Конечно, есть и другие причины, по которым собственное решение может быть предпочтительнее ручного решения с EC2 (например, выживаемость при полной потере зоны доступности или предотвращение простоев из-за возможных сбоев оборудования экземпляра), но это не так. t часть сценария.

Вариант 2. Ответ неверен по другой причине, нежели предложенное объяснение.

Написав и поразмыслив над вышесказанным, я понял, что может быть гораздо более простое объяснение: "он не будет использовать преимущества уже существующего соединения Direct Connect" - это просто неправильное оправдание для отклонения этого ответа.

Он должен быть отклонен по процедурным причинам из-за указания выбрать 3. Вот два других правильных ответа.

A) Настройте VPC с виртуальным частным шлюзом.

C) Настройте общедоступный виртуальный интерфейс для подключения Direct Connect.

Чтобы реализовать собственный туннель IPSec между локальным сервером и EC2 через Direct Connect, вам не нужно ничего из этого делать. Виртуальный частный шлюз - это сторона AWS управляемой AWS VPN, и общедоступный виртуальный интерфейс необходим, чтобы сделать один из них доступным изнутри Direct Connect (среди прочего, но это не обязательно для доступа к виртуальным машинам внутри VPC. с использованием частных IP-адресов через Direct Connect).

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