Amazon VPC: вопросы и ответы

Плата за создание и использование самого облака VPC не взимается. Плата за пользование прочими сервисами Amazon Web Services, включая Amazon EC2, начисляется по опубликованным тарифам на соответствующие ресурсы, включая плату за передачу данных. Если облако VPC подключается к корпоративному ЦОД посредством дополнительного аппаратного VPN‑подключения, плата будет взиматься за час VPN‑подключения (по количеству времени, в течение которого VPN‑подключение находилось в активном состоянии). Неполные часы пользования оплачиваются как полные. Плата за данные, переданные через VPN‑подключение, будет взиматься по стандартным тарифам AWS на передачу данных. Информацию о ценах на VPC‑VPN см. в разделе цен на странице описания Amazon VPC.

Плата за использование прочих сервисов Amazon Web Services, включая Amazon EC2, начисляется по опубликованным тарифам на соответствующие ресурсы. Плата за передачу данных не взимается, если доступ к сервисам Amazon Web Services, таким как Amazon S3, осуществляется через интернет-шлюз VPC.

Если доступ к ресурсам AWS будет осуществляться через VPN-подключение, вам придется оплатить передачу данных через Интернет.

Облако Amazon VPC можно подключить:

• к сети Интернет (через интернет‑шлюз);
• к корпоративному ЦОД с помощью подключения AWS VPN по схеме site‑to‑site (через шлюз виртуальной частной сети);
• одновременно к сети Интернет и корпоративному ЦОД (используя как интернет‑шлюз, так и шлюз виртуальной частной сети);
• к прочим сервисам AWS (через интернет‑шлюз, NAT, шлюз виртуальной частной сети или адреса сервера VPC);
• к другим VPC (через пиринговое подключение VPC).

Сервис Amazon VPC поддерживает создание интернет‑шлюза. Этот шлюз позволяет инстансам Amazon EC2, находящимся в VPC, осуществлять прямой доступ в Интернет. Также можно использовать выходной интернет‑шлюз – шлюз с фиксацией состояния для IPv6‑трафика, представляющий доступ на выход из облака VPC в Интернет.

Нет. Для интернет‑шлюза предусмотрено горизонтальное масштабирование, обеспечение избыточности и высокой доступности. Он не подразумевает ограничений на пропускную способность.

Использование публичных IP‑адресов, в том числе эластичных IP‑адресов (EIP) и глобальных уникальных адресов (GUA) IPv6, дает возможность инстансам VPC выполнять прямое исходящее подключение к Интернету и получать незапрашиваемый входящий трафик из Интернета (например, от веб‑серверов). Можно также использовать решения, изложенные в ответе на следующий вопрос.

Любой назначенный инстансу или размещенному в VPC сервису IP-адрес, к которому можно получить доступ через Интернет, считается публичным. Только публичные IPv4-адреса, включая эластичные IP-адреса (EIP) и адреса IPv6 GUA, можно маршрутизировать в Интернете. Для этого потребуется сначала подключить VPC к Интернету, а затем обновить таблицу маршрутизации, чтобы обеспечить доступ адресов в Интернет и их доступность из Интернета.

Инстансы без публичных IP-адресов могут получать доступ в Интернет одним из двух способов.

1. Инстансы без публичных IP‑адресов для доступа в Интернет могут направлять свой трафик через шлюз NAT или инстанс NAT. Такие инстансы для доступа в Интернет используют публичные IP‑адреса шлюза NAT или инстанса NAT. Шлюз NAT или инстанс NAT позволяют выполнять исходящие подключения, но не позволяют другим компьютерам в Интернете инициировать соединение с инстансами, имеющими частные адреса
2. В случае облака VPC с аппаратным VPN‑подключением или с подключением Direct Connect интернет‑трафик инстансов можно маршрутизировать через виртуальный частный шлюз к существующему ЦОД. Оттуда трафик попадает в Интернет через существующие выходные точки и устройства безопасности и мониторинга сети.

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

Нет. При использовании публичных IP-адресов взаимодействие между инстансами и сервисами на AWS происходит с помощью частной сети AWS. Пакеты, которые созданы в сети AWS и имеют местом назначения сеть AWS, остаются в глобальной сети AWS за исключением трафика, направленного в регионы AWS в Китае и обратно.

Кроме того, все данные, проходящие через глобальную сеть AWS, которая связывает наши центры обработки данных и регионы, автоматически шифруются перед отправкой на физическом уровне. Помимо этого используются и дополнительные уровни шифрования, например межрегиональный пиринговый трафик между всеми VPC и подключения Transport Layer Security (TLS) между сервисом и клиентом и между несколькими сервисами. 

Подключение AWS VPN по схеме site‑to‑site позволяет установить соединение между VPC и ЦОД. Amazon поддерживает VPN‑подключения с поддержкой IPsec. Маршрутизация данных, передаваемых между VPC и ЦОД, выполняется через зашифрованное VPN‑подключение в целях обеспечения конфиденциальности и целостности данных во время передачи. Для установления подключения AWS VPN по схеме site‑to‑site интернет‑шлюз не требуется.

Можно использовать любой диапазон адресов IPv4, включая RFC 1918, или диапазоны IP‑адресов с публичной маршрутизацией для первичного блока CIDR. Для вторичных блоков CIDR применяются некоторые ограничения. Доступ к блокам IP‑адресов с публичной маршрутизацией возможен только через виртуальный частный шлюз; к ним не удастся получить доступ через Интернет с помощью интернет‑шлюза. Сервис AWS не передает информацию о пользовательских блоках IP‑адресов в Интернет. До пяти блоков GUA CIDR IPv6, предоставленных Amazon или по модели BYOIP, можно назначить облаку VPC через Консоль управления AWS или посредством соответствующего вызова API.

В качестве первичного блока CIDR при создании VPC назначается один диапазон IP‑адресов бесклассовой междоменной маршрутизации (CIDR), а после создания VPC можно добавить до четырех (4) вторичных блоков CIDR. Адреса подсетей в рамках облака VPC задаются из этого диапазона IP‑адресов CIDR. Обратите внимание: если создать несколько VPC с перекрывающимися диапазонами IP‑адресов, подключить эти VPC к обычным локальным сетям через аппаратное VPN‑подключение будет невозможно. Для этих целей мы рекомендуем использовать неперекрывающиеся диапазоны IP-адресов. Для своего VPC можно выделить до пяти блоков CIDR IPv6, предоставленных Amazon или по модели BYOIP.

