Я настраиваю инфраструктуру для стартапа, который в значительной степени не будет иметь большого трафика, но при необходимости сможет масштабироваться.
Мы предпочитаем установку с LB, которая распределяет трафик между интерфейсными узлами в выделенной частной подсети (более 3 зон доступности), которые, в свою очередь, делают запросы к поддерживаемым узлам в своей собственной выделенной частной подсети, которая, в свою очередь, делает запросы к mongodb управляется через атлас и пиринг vpc.
Для того, чтобы каждый узел мог подготовиться, требуется доступ в Интернет. Бэкэнд-узлы также отправляют запросы сторонним сервисам и, следовательно, требуют доступа в Интернет, когда они работают.
Я вижу три варианта:
настроить nat-шлюз для каждой частной подсети в каждой зоне доступности. В зависимости от местоположения это составляет около 30 долларов за подсеть в каждой зоне доступности. С 3 зонами доступности и 2 подсетями это составит около 180 долларов в месяц, что на самом деле больше, чем мы планируем использовать для инстансов ec2, пока в системе не так много трафика и нагрузки. Мы могли бы, вероятно, сократить это, чтобы просто использовать 1 nat-шлюз в каждой зоне доступности для всех частных подсетей, но все равно это около 90 долларов.
настроить экземпляры ec2 в качестве шлюза nat, что, вероятно, будет немного дешевле, но требует обслуживания и настройки.
просто используйте одну частную подсеть, назначьте общедоступные IP-адреса каждому узлу и используйте интернет-шлюз через записи таблицы маршрутов. Я не думаю, что использование выделенных частных подсетей будет иметь смысл, поскольку узлы в любом случае должны иметь возможность подключаться друг к другу через шлюз.
Последний вариант, скорее всего, будет самым дешевым, поскольку один эластичный IP-адрес уже включен в экземпляр ec2, а выделенные шлюзы не нужны. Однако мне было интересно, есть ли в этом значительный недостаток или риск? Мы планируем вернуться к идее с выделенными подсетями, когда в этом возникнет необходимость (например, при наличии значительного трафика), но мы действительно хотели бы сохранить расходы на минимально возможном уровне вначале.
Похоже, вы неправильно понимаете основы сети в VPC.
настроить nat-шлюз для каждой частной подсети в каждой зоне доступности.
Для всех практических целей вам никогда не понадобится это делать.
Максимальное количество шлюзов NAT, которое вам когда-либо понадобится в одном VPC, будет равно 1 на зону доступности.
NAT-шлюзы никогда размещены в (любой) подсети, которую они обслуживают. Шлюзы NAT размещаются в общедоступной подсети, маршрут которой по умолчанию указывает на Интернет-шлюз. Затем они предоставляют услуги NAT экземплярам на другие подсети, где шлюз NAT указан в качестве шлюза по умолчанию для этих подсетей.
Таким образом, количество частных подсетей в am AZ не имеет отношения к количеству шлюзов NAT. Если вам не нужна пропускная способность Интернета, превышающая 45 Гбит / с на зону доступности, вам не потребуется несколько шлюзов NAT.
Далее, технически вам не нужен, кроме одного шлюза NAT на каждый VPC. Шлюз NAT - это логичный объект, а не физический, поэтому не существует известного механизма, с помощью которого можно «потерпеть неудачу» (кроме как при первоначальном создании, когда существует вероятность того, что он не может быть определен). Против совместного использования шлюза NAT в разных регионах рекомендуются следующие моменты:
Далее, использование экземпляров EC2 в качестве устройств NAT практически не требует настройки. Стандартный AMI для экземпляров NAT не требует настройки на уровне экземпляра. Вы также можете построить свой собственный. Восстановление инстанса EC2 может восстановить экземпляр NAT, когда базовое оборудование действительно выходит из строя или гипервизор перестает отвечать (редко, но возможно).
Я не думаю, что использование выделенных частных подсетей будет иметь смысл, поскольку узлы в любом случае должны иметь возможность подключаться друг к другу через шлюз.
В любом случае это не актуально. Выделенные подсети или их отсутствие не оказывает реального влияния на то, как экземпляры взаимодействуют друг с другом - только на то, как они верить они общаются. «Маршрутизатор по умолчанию» в каждой подсети в VPC - это воображаемое устройство, которое существует для совместимости с тем, как работает IP over Ethernet. Когда двум экземплярам в VPC разрешено обмениваться данными группами безопасности и сетевыми ACL, способ передачи их фактического трафика от одного экземпляра к другому идентичен, независимо от того, находятся ли эти два экземпляра в одной подсети или нет.
Между подсетями, экземпляр выполняет действия, связанные с подключением шлюза по умолчанию и отправкой на него трафика, в то время как гипервизор подыгрывает, но эффективно игнорирует все это и отправляет трафик непосредственно в гипервизор другого экземпляра. Внутри подсети экземпляр arps для своего однорангового узла, гипервизор имитирует этот ответ (ARP, «который имеет», никогда не появляется в целевом экземпляре, но исходный экземпляр видит ответ, который не генерировал целевой объект) и трафик между узлами следует точно так же, как и раньше.
В течение многих лет мы все отлично справлялись с использованием экземпляров EC2 в качестве экземпляров NAT, потому что это был единственный вариант - шлюз NAT - относительно новая услуга. Если вы пытаетесь сэкономить, сделайте это. Или используйте это во всех зонах доступности, кроме одной, и используйте один шлюз NAT в этой зоне доступности.
Добавьте конечные точки VPC для сервисов, которые их поддерживают, например S3 и DynamoDB, поскольку эти конечные точки позволяют вам получать доступ к этим сервисам без устройства NAT.
Вы можете направить исходящий трафик из нескольких частных подсетей в один и тот же экземпляр natgw.
Иногда я создаю отдельную общедоступную подсеть «управления», где находится natgw (или аналогичные ресурсы), и предоставляю все частные подсети, которые должны иметь доступ к Интернету с соответствующим маршрутом к этому natgw.
Такая схема делает более очевидным, что эта подсеть предназначена для специального назначения и в конечном итоге используется несколькими другими разделенными подсетями. Обычно я назначаю такой подсети крошечный CIDR.