Общие вопросы

Вопрос: Что такое AWS Direct Connect?

AWS Direct Connect – это сетевой сервис, который предоставляет альтернативный вариант подключения локальных местоположений клиентов к AWS (без использования Интернета).


Вопрос: Какие задачи можно выполнять с помощью AWS Direct Connect?

Благодаря AWS Direct Connect данные, которые раньше передавались через Интернет, теперь могут доставляться через частное сетевое подключение, установленное между AWS и ЦОД или корпоративной сетью клиента.


Вопрос: Каковы преимущества использования AWS Direct Connect и частных сетевых подключений?

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


Вопрос: Какие сервисы AWS можно использовать с AWS Direct Connect?

С AWS Direct Connect можно использовать все сервисы AWS, включая Amazon Elastic Compute Cloud (EC2), Amazon Virtual Private Cloud (VPC), Amazon Simple Storage Service (S3) и Amazon DynamoDB.


Вопрос: Можно ли использовать одно частное сетевое подключение для одновременной работы с Amazon Virtual Private Cloud (VPC) и другими сервисами AWS?

Да. Каждое подключение к AWS Direct Connect можно настроить на работу с одним или несколькими виртуальными интерфейсами. Виртуальные интерфейсы можно настроить на доступ к сервисам AWS, например Amazon EC2 и Amazon S3, с помощью пространства публичных IP‑адресов или к ресурсам облака VPC с помощью пространства частных IP‑адресов.


Вопрос: Если при работе в Amazon CloudFront источник находится в пользовательском ЦОД, можно ли использовать AWS Direct Connect для передачи объектов, хранящихся в пользовательском ЦОД?

Да. Amazon CloudFront поддерживает различные пользовательские источники, включая источники, находящиеся за пределами AWS. Доступ к периферийным местоположениям CloudFront ограничен ближайшим в географическом отношении регионом AWS. Исключение составляют регионы Северной Америки, в которых сейчас разрешен доступ к внутрисетевым источникам CloudFront из всех регионов Северной Америки. При работе с данными источника с помощью AWS Direct Connect плата за передачу данных взимается по тарифам AWS Direct Connect.

При использовании Direct Connect клиентский трафик после входа в магистральную сеть Amazon будет оставаться в ее пределах. Поэтому префиксы местоположений CloudFront, которые находятся не в магистральной сети Amazon, не будут анонсироваться через Direct Connect. Подробнее об IP‑префиксах, анонсируемых с публичных виртуальных интерфейсов AWS Direct Connect, см. по ссылке. Чтобы узнать больше о политике маршрутизации сервиса Direct Connect, можно также ознакомиться с этим материалом.


Вопрос: В каких регионах доступен сервис AWS Direct Connect?

Полный перечень местоположений Direct Connect см. на странице сведений о продукте.


Вопрос: Можно ли использовать AWS Direct Connect, если сеть клиента не присутствует в местоположении AWS Direct Connect?

Да. Партнеры по AWS Direct Connect помогут в расширении существующих ЦОД или офисных сетей клиентов для подключения к местоположению AWS Direct Connect. Подробнее см. в разделе Партнеры по AWS Direct Connect.


Вопрос: Как начать работу с AWS Direct Connect?

Используйте вкладку AWS Direct Connect в Консоли управления AWS, чтобы создать новое подключение После этого можно изменить регион на желаемый. При запросе подключения можно будет выбрать предпочтительное местоположение AWS Direct Connect, количество портов подключения и их скорость. Кроме того, если требуется помощь в расширении офисной сети или сети ЦОД до ближайшего местоположения AWS Direct Connect, можно оставить запрос, чтобы с вами связался партнер по AWS Direct Connect.


Вопрос: Можно ли заказать порт для подключения к региону AWS GovCloud (США) через Консоль управления AWS?

Чтобы заказать порт для подключения к региону AWS GovCloud (США), необходимо воспользоваться консолью управления AWS GovCloud (США). Подробнее о начале работы в регионе AWS GovCloud (США) см. по ссылке.

Оплата

Вопрос: Предусмотрена ли плата за настройку или обязательства по минимальному сроку обслуживания для использования AWS Direct Connect?

Плата за настройку не взимается. От использования сервиса можно отказаться в любой момент. На сервисы, предоставляемые партнерами по AWS Direct Connect, могут распространяться другие условия или ограничения.

Вопрос: Как оплачивается пользование сервисом AWS Direct Connect?

Стоимость AWS Direct Connect включает две отдельные статьи: время использования портов (в часах) и передачу данных. Стоимость рассчитывается для портов каждого типа на основе общего количества часов работы. Неполные часы использования порта оплачиваются как полные. Плата за время использования порта взимается с аккаунта, владеющего соответствующим портом.

Плата за передачу данных через AWS Direct Connect включается в счет за тот месяц, в котором она состоялась.  См. дополнительные вопросы и ответы ниже, чтобы понять, как будет начисляться плата за передачу данных.

Вопрос: Будет ли региональная передача данных оплачиваться по тарифам AWS Direct Connect?

Нет, передача данных между зонами доступности в рамках региона оплачивается по стандартным тарифам региона на передачу данных в том же месяце, в котором происходило использование.

Вопрос: Как оплачивается время использования портов для выделенных подключений?

Время использования портов оплачивается с момента установки подключения между маршрутизаторами AWS и клиента или по истечении 90 дней с момента заказа порта, в зависимости от того, что произойдет раньше. Плата за порт будет взиматься при каждом выделении порта AWS Direct Connect для использования. Если вы больше не хотите оплачивать порт, выполните процедуру отключения, описанную в ответе на вопрос Как отключить сервис AWS Direct Connect?

Вопрос: Как оплачивается время использования портов для размещенных подключений?

Время использования портов оплачивается с момента принятия размещенного подключения. Плата за порт будет начисляться в течение всего периода, когда размещенное подключение выделено для использования. Если вы больше не хотите оплачивать размещенное подключение, обратитесь к партнеру по AWS Direct Connect, чтобы отключить его.

Вопрос: Какова схема почасовой оплаты портов для размещенного подключения?

Платежи за почасовое использование портов для размещенного подключения в местоположении Direct Connect группируются по пропускной способности.

Например, счет для клиента с двумя отдельными размещенными соединениями со скоростью 200 Мбит/с в местоположении Direct Connect без каких-либо других размещенных соединений в этом местоположении. Платежи за почасовое использование двух отдельных размещенных соединений со скоростью 200 Мбит/с будут объединены в один элемент с меткой «HCPortUsage:200M» в конце. Если общее количество часов в месяц равно 720, то общее время использования порта для этого элемента будет равно 1440, то есть общее количество часов в месяце, умноженное на общее количество размещенных подключений 200 Мбит/с в этом местоположении.

Идентификаторы ресурса размещенного подключения, которые могут появиться в вашем счете:

HCPortUsage:50M
HCPortUsage:100M
HCPortUsage:200M
HCPortUsage:300M
HCPortUsage:400M
HCPortUsage:500M
HCPortUsage:1G
HCPortUsage:2G
HCPortUsage:5G
HCPortUsage:10G

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

Вопрос: С какого аккаунта AWS взимается плата за исходящую передачу данных, выполненную через публичный виртуальный интерфейс?

В случае использования общедоступных ресурсов AWS (например, корзин Amazon S3, инстансов EC2 Classic или трафика EC2 через интернет‑шлюз), если исходящий трафик предназначен для общедоступных префиксов, принадлежащих тому же аккаунту плательщика AWS, и активно взаимодействует с AWS через публичный виртуальный интерфейс AWS Direct Connect, использование передачи исходящих данных (DTO) для владельца ресурса учитывается в соответствии со скоростью передачи данных AWS Direct Connect.

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

Вопрос: В каком аккаунте AWS начисляется плата за передачу исходящих данных, выполняемую через транзитный / частный виртуальный интерфейс?

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

  • Частный виртуальный интерфейс (несколько интерфейсов) используется для взаимодействия с облаком (несколькими облаками) Amazon Virtual Private Cloud через шлюз (несколько шлюзов) Direct Connect или без таковых. В случае частного виртуального интерфейса плата будет начислена в аккаунте AWS, владеющем ресурсами AWS, которые инициировали передачу исходящих данных.
  • Транзитный виртуальный интерфейс (несколько интерфейсов) используется для взаимодействия со шлюзом (несколькими шлюзами) AWS Transit Gateway. В случае использования транзитного виртуального интерфейса плата начисляется в аккаунте AWS, которому принадлежит облако (несколько облаков) Amazon Virtual Private Cloud, подключенное к шлюзу AWS Transit Gateway, который, в свою очередь, связан со шлюзом Direct Connect, подключенным к транзитному виртуальному интерфейсу. Обратите внимание, что все применимые специальные сборы за использование шлюза AWS Transit Gateway (за обработку и вложение данных) будут начисляться в дополнение к плате за передачу исходящих данных AWS Direct Connect.

Вопрос: Как AWS Direct Connect использует консолидированную оплату?

Использование передачи данных AWS Direct Connect суммируется в главном аккаунте.

Вопрос: Как отключить сервис AWS Direct Connect?

Чтобы отключить сервис AWS Direct Connect, необходимо удалить порты в Консоли управления AWS. Кроме того, необходимо прекратить использование всех сервисов сторонних компаний. К примеру, нужно будет обратиться к провайдеру колокационных услуг для отключения всех кросс‑подключений от AWS Direct Connect и (или) к поставщику сетевых услуг, который обеспечивает сетевое подключение из вашего удаленного местоположения к местоположению AWS Direct Connect.

Вопрос. Указанные цены включают налоги?

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

Технические вопросы

Вопрос: Какие варианты пропускной способности подключения поддерживаются в AWS Direct Connect?