По умолчанию для VPC назначен следующий диапазон CIDR: 172.31.0.0/16. Подсети по умолчанию в рамках VPC по умолчанию назначаются в сетевых блоках /20 в рамках диапазона CIDR VPC. 

Да, в AWS VPC можно использовать собственные публичные адреса IPv4 и GUA-адреса IPv6 и настроить для них статичную связь с подсетями и инстансами EC2. Чтобы получить доступ к этим адресам через Интернет, необходимо анонсировать их из собственной локальной сети. Кроме того, необходимо настроить маршрутизацию трафика к этим адресам между своим облаком VPC и локальной средой, используя подключение AWS Direct Connect или AWS VPN. Для маршрутизации трафика из облака VPC можно использовать Virtual Private Gateway. Аналогичным образом можно направить трафик из локальной сети обратно в VPC с помощью собственных маршрутизаторов.

В настоящее время Amazon VPC поддерживает 5 (пять) диапазонов IP‑адресов IPv4: 1 (один) первичный и 4 (четыре) вторичных. Каждый из этих диапазонов может быть размером от /28 и до /16 (в представлении CIDR). Диапазон IP-адресов VPC не должен перекрывать диапазоны адресов существующей сети.

Для IPv6 VPC имеет фиксированный размер /56 (в представлении CIDR). У VPC могут быть и блоки CIDR IPv4, и блоки CIDR IPv6.

Да. Существующее облако VPC можно расширить, добавив к нему 4 (четыре) вторичных диапазона адресов IPv4 (блоков CIDR). Можно уменьшить VPC, удалив вторичные блоки CIDR, которые были добавлены в VPC.   Также в VPC можно добавить до пяти (5) дополнительных диапазонов IP IPv6 (CIDR).  Вы можете уменьшить VPC, удалив эти дополнительные диапазоны.

В настоящее время в одном VPC можно создавать до 200 подсетей. Если требуется создать большее количество подсетей, отправьте запрос в центр поддержки.

Минимальный размер подсети – /28 (или 14 IP‑адресов) для IPv4. Размер подсети не может превышать размер облака VPC, в котором она создается.

Для IPv6 размер подсети всегда составляет /64. Подсети может быть назначен только один блок CIDR IPv6.

Нет. Amazon резервирует первые четыре IP‑адреса и последний IP‑адрес каждой из подсетей в целях надлежащей работы протокола IP.

Во время запуска инстанса Amazon EC2 в рамках подсети, предназначенной не только для IPv6, можно дополнительно задать основной частный IPv4‑адрес инстанса. Если основной частный IPv4‑адрес инстанса не будет задан, AWS автоматически присвоит ему адрес из диапазона IPv4‑адресов, назначенного для данной подсети. Вы можете назначить дополнительный частный IPv4‑адрес во время запуска инстанса, при создании эластичного сетевого интерфейса или в любой момент после запуска инстанса или создания интерфейса. При запуске инстанса Amazon EC2 в пределах подсети, предназначенной только для IPv6, AWS автоматически обращается к нему с предоставленного Amazon адреса подсети IPv6 GUA CIDR. Адреса инстанса IPv6 GUA останутся частными, если вы не обеспечите их доступ в Интернет и доступность из Интернета, выбрав правильную группу безопасности, NACL и настройки таблицы маршрутизации.

Основной частный IPv4-адрес инстанса, запущенного в IPv4 или подсети с «двойным стеком», остается неизменным в течение жизненного цикла инстанса или интерфейса. Дополнительные частные IPv4‑адреса можно назначать, отменять, а также перемещать между интерфейсами или инстансами в любой момент. Присвоенный адрес IPv6 GUA инстанса, запущенного в пределах подсети, предназначенной только для IPv6, также является первым IP-адресом главной сети инстанса, и его можно изменить в любой момент, привязав новый адрес и убрав старый.

Нет. IPv4‑адрес, назначенный запущенному инстансу, можно использовать повторно только в том случае, если исходный инстанс перешел в состояние «terminated» (завершен). Но адрес IPv6 GUA, назначенный запущенному инстансу, можно убрать с текущего инстанса и использовать повторно на другом.

Нет. IP‑адрес можно указать только для одного инстанса в момент его запуска.

Инстансу можно назначать любые IP-адреса, отвечающие следующим условиям:

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

Да. Эластичному сетевому интерфейсу или инстансу EC2 в облаке Amazon VPC можно назначить один или несколько дополнительных частных IP‑адресов. Количество дополнительных частных IP‑адресов, которое можно назначить инстансу, зависит от его типа. Для получения дополнительной информации о количестве дополнительных частных IP‑адресов, присваиваемых определенным типам инстансов, см. Руководство пользователя EC2.

Да, но стоит учесть, что адреса EIP будут доступны только из Интернета (не будут доступны через VPN‑подключение). Каждый эластичный IP‑адрес должен быть связан с уникальным частным IP‑адресом инстанса. Эластичные IP‑адреса следует использовать только для инстансов в подсетях, настроенных на маршрутизацию трафика непосредственно через интернет‑шлюз. EIP-адреса невозможно использовать для инстансов в подсетях, если для доступа в Интернет используется инстанс NAT или шлюз NAT. Все указанное применимо только для IPv4. В настоящее время Amazon VPC не поддерживают эластичные IP-адреса для IPv6.

Возможность использования собственного IP‑адреса, или BYOIP, позволяет клиентам перемещать (частично или полностью) свое адресное пространство IPv4 или IPv6 с публичной маршрутизацией в AWS для использования со своими ресурсами AWS. Диапазон IP-адресов будет по-прежнему принадлежать клиентам. Клиенты могут создавать эластичные IP‑адреса из пространства IPv4, которое они добавили в AWS, и использовать их с инстансами EC2, шлюзами NAT и балансировщиками Network Load Balancer. Клиенты также могут связывать до пяти CIDR с VPC из пространства IPv6, которое они добавили в AWS. Доступ к IP‑адресам, предоставляемым Amazon, при этом сохраняется, и клиенты могут выбирать, что использовать: эластичные IP‑адреса BYOIP, предоставляемые Amazon IP‑адреса или и те, и другие.

Добавлять свои собственные IP-адреса в AWS может потребоваться по следующим причинам.
Репутация IP. Многие клиенты считают, что репутация IP‑адресов является стратегическим активом, и поэтому хотят использовать собственные IP‑адреса для своих ресурсов в AWS. Например, клиенты, которые обслуживают такие сервисы, как агенты передачи сообщений исходящей электронной почты с IP-адресами высокой репутации, теперь могут использовать свое пространство IP-адресов и успешно поддерживать имеющийся уровень успешности отправки.

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

