Зачем нужна частная подсеть в VPC?

В настройке AWS VPC есть 4 сценария . Но давайте посмотрим на эти два:

• Сценарий 1: 1 общедоступная подсеть.
• Сценарий 2: 1 общедоступная подсеть и 1 частная подсеть.

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

• Зачем нужна частная подсеть?
• В чем именно разница между частной и общедоступной подсетями?

Обновление: в конце декабря 2015 года AWS анонсировала новую функцию - управляемый шлюз NAT для VPC . Эта дополнительная услуга предоставляет альтернативный механизм для экземпляров VPC в частной подсети для доступа к Интернету, где ранее общим решением был экземпляр EC2 в общедоступной подсети в VPC, функционирующий как «экземпляр NAT», обеспечивающий преобразование сетевых адресов ( технически преобразование адресов порта ) для экземпляров в других частных подсетях, позволяя этим машинам использовать общедоступный IP-адрес экземпляра NAT для исходящего доступа в Интернет.

Новая управляемая служба NAT не меняет принципиально применимость следующей информации, но этот параметр не рассматривается в последующем контенте. Экземпляр NAT по-прежнему можно использовать, как описано, или вместо него можно предоставить службу управляемого шлюза NAT. В ближайшее время будет выпущена расширенная версия этого ответа, включающая дополнительную информацию о шлюзе NAT и его сравнении с экземпляром NAT, поскольку оба они имеют отношение к парадигме частной / общедоступной подсети в VPC.

Обратите внимание, что интернет-шлюз и NAT-шлюз - это две разные функции. Все конфигурации VPC с доступом в Интернет будут иметь виртуальный объект Internet Gateway.

Чтобы понять различие между «частными» и «общедоступными» подсетями в Amazon VPC, необходимо понять, как в целом работают IP-маршрутизация и преобразование сетевых адресов (NAT) и как они конкретно реализованы в VPC.

Основное различие между общедоступной и частной подсетями в VPC определяется маршрутом по умолчанию для этой подсети в таблицах маршрутизации VPC.

Эта конфигурация, в свою очередь, определяет допустимость использования или неиспользования общедоступных IP-адресов на экземплярах в этой конкретной подсети.

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

• объект "Интернет-шлюз" VPC в случае "общедоступной" подсети или
• устройство NAT, то есть шлюз NAT или экземпляр EC2, выполняющий роль «экземпляра NAT» в случае «частной» подсети.

Интернет - шлюз не делает никакого преобразования сетевых адресов для экземпляров без каких IP - адресов , поэтому экземпляр без IP адреса общественности не может подключиться наружу к Интернету - делать такие вещи , как загрузка обновлений программного обеспечения, или доступ к другим AWS ресурсам , таким как S3 ¹ и SQS - если маршрут по умолчанию в его подсети VPC - это объект Internet Gateway. Итак, если вы являетесь экземпляром в «общедоступной» подсети, то вам понадобится общедоступный IP-адрес, чтобы выполнять значительное количество вещей, которые обычно необходимы серверам.

Для экземпляров, имеющих только частный IP-адрес, есть альтернативный способ исходящего доступа в Интернет. Здесь на помощь приходят преобразование сетевых адресов² и экземпляр NAT.

Машины в частной подсети могут получить доступ к Интернету, потому что маршрут по умолчанию в частной подсети не является объектом VPC «Интернет-шлюз» - это экземпляр EC2, настроенный как экземпляр NAT.

Экземпляр NAT - это экземпляр в общедоступной подсети с общедоступным IP-адресом и определенной конфигурацией. Для этого есть предварительно созданные AMI, или вы можете создать свои собственные.

Когда машины с частным адресом отправляют трафик наружу, трафик отправляется через VPC в экземпляр NAT, который заменяет исходный IP-адрес в пакете (частный IP-адрес частной машины) своим собственным общедоступным IP-адресом, отправляет трафик. в Интернет, принимает ответные пакеты и пересылает их обратно на частный адрес исходной машины. (Он также может переписать исходный порт, и в любом случае он запоминает сопоставления, чтобы знать, какая внутренняя машина должна получать ответные пакеты). Экземпляр NAT не позволяет «неожиданному» входящему трафику достигать частных экземпляров, если он специально не настроен для этого.

Таким образом, при доступе к внешнему интернет-ресурсу из частной подсети трафик проходит через экземпляр NAT и для пункта назначения кажется, что он исходит с общедоступного IP-адреса экземпляра NAT ... поэтому ответный трафик возвращается в экземпляр NAT. Ни группу безопасности, назначенную экземпляру NAT, ни группу безопасности, назначенную частному экземпляру, не нужно настраивать так, чтобы «разрешать» этот ответный трафик, поскольку группы безопасности отслеживают состояние. Они понимают, что ответный трафик соотносится с внутренними сеансами, поэтому он автоматически разрешается. Неожиданный трафик, конечно же, запрещен, если группа безопасности не настроена на его разрешение.