Для выделенного подключения доступны порты 1 Гбит/с и 10 Гбит/с. Для размещенных подключений доступны варианты 50 Мбит/с, 100 Мбит/с, 200 Мбит/с, 300 Мбит/с, 400 Мбит/с, 500 Мбит/с, 1 Гбит/с, 2 Гбит/с, 5 Гбит/с and 10 Гбит/с, которые можно заказать у одобренных партнеров по AWS Direct Connect. Подробнее см. в разделе Партнеры по AWS Direct Connect .

Вопрос: Существуют ли ограничения на объем данных, которые можно передать с помощью AWS Direct Connect?

Нет. Передавать можно любой объем данных, в пределах выбранных ресурсов порта.

Вопрос. Ограничено ли количество маршрутов, которые можно транслировать в AWS с помощью AWS Direct Connect?

Да. С помощью AWS Direct Connect можно транслировать не более 100 маршрутов в каждом сеансе протокола пограничного шлюза.

Вопрос. Что произойдет, если транслировать более 100 маршрутов в рамках сеанса протокола пограничного шлюза?

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

Нет. Передавать можно любой объем данных, в пределах выбранных ресурсов порта. Вопрос. Какие технические требования предъявляются к подключению?

AWS Direct Connect поддерживает подключения 1000BASE‑LX или 10GBASE‑LR по одномодовому волокну с использованием Ethernet для передачи данных. Устройство клиента должно поддерживать VLAN стандарта 802.1Q. Подробную информацию о технических требованиях см. в Руководстве пользователя AWS Direct Connect.


Вопрос: К каким регионам AWS можно подключаться с помощью данного подключения?

Используя шлюз Direct Connect, можно подключиться из своего местоположения к облакам VPC, развернутым в любых регионах AWS. Подробнее см. на странице шлюза Direct Connect.


Местоположения Direct Connect могут также обращаться к публичным ресурсам в любом регионе AWS, используя публичный виртуальный интерфейс.


Вопрос: К каким зонам доступности можно подключаться с помощью такого подключения?

Используя шлюз Direct Connect, можно подключиться из своего местоположения к облакам VPC, развернутым в любых зонах доступности любых регионов AWS. Подробнее см. на странице шлюза Direct Connect.

Вопрос: Обеспечивается ли избыточность при подключении к AWS Direct Connect?

Каждое подключение состоит из одного выделенного подключения между портами маршрутизатора клиента и маршрутизатора Amazon. Если требуется избыточность, рекомендуется установить второе подключение. При запросе нескольких портов в рамках одного местоположения AWS Direct Connect они выделяются на нескольких маршрутизаторах Amazon с обеспечением избыточности. Для обеспечения высокой доступности рекомендуется использовать подключения в разных местоположениях AWS Direct Connect. Подробнее о создании высокодоступных сетевых подключений см. на этой странице.


Вопрос: Пропадет ли связь, если произойдет сбой соединения с AWS Direct Connect?

Если установлено второе подключение к AWS Direct Connect, трафик будет автоматически перенаправлен на второе подключение. При настройке подключений рекомендуется использовать протокол Bidirectional Forwarding Detection (BFD), чтобы обеспечить быстрое обнаружение и обработку отказа.

Для обеспечения высокой доступности рекомендуется использовать подключения в разных местоположениях AWS Direct Connect. Подробнее о создании высокодоступных сетевых подключений см. на этой странице.

Если вместо этого настроено резервное VPN‑подключение IPsec, при обработке отказа весь трафик VPC автоматически пойдет через VPN‑подключение. Трафик, поступающий с публичных ресурсов (например, Amazon S3) или на таковые, будет направлен через Интернет. Если нет резервного подключения AWS Direct Connect или VPN‑подключения IPsec, трафик Amazon VPC будет утерян при возникновении сбоя. Трафик, поступающий с публичных ресурсов или на таковые, будет направлен через Интернет.

Вопрос: Можно ли расширить какую‑либо сеть VLAN в облако AWS с помощью AWS Direct Connect?

Нет, сети VLAN используются в AWS Direct Connect только для разделения трафика между виртуальными интерфейсами.


Вопрос: Предлагается ли с сервисом AWS Direct Connect соглашение об уровне обслуживания (SLA)?

Да, с AWS Direct Connect предлагается соглашение об уровне обслуживания (SLA). Подробнее см. по ссылке.


Вопрос: Какие технические требования предъявляются к виртуальным интерфейсам для использования публичных сервисов AWS, например Amazon EC2 и Amazon S3?

Данное подключение требует использования протокола пограничной маршрутизации (BGP) с номерами автономных систем (ASN) и префиксами IP‑адресов. Для подключения потребуется следующая информация.

  • Публичный или частный ASN. Если вы используете публичный ASN, вы должны быть его владельцем. Если вы используете частный ASN, он должен находиться в диапазоне от 64512 до 65535.
  • Новый неиспользованный тег VLAN по вашему выбору.
  • Публичные IP‑адреса (/30), выделенные вами для сессии BGP

По умолчанию Amazon будет транслировать префиксы публичных IP‑адресов через BGP.  Вы должны транслировать префиксы принадлежащих вам публичных IP‑адресов (/30 или меньше) через BGP. Для получения дополнительной информации ознакомьтесь с Руководством пользователя AWS Direct Connect.


Вопрос: Что такое номер автономной системы (ASN) и нужен ли он для использования AWS Direct Connect?

Номера автономных систем (ASN) используются для идентификации сетей, представляющих четко заданную политику внешней маршрутизации в Интернете. Номер ASN необходим AWS Direct Connect для создания публичного или частного виртуального интерфейса. Можно использовать принадлежащий вам публичный ASN или выбрать частный ASN в диапазоне от 64512 до 65535.


Вопрос: Какие IP‑адреса будут присвоены конечным точкам виртуального интерфейса?

При настройке виртуального интерфейса для публичного облака AWS IP‑адреса для обеих конечных точек подключения должны быть выделены из принадлежащего вам пространства публичных IP‑адресов. Если вы настраиваете виртуальный интерфейс для VPC и хотите, чтобы IP‑адреса или CIDR‑адреса для одноранговых узлов были сгенерированы AWS автоматически, пространство IP‑адресов для обеих конечных точек подключения будет выделено AWS в диапазоне 169.254.0.0/16.


Вопрос: Можно ли подключаться к Интернету с помощью данного подключения?

Нет.


Вопрос: Можно ли обмениваться трафиком между двумя портами при наличии нескольких подключенных виртуальных интерфейсов?

Нельзя, если речь идет о публичных виртуальных интерфейсах Direct Connect; однако возможен обмен трафиком между двумя портами, если они находятся в одном регионе и подключены к одному виртуальному частному шлюзу (VGW).


Вопрос: Можно ли расположить аппаратное обеспечение рядом с оборудованием, отвечающим за работу AWS Direct Connect?

Вы можете приобрести пространство на стойках объекта, где находится местоположение AWS Direct Connect, и выполнить развертывание своего оборудования в непосредственной близости. Тем не менее по соображениям безопасности клиентское оборудование не может быть размещено в стойках или отсеках, используемых для оборудования AWS Direct Connect. Для получения дополнительной информации по конкретному объекту свяжитесь с оператором этого объекта. После развертывания подключить клиентское оборудование к AWS Direct Connect можно с помощью кросс‑подключения.


Вопрос: Как активировать протокол BFD для подключения Direct Connect?

Асинхронный режим протокола BFD по умолчанию активирован для каждого виртуального интерфейса Direct Connect, но начинает действовать только после соответствующей настройки маршрутизатора. В настройках AWS минимальный интервал обнаружения протоколом BFD неисправностей составляет 300 мс, а множитель обнаружения неисправностей равен 3.


Вопрос: Как настроить Direct Connect в регионе AWS GovCloud (США)?

Подробные инструкции по настройке подключения Direct Connect в регионе AWS GovCloud (США) см. в Руководстве пользователя AWS GovCloud (США).

Вопрос: Что это за возможность?

Группа агрегирования каналов (LAG) позволяет пользователям заказывать несколько портов Direct Connect, объединенных в один более крупный логический канал, и управлять этими портами как единым подключением, а не как отдельными независимыми подключениями.

Вопрос: Какое максимальное количество каналов может быть в группе LAG?
Максимальное количество каналов в группе LAG равно четырем.

Вопрос: Как выглядит договор LOA?

Пользователь получает LOA как один документ, в котором каждому подключению посвящена отдельная страница.

Вопрос: Как организована работа групп агрегирования каналов (LAG)?

Используется стандартный для отрасли протокол управления агрегированием каналов (LACP).

Вопрос: В каком варианте в группах LAG используется протокол LACP: в статическом или в динамическом?

Мы настраиваем подключения на использование динамических пакетов LACP. Статические пакеты LACP не поддерживаются.

Вопрос: Какой в этом случае используется режим: «активный / активный» или «активный / пассивный»?

Используется режим «активный / активный». Это означает, что порты AWS будут постоянно посылать блоки данных протокола управления агрегированием каналов (LACPDU).

Вопрос: Может ли измениться наибольший размер передаваемых данных (MTU)?

Максимальный размер полезного блока данных (MTU) группы агрегирования каналов (LAG) можно изменить. Подробнее см. документацию по использованию Jumbo-кадров здесь.

Вопрос: Можно ли настроить конфигурацию своих портов на режим «активный / пассивный» вместо «активный / активный»?

На стороне пользователя можно настроить активный или пассивный режим для LAG, но на стороне AWS протокол LACP всегда находится в активном режиме.


Вопрос: Можно ли сочетать интерфейсы разных типов и иметь в одной группе LAG несколько 1‑гигабитных и несколько 10‑гигабитных портов?