Жестко заданные зависимости. У некоторых клиентов могут существовать устройства с жестко заданными IP‑адресами или архитектурные зависимости от таких IP‑адресов. BYOIP позволяет таким клиентам беспрепятственно выполнить миграцию в AWS.

Регулирование и соответствие требованиям. Многие клиенты должны использовать определенные IP‑адреса из‑за существующих норм или требований. BYOIP позволяет открыть доступ к этим IP‑адресам.

В соответствии с политикой локальной сети IPv6 многие клиенты могут направлять в свою локальную сеть только адреса IPv6. BYOIP позволяет открыть доступ для этих клиентов при назначении собственного диапазона адресов IPv6 для VPC и его направлении в локальную сеть через Интернет или Direct Connect.

При освобождении эластичного IP‑адреса из диапазона BYOIP он возвращается в пул IP‑адресов BYOIP, из которого был выделен.

Подробные сведения о доступности BYOIP приведены в документации .

Да. Префикс BYOIP можно использовать с любым количеством VPC в одном аккаунте.

В аккаунт можно добавить не более пяти диапазонов IP-адресов.

Наиболее специфические префиксы, которые можно добавить с помощью BYOIP, – это префикс IPv4 /24 и префикс IPv6 /56. Если вы планируете транслировать префикс Ipv6 в Интернет, наиболее специфическим префиксом IPv6 является /48.

Использовать можно зарегистрированные префиксы ARIN, RIPE и APNIC.

На данный момент использование переназначенных или перераспределенных префиксов не допускается. Диапазоны IP-адресов должны быть результатом прямого распределения или прямого назначения.

Да. Вы можете это сделать, отменив выделение префикса BYOIP для текущего региона и выделив этот префикс для нового региона.

Amazon VPC IP Address Manager (IPAM) – это управляемый сервис, который упрощает планирование, отслеживание и мониторинг IP-адресов для рабочих нагрузок AWS. С помощью IPAM можно легко организовать IP-адреса на основе ваших потребностей в маршрутизации и безопасности, а также установить простые бизнес-правила для управления назначением IP-адресов. Вы также можете автоматизировать назначение IP-адресов VPC, избавляясь от необходимости использовать электронные таблицы или собственные приложения для планирования IP-адресов, которые могут быть сложными в обслуживании и занимать много времени. IPAM обеспечивает единое операционное представление, которое можно использовать как единственный источник достоверной информации, позволяющий быстро и эффективно выполнять рутинные действия по управлению IP-адресами, такие как отслеживание использования IP, устранение неполадок и аудит.

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

AWS IPAM предлагает указанные ниже возможности.
 

• Выделение IP-адресов для крупномасштабных сетей. IPAM может автоматизировать выделение IP-адресов для сотен аккаунтов и VPC на основе настраиваемых бизнес-правил.
   
• Мониторинг использования IP-адресов в сети. IPAM может отслеживать IP-адреса и позволяет получать оповещения, когда IPAM обнаруживает потенциальные проблемы, такие как исчерпание IP-адресов, которые могут остановить рост сети, или перекрывающиеся IP-адреса, которые могут привести к ошибочной маршрутизации.
   
• Устранение неполадок в сети. IPAM может помочь вам быстро определить, вызваны ли проблемы с подключением неправильной настройкой IP-адреса или другими проблемами.
   
• Аудит IP-адресов. IPAM автоматически сохраняет данные мониторинга IP-адреса (максимум до трех лет). Вы можете использовать эти исторические данные для проведения ретроспективного анализа и аудита сети.

Основные компоненты IPAM указаны ниже.

• Область действия – контейнер самого высокого уровня в IPAM. IPAM содержит две области по умолчанию. Каждая область действия представляет пространство IP для одной сети. Частная область действия предназначена для всего частного пространства. Публичная область действия предназначена для всего публичного пространства. Области действия позволяют повторно использовать IP-адреса в нескольких неподключенных сетях, не вызывая перекрытия или конфликта IP-адресов. В пределах области можно создавать пулы IPAM.
   
• Пул – это набор смежных диапазонов IP-адресов (или CIDR). Пулы IPAM позволяют организовать IP-адреса в соответствии с вашими потребностями в маршрутизации и безопасности. Вы можете иметь несколько пулов в пуле верхнего уровня. Например, если у вас есть отдельные потребности в маршрутизации и безопасности для приложений разработки и производства, вы можете создать пул для каждого из них. В пулах IPAM вы выделяете CIDR для ресурсов AWS.
• Выделение – это назначение CIDR из пула IPAM другому ресурсу или пулу IPAM. Когда вы создаете VPC и выбираете пул IPAM для CIDR VPC, CIDR выделяется из CIDR, подготовленного для пула IPAM. Вы можете отслеживать и управлять выделением с помощью IPAM.

Да. IPAM поддерживает адреса BYOIPv4 и BYOIPv6. BYOIP – это функция EC2, позволяющая перенести принадлежащие вам IP-адреса в AWS. С помощью IPAM вы можете напрямую выделять блоки IP-адресов и делиться ими между учетными записями и организациями. Существующие клиенты BYOIP, использующие IPv4, могут перенести свои пулы в IPAM, чтобы упростить управление IP.

Да, Amazon предоставляет непрерывные блоки CIDR IPv6 для выделения VPC. Непрерывные блоки CIDR позволяют объединять CIDR в одну запись для сетей и конструктов безопасности, таких как списки контроля доступа, таблицы маршрутизации, группы безопасности и брандмауэры. Вы можете добавить CIDR Amazon IPv6 в общедоступный пул и использовать все функции IPAM для управления и мониторинга использования IP. Выделение этих блоков CIDR начинается с приращения /52, а блоки большего размера доступны по запросу. Например, вы можете выделить /52 CIDR от Amazon и использовать IPAM для совместного использования между аккаунтами и создания VPC в этих учетных записях.

Нет, предоставленные Amazon непрерывные блоки CIDR IPv6 в настоящее время поддерживаются только в IPAM.

Вы можете совместно использовать пулы IPAM с другими аккаунтами в вашей организации AWS с помощью AWS Resource Access Manager (RAM). Вы также можете совместно использовать пулы IPAM с аккаунтами за пределами основной организации AWS. Например, эти аккаунты могут представлять другое направление деятельности вашей компании или управляемую службу, размещенную партнером от вашего имени в другой организации AWS.

