Назад | Перейти на главную страницу

Стратегия маршрутизации для нескольких VPC на AWS

Я планирую установить несколько виртуальных частных облаков (VPC) на AWS. Эти VPC будут расположены в разных регионах. У каждого VPC будут как публичные, так и частные экземпляры. Мне нужно включить эффективную стратегию маршрутизации для всех экземпляров, работающих на всех VPC. Перекрестная связь VPC будет происходить через туннели IPsec. Любые предложения относительно следующих проблем будут мне очень полезны.

  1. Должен ли я создать ступица со спицами структура, в которой каждый VPC будет иметь туннель Ipsec к VPC концентратора, или я должен создать туннель Ipsec для каждой пары VPC и сформировать клика?
  2. Мне нужно сохранить экземпляр в каждом VPC, который будет действовать как Шлюз ipsec и существует риск того, что этот экземпляр станет узким местом или, что еще хуже, точкой отказа. Есть ли варианты архитектуры, при которых я могу этого избежать?
  3. Какой схеме IP-адресации мне следует придерживаться, чтобы в будущем я мог перемещать экземпляр из общедоступной подсети в частную подсеть и наоборот, не влияя на общую маршрутизацию?

Также предоставьте ссылки на соответствующие документы / примеры из практики, которые, по вашему мнению, могут помочь мне в этом сценарии.

Спасибо.

Во-первых, вы не можете перемещать экземпляр между подсетями. После того, как основной ENI был назначен экземпляру, его нельзя отсоединить, поэтому он останется в этой подсети. Лучшее, что вы можете сделать, - это запустить новый экземпляр в новой подсети, остановить его, а затем переместить основной том EBS из старого экземпляра в новый. Но, конечно же, это даст вам новый IP-адрес.

Во-вторых, вы должны создать полную сеть VPN-подключений между всеми зонами доступности во всех регионах, где вы создаете VPC. Таким образом, если у вас есть две зоны доступности в регионе alfa и две зоны доступности в регионе браво, у вас будет 4 туннеля VPN. Как бы то ни было, эти экземпляры также могут выступать в качестве исходящих экземпляров NAT для частных подсетей в зоне доступности. Там есть некоторая документация на этой конфигурации.

Наконец, способ избежать единой точки отказа для экземпляров VPN / NAT - это использовать автоматическое масштабирование и подготовку экземпляров по сценариям. Это сделано для того, чтобы в случае сбоя экземпляра он был немедленно заменен новым экземпляром. Уловка заключается в том, что всем экземплярам VPN / NAT потребуется ENI, который будет повторно использоваться каждый раз, когда экземпляр выходит из строя и заменяется. В этой презентации re: Invent 2013 представлен обзор процесса: видео и слайды.