Нет. В группу LAG могут входить только порты одного типа (1‑гигабитные или 10‑гигабитные).

Вопрос: Для какого типа портов доступно использование групп агрегирования?

Данная возможность доступна для 1‑гигабитных и 10‑гигабитных портов выделенного подключения.

Вопрос: Можно ли объединять в группы LAG размещенные подключения?

Нет. Объединение в группы LAG доступно только для выделенных 1‑гигабитных и 10‑гигабитных подключений. Для размещенных подключений эта возможность недоступна.

Вопрос: Можно ли создать группу LAG из существующих портов?

Да, если эти порты расположены на одном коммутационном устройстве. Обратите внимание, в ходе изменения конфигурации на группу LAG эти порты на короткое время отключатся. Работа портов будет возобновлена только после того, как на стороне клиента они также будут сконфигурированы как группа LAG.

Вопрос: Может ли группа LAG объединять порты на нескольких маршрутизаторах AWS?

В группу LAG могут входить только порты одного устройства AWS. Группы LAG из портов на разных устройствах не поддерживаются.

Вопрос: Как добавить канал к группе LAG после ее настройки?

Можно запросить еще один порт для группы LAG, но если на том же устройстве не окажется доступных портов, необходимо будет заказать новую группу LAG и выполнить миграцию подключений. Например, есть три 1‑гигабитных соединения и нужно добавить четвертое. При отсутствии доступного порта на имеющемся коммутационном устройстве потребуется заказать новую группу LAG, состоящую из четырех 1‑гигабитных портов.

Вопрос: Как будет выглядеть новый договор LOA при заказе дополнительного подключения в группе LAG?

В таких случаях клиент получает отдельный документ LOA для каждого нового канала в группе LAG.

Вопрос: Предположим, доступных портов нет и приходится заказывать новую группу LAG, но виртуальные интерфейсы уже настроены. Как перенести их?

К виртуальному частному шлюзу (VGW) можно подключить несколько виртуальных интерфейсов, при этом настраивать виртуальные интерфейсы для подключения можно даже при отсутствии подключения. В описанной ситуации рекомендуется создать новые виртуальные интерфейсы для новой группы каналов, а затем, когда все виртуальные интерфейсы созданы, переместить подключения на новую группу. Не забудьте удалить старые подключения, чтобы за них не начислялась плата.

Вопрос: Можно ли удалить один порт из группы LAG?

Да, но только в том случае, если количество портов в группе не окажется при этом меньше установленного минимального количества каналов. Например, если имеется четыре порта и минимальное количество каналов равно четырем, нельзя будет удалить порт из группы. Если минимальное количество каналов равно трем, удалить один порт из группы можно. После удаления придет оповещение об удалении с указанием конкретного порта и панели, а также напоминание о необходимости отключить кросс‑подключение и линию связи с Amazon.

Вопрос: Можно ли удалить всю группу LAG сразу?

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

Вопрос: Можно ли удалить один порт, если в группе LAG всего два порта?

Да, в группе LAG может быть один порт.

Вопрос: Можно ли заказать группу LAG, состоящую из одного порта?

Да, можно. Но имейте в виду, что мы не можем гарантировать наличие дополнительных портов на том же
устройстве, если в будущем понадобится добавить дополнительные порты.

Вопрос: Можно ли преобразовать группу LAG обратно в независимые порты?
Да. Это можно сделать вызовом API DisassociateConnectionWithLag. См. раздел API.

Вопрос: Не планируется ли создать инструмент для удобного перемещения виртуальных интерфейсов?

Операции перемещения можно выполнять с помощью вызова API AssociateVirtualInterface или в консоли сервиса.

Вопрос: Как будет отображаться группа LAG: в виде отдельного подключения или набора подключений?

Группа будет отображаться как одно подключение dxlag, под которым будет приведен список идентификаторов подключений.

Вопрос: Что такое минимальное количество каналов (Min Links) и почему при заказе группы требуется установка этого параметра?

Минимальное количество каналов – это специальная возможность протокола LACP, позволяющая установить в группе минимальное количество каналов, которые должны быть активны, чтобы группа была активной и пропускала трафик. Например, если есть четыре порта, минимальное количество каналов равно трем, но только два порта активны, то группа портов не будет активна. Если активных портов будет три или более, группа окажется активной и будет пропускать трафик, если имеется настроенный виртуальный интерфейс (VIF).

Вопрос: Что произойдет, если я не укажу минимальное количество каналов (Min Links)?

В таких случаях минимальное количество каналов (Min Links) устанавливается как 0 (значение по умолчанию).

Вопрос: Можно ли изменить минимальное количество каналов после настройки группы LAG?

Да. После того как группа настроена, минимальное количество каналов можно изменить с помощью консоли либо вызова API.

Вопрос: Если связать существующее подключение DirectConnect с группой LAG, что произойдет с существующими виртуальными интерфейсами, уже созданными для подключения DirectConnect?

Когда подключение DirectConnect с существующими виртуальными интерфейсами (VIF) связывается с группой LAG, виртуальные интерфейсы переносятся в группу LAG. Обратите внимание, что для переноса в группу LAG некоторые параметры, связанные с VIF, такие как номера VLAN, должны быть уникальными.

Вопрос: Если имеется несколько групп LAG, можно ли продолжать использовать BFD для уменьшения времени переключения на другой маршрут при отказе?

BFD по‑прежнему будет поддерживаться.

Вопрос: Можно ли установить приоритет определенного канала?

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

Вопрос: Способствует ли использование группы LAG отказоустойчивости подключения?

Нет, использование LAG не повышает отказоустойчивость подключения к AWS. Если в состав группы LAG входит несколько каналов и минимальное количество каналов равно 1, группа LAG обеспечивает защиту от отказа отдельного канала. Это не защищает от отказа отдельного устройства AWS, в результате которого происходит остановка работы группы LAG.

Для обеспечения высокой доступности подключения к AWS рекомендуется использовать подключения в нескольких местоположениях AWS Direct Connect. Подробнее о создании высокодоступных сетевых подключений см. на этой странице.

Вопрос: Можно ли подключить виртуальные интерфейсы (VIF) двух различных групп LAG к одному виртуальному частному шлюзу (VGW)?

Да. Это будет работать так же, как при создании виртуальных интерфейсов на отдельных портах.

Вопрос: Можно ли подключить интерфейс Ethernet 40 Gigabit на своей стороне к четырем портам Ethernet 10 Gigabit на стороне AWS?

Для подключения к AWS потребуется четыре интерфейса Ethernet 10 Gigabit на вашем маршрутизаторе. Подключение одного 40‑гигабитного интерфейса Ethernet к четырем 10‑гигабитным портам Ethernet LACP не поддерживается.

Вопрос: Взимается ли дополнительная плата за группу LAG?

За использование групп LAG дополнительная плата не взимается.

IPv6

Вопрос: Можно ли использовать IPv4 и IPv6 в рамках одного и того же виртуального интерфейса (VIF)?

AWS Direct Connect поддерживает для частных и публичных виртуальных интерфейсов конфигурации как с одним, так и с двумя стеками. Можно добавить пиринговую сессию IPv6 к существующему VIF с пиринговой сессией IPv4 (или наоборот). Кроме того, можно создать два независимых VIF: один для IPv4, другой для IPv6.

Вопрос: Может ли Amazon выделить для меня диапазон публичных адресов IPv6, если потребуется?

Да. Адресация для частных и публичных VIF предоставляется по умолчанию с использованием маски сети /125.

Вопрос: Какой IP‑адрес выделит Amazon частному VIF, если выбрать в консоли команду «assign an IP» (назначить IP)?

Для частных VIF с использованием IPv4 Amazon выделит диапазон CIDR /30. Для частных VIF с использованием IPv6 Amazon выделит диапазон CIDR /125.

Вопрос: Нужно ли будет по‑прежнему запускать BGP в своих VIF?

Да. Как частные, так и публичные подключения Direct Connect требуют нативных пиринговых подключений с использованием IPv4 или IPv6. Мультипротокольные расширения для BGP в настоящий момент не поддерживаются.

Вопрос: Меняются ли требования к назначению VLAN?

Нет. Функциональные требования уровня 2 остаются неизменными как для IPv4, так и для IPv6.

Вопрос: Можно ли будет продолжать использование BFD для быстрой обработки отказа BGP?

Да. Режим BFD поддерживается для пиринговых подключений BGP с использованием IPv6.

Вопрос: Изменится ли длина блоков CIDR, которые можно анонсировать в AWS?

Да, для IPv6 мы будем ограничивать длину блоков CIDR для анонсирования в AWS посредством публичных виртуальных интерфейсов Direct Connect до /64 (или менее). Для IPv4 лимит использования префиксов останется прежним.

Вопрос: Какие маршруты AWS будет анонсировать клиенту через публичный VIF?

Все публичные маршруты.

Вопрос: Будет ли поддерживаться многоадресная или произвольная рассылка через VIF, использующие IPv6?

В Direct Connect не будет поддерживаться многоадресная или произвольная рассылка.

Вопрос: Какие маршруты я получу от AWS через публичный VIF?

Публичное подключение AWS Direct Connect будет анонсировать префиксы IPv6 для всех сервисов с поддержкой IPv6.

Вопрос: Можно ли создать размещенный виртуальный интерфейс для абонента, поддерживающего IPv6?

Да, можно.

Вопрос: Повлияет ли это на политики, связанные с размещенными подключениями?

Не повлияет.

Вопрос: Продолжит ли работу CloudHub в моем шлюзе VGW? (Вопрос также относится к VPN.)

CloudHub будет работать только с идентичным трафиком. Это значит, что вы сможете отправлять трафик IPv4 только с помощью интерфейса IPv4. Преобразование IPv4 в IPv6 и наоборот не поддерживается. Преобразование IPv4 в IPv6 и наоборот не поддерживается.

 