Да. Для каждой подсети можно создать маршрут по умолчанию. Маршрут по умолчанию может направлять трафик на выход из VPC через интернет-шлюз, виртуальный частный шлюз или шлюз NAT.

Для обеспечения безопасности инстансов в Amazon VPC можно использовать группы безопасности Amazon EC2. Группы безопасности VPC позволяют указать как входящий, так и исходящий сетевой трафик, разрешенный для обмена с инстансом Amazon EC2. Трафик, явным образом не разрешенный для обмена с инстансом, автоматически блокируется.

Помимо групп безопасности, можно разрешить или запретить сетевой трафик каждой подсети, входящий и/или исходящий, с помощью списков контроля доступа (ACL) к сети.

Группы безопасности VPC определяют трафик, разрешенный для обмена с инстансом Amazon EC2. Сетевые ACL работают на уровне подсети и выполняют оценку входящего и исходящего трафика. Сетевые ACL можно использовать для создания как разрешающих, так и запрещающих правил. Сетевые ACL не фильтруют трафик для инстансов в рамках одной подсети. Кроме того, сетевые ACL выполняют фильтрацию без фиксации состояния, а группы безопасности выполняют фильтрацию с фиксацией состояния.

Фильтрация с фиксацией состояния отслеживает источник запроса и может автоматически разрешить отправку ответа на запрос к компьютеру‑источнику. Например, фильтр с фиксацией состояния, отвечающий за прохождение входящего трафика через TCP‑порт 80 веб‑сервера, разрешит прохождение обратного трафика, обычно через порт с более высоким номером (например, TCP‑порт получателя 63 912), через фильтр с фиксацией состояния, расположенный между клиентом и веб‑сервером. Фильтрующее устройство поддерживает таблицу состояний, в которую заносятся номера портов и IP‑адреса источника и получателя. Фильтрующее устройство должно содержать всего одно правило: разрешать трафик, входящий на веб-сервер через TCP-порт 80.

Фильтрация без фиксации состояния проверяет только IP‑адреса источника и получателя и порт назначения; она не определяет, является трафик новым запросом или ответом на запрос. В вышеуказанном примере необходимо применить два правила для фильтрующего устройства: первое правило – разрешить трафик, входящий на веб-сервер через TCP-порт 80, и второе правило – разрешить трафик, исходящий от веб-сервера (диапазон TCP-портов: 49 152–65 535).

Да. Если настроен интернет‑шлюз, трафик Amazon VPC для инстансов Amazon EC2, не входящих в VPC, пройдет через интернет‑шлюз и затем попадет в публичную сеть AWS, откуда сможет достичь нужного инстанса EC2. Если интернет-шлюз не был настроен или если инстанс находится в подсети, маршрутизируемой через виртуальный частный шлюз, трафик пройдет через VPN-подключение, выйдет через ЦОД, а затем повторно войдет в публичную сеть AWS.

Да. Инстансы в одном регионе могут обмениваться данными друг с другом посредством межрегионального пирингового подключения VPC, публичных IP-адресов, шлюзов NAT, инстансов NAT, VPN-подключений или подключений Direct Connect.

Да. Существует несколько вариантов организации обмена данными между ресурсами, находящимися в облаке VPC, и сервисом Amazon S3. Можно использовать адрес VPC для S3, который позволяет убедиться в том, что весь трафик остается в рамках сети Amazon, и применять дополнительные политики доступа к трафику Amazon S3. Для организации доступа в Интернет из облака VPC, а также обмена данными между инстансами облака VPC и сервисом Amazon S3 можно использовать интернет‑шлюз. Можно также направить весь трафик в Amazon S3 через Direct Connect или VPN-подключение для выхода из ЦОД и повторного входа в публичную сеть AWS.

Да. Чтобы отслеживать сетевой трафик в Amazon VPC, можно использовать зеркалирование трафика Amazon VPC и журналы Amazon VPC Flow Logs.

Журналы потоков VPC – это функция, которая позволяет захватывать информацию об IP‑трафике, идущем к сетевым интерфейсам в VPC или от них. Данные из журналов потоков можно публиковать либо в журналах Amazon CloudWatch Logs, либо в Amazon S3. Мониторинг журналов потоков VPC обеспечивает операционный контроль сетевых зависимостей и моделей трафика, выявление аномалий и предотвращение утечки данных или устранение неполадок сетевых подключений и проблем конфигурации. Обогащенные метаданные в журналах потоков дают дополнительную аналитическую информацию об инициаторе TCP-подключений, фактическом источнике на уровне пакетов и точке назначения трафика, проходящего по средним уровням, таким как шлюз NAT. Можно также архивировать журналы потоков. Это поможет выполнить определенные нормативные требования. Подробнее о журналах потоков Amazon VPC см. в документации.

Вы можете создать журнал потоков для VPC, подсети или сетевого интерфейса. Если вы создаете журнал потоков для подсети или VPC, каждый сетевой интерфейс в этой подсети или в этом VPC отслеживается. Создавая подписку на журнал потоков, вы можете выбрать поля метаданных, которые требуется захватывать, максимальный период агрегирования и предпочитаемый тип журнала. Также можно выбрать, следует ли захватывать весь трафик или только принятый или отклоненный. Для анализа журналов потоков VPC, доставляемых в журналы CloudWatch Logs, вы можете пользоваться такими инструментами, как CloudWatch Log Insights или CloudWatch Contributor Insights. Для опроса и визуализации журналов потоков VPC, доставляемых в Amazon S3, вы можете пользоваться такими инструментами, как Amazon Athena или AWS QuickSight. Для анализа журналов вы можете создать подчиненное пользовательское приложение или воспользоваться партнерскими решениями, такими как Splunk, Datadog, Sumo Logic, Cisco StealthWatch, Checkpoint CloudGuard, New Relic и другими.

Да, вы можете создать журнал потока VPC для транзитного шлюза или для отдельного вложения транзитного шлюза. С помощью этой функции транспортный шлюз может экспортировать подробную информацию, такую как IP-адреса источника/назначения, порты, протокол, счетчики трафика, временные метки и различные метаданные для сетевых потоков, проходящих через транспортный шлюз. Подробнее о поддержке журналов потоков Amazon VPC для транспортного шлюза см. в документации.

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

За публикацию журналов потоков в CloudWatch Logs или Amazon S3 взимается плата за прием и архивирование данных. Подробную информацию и примеры см. на странице цен на Amazon CloudWatch. С помощью тегов распределения расходов можно отслеживать оплату в журналах протоколов.

