Зачем нам нужна частная подсеть в VPC?
В AWS VPC есть 4 сценария настройки. Но давайте посмотрим на эти два:
- Сценарий 1: 1 публичной подсети.
- Сценарий 2: 1 общедоступная подсеть и 1 частная подсеть.
Поскольку любой экземпляр, запущенный в общедоступной подсети, не имеет EIP (если только он не назначен), он уже не адресуем из Интернета. Затем:
- Почему нужна частная подсеть?
- Каковы различия между частной и общедоступной подсетями?
4 ответа
Обновление: в конце декабря 2015 года AWS анонсировала новую функцию - Managed NAT Gateway для VPC. Эта дополнительная услуга предоставляет альтернативный механизм для экземпляров VPC в частной подсети для доступа к Интернету, где ранее общим решением был экземпляр EC2 в публичной подсети внутри VPC, функционирующий как "экземпляр NAT", обеспечивающий преобразование сетевых адресов (технически, преобразование адреса порта) для экземпляров в других частных подсетях, что позволяет этим машинам использовать общедоступный IP-адрес экземпляра NAT для своего исходящего доступа в Интернет.
Новая управляемая служба NAT принципиально не меняет применимость следующей информации, но эта опция не рассматривается в последующем контенте. Экземпляр NAT все еще может использоваться, как описано, или вместо этого может быть предоставлена служба Managed NAT Gateway. Будет предложена расширенная версия этого ответа, включающая дополнительную информацию о шлюзе NAT и его сравнении с экземпляром NAT, поскольку они оба относятся к парадигме частной / публичной подсети в VPC.
Обратите внимание, что Интернет-шлюз и NAT-шлюз являются двумя различными функциями. Все конфигурации VPC с доступом к Интернету будут иметь виртуальный объект интернет-шлюза.
Чтобы понять различие между "частной" и "общедоступной" подсетями в Amazon VPC, необходимо понять, как работает IP-маршрутизация и преобразование сетевых адресов (NAT) в целом, и как они конкретно реализованы в VPC.
Основное различие между общедоступной и частной подсетями в VPC определяется тем, какой маршрут этой подсети используется по умолчанию в таблицах маршрутизации VPC.
Эта конфигурация, в свою очередь, диктует правильность использования или не использования общедоступных IP-адресов в экземплярах этой конкретной подсети.
Каждая подсеть имеет ровно один маршрут по умолчанию, который может быть только одним из двух:
- объект "Интернет-шлюз" VPC, в случае "общедоступной" подсети, или
- устройство NAT - то есть, либо шлюз NAT, либо экземпляр EC2, выполняющий роль "экземпляр NAT", в случае "частной" подсети.
Интернет-шлюз не выполняет трансляцию сетевых адресов для экземпляров без общедоступных IP-адресов, поэтому экземпляр без общедоступного IP-адреса не может подключаться к Интернету, например, для загрузки обновлений программного обеспечения или доступа к другим ресурсам AWS, таким как S3 1 и SQS. - если маршрут по умолчанию в его подсети VPC является объектом интернет-шлюза. Итак, если вы являетесь экземпляром в "общедоступной" подсети, то вам нужен общедоступный IP-адрес для выполнения значительного количества вещей, которые обычно должны выполнять серверы.
Для случаев с только частным IP-адресом существует альтернативный способ исходящего доступа в Интернет. Это где Network Address Translation² и экземпляр 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 для трафика), а не объектом интернет-шлюза (который не работает). Входящий трафик из Интернета будет попадать в общедоступный 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 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 долл. США (стандартная плата за передачу данных AWS в размере 10 долл. США / ГБ для всех данных, передаваемых через NAT-шлюз) = $47,98
Экземпляр t2.nano, настроенный как экземпляр NAT, = 4,84 долл. США в месяц (0,0065 * 744 часа в месяц) + 10 долл. (стандартная плата за передачу данных AWS в размере 10 долл. США / ГБ для всех данных, передаваемых через экземпляр NAT) = 14,84 долл. США.
Это, конечно, меняется, когда вы выбираете избыточные экземпляры NAT, поскольку управляемый AWS шлюз NAT имеет встроенную избыточность для обеспечения высокой доступности. Если вам не нужны дополнительные 33 доллара в месяц, то управляемый экземпляр NAT определенно стоит того, чтобы не поддерживать другой экземпляр. Если вы используете экземпляр VPN (например, OpenVPN) для доступа к вашим экземплярам в VPC, вы можете просто настроить этот экземпляр так, чтобы он также работал в качестве шлюза NAT, и тогда вам не нужно поддерживать дополнительный экземпляр только для NAT (хотя некоторые люди могут не одобрить идею объединения VPN и NAT).
Ответ Михаэля - sqlbot делает неявное предположение, что частные IP-адреса требуются. Я думаю, что стоит усомниться в этом предположении - нужно ли вообще использовать частные IP-адреса? По крайней мере, один комментатор задал тот же вопрос.
В чем преимущество сервера в частной подсети с экземпляром NAT [против] сервера [в] общедоступной подсети со строгой политикой безопасности? - Абхиллман 24 июня 14: 23:45
Представьте себе сценарий, в котором вы используете VPC и назначаете публичные IP-адреса всем своим экземплярам EC2. Не волнуйтесь, это не означает, что они обязательно доступны через Интернет, потому что вы используете группы безопасности для ограничения доступа точно так же, как и в случае с EC2 classic. Используя общедоступные IP-адреса, вы можете легко предоставлять определенные услуги ограниченному кругу лиц без необходимости использовать что-то вроде ELB. Это освобождает вас от необходимости настраивать экземпляр NAT или шлюз NAT. А поскольку вам нужно вдвое меньше подсетей, вы можете выбрать меньшее выделение CIDR для своего VPC или создать большие подсети с таким же размером VPC. А меньшее количество подсетей означает, что вы будете платить меньше за трафик между AZ.
Так почему бы нам не сделать это? Почему 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, вы можете свободно присоединять / отсоединять Elastic IP в любое время, и у вас есть свобода изменять группы безопасности, применяемые к вашим экземплярам EC2.
... Но AWS ограничивает вас 5 EIP на регион. Вы можете запросить больше, и ваш запрос может быть удовлетворен. Но AWS с такой же вероятностью может отклонить этот запрос на основании вышеупомянутых доводов. Так что вы, вероятно, не хотите полагаться на EIP, если планируете когда-либо расширять свою инфраструктуру за пределы 5 экземпляров EC2 на регион.
В заключение, использование общедоступных IP-адресов дает некоторые приятные преимущества, но вы столкнетесь с проблемами администрирования или масштабирования, если попытаетесь использовать исключительно публичные IP-адреса. Надеюсь, это поможет проиллюстрировать и объяснить, почему лучшие практики такие, какие они есть.