Использование AWS Direct Connect с Amazon Virtual Private Cloud

Вопрос: Какие технические требования предъявляются к виртуальным интерфейсам для VPC?

Данное подключение требует использования протокола пограничной маршрутизации (BGP). Для подключения потребуется следующая информация.

  • Публичный или частный ASN. Если вы используете публичный ASN, вы должны быть его владельцем. Если вы используете частный ASN, он должен находиться в диапазоне от 64512 до 65535.
  • Новый неиспользованный тег VLAN по вашему выбору.
  • Идентификатор шлюза виртуальной частной сети (VGW) для VPC

AWS выделит частные IP‑адреса (/30) в диапазоне 169.x.x.x для сессии BGP и будет транслировать блок бесклассовой адресации VPC через BGP. Вы можете транслировать маршрут по умолчанию через BGP.


Вопрос: В чем отличие AWS Direct Connect от VPN‑подключения IPSec?

В случае VPN‑подключения устанавливается шифрованное сетевое подключение между интранетом клиента и Amazon VPC через Интернет с использованием протокола IPSec. VPN‑подключения настраиваются за считаные минуты и являются отличным решением, если подключение необходимо срочно, у вас низкие или умеренные требования к пропускной способности и вас не беспокоит естественная изменчивость скорости интернет‑подключения. Сервис AWS Direct Connect не использует интернет‑подключение – вместо него используются выделенные частные сетевые подключения между интранетом клиента и Amazon VPC.


Вопрос: Можно ли одновременно использовать AWS Direct Connect и VPN‑подключение к одному и тому же облаку VPC?

Да. Однако это возможно только в сценариях обработки отказов. Когда соединение установлено, подключение с помощью Direct Connect будет всегда предпочтительным, вне зависимости от добавляемого пути автономной системы.


Вопрос: Можно ли установить подключение между VPC и сетью клиента на уровне 2?

Нет, подключения на уровне 2 не поддерживаются.

Шлюз Direct Connect

Вопрос: Что такое шлюз Direct Connect?

Шлюз Direct Connect – это совокупность шлюзов виртуальной частной сети (VGW) и частных виртуальных интерфейсов (VIF).

Вопрос: Что представляет собой поддержка нескольких аккаунтов для шлюза Direct Connect?

Поддержка нескольких аккаунтов для шлюза Direct Connect позволяет связать до 10 облаков Amazon Virtual Private Cloud (Amazon VPC) или до трех шлюзов AWS Transit Gateway, принадлежащих нескольким аккаунтам AWS, с одним шлюзом Direct Connect.

Вопрос: Можно ли связать облака Amazon Virtual Private Cloud (Amazon VPC), принадлежащие какому‑либо аккаунту AWS, со шлюзом Direct Connect, принадлежащим некому другому аккаунту AWS?

Да, облака Amazon Virtual Private Cloud (Amazon VPC), принадлежащие любому аккаунту AWS, можно связать со шлюзом Direct Connect, принадлежащим любому другому аккаунту AWS.

Вопрос: Можно ли связать шлюз AWS Transit Gateway, принадлежащий какому‑либо аккаунту AWS, со шлюзом Direct Connect, принадлежащим некому другому аккаунту AWS?

Да, шлюз AWS Transit Gateway, принадлежащий любому аккаунту AWS, можно связать со шлюзом Direct Connect, принадлежащим любому другому аккаунту AWS.

Вопрос: Как использовать поддержку нескольких аккаунтов для шлюза Direct Connect?

Поддержку нескольких аккаунтов для шлюза Direct Connect можно активировать в Консоли управления AWS или с помощью API AWS Direct Connect. Для этого владельцу шлюза Direct Connect нужно выполнить действия, приведенные в руководстве пользователя AWS Direct Connect.

Вопрос: Для чего нужен шлюз Direct Connect?

Шлюз выполняет три основные функции. Во‑первых, шлюз Direct Connect позволяет взаимодействовать с облаками VPC в любом регионе AWS (кроме региона AWS Китай), что дает возможность использовать подключения AWS Direct Connect для взаимодействия с несколькими регионами AWS.

Во‑вторых, частный виртуальный интерфейс можно использовать для взаимодействия сразу с десятью облаками Virtual Private Cloud (VPC), что позволяет сократить количество BGP‑сессий между локальной сетью и развертываниями AWS.

В‑третьих, подключив транзитный виртуальный интерфейс (несколько интерфейсов) к шлюзу Direct Connect и связав шлюз Transit Gateway (несколько шлюзов) со шлюзом Direct Connect, можно совместно использовать транзитный виртуальный интерфейс (несколько интерфейсов) для взаимодействия со шлюзами Transit Gateway количеством до трех штук. Это также позволяет сократить количество BGP‑сессий между локальной сетью и развертываниями AWS.

Вопрос: Проходит ли трафик в целевой регион AWS через домашний регион AWS, связанный с используемым для передачи шлюзом Direct Connect?

Нет. При использовании шлюза Direct Connect трафик будет проходить из местоположения Direct Connect в целевой регион AWS (и обратно) по кратчайшему пути. Это не зависит от того, с каким домашним регионом AWS связано используемое местоположение Direct Connect.

Вопрос: Начисляется ли дополнительная плата при использовании шлюза Direct Connect в работе с удаленными регионами?

За использование шлюза Direct Connect плата не начисляется. При таком подключении взимаются только плата за передачу исходящих данных по тарифам удаленного региона AWS и почасовая плата за использование портов по тарифам AWS Direct Connect.

Вопрос: Требуется ли для использования всех функциональных возможностей шлюза Direct Connect, чтобы частные / транзитные виртуальные интерфейсы, шлюз Direct Connect, шлюз виртуальной частной сети или шлюзы AWS Transit Gateway принадлежали одному аккаунту?

Да, чтобы использовать все функциональные возможности шлюза Direct Connect, частные виртуальные интерфейсы и шлюз Direct Connect должны находиться в одном аккаунте AWS. Аналогичным образом, чтобы использовать все функциональные возможности шлюза Direct Connect, транзитные виртуальные интерфейсы и шлюз Direct Connect должны находиться в одном аккаунте AWS.

Шлюзы виртуальной частной сети или шлюзы AWS Transit Gateway могут находиться в аккаунтах AWS, отличных от того, которому принадлежит шлюз Direct Connect.

Вопрос: Сохраняются ли все возможности VPC, если связать шлюз VGW (связанный с Amazon VPC) со шлюзом Direct Connect?

Да. Такие сетевые возможности, как Elastic File System, Elastic Load Balancer, Application Load Balancer, группы безопасности, список контроля доступа и AWS PrivateLink, продолжат работу при использовании шлюза Direct Connect.

Шлюз Direct Connect не поддерживает функциональные возможности CloudHub, но в случае применения VPN‑подключения AWS Classic или VPN‑подключения AWS к шлюзу VGW, связанному со шлюзом Direct Connect, можно использовать такое VPN‑подключение для обработки отказов.

Возможности, которые в настоящее время не поддерживаются Direct Connect, VPN AWS Classic или VPN AWS (например, полная маршрутизация, пиринговое подключение VPC и адрес VPC), также не будут поддерживаться и шлюзом Direct Connect.

Вопрос: Я работаю с одним из партнеров AWS Direct Connect, чтобы получить частный виртуальный интерфейс для своего аккаунта. Смогу ли я использовать шлюз Direct Connect?

Да. Вы можете связать выделенный частный виртуальный интерфейс со шлюзом Direct Connect при подтверждении выделенного частного виртуального интерфейса в своем аккаунте AWS.

Вопрос: Что делать, если я просто хочу подключиться к VPC в своем локальном регионе?

Можно продолжать пользоваться существующей возможностью подключения VIF к VGW, при этом по‑прежнему будет обеспечиваться подключение к VPC внутри региона, а также будет взиматься плата за исходящий трафик по тарифам географических регионов.

Вопрос: Какие лимиты действуют при использовании шлюза Direct Connect?

Узнать об лимитах использования шлюза Direct Connect можно в разделе «Лимиты AWS Direct Connect».

Вопрос: Может ли один шлюз VGW (связанный с VPC) входить в состав нескольких шлюзов Direct Connect?

Нет. Связка VGW‑VPC не может входить в состав нескольких шлюзов Direct Connect одновременно.

Вопрос: Можно ли подключить один частный виртуальный интерфейс к нескольким шлюзам Direct Connect?

Нет. Один частный виртуальный интерфейс можно подключить только к одному шлюзу Direct Connect ИЛИ к одному шлюзу виртуальной частной сети. Мы рекомендуем следовать рекомендациям по обеспечению отказоустойчивости AWS Direct Connect и подключать несколько частных виртуальных интерфейсов.

Вопрос: Можно ли связать несколько шлюзов VGW (каждый из которых связан с VPC) с одним шлюзом Direct Connect?

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

Вопрос: Нарушает ли шлюз Direct Connect работу существующих функциональных возможностей CloudHub для клиентов?

Нет. Шлюз Direct Connect не нарушает работу существующих возможностей CloudHub для клиентов. Шлюз Direct Connect обеспечивает соединение между локальными сетями и VPC в любом регионе AWS. CloudHub позволяет обеспечить соединение с локальными сетями, используя Direct Connect или VPN в том же регионе, в котором VIF напрямую связан с VGW. Существующие функциональные возможности CloudHub будут поддерживаться без изменений.

Вопрос: Какие типы трафика поддерживаются и не поддерживаются шлюзом Direct Connect?

Сведения о поддерживаемых и не поддерживаемых типах трафика см. в Руководстве пользователя AWS Direct Connect.

Вопрос: Будет ли в дальнейшем поддерживаться использование CloudHub внутри региона?