Возможность зеркалирования трафика Amazon VPC позволяет клиентам просто реплицировать входящий и исходящий сетевой трафик инстанса Amazon EC2 и перенаправлять трафик к внеполосным устройствам мониторинга и обеспечения безопасности, когда необходимо инспектировать контент, отслеживать угрозы, выявлять и устранять неисправности. Такие устройства можно развертывать на одном или нескольких инстансах EC2, размещенных за балансировщиком Network Load Balancer (NLB) с получателем протокола UDP.

В случае с инстансами EC2 возможность зеркалирования трафика поддерживает запись сетевых пакетов на уровне эластичных сетевых интерфейсов (ENI). См. документацию для инстансов EC2, которые поддерживают зеркальное отображение трафика Amazon VPC.

Клиенты могут использовать как инструменты с открытым кодом, так и разнообразные решения для мониторинга, представленные в AWS Marketplace. Возможность зеркалирования трафика позволяет клиентам передавать реплицируемый трафик в средство сбора, брокер сетевых пакетов или же в средство аналитики, не требуя установки каких‑либо специальных агентов.

Журналы Amazon VPC Flow Logs позволяют клиентам собирать, хранить и анализировать журналы сетевых потоков. В журналы Flow Logs записываются данные о разрешенном и заблокированном трафике, исходные и целевые IP‑адреса, порты, номера протоколов, количество пакетов и байтов, а также действия (принять или отклонить). Эту возможность можно использовать для устранения проблем с подключением и безопасностью, а также для проверки того, что правила сетевого доступа работают надлежащим образом.

Зеркалирование трафика Amazon VPC позволяет подробнее изучать сетевой трафик. В частности, с ее помощью можно анализировать фактическое содержимое трафика, например полезные данные. Эта возможность предназначена для сложных ситуаций. К примеру, с ее помощью можно проанализировать фактические пакеты и определить источник проблем с производительностью, подробно изучить сложную сетевую атаку, обнаружить нарушения внутри организации или скомпрометированные рабочие нагрузки.

В настоящее время Amazon VPC можно использовать в различных зонах доступности во всех регионах Amazon EC2.

Да. 

Нет. Подсеть должна находиться в одной зоне доступности.

При запуске инстанса Amazon EC2 необходимо указать подсеть, в которой требуется запустить инстанс. Инстанс будет запущен в зоне доступности, связанной с указанной подсетью.

При создании подсети необходимо указать зону доступности, в которой ее необходимо разместить. C помощью VPC Wizard можно выбрать зону доступности подсети на экране подтверждения. При использовании API или интерфейса командной строки можно задать зону доступности подсети в процессе ее создания. Если вы не указали зону доступности, по умолчанию будет выбрано значение No Preference и подсеть будет создана в произвольной зоне доступности в регионе.

Если инстансы находятся в подсетях, расположенных в разных зонах доступности, с вас будет взиматься плата в размере 0,01 USD за 1 ГБ переданных данных.

Да. API DescribeInstances() вернет список всех запущенных инстансов Amazon EC2. Инстансы EC2‑Classic можно отличить от инстансов EC2‑VPC по содержимому поля подсети. Если в поле содержится идентификатор подсети, значит инстанс находится в VPC.

Да. Процедура DescribeVolumes() вернет список всех томов EBS.

При использовании инстансов с IPv4-адресами в VPC можно запускать любое количество инстансов Amazon EC2, если размер VPC позволяет назначить IPv4‑адреса каждому из инстансов. Изначально существует ограничение на одновременный запуск до 20 инстансов Amazon EC2 и на максимальный размер VPC /16 (65 536 IP‑адресов). Если требуется увеличить эти лимиты, заполните следующую форму. При использовании инстансов, предназначенных только для IPv6, VPC размером /56 позволяет запускать практически неограниченное количество инстансов Amazon EC2.

В Amazon VPC можно использовать AMI, зарегистрированные в том же регионе, что и VPC. Например, можно использовать AMI, зарегистрированные в us‑east‑1, в VPC, зарегистрированном в us‑east‑1. Дополнительную информацию см. в разделе «Регионы и зоны доступности» на странице вопросов и ответов по сервису Amazon EC2.

Да, снимки состояния EBS можно использовать, если они находятся в том же регионе, что и VPC. Подробные сведения см. в разделе «Регионы и зоны доступности» на странице вопросов и ответов по сервису Amazon EC2.

Да, однако инстанс, запускаемый в VPC с помощью AMI с поддержкой Amazon EBS, при остановке и перезапуске будет иметь один и тот же IP‑адрес. Если аналогичные инстансы будут запускаться вне VPC, они будут получать новый IP‑адрес. IP-адреса остановленных инстансов в подсети будут считаться недоступными.

Да.

Да. 

Да. Кластерные инстансы поддерживаются в Amazon VPC, однако не все типы инстансов будут доступны во всех регионах и зонах доступности.

При запуске инстанса ему назначается имя узла. Доступны два варианта: имя на основе IP-адреса или на основе ресурса, и этот параметр можно менять во время запуска. Имя на основе IP-адреса использует форму частного адреса IPv4, в то время как имя на основе ресурса – форму «инстанс-id».

Да, можно изменить имя узла на основе IP-адреса на имя на основе ресурса, или наоборот, остановив инстанс и затем поменяв параметры наименования на основе ресурсов.

Да, имя узла инстанса можно использовать в качестве имен узла DNS. У инстансов, запущенных в подсетях, предназначенных только для IPv4, или в подсетях с «двойным стеком», имя на основе IP-адреса всегда преобразуется в частный IPv4-адрес главного сетевого интерфейса инстанса, и его нельзя отключить. По желанию можно настроить преобразование имени на основе ресурса либо в частный IPv4-адрес главного сетевого интерфейса, либо в первый адрес IPv6 GUA главного сетевого интерфейса, либо в оба адреса одновременно. В инстансах, которые запущены в подсети, предназначенной только для IPv6, имя на основе ресурса можно преобразовать в первый адрес IPv6 GUA главного сетевого интерфейса. 

VPC по умолчанию – это логически изолированная виртуальная сеть в облаке AWS, которая автоматически создается для аккаунта AWS при первом выделении ресурсов Amazon EC2. Если инстанс будет запущен без указания идентификатора подсети, он запустится в VPC по умолчанию.

