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