Да. Клиенты по‑прежнему смогут подключать VIF Direct Connect напрямую к VGW для поддержки CloudHub.

Вопрос: В настоящее время у меня есть сеть VPN в регионе us‑east‑1, подключенная к VGW. Я хочу включить CloudHub в регионе us‑east‑1 для связи между существующей там сетью VPN и новым VIF. Можно ли сделать это с помощью шлюза Direct Connect?

Нет. С помощью шлюза Direct Connect это сделать нельзя, но существует возможность подключить VIF непосредственно к VGW, чтобы реализовать пример использования VPN <‑> Direct Connect CloudHub.

Вопрос: У меня настроен частный виртуальный интерфейс, связанный с VGW. Можно ли связать такой интерфейс со шлюзом Direct Connect?

Нет. Существующий частный виртуальный интерфейс, связанный с VGW, нельзя связать со шлюзом Direct Connect. Создайте новый частный виртуальный интерфейс и в процессе создания свяжите его со своим шлюзом Direct Connect.

Вопрос: Шлюз Direct Connect исключает применение функциональных возможностей CloudHub?

Нет. Созданный ранее CloudHub можно продолжать использовать.

Вопрос: Можно ли создать новый CloudHub между VPN‑подключением и виртуальным интерфейсом Direct Connect?

Да. Можно создать CloudHub между VPN и виртуальным интерфейсом Direct Connect, используя подключение к VGW вместо подключения к шлюзу Direct Connect.

Вопрос: Если у меня есть VGW, подключенный к VPN и шлюзу Direct Connect, будет ли трафик облака VPC маршрутизироваться через VPN в случае отказа канала связи Direct Connect?

Да. Это будет происходить, если в таблице маршрутизации VPC прописаны маршруты к VGW в направлении VPN.

Вопрос: Можно ли подключить к шлюзу Direct Connect шлюз VGW, не связанный с VPC?

Нет. Шлюз VGW, не связанный с VPC, нельзя подключить к шлюзу Direct Connect.

Вопрос: У меня есть шлюз Direct Connect с одним частным виртуальным интерфейсом Direct Connect и тремя неперекрывающимися шлюзами VGW (каждый из которых связан с VPC). Что произойдет, если я отсоединю один из шлюзов VGW от VPC?

Передача трафика из локальной сети к отсоединенному облаку VPC прекратится, а связь VGW со шлюзом Direct Connect будет удалена.

Вопрос: У меня есть шлюз Direct Connect с одним виртуальным интерфейсом Direct Connect и тремя неперекрывающимися парами VGW‑VPC. Что произойдет, если я отсоединю один из шлюзов VGW от шлюза Direct Connect?

Передача трафика из локальной сети к отсоединенному шлюзу VGW (связанному с VPC) прекратится.

Вопрос: Можно ли направить трафик из одного облака VPC, связанного со шлюзом Direct Connect, в другое облако VPC, связанное с тем же шлюзом Direct Connect?

Нет. Шлюз Direct Connect поддерживает только маршрутизацию трафика из виртуальных интерфейсов Direct Connect в шлюзы VGW (связанные с VPC). Чтобы передавать трафик между двумя облаками VPC, необходимо настроить пиринговое подключение между VPC по стандартной схеме.

Вопрос: У меня есть сеть VPN в регионе us‑east‑1, подключенная к VGW. Если я свяжу этот шлюз VGW со шлюзом Direct Connect, можно ли будет направить трафик из этой сети VPN в виртуальный интерфейс, подключенный к шлюзу Direct Connect в другом регионе?

Нет. Шлюз Direct Connect не будет маршрутизировать трафик между VPN и виртуальным интерфейсом Direct Connect. Чтобы такой пример использования стал возможен, необходимо создать VPN в регионе VIF и подключить VIF и VPN к одному и тому же шлюзу VGW.

Вопрос: Как отсоединить пару VGW‑VPC от шлюза Direct Connect?

Отсоединить пару VGW‑VPC от шлюза Direct Connect можно с помощью Консоли AWS или соответствующего API.

Вопрос: Предоставляется ли для шлюза Direct Connect соглашение об уровне обслуживания (SLA)?

Ознакомиться с SLA для AWS Direct Connect можно здесь.

Вопрос: Можно ли изменить размер облака Amazon VPC, которое связано со шлюзом Direct Connect?

Да, вы можете изменить размер Amazon VPC. При изменении размера облака Amazon VPC потребуется повторно отправить владельцу шлюза Direct Connect предложение с измененным размером VPC CIDR. Как только владелец шлюза Direct Connect подтвердит новое предложение, для локальной сети будет анонсирован измененный размер VPC CIDR.

Вопрос: Можно ли настроить шлюз Direct Connect для выборочного распространения префиксов в / из Amazon VPC?

Да, шлюз Direct Connect предоставляет возможность выборочного объявления префиксов для используемых локальных сетей. Владелец шлюза Direct Connect может переопределить префиксы, анонсированные для локальной сети, прежде чем принять предложение о сопоставлении ИЛИ в момент, когда можно обновить запрос на сопоставление с разрешенными префиксами. Для получения дополнительных сведений ознакомьтесь с документацией.

Если префиксы анонсируются в локальных сетях, каждое облако VPC, связанное со шлюзом Direct Connect, будет получать все префиксы, анонсированные в соответствующих локальных сетях.

Если необходимо ограничить входящий или исходящий трафик для определенного Amazon VPC, рекомендуем использовать для каждого VPC списки контроля доступа (ACL).

Вопрос: Можно ли связать несколько шлюзов AWS Transit Gateway с одним шлюзом Direct Connect?

Да, с одним шлюзом Direct Connect можно связать до трех шлюзов AWS Transit Gateway, если блоки IP‑адресов CIDR, объявленные в шлюзах AWS Transit Gateway, не перекрываются.

Шлюз Direct Connect. Поддержка собственных частных ASN

Вопрос: Что это за возможность?

Настраиваемый частный номер автономной системы (ASN). Эта возможность позволяет клиентам настраивать ASN на стороне Amazon при установлении BGP‑сессии для частных VIF на любом новом шлюзе Direct Connect.

Вопрос: Где доступны эти возможности?

Во всех коммерческих регионах AWS (кроме региона AWS Китай) и в регионе GovCloud (США).

Вопрос: Как можно настроить или назначить свой ASN для анонсирования в качестве ASN на стороне Amazon?

Настроить или назначить выбранный ASN для транслирования в качестве ASN на стороне Amazon можно в процессе создания нового шлюза Direct Connect. Шлюз Direct Connect можно создать с помощью консоли AWS Direct Connect или вызова API CreateDirectConnectGateway.

Вопрос: Можно использовать любой ASN, как публичный, так и частный?

На стороне Amazon можно назначить любой частный номер ASN. Назначить какой‑либо публичный ASN нельзя.

Вопрос: Почему нельзя назначить публичный ASN BGP‑сессии на стороне Amazon?

Amazon не занимается проверкой прав владения ASN, поэтому мы ограничиваем возможность выбора ASN на стороне Amazon частными ASN. Мы хотим защитить клиентов от подделки BGP‑подключений.

Вопрос: Какой ASN можно выбрать?

Выбрать можно любой частный ASN. Диапазон 16‑разрядных частных ASN: 64512–65534. Кроме того, можно использовать 32‑разрядные ASN в диапазоне 4200000000–4294967294.

Вопрос: Что произойдет, если я попытаюсь назначить публичный ASN BGP‑сессии на стороне Amazon?

Мы попросим вас повторно ввести частный ASN при попытке создания шлюза Direct Connect.

Вопрос: Если я не укажу ASN BGP‑сессии на стороне Amazon, какой ASN мне назначит Amazon?

Amazon предоставляет для шлюза Direct Connect ASN 64512, если другое значение не указано клиентом.

Вопрос: Где можно посмотреть ASN на стороне Amazon?

ASN на стороне Amazon можно посмотреть в консоли AWS Direct Connect, в ответе API DescribeDirectConnectGateways или с помощью API DescribeVirtualInterfaces.

Вопрос: Если у меня есть публичный ASN, будет ли он работать с частным ASN на стороне AWS?

Да. Для BGP‑сессии можно настроить использование частного ASN на стороне Amazon и публичного ASN на стороне клиента.

Вопрос: У меня есть настроенные частные VIF. При этом на существующем VIF требуется назначить другой ASN BGP‑сессии на стороне Amazon. Как внести изменение?

Необходимо создать новый шлюз Direct Connect с выбранным ASN и создать новый VIF с помощью только что созданного шлюза Direct Connect. Кроме того, потребуется соответствующим образом изменить конфигурацию устройства.

Вопрос: Я подключаю несколько частных VIF к одному шлюзу Direct Connect. Можно ли для каждого VIF использовать отдельный ASN на стороне Amazon?

Нет. Назначить или настроить отдельный ASN на стороне Amazon можно для каждого шлюза Direct Connect, но не для каждого VIF. ASN на стороне Amazon для VIF наследуется от ASN соответствующего шлюза Direct Connect на стороне Amazon.

Вопрос: Можно ли использовать разные частные ASN для шлюза Direct Connect и шлюза виртуальной частной сети?

Да. Для шлюза Direct Connect и шлюза виртуальной частной сети можно использовать разные частные ASN. Обратите внимание на то, что ASN на стороне Amazon, который вы получите, зависит от связи с частным виртуальным интерфейсом.

Вопрос: Можно ли использовать одинаковые частные ASN для шлюза Direct Connect и шлюза виртуальной частной сети?

Да. Для шлюза Direct Connect и шлюза виртуальной частной сети можно использовать одинаковые частные ASN. Обратите внимание на то, что ASN на стороне Amazon, который вы получите, зависит от связи с частным виртуальным интерфейсом.

