AWS VPC - эластичные IP-адреса для разных сред

Я пытаюсь создать архитектуру VPC для разных сред (dev / test / pre-prod / prod), и у меня возникла проблема с ограничением ограничений эластичных IP-адресов. Было бы здорово узнать, идет ли архитектура в правильном направлении в первую очередь. Итак, позвольте мне объяснить вам детали здесь:

  1. 1 VPC для всех сред с 1 интернет-шлюзом
  2. VPC в одном регионе
  3. 3 зоны доступности с 1 частной подсетью и 1 служебной подсетью для каждой (всего 6 подсетей)
  4. 3 шлюза NAT - по одному для каждой служебной подсети с 3 эластичными IP-адресами, назначенными их сетевым интерфейсам
  5. Экземпляры EC2 (мастер и узел) в каждой частной подсети
  6. Виртуальный частный шлюз для подключения к корпоративной сети

Я использую Terraform для автоматизации всей этой инфраструктуры в виде кода (здесь это не имеет большого значения). Когда я запускаю сценарий Terraform для одной среды (скажем, для разработчиков), вся описанная выше инфраструктура создается нормально и хорошо работает. Но теперь, когда я запускаю сценарий для другой среды (скажем, для теста), у меня заканчиваются эластичные IP-адреса (поскольку существует ограничение в 5 EIP на регион).

Как лучше всего перестроить эту архитектуру, чтобы я мог создавать инфраструктуру для различных сред, не нарушая при этом эти ограничения EIP?

Большое спасибо за помощь. Пожалуйста, дайте мне знать, если потребуется дополнительная информация.

С уважением, Абдул


