AWS: сократить расходы на NAT-шлюз для небольшой системы

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

Мы предпочитаем настройку с балансировщиком нагрузки (LB), который распределяет трафик на фронтенд-узлы в выделенной частной подсети (в более чем трех зонах доступности), которая в свою очередь делает запросы к бэкенд-узлам в своей собственной выделенной частной подсети, которые, в свою очередь, делают запросы к mongodb, управляемой через atlas и vpc peering.

Чтобы каждый узел мог работать, ему необходим доступ в интернет. Бэкенд-узлы также делают запросы к сторонним сервисам, и поэтому им также необходим доступ в интернет, когда они работают.

Я вижу три варианта:

• установить nat gateway для каждой частной подсети в каждой зоне доступности. В зависимости от местоположения это составляет около 30 долларов на подсеть в каждой зоне доступности. С 3 зонами доступности и 2 подсетями это будет составлять около 180 долларов в месяц, что на самом деле больше, чем мы планируем тратить на экземпляры ec2, пока на систему нет большой нагрузки. Мы могли бы, наверное, сократить это до использования только одного nat gateway в каждой зоне доступности для всех частных подсетей, но все же это будет около 90 долларов.

• настроить экземпляры ec2 в качестве nat gateway, что, вероятно, будет немного дешевле, но требует техобслуживания и настройки.

• просто использовать одну частную подсеть, назначить публичные IP для каждого узла и использовать интернет-шлюз через записи в таблице маршрутизации. Я думаю, что использование выделенных частных подсетей не имеет большого смысла, так как узлы все равно должны иметь возможность подключаться друг к другу через шлюз.

Последний вариант, скорее всего, будет самым дешевым, так как один эластичный IP уже включен в экземляр ec2 и выделенные шлюзы не требуются. Однако, я задаюсь вопросом, есть ли какие-либо значительные недостатки или риски, связанные с этим? Мы планируем вернуться к идее с выделенными подсетями, когда в этом будет необходимость (например, когда будет значительный трафик), но мы действительно хотели бы сохранить затраты как можно ниже в начале.

Кажется, у вас есть некоторые недопонимания в отношении основ сетей в VPC.

установить nat gateway для каждой частной подсети в каждой зоне доступности.

С практической точки зрения, это никогда не будет необходимо делать.

Максимальное количество NAT Gateway, которое вам когда-либо понадобится в одном VPC, будет 1 на зону доступности (AZ).

NAT Gateways никогда не размещаются в (каких-либо) подсетях, которые они обслуживают. NAT Gateways размещаются в публичной подсети, у которой есть маршрут по умолчанию, указывающий на интернет-шлюз. Затем они предоставляют услуги NAT для экземпляров на других подсетях, где NAT Gateway обозначен в качестве основного шлюза для этих подсетей.

Таким образом, количество частных подсетей в AZ не имеет отношения к количеству NAT Gateway. Если вам не требуется интернет-пропускная способность более 45 Гбит/с на AZ, вам не нужно множество NAT Gateway.

Далее, технически вам нужен только один NAT Gateway на VPC. NAT Gateway — это логический объект, а не физический, поэтому не существует известных механизмов, с помощью которых он может “отказаться” (кроме начального создания, когда есть возможность его неудачной настройки). Однако есть несколько причин против обмена NAT Gateway между регионами:

• Вы будете платить за межрегиональный трафик, используя шлюз. До тех пор, пока это меньше стоимости шлюза, это может иметь смысл.
• Вы заметите небольшое увеличение задержки, обычно девять миллисекунд, для кросс-зонального трафика, использующего NAT Gateway для доступа в интернет. Это компромисс, но возможно незначителен.
• Полное отключение, отказ, потеря или разрушение AZ, размещающего шлюз, приведет к потере использования шлюза во всех AZ, но это, как оказалось, никогда не происходило до сих пор.

Далее, использование экземпляров EC2 в качестве устройств NAT практически не требует настройки. Стандартный AMI для NAT Instance не требует никаких дополнительных настроек на уровне экземпляра. Вы также можете создать свой собственный. EC2 Instance Recovery может восстановить NAT Instance, когда основное оборудование фактически отказывает или гипервизор становится неработоспособным (редко, но возможно).

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

Это не имеет значения в обоих случаях. Наличие выделенных подсетей или их отсутствие не влияет на то, как экземпляры общаются друг с другом — только на то, как они считают, что они общаются. “Маршрутизатор по умолчанию” в каждой подсети VPC является воображаемым устройством, которое существует для совместимости с тем, как работает IP поверх Ethernet. Когда два экземпляра в VPC разрешены для взаимодействия группами безопасности и сетевыми ACL, их фактический путь передачи данных от одного экземпляра к другому одинаков, независимо от того, находятся ли два экземпляра в одной подсети или нет.

Кросс-подсеть, экземпляр заходит через процедуры арпинга основного шлюза и отправки данных на него, тем временем гипервизор играет роль, но фактически игнорирует все это и отправляет данные непосредственно гипервизору другого экземпляра. В пределах одной подсети, экземпляр выполняет арпинг для своего узла, гипервизор подделывает ответ (ARP “who has” никогда не появляется на целевом экземпляре, хотя источник видит ответ, который цель не создала) и передача данных между узлами следует точно такому же пути, как и прежде.

Мы все прекрасно обходились в течение многих лет, используя EC2 Instances в качестве NAT Instances, потому что это был единственный вариант — NAT Gateway — относительно новая услуга. Если вы пытаетесь сэкономить, идите с этим. Или используйте это во всех AZ кроме одной, и используйте одну NAT Gateway в этой одной AZ.

Добавьте VPC endpoints для сервисов, которые поддерживают их, таких как S3 и DynamoDB, поскольку эти endpoints позволяют вам получить доступ к этим сервисам без устройства NAT.

Вы можете направлять исходящий трафик из нескольких частных подсетей к одному экземпляру natgw.

Иногда я создаю отдельную публичную “управляющую” подсеть, где находится natgw (или аналогичные ресурсы), и предоставляю всем частным подсетям, которые должны иметь доступ в интернет, соотвествующий маршрут к этому natgw.

Такая компоновка делает более очевидным, что эта подсеть предназначена для особых целей и в конечном итоге используется несколькими другими отдельными подсетями. Обычно я назначаю такой подсети небольшой CIDR.

Чтобы прямо ответить на изначальный вопрос (и ни в коем случае не отвергать любые заслуживающие внимания ответы, уже опубликованные), так как этот вопрос был задан уже несколько лет назад, а теперь доступны некоторые альтерантивные варианты:

https://github.com/AndrewGuenther/fck-nat / https://fck-nat.dev

https://github.com/chime/terraform-aws-alternat

https://www.enforza.io (предложение freemium, я не пробовал, и это может быть не дешевле, чем AWS NAT Gateway)

EC2 instance с NAT AMI (Устаревшее – https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html)

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

Использование в крупномасштабных производственных условиях в крупной корпорации отличается от работы с небольшими веб-приложениями, которым требуется функциональность NAT для конкретного аспекта или API.