В конфигурации AWS VPC есть 4 сценария. Но давайте посмотрим на эти два:
Поскольку любой экземпляр, запущенный в общедоступной подсети, не имеет 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-адресов на экземплярах в этой конкретной подсети.
Каждая подсеть имеет ровно один маршрут по умолчанию, который может быть только одним из двух:
Интернет-шлюз не выполняет преобразование сетевых адресов для экземпляров без общедоступных IP-адресов, поэтому экземпляр без общедоступного IP-адреса не может подключаться внешне к Интернету - для таких действий, как загрузка обновлений программного обеспечения или доступ к другим Ресурсы AWS, такие как S3 1 и 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 1 или SQS.
1. Что касается S3, в частности, сказать, что доступ к Интернету требуется всегда, - это чрезмерное упрощение, которое, вероятно, со временем будет расширяться и распространяться на другие сервисы AWS, поскольку возможности VPC продолжают расти и развиваться. Существует относительно новая концепция, называемая конечная точка VPC, которая позволяет вашим экземплярам, включая те, у кого есть только частные IP-адреса, для прямого доступа к S3 из выбранных подсетей в VPC, не касаясь «Интернета» и без использования экземпляра NAT или шлюза NAT, но это требует дополнительной настройки и может использоваться только для доступа к сегментам внутри тот же регион AWS, что и ваш VPC. По умолчанию S3 - которая на момент написания этой статьи является единственной службой, которая предоставляет возможность создания конечных точек VPC - доступна только изнутри VPC через Интернет. При создании конечной точки VPC создается список префиксов (pl-xxxxxxxx), который можно использовать в таблицах маршрутов VPC для отправки трафика, привязанного к этой конкретной службе AWS, непосредственно к службе через виртуальный объект «Конечная точка VPC». Это также решает проблему ограничения исходящего доступа к 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-адреса. Надеюсь, это поможет проиллюстрировать и объяснить, почему лучшие практики такие, какие они есть.