При запуске ресурсов в VPC по умолчанию клиенты получают преимущества использования расширенных сетевых возможностей Amazon VPC (EC2‑VPC) и простоту эксплуатации облака Amazon EC2 (EC2‑Classic). Вы сможете менять группы безопасности на лету, выполнять фильтрацию исходящих данных с помощью групп безопасности, использовать несколько IP-адресов и несколько сетевых интерфейсов без необходимости создавать VPC отдельно и запускать инстансы в рамках VPC.

Если аккаунт AWS был создан 18 марта 2013 г. или позднее, запускать ресурсы можно в облаке VPC по умолчанию. Ознакомьтесь с этим сообщением на форуме, чтобы узнать список регионов, в которых доступен набор возможностей облака VPC по умолчанию. Аккаунты, созданные до указанной даты, могут также использовать облака VPC по умолчанию в любых поддерживаемых регионах, где ранее не запускались инстансы EC2 или не выделялись ресурсы сервисов Elastic Load Balancing, Amazon RDS, Amazon ElastiCache или Amazon Redshift.

Нет. Для запуска инстансов EC2, а также других ресурсов AWS в облаке VPC по умолчанию и управления ими можно использовать Консоль управления AWS, интерфейс командной строки AWS EC2 или API Amazon EC2. Сервис AWS автоматически создаст VPC по умолчанию и подсеть по умолчанию в каждой из зон доступности региона AWS. VPC по умолчанию будет подключено к интернет-шлюзу, а инстансы автоматически получат публичные IP-адреса, как в случае с EC2-Classic.

См. раздел Различия между EC2-Classic и EC2-VPC Руководства пользователя EC2.

Нет. VPC по умолчанию получает доступ в Интернет, а все инстансы, запущенные в подсетях по умолчанию в рамках VPC по умолчанию, автоматически получают публичные IP‑адреса. При желании можно добавить VPN-подключение к VPC по умолчанию.

Да. Чтобы запустить инстанс в VPC, отличном от доступного по умолчанию, необходимо указать идентификатор подсети в процессе запуска инстанса.

Да. Чтобы запускать инстансы в подсетях, отличных от доступных по умолчанию, необходимо инициировать их запуск с помощью консоли или опции --subnet в интерфейсе командной строки, API или SDK.

Вам доступно по одному облаку VPC по умолчанию в каждом из регионов AWS, где атрибут Supported-Platforms имеет значение EC2-VPC.

Одна подсеть по умолчанию создается для каждой из зон доступности в облаке VPC по умолчанию.

В настоящий момент нет.

В настоящий момент нет.

Да, VPC по умолчанию можно удалить. После удаления можно создать новое облако VPC по умолчанию непосредственно из консоли VPC или с помощью интерфейса командной строки (CLI). Это создаст новое VPC по умолчанию в конкретном регионе. При этом предыдущее VPC, которое было удалено, не восстанавливается.

Да, подсеть по умолчанию можно удалить. После удаления можно создать новую подсеть по умолчанию в зоне доступности с помощью интерфейса командной строки или SDK. При этом будет создана новая подсеть по умолчанию в указанной зоне доступности. При этом удаленная подсеть не восстанавливается.

Самый простой способ получить облако VPC по умолчанию – создать новый аккаунт в регионе, где активировано облако VPC по умолчанию, или использовать существующий аккаунт в регионе, где вы еще не были представлены, когда атрибут Supported-Platforms для этого аккаунта в этом регионе имеет значение EC2-VPC.

Да. Однако мы можем активировать VPC по умолчанию для действующего аккаунта только в том случае, если у аккаунта нет ресурсов EC2‑Classic в данном регионе. Кроме того, требуется завершить в данном регионе работу всех выделенных ресурсов Elastic Load Balancing, Amazon RDS, Amazon ElastiCache и Amazon Redshift, не имеющих отношения к VPC. После того как аккаунт будет настроен на работу с VPC по умолчанию, все запуски ресурсов, выполняемые в будущем, включая инстансы, запускаемые сервисом Auto Scaling, будут происходить в облаке VPC по умолчанию. Чтобы запросить настройку существующего аккаунта на работу с VPC по умолчанию, перейдите в раздел «Account and Billing» (Аккаунт и счета), выберите «Service: Account -> Category: Convert EC2 Classic to VPC» (Сервис: аккаунт > Категория: преобразование EC2 Classic в VPC) и сформируйте запрос. Мы проверим ваш запрос, существующие сервисы AWS, наличие EC2-Classic и предоставим руководство по дальнейшим шагам.

Если ваш аккаунт AWS использует облако VPC по умолчанию, все аккаунты IAM, связанные с аккаунтом AWS, используют то же VPC по умолчанию, как и аккаунт AWS.

EC2-Classic – это однородная сеть, которую мы выпустили в EC2 летом 2006 года. EC2-Classic позволяет инстансам работать в единой однородной сети, которую вы можете разделить с другими клиентами. В 2009 году, вдохновившись постоянно меняющимися потребностями наших клиентов, мы создали Amazon Virtual Private Cloud (VPC), позволив запуск инстансов в виртуальном частном облаке, логически изолированном от аккаунта AWS. Сегодня, несмотря на то, что большинство клиентов используют Amazon VPC, некоторые из них по-прежнему работают с EC2-Classic.

15 августа 2022 года мы закрываем Amazon EC2-Classic, и до этой даты вам необходимо перенести все инстансы EC2 и другие ресурсы AWS из EC2-Classic в Amazon VPC. В следующем разделе представлена дополнительная информация о закрытии EC2-Class, а также инструменты и ресурсы, которые помогут в процессе миграции.

Оно повлияет только в том случае, если в вашем аккаунте в любом из регионов AWS включена функция EC2-Classic. Вы можете проверить, включена ли функция EC2-Classic для региона AWS с помощью консоли или команды describe-account-attributes. Подробную информацию см. в этом документе.

Если у вас нет активных ресурсов AWS с функцией EC2-Classic в любом из регионов, отключите EC2-Classic в аккаунте для этого региона. Отключение EC2-Classic позволит по умолчанию запустить VPC в регионе. Для этого перейдите в Центр поддержки AWS на странице console.thinkwithwp.com/support, выберите Create case (Создать обращение), затем Account and billing support (Помощь по вопросам аккаунта и оплаты). В поле Type (Тип) выберите Account (Аккаунт), для поля Category (Категория) – Convert EC2 Classic to VPC (Конвертировать EC2 Classic в VPC), заполните другие необходимые данные и нажмите Submit (Отправить).