Вопрос: Я подключаю несколько шлюзов виртуальной частной сети с собственными частными ASN к одному шлюзу Direct Connect с собственным частным ASN. Какой частный ASN будет иметь приоритет: шлюза VGW или шлюза Direct Connect?

Во время BGP‑сессий между вашей сетью и AWS в качестве ASN на стороне Amazon будет использоваться частный ASN шлюза Direct Connect.

Вопрос: Где можно выбрать свой частный ASN?

При создании шлюза Direct Connect в консоли шлюза AWS Direct Connect. После настройки шлюза Direct Connect с помощью ASN на стороне Amazon частные виртуальные интерфейсы, связанные со шлюзом Direct Connect, будут использовать настроенный вами ASN в качестве ASN на стороне Amazon.

Вопрос: Я использую CloudHub. Потребуется ли в дальнейшем менять его настройки?

Вносить какие‑либо изменения не понадобится.

Вопрос: Я хочу выбрать 32‑разрядный ASN. Какой диапазон у 32‑разрядных частных ASN?

Поддерживаются 32‑разрядные ASN с 4200000000 по 4294967294.

Вопрос: Можно ли изменить ASN на стороне Amazon после создания шлюза Direct Connect?

Нет. Изменить ASN на стороне Amazon после создания шлюза невозможно. Можно удалить шлюз Direct Connect и повторно создать новый шлюз Direct Connect с нужным частным ASN.

Использование публичных виртуальных интерфейсов

Вопрос: Какие префиксы IP-адресов будут получены через BGP при создании виртуального интерфейса для работы с сервисами AWS с использованием пространства публичных IP-адресов?

Вам будут предоставлены все префиксы IP‑адресов Amazon для региона, к которому выполняется подключение, из поддерживаемых регионов AWS, а также доступные внутрисетевые префиксы из других нерегиональных точек присутствия (PoP) AWS, таких как CloudFront. Дополнительные сведения см. по ссылке. В их число входят префиксы, необходимые для доступа к сервисам AWS, и могут входить префиксы для других дочерних сервисов Amazon, включая расположенные по адресу www.amazon.com. Текущий перечень префиксов, анонсируемых AWS, можно загрузить в виде списка диапазона IP‑адресов AWS в формате JSON. Примечание. AWS может анонсировать префикс в более определенных (или более длинных) диапазонах. Например, префикс 96.127.0.0/17 в файле может быть анонсирован как 96.127.0.0/21, 96.127.8.0/21, 96.127.32.0/19 и 96.127.64.0/18, поэтому убедитесь, что конкретные диапазоны совпадают.

Если клиенты используют AWS Direct Connect, трафик клиентов остается в глобальной магистральной сети AWS, после того как попадает в нее. Поэтому префиксы сервисов, таких как Route 53, или определенные местоположения CloudFront, которые находятся за пределами магистральной сети Amazon, не будут анонсироваться через Direct Connect.

Для только что созданного публичного VIF клиенты Direct Connect получат все публичные префиксы IP‑адресов Amazon в поддерживаемых регионах AWS и доступные внутрисетевые префиксы из других нерегиональных точек присутствия (POP) AWS, таких как CloudFront. Для всего трафика, передаваемого через подключение AWS Direct Connect, действуют стандартные тарифы на исходящую передачу данных AWS Direct Connect. Дополнительную информацию о политике маршрутизации публичных виртуальных интерфейсов можно найти на форуме сообщества AWS Direct Connect.

Примечание. В настоящий момент префиксы AWS Global Accelerator не анонсируются через публичный виртуальный интерфейс AWS Direct Connect.

Вопрос. Какие префиксы IP‑адресов необходимо анонсировать через BGP для виртуальных интерфейсов для работы с публичными сервисами AWS?

Через BGP необходимо транслировать соответствующие префиксы принадлежащих вам публичных IP‑адресов. Трафик сервисов AWS, направленный на эти префиксы, будет маршрутизироваться через подключение AWS Direct Connect.

Вопрос. Я собираюсь создать новый публичный виртуальный интерфейс. Нужно ли предпринимать какие‑либо действия, чтобы получить префиксы глобальных публичных IP‑адресов Amazon?

Нет, по умолчанию AWS Direct Connect анонсирует локальные и удаленные префиксы региона AWS при наличии таковых и включает внутрисетевые префиксы из других точек присутствия AWS (PoP), если они есть, например CloudFront и Route53. Примечание. В настоящий момент префиксы AWS Global Accelerator не анонсируются через публичный виртуальный интерфейс AWS Direct Connect.

Вопрос. Как получить префиксы IP‑адресов для AWS Global Accelerator через мой публичный виртуальный интерфейс?

В настоящее время AWS Direct Connect не анонсирует префиксы IP‑адресов для AWS Global Accelerator через публичный виртуальный интерфейс.

Вопрос. Я вижу асимметричный трафик, связанный с AWS Global Accelerator. Мой трафик, идущий в AWS Global Accelerator, проходит через Интернет, а обратный трафик, который поступает в локальную сеть, проходит через публичный виртуальный интерфейс AWS Direct Connect. Как получить симметричный трафик между локальной сетью и AWS Global Accelerator?

В настоящее время мы рекомендуем не анонсировать IP‑адреса, используемые для связи с AWS Global Accelerator через публичный виртуальный интерфейс AWS Direct Connect.

Вопрос. Меня устраивает асимметричный трафик для AWS Global Accelerator. Мой трафик, идущий в AWS Global Accelerator, проходит через Интернет, а обратный трафик, который поступает в локальную сеть, проходит через публичный виртуальный интерфейс AWS Direct Connect. Какие тарифы на передачу исходящих данных применяются к трафику AWS Global Accelerator через AWS Direct Connect?

Оплата начисляется по тарифам на передачу исходящих данных через Интернет за трафик AWS Global Accelerator, проходящий через публичный виртуальный интерфейс AWS Direct Connect.

Вопрос. Можно ли включить Jumbo MTU на публичном виртуальном интерфейсе?

Нет. Jumbo MTU не поддерживается на публичном виртуальном интерфейсе.

Вопрос. Будет ли эта новая возможность влиять на существующие публичные виртуальные интерфейсы?

Нет. Существующие публичные виртуальные интерфейсы не будут затронуты.

Вопрос: Сколько префиксов будет анонсироваться через только что созданный публичный виртуальный интерфейс?

На интерфейс будет передано примерно 2000 префиксов, в дальнейшем это количество будет расти.

Вопрос: Мне не нужны глобальные публичные IP‑префиксы. Можно ли отказаться от их получения?

Да. Отказаться можно с помощью ограничения списка сообществ. Подробнее об ограничениях списка сообществ, поддерживаемых AWS Direct Connect, см. по ссылке.

Вопрос: Я хочу перенести существующий публичный виртуальный интерфейс, чтобы получать глобальные префиксы. Как выполнить миграцию?

Есть два варианта такой миграции. Можно создать новый публичный виртуальный интерфейс, перенести трафик из существующего публичного виртуального интерфейса на только что созданный публичный виртуальный интерфейс, после чего удалить старый публичный виртуальный интерфейс. Как вариант, можно создать заявку в службе поддержки, чтобы запросить изменение настроек для существующего публичного виртуального интерфейса. При этом в процессе изменения настроек будет наблюдаться нестабильная работа BGP.

Jumbo-кадры

Вопрос: Какой максимальный размер полезного блока данных (MTU) поддерживается AWS Direct Connect?

AWS Direct Connect и Direct Connect Gateway поддерживают такие максимальные размеры полезного блока данных (MTU), как 1500 и 9001. Максимальный размер полезного блока данных можно настроить в частном виртуальном интерфейсе AWS Direct Connect.

Вопрос: Как изменить MTU частного виртуального интерфейса?

  • Если у вас есть порт AWS Direct Connect и частный виртуальный интерфейс, созданный на этом порте, вы можете изменить MTU этого интерфейса или создать новый интерфейс с MTU 9001 с помощью API, интерфейсной командной строки (CLI) или консоли.
  • Если порт AWS Direct Connect относится к другому аккаунту AWS, владелец порта должен изменить MTU в текущем виртуальном интерфейсе или создать новый интерфейс с MTU 9001, чтобы активировать Jumbo‑кадры.
  • Если подключение AWS Direct Connect обеспечивает партнер по AWS Direct Connect, нужно проверить, поддерживает ли нужный порт Jumbo‑кадры с помощью API, интерфейса командной строки (CLI) или консоли. Если порт поддерживает Jumbo‑кадры, изменить настройки MTU можно в виртуальном интерфейсе. В противном случае партнер по AWS Direct Connect должен связаться с AWS Support, чтобы активировать поддержку Jumbo‑кадров.

Вопрос: Можно ли передавать Jumbo-кадры по AWS Direct Connect по распространяемым и статическим маршрутам?

Jumbo-кадры можно использовать только по распространяемым маршрутам из Direct Connect. Если вы добавите статические маршруты, направленные на ваш шлюз виртуальной частной сети, в таблицу маршрутизации, трафик по этим маршрутам будет передаваться с MTU 1500.

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

Если есть два частных виртуальных интерфейса, которые транслируют один и тот же маршрут и используют разные MTU, будет применен MTU 1500 для обоих интерфейсов.

Вопрос: Будут ли работать Jumbo-кадры, если AWS Direct Connect и AWS Managed VPN транслируют один и тот же маршрут?

Сервис AWS Managed VPN не поддерживает Jumbo-кадры. Если один и тот же маршрут транслируется по AWS Direct Connect и AWS Managed VPN, будет использоваться MTU 1500.

Вопрос: Можно ли перенести частный виртуальный интерфейс с активированными Jumbo-кадрами c одного порта Direct Connect на другой?

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

