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).

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

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

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

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

Можно использовать любой диапазон адресов 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.

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

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

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

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

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

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

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

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

Добавлять свои собственные 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.

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

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

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

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

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

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

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

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

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

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

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

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

При использовании инстансов с 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.

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

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

Да. Однако мы можем активировать 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 включена функция EC2-Classic. Вы можете проверить, включена ли функция EC2-Classic для региона AWS с помощью консоли или команды describe-account-attributes. Подробную информацию см. в этом документе.

Если у вас нет активных ресурсов AWS с функцией EC2-Classic в любом из регионов, отключите EC2-Classic в аккаунте для этого региона. Отключение EC2-Classic позволит по умолчанию запустить VPC в регионе. Для этого перейдите в Центр поддержки AWS на странице console.aws.amazon.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 в рамках одного и того же аккаунта.

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

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

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

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

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

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

Для сервисов, работающих на основе 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.

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

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

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