30 октября 2021 года мы автоматически отключим EC2-Classic в вашем аккаунте в любом регионе, не имеющем ресурсов AWS (инстансы EC2, Amazon Relational Database, AWS Elastic Beanstalk, Amazon Redshift, AWS Data Pipeline, Amazon EMR, AWS OpsWorks) на EC2-Classic с 1 января 2021 года.

С другой стороны, если у вас есть ресурсы AWS, работающие на EC2-Classic, мы просим как можно скорее осуществить миграцию на Amazon VPC. Вы не сможете запускать какие-либо инстансы или сервисы AWS на платформе EC2-Classic после 15 августа 2022 года. Любые запущенные рабочие нагрузки или сервисы постепенно потеряют доступ ко всем сервисам AWS на платформе EC2-Classic, начиная с 16 августа 2022 года, после выведения из эксплуатации.

Руководства по миграции для ресурсов AWS приведены в следующем вопросе.

Amazon VPC предоставляет вам полный контроль над виртуальной сетевой средой AWS, логически изолированной от вашего аккаунта AWS. В среде EC2-Classic рабочие нагрузки используют единую однородную сеть вместе с другими клиентами. Среда Amazon VPC предлагает множество преимуществ по сравнению с EC2-Classic. Например, выбор собственного пространства IP-адресов, конфигурация общедоступной и частной подсетей, а также управление таблицами маршрутов и сетевыми шлюзами. Все службы и инстансы, в настоящее время доступные на EC2-Classic, имеют аналогичные сервисы в среде Amazon VPC. Amazon VPC также предлагает гораздо более широкий и современный набор инстансов, чем EC2-Classic. Дополнительную информацию об Amazon VPC см. по этой ссылке.

Чтобы помочь в миграции ресурсов, мы опубликовали руководства и создали решения, которые перечислены ниже. Для миграции вам необходимо воссоздать ресурсы EC2-Classic в своем VPC. Во-первых, вы можете использовать этот скрипт для поиска всех ресурсов, предоставленных в EC2-Classic во всех регионах аккаунта. Затем можно воспользоваться указанными ниже руководствами по миграции для соответствующих ресурсов AWS:

• Инстансы и группы безопасности
• Classic Load Balancer
• Amazon Relational Database Service
• AWS Elastic Beanstalk
• Amazon Redshift для миграции кластеров DC1 и узлов других типов
• AWS Data Pipeline 
• Amazon EMR 
• AWS OpsWorks

Помимо вышеперечисленных руководств, мы предлагаем высокоавтоматизированное решение для переноса приложений (rehost) – сервис AWS Application Migration Service (AWS MGN), который упрощает и ускоряет миграцию приложений и скоращает затраты на нее. Соответствующие ресурсы об AWS MGN см. здесь:

• Начало работы с AWS Application Migration Service 
• Технический курс по запросу о AWS Application Migration Service
• Документация по подробному знакомству с функциями и возможностями сервиса AWS Application Migration Service Features
• Видео об архитектуре сервиса и сети

Для простой миграции отдельных инстансов EC2 из EC2-Classic на VPC можно использовать не только AWS MGN или Руководства по миграции инстансов, но и перечень задач AWSSupport-MigrateEC2 ClassicToVPC из раздела AWS Systems Manager (Менеджер систем AWS) > Automation (Автоматизация). Этот перечень задач автоматизирует шаги по миграции инстанса из EC2-Classic на VPC путем создания AMI инстанса в EC2-Classic, создания нового инстанса из AMI в VPC и, при необходимости, удаления инстанса EC2-Classic.

Если у вас есть какие-либо вопросы или опасения, вы можете связаться со службой поддержки AWS через Поддержку AWS-премиум.

Пожалуйста, обратите внимание. Если у вас есть ресурсы AWS, работающие на EC2-Classic в нескольких регионах, мы рекомендуем отключить EC2-Classic для каждого из этих регионов сразу после переноса всех ресурсов на VPC.

В преддверии закрытия 15 августа 2022 года мы предпримем следующие шаги.

• 30 октября 2021 года прекратим выпуск 3-летних зарезервированных инстансов (RI) и 1-летних RI для среды EC2-Classic. Уже установленные в среде EC2-Classic RI не будут затронуты. RI, срок действия которых истекает после 15 августа 2022 года, необходимо модифицировать, чтобы использовать среду Amazon VPC в течение оставшегося срока аренды. Подробную информацию о модификации RI см. в нашем документе.
• 15 августа 2022 года мы запретим создание новых инстансов (спотовых или по требованию) или других сервисов AWS в среде EC2-Classic. Любые запущенные рабочие нагрузки или сервисы постепенно потеряют доступ ко всем сервисам AWS на платформе EC2-Classic, начиная с 16 августа 2022 года, после выведения из эксплуатации.

Да.

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

Сетевые интерфейсы можно закреплять за инстансами в VPC в рамках одного и того же аккаунта.

Да, однако этот сценарий не является оптимальным примером использования нескольких интерфейсов. Вместо этого назначьте дополнительные частные IP-адреса инстансам, а затем свяжите EIP с частными IP-адресами в порядке необходимости.

Нет. Закреплять/откреплять можно дополнительные интерфейсы (eth1‑ethn), но интерфейс eth0 открепить от инстансов EC2 невозможно.

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

Да, учитывая, что владелец другого облака VPC одобрит запрос на создание пирингового подключения.

За создание пирингового подключения плата не взимается. Однако будет взиматься плата за передачу данных через пиринговое подключение. Расценки за передачу данных приведены в разделе «Передача данных» на странице цен на EC2.

Нет. Пиринговые подключения к VPC не требуют наличия интернет‑шлюза.

Нет. Трафик, проходящий между инстансами облаков VPC, взаимодействующих по пиринговому подключению, остается частным и изолированным. Таким же образом обстоит дело с трафиком, проходящим между двумя инстансами в рамках одного облака VPC.

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

Нет. Переходные пиринговые связи не поддерживаются.

AWS использует существующую инфраструктуру облака VPC для создания пирингового подключения; это не шлюз и не VPN‑подключение, оно не полагается на отдельный элемент физического оборудования. Оно не имеет слабых мест, которые могли бы привести к сбою связи, или ограничений пропускной способности.

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

Если межрегиональное пиринговое подключение все же прервется, трафик не будет перенаправляться через Интернет.