Вопрос: Будет ли простой во время включения Jumbo-кадров в частном виртуальном интерфейсе?

Да. Если владелец порта AWS Direct Connect, на котором есть виртуальные интерфейсы без включенных Jumbo-кадров, впервые создает частный виртуальный интерфейс с активированными Jumbo-кадрами, на физическом порте будет простой от 5 до 30 секунд. Простой также коснется других виртуальных интерфейсов на этом порте, независимо от того, к какому аккаунту они относятся. Если на физическом порте есть хотя бы один виртуальный интерфейс с активированными Jumbo-кадрами, то вы сможете избежать простоя на физическом интерфейсе.

Вопрос: Как активировать Jumbo-кадры в частном виртуальном интерфейсе с группой агрегирования каналов (LAG)?

Для этого необходимо активировать Jumbo-кадры хотя бы в одном частном виртуальном интерфейсе в группе агрегирования каналов (LAG).

Приоритетные локальные сообщества для частного виртуального интерфейса

Вопрос: Что это за возможность?

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

Вопрос: Можно ли использовать эту возможность для существующих сессий EBGP?

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

Вопрос: Взимается ли дополнительная плата за эту возможность?

Данная возможность предоставляется бесплатно.

Вопрос: Будет ли данная возможность доступна как для публичных, так и для частных виртуальных интерфейсов?

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

Вопрос: Будет ли данная возможность работать со шлюзом Direct Connect?

Да, эта возможность будет работать с частными виртуальными интерфейсами, подключенными через шлюз Direct Connect.

Вопрос: Можно ли проверить, какие сообщества принимаются AWS?

Нет, в настоящее время возможности такого мониторинга не предоставляются.

Вопрос: Какие приоритетные локальные сообщества поддерживаются для частного виртуального интерфейса Direct Connect?

Для частного виртуального интерфейса поддерживаются перечисленные ниже сообщества; они оцениваются в порядке от наименьшего предпочтения к наибольшему. Сообщества являются взаимоисключающими. Если префиксы отмечены одними и теми же сообществами и имеют одинаковые атрибуты MED* и AS_PATH, они становятся кандидатами на мультитрактовую маршрутизацию.

  • 7224:7100 – низкий приоритет
  • 7224:7200 – средний приоритет
  • 7224:7300 – высокий приоритет


Вопрос: Что происходит по умолчанию, если поддерживаемые сообщества не используются?

Если не указать приоритетные локальные сообщества для частного виртуального интерфейса, локальные предпочтения по умолчанию будут выбраны на основании расстояния от локального региона до местоположения Direct Connect. В такой ситуации поведение исходящего трафика нескольких VIF из нескольких местоположений Direct Connect может быть произвольным.

Вопрос: У меня есть два частных VIF на физических подключениях в местоположении Direct Connect. Можно ли использовать поддерживаемые сообщества, чтобы влиять на поведение исходящего трафика на этих двух частных VIF?

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

Вопрос: У меня есть два подключения Direct Connect, оба 1‑гигабитные. Я хочу, чтобы весь входящий трафик в моей сети был сбалансирован между этими двумя соединениями. Можно ли использовать маршрутизацию на основе сообществ для достижения такой балансировки нагрузки по всем местоположениям?

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

Вопрос: Будет ли поддерживаться обработка отказа при использовании приоритетных локальных сообществ?

Да. Это можно настроить путем анонсирования через первичный / активный виртуальный интерфейс префиксов с сообществом более высокого локального приоритета, чем в префиксах, анонсируемых через резервный / пассивный виртуальный интерфейс. Такая возможность обратно совместима с уже существующими методами обеспечения отказоустойчивости; если в настоящее время Direct Connect настроен на обработку отказа, дополнительных изменений не требуется.

Вопрос: Я уже настроил свои маршрутизаторы с использованием AS_PATH. Нужно ли изменять конфигурацию и приостанавливать работу моей сети, чтобы использовать теги сообществ?

Нет, мы будем продолжать учитывать атрибут AS_PATH. Новая возможность является дополнительным средством управления, которое можно использовать, чтобы лучше контролировать входящий трафик от AWS. Direct Connect использует при выборе маршрута стандартный подход. Следует помнить, что локальный приоритет оценивается до атрибута AS_PATH.

Вопрос: У меня есть два подключения Direct Connect, одно 1‑гигабитное, другое 10‑гигабитное, оба анонсируют один и тот же префикс. Я хотел бы получать весь трафик для этого пункта назначения через 10‑гигабитное соединение Direct Connect, но сохранить возможность переключаться при отказе на 1‑гигабитное соединение. Могут ли приоритетные локальные сообщества использоваться для балансировки трафика в таком сценарии?

Да. Если пометить префикс, анонсируемый по 10‑гигабитному соединению Direct Connect, сообществом с более высоким локальным приоритетом, это будет предпочтительный маршрут. В случае сбоя 10‑гигабитного соединения или отмены префикса обратным маршрутом станет 1‑гигабитный интерфейс.

Вопрос: В каком объеме будет использоваться мультитрактовая маршрутизация трафика в мою сеть?

Мы будем использовать для каждого префикса мультитрактовую маршрутизацию в объеме до 16 соседних узлов, где каждый следующий узел является уникальным адресом AWS.

Вопрос: Можно ли запускать в рамках одного VPN‑тоннеля сессии BGP v4 и v6?

В настоящий момент мы поддерживаем только запуск сессий BGP v4 в рамках VPN‑тоннеля с адресом конечной точки IPv4. В будущем планируется реализовать поддержку сессий BGP v6 в рамках VPN‑тоннеля с адресом конечной точки IPv4.

Вопрос: Изменится ли настройка / конфигурация BGP для использования в системах DX?

В системах DX будет работать тот же VPN BGP.

Вопрос: Можно ли использовать адрес IPv6 в качестве конечной точки тоннеля?

В настоящий момент мы поддерживаем только адреса IPv4 для конечных точек VPN. В будущем поддержка адресов IPv6 для конечных точек VPN будет реализована.

Вопрос: Можно ли использовать адрес IPv4 в качестве конечной точки тоннеля и запускать в нем сессии BGP IPv6?

В настоящий момент мы поддерживаем только запуск сессий BGP v4 в рамках VPN‑тоннеля с адресом конечной точки IPv4. В будущем планируется реализовать поддержку сессий BGP v6 в рамках VPN‑тоннеля с адресом конечной точки IPv4.

Логическая поддержка избыточности данных

Вопрос. Что такое логическое резервирование с единым виртуальным интерфейсом?

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

Вопрос. Избавляет ли логическое резервирование от необходимости обеспечивать физическую устойчивость?

Нет, логическое резервирование не устраняет необходимости обеспечить физическую устойчивость, как мы и рекомендуем. Подробные сведения о рекомендациях по обеспечению устойчивости AWS Direct Connect см. здесь.

Вопрос. Нужно ли заказывать новое подключение AWS Direct Connect, чтобы воспользоваться этой функцией логического резервирования?

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

Вопрос. Где доступно логическое резервирование с единым виртуальным интерфейсом?

Equinix SV5 (Сан‑Хосе, Калифорния) и CoreSite SV2 (Милпитас, Калифорния) – два местоположения, где поддерживается данная возможность. Если вы приобретаете размещенные подключения, обратитесь к партнеру по AWS Direct Connect.

Вопрос: Поддерживаете ли вы типы подключений 1G и 10G и группы агрегации ссылок?

Да, можно запросить подключение 1 Гбит/с или 10 Гбит/с, а также создать группу агрегации ссылок.

Вопрос. Нужно ли платить за включение логического резервирования?

Эта функция предоставляется без дополнительной платы. Вы по-прежнему будете платить за использование портов (почасовая оплата) и исходящую передачу данных.

Вопрос. Что если я хочу воспользоваться этой функцией в своем текущем расположении?

Сегодня эта функция доступна только в Equinix SV5 (Сан-Хосе, Калифорния) и CoreSite SV2 (Милпитас, Калифорния). По мере внедрения данной функции в других регионах мы будем обновлять информацию на странице Сведения о продукте

Вопрос. Как узнать, доступно ли логическое резервирование для моего подключения 1 Гбит/с или 10 Гбит/с?

Чтобы узнать, поддерживает ли подключение логическое резервирование, можно воспользоваться либо API DescribeConnections, либо консолью AWS Direct Connect. Если оконечным устройством вашего подключения является устройство AWS, поддерживающее логическое резервирование, на консоли для параметра «Поддерживает логическое резервирование» вы увидите значение «Да». Если оконечным устройством вашего физического подключения является устройство AWS, не поддерживающее логическое резервирование, на консоли для параметра «Поддерживает логическое резервирование» вы увидите значение «Нет».

Вопрос: Эта возможность меняет количество виртуальных интерфейсов на подключение?

Нет, данная возможность не меняет количество виртуальных интерфейсов на подключение. Клиенты с выделенными подключениями 1 Гбит/с и 10 Гбит/с получают 50 VIF. Размещенные подключения, предоставляемые партнерами по AWS Direct Connect, будут иметь один виртуальный интерфейс.

Вопрос: Будет ли обеспечено резервирование BGP для частных и публичных виртуальных интерфейсов?

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

Вопрос. Обеспечивается ли резервирование BGP для пространства адресов IPv4 и IPv6?

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

Вопрос. При использовании публичного виртуального интерфейса мне потребуются публичные IPv4-адреса /29. Предоставит ли мне AWS публичные IPv4-адреса /29 бесклассовой междоменной маршрутизации (CIDR)?

Да, по запросу AWS предоставит вам публичные IPv4-адреса /29 из блока CIDR.

Вопрос. Требуется ли использовать для своих сеансов логического резервирования адрес /29 или можно использовать два адреса /31?