amazon-web-services amazon-ec2 terraform amazon-vpc eip
person Basith    schedule 30.01.2018    source источник
comment
Если вам действительно нужны EIP для всех ваших инстансов, вы можете запросить увеличение лимита в службе поддержки AWS. docs.aws.amazon.com/general/latest/gr/aws_service_limits. html   -  person Briansbum    schedule 30.01.2018
comment
Спасибо, Briansbum. В настоящее время эластичные IP-адреса назначаются сетевым интерфейсам в общедоступной подсети. Итак, мой вопрос: правильно ли я делаю, назначая 3 эластичных IP-адреса для каждой среды, которую я создаю? Есть ли способ лучше?   -  person Basith    schedule 30.01.2018
comment
Если вам не нужен HA на шлюзах NAT, вы можете обойтись одним шлюзом NAT для каждого VPC. Это будет нормально, пока зона доступности, содержащая ваш шлюз NAT, не выйдет из строя, после чего другие зоны доступности не смогут выйти в Интернет (или любой другой маршрут, пересекающий шлюз NAT). Шлюзы NAT высокодоступны в самой зоне доступности, поэтому вам нужно беспокоиться только о случае отказа зоны доступности, который должен быть достаточно редким, чтобы не беспокоиться об этом вне производственной среды. Но в конечном итоге вам просто нужно попросить AWS увеличить лимит EIP для вашей учетной записи + региона.   -  person ydaetskcoR    schedule 30.01.2018
comment
Спасибо @ydaetskcoR. Значит, я могу создать шлюз NAT в AZ1 в его общедоступной подсети, а затем разрешить экземплярам из частных подсетей всех зон доступности общаться с общедоступной подсетью в AZ1? Это возможно? Это должно работать для других сред, таких как dev / test / pre-prod / staging, но я считаю, что все равно столкнусь с проблемой ограничения EIP (3 для prod, 1 для каждой среды)? Я могу запросить увеличение лимита, если это правильный путь, но пытаюсь понять, правильное ли это решение, потому что это очень распространенный сценарий развертывания?   -  person Basith    schedule 30.01.2018
comment
Да в основном это. И вы просто хотите, чтобы маршрут 0.0.0.0/0 для всех частных подсетей шел к единственному шлюзу NAT в VPC.   -  person ydaetskcoR    schedule 30.01.2018
comment
Спасибо @ydaetskcoR   -  person Basith    schedule 30.01.2018
comment
@ydaetskcoR. Если задуматься, если этот шлюз NAT выйдет из строя, это затронет все экземпляры, и они станут единой точкой отказа? Хм, есть ли другие альтернативы? Спасибо за вашу помощь.   -  person Basith    schedule 30.01.2018
comment
Это если АЗ выйдет из строя. Шлюзы NAT являются HA внутри своей зоны доступности (см. docs. aws. Для меня это нормально вне производства, но это решение, которое вы должны принять, а не кто-либо посторонний, который вам скажет.   -  person ydaetskcoR    schedule 30.01.2018
comment
Совершенно не связано с EIP: вам действительно стоит рассмотреть один VPC для каждой среды. У этого есть несколько преимуществ, но самое большое из них заключается в том, что вы не можете случайно настроить серверы разработки / тестирования для подключения к базе данных prod.   -  person kdgregory    schedule 30.01.2018
comment
@kdgregory: Я думал об этом. Но есть также две вещи, которые следует учитывать, когда мы выбираем это решение: 1. Затраты на передачу данных между VPC от экземпляров частной подсети к шлюзу NAT 2. Сложность выставления счетов, даже если она консолидирована.   -  person Basith    schedule 30.01.2018

Ответы (2)


arrow_upward
3
arrow_downward

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

Таким образом мы сохраняем 3 среды. Производство, разработка и отказоустойчивая среда. Отказоустойчивая учетная запись содержит производственные резервные копии в другом регионе.

Разделение сред по учетным записям дает множество преимуществ. Например:

person Rodrigo M    schedule 30.01.2018
comment
Спасибо @Rodrigo M. Рад слышать, что у вас есть такая система. Обязательно учту это. - person Basith; 30.01.2018
comment
Вы делаете ставку. Мне жаль, что я не сделал это раньше в моем окружении. Есть несколько преимуществ, например, вам не нужно предоставлять всем производственный доступ, и вы можете указать, что некоторые ресурсы будут созданы только в определенных средах. Плюс кодовые пространства arstechnica.com/information-technology/2014/06/ - person Rodrigo M; 30.01.2018
comment
Рассказ о CodeSpaces довольно пугающий, но здесь можно поделиться. Ваше здоровье.. - person Basith; 30.01.2018

arrow_upward
2
arrow_downward

Как упоминалось в комментариях, ограничение EIP - это просто ограничение на использование сервисов AWS для EIP, поэтому вам следует поговорить с AWS о его повышении. Запуск отдельных рабочих нагрузок в отдельных учетных записях AWS, как предлагает Rodrigo M, - еще один способ обойти ограничения обслуживания, но он также является хорошей идеей для многие другие причины, перечисленные в его ответе.

Как также обсуждалось, вы можете рассмотреть возможность использования только одного шлюза NAT в непроизводственных VPC, поскольку это снизит ваши затраты (а также уменьшит количество необходимых EIP).

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

Для меня такая меньшая HA подходит для непроизводственных сред и позволяет сэкономить 65 долларов в месяц на непроизводственном VPC. Однако в производственной среде я счастлив съесть эту небольшую дополнительную плату, чтобы уменьшить ущерб, вызванный отказом зоны доступности, а также всю другую работу, которую я выполняю, чтобы избежать единичных точек отказа.

person ydaetskcoR    schedule 30.01.2018
comment
Хорошие моменты. Как я предположил в своем ответе, при правильном оснащении и разделении среды определенные ресурсы могут быть ограничены или опущены в определенных средах. Более низкие уровни высокой доступности в непроизводственной среде, безусловно, являются хорошим способом снижения затрат. - person Rodrigo M; 30.01.2018
comment
Да, определенно, разделение сред между учетными записями AWS определенно стоит того по множеству причин, но повышение (мягких) лимитов услуг, вероятно, наименьшее из них;) - person ydaetskcoR; 30.01.2018