Пропускная способность между инстансами облаков VPC, взаимодействующих по пиринговому подключению, не отличается от ситуации, когда обмен данными осуществляется между двумя инстансами в рамках одного VPC. Примечание. Группа размещения может распространяться на облака VPC, взаимодействующие по пиринговому подключению, однако в подобных VPC не достигается полноценная пропускная способность между инстансами. Ознакомьтесь с дополнительной информацией о группах размещения.

Трафик шифруется с помощью современных алгоритмов аутентифицированного шифрования с присоединенными данными (AEAD). Согласование ключей и управление ключами выполняет AWS.

По умолчанию запрос публичного имени хоста инстанса в одноранговом VPC в другом регионе будет разрешен в публичный IP‑адрес. Для разрешения в частный IP-адрес при межрегиональном пиринговом подключении VPC можно также использовать частную службу DNS Route 53.

Нет. Ссылки на группы безопасности через межрегиональное пиринговое подключение VPC не работают.

Да. При межрегиональном пиринговом подключении VPC поддерживается протокол IPv6.

Нет. Межрегиональное пиринговое подключение VPC нельзя использовать вместе с EC2‑ClassicLink.

Сервис Amazon Virtual Private Cloud (VPC) ClassicLink позволяет инстансам EC2 платформы EC2‑Classic выполнять обмен данными с инстансами VPC посредством частных IP‑адресов. Чтобы использовать сервис ClassicLink, активируйте его для VPC в своем аккаунте и свяжите группу безопасности этого VPC с инстансом платформы EC2‑Classic. Все правила группы безопасности VPC будут применены к соединению между инстансами платформ EC2-Classic и VPC. 

За использование сервиса ClassicLink плата не взимается. Однако плата будет взиматься за транзитную передачу данных через различные зоны доступности. Подробнее о ценовой политике EC2 см. на соответствующей странице.

Чтобы использовать сервис ClassicLink, сначала необходимо активировать хотя бы одно VPC для ClassicLink в своем аккаунте. Затем необходимо связать группу безопасности VPC с необходимым инстансом платформы EC2‑Classic. Инстанс платформы EC2-Classic теперь будет связан с VPC и станет участником выбранной группы безопасности VPC. Инстанс платформы EC2-Classic можно одновременно связать только с одним облаком VPC.

Инстанс платформы EC2‑Classic не становится участником облака VPC. Он становится участником связанной с ним группы безопасности VPC. Все правила и ссылки группы безопасности VPC применяются к обмену данными между инстансами в инстансе платформы EC2-Classic и ресурсами сервиса VPC.

Нет. Публичное имя хоста DNS EC2 не будет преобразовано в частный IP‑адрес инстанса EC2‑VPC при опросе из инстанса платформы EC2‑Classic и наоборот.

Да. Сервис ClassicLink невозможно активировать для VPC с бесклассовой адресацией (CIDR), находящейся в диапазоне 10.0.0.0/8, за исключением 10.0.0.0/16 и 10.1.0.0/16. Кроме того, сервис ClassicLink невозможно активировать для любых VPC, таблица маршрутизации которых указывает на пространство CIDR 10.0.0.0/8 любого получателя, отличного от local.

Трафик, исходящий от инстанса платформы EC2‑Classic, можно маршрутизировать только на частные IP‑адреса в VPC. Он не будет маршрутизироваться до получателей, расположенных вне VPC, включая интернет-шлюз, виртуальный частный шлюз или VPC с пиринговым подключением.

Сервис ClassicLink не влияет на контроль доступа, определенный для инстансов платформы EC2-Classic в существующих группах безопасности платформы EC2-Classic.

Соединение ClassicLink не сохранится после остановки/запуска инстанса платформы EC2‑Classic. После остановки и последующего запуска инстанс платформы EC2‑Classic необходимо связать повторно с VPC. Однако соединение ClassicLink сохранится после циклов перезагрузки инстанса.

Сервис ClassicLink не позволяет правилам группы безопасности EC2-Classic ссылаться на группы безопасности VPS и наоборот.

С помощью AWS PrivateLink клиенты получают доступ к сервисам, размещенным на AWS, с обеспечением высокой доступности и масштабируемости, при этом весь сетевой трафик остается в пределах сети AWS. Клиенты могут применять эту технологию для обеспечения частного доступа к сервисам Amazon из своего облака Amazon Virtual Private Cloud (VPC) или локального центра обработки данных посредством PrivateLink, без необходимости использовать публичные IP‑адреса и передавать трафик через Интернет. Владельцы сервисов могут зарегистрировать свои балансировщики Network Load Balancer на сервисах PrivateLink и предоставлять эти сервисы другим клиентам AWS.

Для сервисов, работающих на основе PrivateLink, необходимо создать адреса VPC типа «интерфейс». Эти сервисные адреса будут отображаться в виде эластичных сетевых интерфейсов (ENI) с частными IP‑адресами в соответствующих облаках VPC. После создания адресов любой трафик, предназначенный для этих IP-адресов, будет перенаправлен через частное подключение в соответствующие сервисы AWS.

Вы можете подключить свой сервис к AWS PrivateLink. Для этого нужно установить Network Load Balancer (NLB), создать сервис PrivateLink и зарегистрировать его на данном NLB. Чтобы клиенты могли подключаться к вашему сервису, им нужно будет установить адреса в своих VPC, а вам – внести в белый список их аккаунты и роли IAM.

Эту возможность поддерживают следующие сервисы AWS: Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Kinesis Streams, Service Catalog, EC2 Systems Manager, Amazon SNS и AWS DataSync. Эту же возможность поддерживают многие решения SaaS. Чтобы узнать о других продуктах SaaS, подключенных к AWS PrivateLink, посетите Торговую площадку AWS.

Да. Приложение, работающее в локальной сети, может подключаться к сервисным адресам Amazon VPC через AWS Direct Connect. Сервисные адреса автоматически направляют трафик в сервисы AWS, работающие на основе AWS PrivateLink.

Да. Консоль управления AWS можно использовать для управления объектами Amazon VPC: VPC, подсетями, таблицами маршрутизации, интернет‑шлюзами и VPN‑подключениями IPSec. Кроме того, можно задействовать простой мастер создания VPC.

Сведения об ограничениях VPC приведены в Руководстве пользователя Amazon VPC.

Да. Нажмите здесь, чтобы получить дополнительные сведения о Поддержке AWS.

Расширение ElasticFox для управления облаком Amazon VPC больше официально не поддерживается. Поддержка Amazon VPC осуществляется через API AWS, инструменты командной строки и Консоль управления AWS, а также различные служебные программы сторонних разработчиков.