Для упрощения маршрутизации рекомендуется использовать адреса /29, которые являются адресами по умолчанию для единого виртуального интерфейса. Если согласно требованиям вашей сети нужно использовать несколько адресов /31, можно создать два отдельных адреса /31 для одного VIF. Для обеспечения высокой доступности конечными устройствами для однорангового соединения BGP на этих двух адресах /31 будет несколько устройств AWS.

Вопрос. Что делать, если я хочу использовать адрес IPv6 для публичного виртуального интерфейса?

Для публичного виртуального интерфейса AWS автоматически предоставит публичные адреса IPv6 CIDR.

Вопрос. Можно ли использовать логическое резервирование со шлюзом Direct Connect?

Да, логическое резервирование можно использовать со шлюзом Direct Connect. Резервные сессии BGP устанавливаются с частным номером BGP ASN шлюза Direct Connect.

Вопрос. Что если я не хочу создавать резервную сессию BGP?

Вы по-прежнему будете пользоваться сервисами AWS в рамках одной сессии BGP. Когда AWS проводит плановое или экстренное техническое обслуживание устройства AWS, на котором устанавливается ваша сессия BGP, цепь AWS Direct Connect будет разорвана.

Вопрос. Можно ли использовать разные пути AS_PATH для сессий BGP?

Да, использовать один и тот же путь AS_PATH необязательно. Если требуется создать конфигурацию «активный – активный», требуется использовать один и тот же путь AS_PATH для всех сессий BGP. Если вы создали конфигурацию «активный – пассивный», один из путей можно настроить для использования в качестве резервного.

Вопрос. Нужно ли использовать одни и те же маршруты для всех сессий BGP?

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

Вопрос. Нужно ли использовать разные номера ASN для каждой сессии BGP?

Нет, нужно использовать один и тот же номер ASN для обеих сессий BGP.

Вопрос. Я заказываю новое подключение AWS Direct Connect. Нужно ли заказать это подключение с поддержкой логического резервирования?

Нет, в расположениях, где поддерживается AWS Direct Connect, ваше новое подключение будет автоматически размещаться на устройствах AWS, поддерживающих логическое резервирование. Если вы запрашиваете добавление подключения или подключений в существующую группу LAG, дополнительное подключение будет размещено на том же устройстве AWS, что и существующая группа LAG. Если существующая группа LAG не размещена на устройстве AWS, которое поддерживает логическое резервирование, поддержка логического резервирования реализована не будет.

Вопрос. У меня есть подключения в Equinix SV5 (Сан-Хосе). Как перенести их для реализации поддержки логического резервирования?

Рекомендуется запросить новые соединения в Equinix SV5 (Сан-Хосе). Как только подключения станут доступны, вы сможете использовать избыточность логических данных.

 

Поддержка AWS Transit Gateway

Вопрос: В каких регионах AWS сервис AWS Direct Connect предлагает поддержку AWS Transit Gateway?

В настоящее время поддержка AWS Transit Gateway в AWS Direct Connect доступна в регионах AWS GovCloud (Восток США), AWS GovCloud (Запад США), Канада (Центр), Восток США (Сев. Вирджиния), Восток США (Огайо), Запад США (Сев. Калифорния), Запад США (Орегон), ЕС (Ирландия), ЕС (Лондон), ЕС (Франкфурт), Азия и Тихий океан (Мумбаи), Азия и Тихий океан (Сеул), Азия и Тихий океан (Сидней), Азия и Тихий океан (Сингапур), Азия и Тихий океан (Токио), ЕС (Париж) и Южная Америка (Сан‑Паулу).

Вопрос: Что такое транзитный виртуальный интерфейс?

Транзитный виртуальный интерфейс – это тип виртуального интерфейса, который можно создать для любого соединения AWS Direct Connect со скоростью 1, 2, 5 или 10 Гбит/с. Транзитный виртуальный интерфейс можно подключить только к шлюзу Direct Connect. Можно использовать шлюз AWS Direct Connect с подключением одного или нескольких транзитных виртуальных интерфейсов для взаимодействия с тремя шлюзами AWS Transit Gateway в любых поддерживаемых регионах AWS.

Как и в случае с частным виртуальным интерфейсом, можно установить один сеанс IPv4 BGP и один сеанс IPv6 BGP в одном транзитном виртуальном интерфейсе, а при наличии соединения 1 Гбит/с или 10 Гбит/с и поддержке избыточности логических данных можно создать соединение в избыточном слое 3 с помощью транзитного виртуального интерфейса.

Вопрос. Как создать транзитный виртуальный интерфейс?

Для создания транзитного виртуального интерфейса можно воспользоваться Консолью управления AWS или API.

Вопрос. Можно ли выделить транзитный виртуальный интерфейс в другом аккаунте AWS?

Да, выделить транзитный виртуальный интерфейс можно в любом аккаунте AWS.

Вопрос. Можно ли подключить транзитный виртуальный интерфейс к шлюзу виртуальной частной сети?

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

Вопрос. Можно ли подключить частный виртуальный интерфейс к шлюзу AWS Transit Gateway?

Нет, подключить частный виртуальный интерфейс к шлюзу AWS Transit Gateway невозможно.

Вопрос. Кто оплачивает передачу исходящих данных через транзитный виртуальный интерфейс?

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

Вопрос. Какие ограничения предусмотрены для транзитного виртуального интерфейса?

Дополнительную информацию об ограничениях, предусмотренных для использования транзитного виртуального интерфейса, см. на странице, посвященной ограничениям для AWS Direct Connect.

Вопрос. Можно ли добавить дополнительные транзитные виртуальные интерфейсы для соединения?

Нет, можно создать только один транзитный виртуальный интерфейс для любого соединения AWS Direct Connect со скоростью 1, 2, 5 или 10 Гбит/с.

Вопрос. Существующий шлюз Direct Connect подключен к частному виртуальному интерфейсу. Можно ли подключить транзитный виртуальный интерфейс к этому шлюзу Direct Connect?

Нет, к шлюзу Direct Connect можно подключать только один тип виртуальных интерфейсов.

Вопрос. Можно ли подключить шлюз AWS Transit Gateway к шлюзу Direct Connect, подключенному к частному виртуальному интерфейсу?

Нет, шлюз AWS Transit Gateway можно подключить только к шлюзу Direct Connect, подключенному к транзитному виртуальному интерфейсу.

Вопрос. Сколько времени занимает установка подключения между шлюзом AWS Transit Gateway и AWS Direct Connect?

Установка подключения между шлюзом AWS Transit Gateway и AWS Direct Connect может занимать до 40 минут.

Вопрос. Сколько всего виртуальных интерфейсов можно создать для одного выделенного соединения 1 Гбит/с или 10 Гбит/с?

Для одного выделенного соединения 1 Гбит/с или 10 Гбит/с можно создать максимум 51 виртуальный интерфейс, в том числе один транзитный виртуальный интерфейс.

Вопрос. Транзитный виртуальный интерфейс поддерживает Jumbo-кадры?

Да, транзитный виртуальный интерфейс поддерживает Jumbo-кадры. Размер максимального передаваемого блока данных (MTU) будет ограничен до 8500.

Вопрос. Я работаю с группой LAG 4 x 10 Гбит/с. Сколько транзитных виртуальных интерфейсов можно создать в этой группе агрегирования каналов (LAG)?

Можно создать один транзитный виртуальный интерфейс в группе LAG 4 x 10 Гбит/с.

Вопрос. Вы поддерживаете все атрибуты Border Gateway Protocol (BGP), поддерживаемые в частном виртуальном интерфейсе, для транзитного виртуального интерфейса?

Да, можно по-прежнему использовать поддерживаемые атрибуты BGP (AS_PATH, Local Pref, NO_EXPORT) в транзитном виртуальном интерфейсе.

Вопрос. Можно ли создать транзитный виртуальный интерфейс для размещенного соединения 1, 2, 5 или 10 Гбит/с?

Да, можно создать транзитный виртуальный интерфейс для размещенного соединения 1, 2, 5 или 10 Гбит/с.

Вопрос. Я хочу подключить шлюз Transit Gateway к шлюзу Direct Connect. Можно ли использовать один и тот же Autonomous System Number (ASN) для шлюза Direct Connect и Transit Gateway?

Нет, использовать один и тот же ASN для шлюза Transit Gateway и Direct Connect невозможно.

Виртуальная частная сеть (VPN)

Вопрос: Можно ли запускать в рамках одного VPN‑тоннеля сессии BGP v4 и v6?

В настоящий момент мы поддерживаем только запуск сессий BGP v4 в рамках VPN‑тоннеля с адресом конечной точки IPv4. В будущем планируется реализовать поддержку сессий BGP v6 в рамках VPN‑тоннеля с адресом конечной точки IPv4.

Вопрос: Изменится ли настройка / конфигурация BGP для использования в системах DX?

В системах DX будет работать тот же VPN BGP.

Вопрос: Можно ли использовать адрес IPv6 в качестве конечной точки тоннеля?

В настоящий момент мы поддерживаем только адреса IPv4 для конечных точек VPN. В будущем поддержка адресов IPv6 для конечных точек VPN будет реализована.

Вопрос: Можно ли использовать адрес IPv4 в качестве конечной точки тоннеля и запускать в нем сессии BGP IPv6?

В настоящий момент мы поддерживаем только запуск сессий BGP v4 в рамках VPN‑тоннеля с адресом конечной точки IPv4. В будущем планируется реализовать поддержку сессий BGP v6 в рамках VPN‑тоннеля с адресом конечной точки IPv4.

Подробнее о ценах на AWS Direct Connect

Перейти на страницу цен
Готовы приступить к разработке?
Начать работу с AWS Direct Connect
Есть вопросы?
Свяжитесь с нами