В отличие от обычной IP-маршрутизации, где ваш шлюз по умолчанию находится в той же подсети, способ ее работы в VPC отличается: экземпляр NAT для любой данной частной подсети всегда находится в другой подсети, а эта другая подсеть всегда является общедоступной подсетью, потому что Экземпляр NAT должен иметь общедоступный внешний IP-адрес, а его шлюз по умолчанию должен быть объектом VPC «Интернет-шлюз».

Точно так же ... вы не можете развернуть экземпляр с общедоступным IP-адресом в частной подсети. Это не работает, потому что маршрут по умолчанию в частной подсети - это (по определению) экземпляр NAT (который выполняет NAT для трафика), а не объект Internet Gateway (который не работает). Входящий трафик из Интернета будет попадать на общедоступный IP-адрес экземпляра, но ответы будут пытаться направить наружу через экземпляр NAT, что либо отбросит трафик (поскольку он будет состоять из ответов на подключения, о которых он не знает, поэтому они 'будет считаться недействительным) или перепишет ответный трафик, чтобы использовать свой собственный общедоступный IP-адрес, что не будет работать, поскольку внешний источник не будет принимать ответы, пришедшие с IP-адреса, отличного от того, с которым они пытались инициировать связь. ,

Таким образом, по сути, обозначения «частный» и «общедоступный» на самом деле не связаны с доступностью или недоступностью из Интернета. Они касаются типов адресов, которые будут назначены экземплярам в этой подсети, что актуально из-за необходимости преобразовывать - или избегать преобразования - этих IP-адресов для взаимодействия в Интернете.

Поскольку у VPC есть неявные маршруты от всех подсетей VPC ко всем другим подсетям VPC, маршрут по умолчанию не играет роли во внутреннем трафике VPC. Экземпляры с частными IP-адресами будут подключаться к другим частным IP-адресам в VPC "со" своего частного IP-адреса, а не "со" своего общедоступного IP-адреса (если он у них есть) ... пока адрес назначения является другим частным адресом внутри VPC.

Если вашим экземплярам с частными IP-адресами никогда и ни при каких обстоятельствах не потребуется исходящий интернет-трафик, то они технически могут быть развернуты в «общедоступной» подсети и по-прежнему будут недоступны из Интернета ... но при такой конфигурации, для них невозможно создать исходящий трафик в Интернет, который включает соединения с другими сервисами инфраструктуры AWS, опять же, такими как S3 ¹ или SQS.

^{1. Что касается S3, в частности, сказать, что доступ в Интернет требуется всегда, - это чрезмерное упрощение, которое, вероятно, со временем будет расширяться и распространяться на другие сервисы AWS, поскольку возможности VPC продолжают расти и развиваться. Существует относительно новая концепция, называемая конечной точкой VPC.это позволяет вашим экземплярам, ​​включая экземпляры с частными IP-адресами, напрямую обращаться к S3 из выбранных подсетей в VPC, не касаясь «Интернета» и без использования экземпляра NAT или шлюза NAT, но это требует дополнительной настройки и является можно использовать только для доступа к сегментам в том же регионе AWS, что и ваш VPC. По умолчанию S3 - которая на момент написания этой статьи является единственной службой, которая предоставляет возможность создания конечных точек VPC - доступна только изнутри VPC через Интернет. При создании конечной точки VPC создается список префиксов (pl-xxxxxxxx), которые можно использовать в таблицах маршрутов VPC для отправки трафика, привязанного к конкретному сервису AWS, непосредственно к сервису через виртуальный объект «VPC Endpoint». Это также решает проблему ограничения исходящего доступа к S3, например, потому что список префиксов может использоваться в группах безопасности исходящего трафика вместо целевого IP-адреса или блока, а на конечную точку S3 VPC могут распространяться дополнительные политики. , ограничивая доступ к ковшу изнутри по желанию.}

^{2. Как отмечено в документации, на самом деле здесь обсуждается преобразование портов и сетевых адресов. Обычно, хотя технически это немного неточно, объединенную операцию называют «NAT». Это отчасти похоже на то, как многие из нас обычно говорят «SSL», когда на самом деле имеют в виду «TLS». Мы знаем, о чем говорим, но не используем самое правильное слово, чтобы описать это. «Примечание. Мы используем термин NAT в этой документации, чтобы следовать общепринятой ИТ-практике, хотя фактическая роль устройства NAT заключается как в преобразовании адресов, так и в преобразовании адресов портов (PAT)».}

Я бы предложил другой подход - отказаться от «частных» подсетей и инстансов / шлюзов NAT. В них нет необходимости. Если вы не хотите, чтобы компьютер был доступен из Интернета, не помещайте его в группу безопасности, которая разрешает такой доступ.

Отказавшись от инстанса / шлюза NAT, вы устраняете эксплуатационные расходы на инстанс / шлюз и устраняете ограничение скорости (будь то 250 Мбит или 10 Гбит).

Если у вас есть машина, которой также не требуется прямой доступ к Интернету (и я бы спросил, как вы ее исправляете *), то ни в коем случае не назначайте общедоступный IP-адрес.

* Если здесь ответ какой-то прокси, ну, вы понесете накладные расходы, но каждому свое.

У меня нет репутации, чтобы добавить комментарий к ответу Майкла выше, поэтому я добавляю свой комментарий в качестве ответа.

Стоит отметить, что управляемый шлюз AWS примерно в 3 раза дороже по сравнению с запуском собственного экземпляра. Это, конечно, предполагает, что вам нужен только один экземпляр NAT (т. Е. У вас нет нескольких экземпляров NAT, настроенных для аварийного переключения и т. Д.), Что обычно верно для большинства сценариев использования от малого до среднего. При условии ежемесячной передачи 100 ГБ данных через шлюз NAT,

Ежемесячная стоимость управляемого инстанса NAT = 33,48 доллара США в месяц (0,045 доллара США в час * 744 часа в месяц) + 4,50 доллара США (0,045 доллара США за обработанный ГБ данных * 100 ГБ) + 10 долларов США (0,10 доллара США за 1 ГБ стандартной платы за передачу данных AWS для всех данных, передаваемых через NAT-шлюз) = 47,98 $

Экземпляр t2.nano, настроенный как экземпляр NAT = 4,84 доллара США в месяц (0,0065 доллара США * 744 часа в месяц) + 10 долларов США (0,10 доллара США за гигабайт стандартной платы за передачу данных AWS для всех данных, передаваемых через экземпляр NAT) = 14,84 доллара США.

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

Ответ Майкла - sqlbot неявно предполагает, что требуются частные IP-адреса. Я думаю, что стоит поставить под сомнение это предположение - нужно ли вообще использовать частные IP-адреса? По крайней мере, один комментатор задал тот же вопрос.

В чем преимущество сервера в частной подсети с экземпляром NAT [по сравнению с] сервером [в] общедоступной подсети со строгой политикой безопасности? - abhillman 24 июня '14 в 23:45

Представьте себе сценарий, в котором вы используете VPC и назначаете общедоступные IP-адреса всем своим экземплярам EC2. Не волнуйтесь, это не означает, что они обязательно доступны через Интернет, потому что вы используете группы безопасности для ограничения доступа точно так же, как это работало с классической версией EC2. Используя общедоступные IP-адреса, вы можете легко предоставлять определенные услуги ограниченной аудитории без необходимости использовать что-то вроде ELB. Это освобождает вас от необходимости настраивать экземпляр NAT или шлюз NAT. А поскольку вам нужно вдвое меньше подсетей, вы можете использовать меньшее выделение CIDR для своего VPC или создать подсети большего размера с VPC того же размера. А меньшее количество подсетей означает, что вы также будете меньше платить за трафик между зонами доступности.

Так почему бы нам этого не сделать? Почему AWS считает, что лучше всего использовать частные IP-адреса?

Amazon Web Services имеет ограниченное количество общедоступных адресов IPv4, поскольку в Интернете в целом имеется ограниченное количество общедоступных адресов IPv4. В их интересах использовать частные IP-адреса, которые фактически не ограничены, а не чрезмерно использовать ограниченные общедоступные IPv4-адреса. Вы можете увидеть некоторые доказательства этого в том, как AWS оценивает эластичные IP-адреса; EIP, прикрепленный к экземпляру, предоставляется бесплатно, но неиспользованный EIP стоит денег.

Но в качестве аргумента предположим, что нас не волнует нехватка общедоступных адресов IPv4 в Интернете. В конце концов, мое приложение особенное. Что происходит дальше?

Есть только два способа привязать общедоступный IP-адрес к экземпляру EC2 в VPC.

1. Связанный общедоступный IP-адрес

Вы можете запросить публичный IP-адрес при запуске нового экземпляра EC2. Этот параметр отображается как флажок в консоли, как флаг --associate-public-ip-address при использовании aws-cli и как флаг AssociatePublicIpAddress на встроенном объекте сетевого интерфейса при использовании CloudFormation. В любом случае публичный IP-адрес назначается eth0(DeviceIndex = 0). Вы можете использовать этот подход только при запуске нового экземпляра. Однако у этого есть некоторые недостатки.

Недостатком является то, что изменение группы безопасности экземпляра, который использует объект встроенного сетевого интерфейса, приведет к немедленной замене экземпляра, по крайней мере, если вы используете CloudFormation.

Другой недостаток состоит в том, что назначенный таким образом общедоступный IP-адрес будет утерян при остановке экземпляра.

2. Эластичный IP

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

... Но AWS ограничивает вас 5 EIP на регион. Вы можете запросить больше, и ваш запрос может быть удовлетворен. Но AWS с такой же вероятностью может отклонить этот запрос, основываясь на рассуждениях, которые я упомянул выше. Так что вы, вероятно, не захотите полагаться на EIP, если планируете когда-либо масштабировать свою инфраструктуру за пределы 5 экземпляров EC2 на регион.

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