Как подключиться к облаку надёжно и гибко.

Привет, Хабр! Меня зовут Влад Одинцов, я техлид и product owner сетевых сервисов в K2 Cloud. Мы строим облачную платформу, где стабильное и безопасное подключение клиентов к инфраструктуре — ключевой элемент. В этой статье расскажу про шесть способов подключения к инфраструктуре клиента в К2 Облаке: от Elastic IP до Direct Connect. Каждый из способов решает разные задачи — от простого доступа по публичным адресам до построения отказоустойчивых архитектур гибридного облака. Расскажу о плюсах, ограничениях и подводных камнях. Поехали!

Virtual Private Cloud (VPC)

Начнём с рассказа о самом VPC – изолированной сетевой среде для запуска сервисов в К2 Облаке. Это распределённый облачный роутер, в котором развёрнуты сетевые сервисы: DHCP-, DNS-серверы, Metadata API и так далее. При создании каждое VPC получает собственный адрес сети. Все VPC изолированы друг от друга и не имеют сетевой связности, поэтому можно задавать почти любой адрес сети.

Обычно клиенты K2 Облака используют IP-адреса из приватных диапазонов (RFC 1918). Напрямую подключить виртуальную машину к VPC нельзя — сначала нужно создать подсети.

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

То же самое можно делать и с правилами файервола, которые применяются на «межподсетевом» уровне. Этот файерволл называется Network ACL и работает в stateless-режиме, то есть каждое правило применяется независимо от состояния сетевых соединений (в отличие от того, как работают Security Groups).

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

Подкапотное пространство

Как это всё работает? Чтобы лучше понять, что происходит при передаче трафика между VPC и как работает маршрутизация, стоит заглянуть под капот. Разберём базовое устройство сетевой части K2 Cloud с точки зрения пользователя и инфраструктуры.

Мы используем open source SDN-решение — OVN (Open Virtual Network). Это платформа, предоставляющая базовые сетевые примитивы: виртуальные маршрутизаторы, свитчи, таблицы маршрутизации, балансировщики и ACL. Именно на этих компонентах строятся VPC, Transit Gateway и остальные сетевые сервисы облака.

В рамках архитектуры OVN каждое VPC представляет собой логический маршрутизатор, к которому подключены виртуальные L2-коммутаторы — подсети. Transit Gateway реализован как ещё один логический маршрутизатор, подключающийся к логическим маршрутизаторам VPC. Маршруты, настроенные пользователем, отражаются в таблицах OVN и управляют направлением трафика между подсетями и шлюзами. Если вам интересна тема работы SDN в нашем облаке, можно посмотреть видео о том, как мы меняли SDN с NSX на OVN или прочитать мою статью на Habr по мотивам этого выступления.

Но не SDN единым. Не все сетевые функции нам даёт OVN, поэтому дополнительно мы используем:

• сетевые возможности Linux — для управления виртуальными интерфейсами, маршрутизацией и VPN.

• FRR — для динамической маршрутизации.

• Контейнеры Linux (LXC) и VRF — для изоляции сетевых сервисов.

• Собственные самописные сервисы управления — для автоматизации Control Plane и взаимодействия с пользовательским API и UI.

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

Подробно узнать о подкапотном пространстве можно на грядущей HighLoad++ 2025. Я расскажу, как мы делали наше VPC при помощи L3-фич OVN. Моя коллега Саша Рукомойникова поделится опытом, как мы первыми среди российских облаков добавляли поддержку зеркалирования трафика, и что для этого пришлось изменить в SDN-платформе.

6 способов подключения к K2 Облаку

Теперь разберём, как можно подключиться к облаку — рассмотрим шесть вариантов.

Перед тем как перейти к способам подключения, важно сделать ещё одно важное замечание. Все подключения через интернет подвержены потенциальной нестабильности, связанной с особенностями его устройства. Интернет — это совокупность сетей множества провайдеров, каждый из которых может в любой момент проводить обслуживание или испытывать локальные проблемы. В результате трафик, даже между физически близкими точками, может пройти по неожиданно длинному маршруту — через другой город или даже страну. Далее я расскажу, какие есть способы подключения к инфраструктуре в K2 Облаке и как можно минимизировать влияние таких ситуаций.

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

Теперь разберём каждый способ подключения подробнее.

Способ 1. Elastic IP

Elastic IP — это самый простой способ извне подключиться к виртуальной машине в облаке. Выделенный публичный IPv4-адрес назначается сетевому интерфейсу ВМ, а статический NAT 1:1 обеспечивает прозрачную доставку входящего и исходящего трафика на приватные адреса виртуальных машин. Такой подход позволяет публиковать сервисы в интернет, подключаться к инфраструктуре напрямую или использовать Elastic IP как резервный канал связи при отказе основного или другого способа подключения.

Адрес можно в любой момент переназначить другому интерфейсу — например, при переключении нагрузки между инстансами. Это удобно для обновлений, аварийного фейловера или ручного переключения трафика между зонами доступности. Кроме того, в К2 Облаке поддерживается собственный пул Elastic IP-адресов и возможность принести собственный публичный блок адресов для дальнейшего использования и выделения из него IP-адресов (Bring Your Own IP).

Важно учитывать, что все подключения по Elastic IP проходят через интернет, а значит — зависят от «погоды в интернете» и могут не подходить для инфраструктур с повышенными требованиями к информационной безопасности. В таких случаях стоит рассматривать другие способы подключения, которые я опишу далее.

Elastic IP удобно использовать для типовых задач — например, организации Jump-, Bastion-серверов, пользовательских VPN-решений или простой публикации сервисов в интернет.

Если речь идёт о продакшен-нагрузке, важно учитывать, что Elastic IP-адрес привязан к конкретной виртуальной машине. В случае сбоя этой ВМ доступ к сервису будет потерян, и для восстановления потребуется вручную перевести IP-адрес на другую машину. Поэтому при публикации критичных сервисов стоит дополнительно предусматривать механизмы отказоустойчивости — например, автоматическое переназначение адреса или использование балансировщиков нагрузки.

В целом, Elastic IP-адреса просты в использовании, обеспечивают гибкость при развёртывании сервисов и не требуют дополнительной настройки сетевого оборудования со стороны клиента. Управление доступом и обеспечение сетевой безопасности реализуются с помощью встроенных механизмов: можно использовать Stateless-фильтрацию через Network ACL и Stateful-фильтрацию на основе Security Groups — в зависимости от требований к контролю трафика и безопасности.

Способ 2. VPN as a Service

В K2 Облаке доступен сервис организации шифрованных соединений на основе site-to-site IPSec VPN. Это управляемый сервис, который позволяет настроить защищённый канал связи между инфраструктурой клиента и облаком. Решение реализовано с использованием стандартных возможностей Linux, open-source проекта LibreSwan и нашей «обвязки» вокруг них, а изоляция в рамках сервиса обеспечивается с использованием Linux-контейнеров.

Сервис поддерживает два режима работы:
— стандартный (один туннель),
— повышенной отказоустойчивости (два туннеля в разных дата-центрах для обеспечения избыточности).

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

Site-to-site IPSec VPN можно применять как в точечных сценариях подключения, так и в режиме VPN-хаба, при котором облако выполняет роль маршрутизатора между несколькими VPN-соединениями. Это позволяет подключать к облаку удалённые объекты — офисы, склады, филиалы, а также другие облачные платформы в случае использования мультиоблачной архитектуры. – При помощи использования протокола BGP можно удобно обмениваться маршрутной информацией между множеством удалённых точек и облаком.

Свойства нашего сервиса VPN-соединений:

• IPSec mode: Tunnel, Transport;

• non-HA, HA (2 туннеля);

• IKE v1/v2, различные шифры, алгоритмы хеширования, возможность тюнинга таймеров;

• статическая / динамическая маршрутизация.

Преимущество такого способа подключения в том, что это управляемый сервис. Нет необходимости разворачивать собственную инфраструктуру или устанавливать что-либо на виртуальных машинах. Мы обеспечили совместимость с широким спектром программных и аппаратных решений, что позволяет клиентам использовать существующее оборудование для подключения к облаку. Всё, что вам остаётся — сконфигурировать оборудование на своей стороне. Но и для этого у нас есть решение: в консоли управления облаком вы можете скачать шаблон конфигурации для Linux/FRR или Cisco-маршрутизаторов.

Динамическая маршрутизация поддерживается и интегрирована с таблицами маршрутизации VPC, что упрощает настройку. А поскольку VPN-соединения прокладываются поверх интернета, изредка из-за блокировок ТСПУ site-to-site IPSec VPN могут работать нестабильно. На эту ситуацию мы никак не влияем, но прилагаем все усилия, чтоб их возникало меньше и они разрешались быстро и безболезненно — ведём общение с провайдерами и регуляторами для согласования открытия доступа в рамках расследования инцидента.

Балансировщики нагрузки

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

Каждый балансировщик Balancer включает в себя несколько ключевых компонентов. Он определяется зоной доступности (AZ) и диапазоном IP-адресов, через которые в облако поступает трафик. Для работы создаётся DNS-имя, которое разрешается в один или несколько IP-адресов в зависимости от количества зон доступности, в которых развёрнут балансировщик. Далее в балансировщике конфигурируются Listener’ы — они определяют, на каком протоколе и порту балансировщик ожидает входящие соединения и по каким правилам направляет их дальше в Target Group.

Входящий трафик маршрутизируется в Target Group — набор целевых ресурсов, таких как виртуальные машины, слушающие указанный порт по заданному протоколу. Каждый Target — это конкретный экземпляр приложения (ВМ, протокол, порт).

В K2 Облаке предусмотрены два типа балансировщиков: внешние и внутренние. Внешние принимают трафик из интернета, а внутренние — обрабатывают трафик внутри VPC, в котором они развернуты. Внешние балансировщики, как и все интернет-сервисы, могут зависеть от качества внешних сетевых соединений, подвержены изменениям «погоды в интернете». Все балансировщики поддерживают активные проверки состояния (health checks), которые позволяют направлять трафик только на доступные и готовые к работе экземпляры приложений. Настройки проверок гибко конфигурируются: можно задать интервал, тайм-аут, а также количество успешных или неуспешных попыток, необходимых для определения состояния узла.

Каждому балансировщику назначается динамическое DNS-имя. Оно автоматически разрешается в один или несколько IP-адресов — в зависимости от количества зон доступности, в которых развернут балансировщик. Все балансировщики интегрированы с нашим сервисом DNS-хостинга (DNSaaS), что обеспечивает дополнительную устойчивость к сбоям и отказам на разных уровнях.

Способ 3. Network Load Balancers

Сетевые балансировщики — это первый тип балансировщиков нагрузки в K2 Облаке и один из способов подключения к сервисам, развёрнутым в облачной инфраструктуре. Они работают на уровне транспортного протокола и поддерживают TCP и UDP. Балансировка трафика осуществляется на основе так называемого 5-tuple hash (подсчёт хэш-суммы по пяти полям пакета): протокол, исходный и целевой IP-адрес, а также исходный и целевой порты. Этот способ хорошо зарекомендовал себя в индустрии и даёт хороший уровень распределения трафика по бекендам. При этом алгоритм гарантирует, что пакеты в рамках одного TCP или UDP потока будут попадать на один и тот же бекенд при условии, что он находится в состоянии UP. Проблема консистентного хэширования, в данном варианте балансировки решается SDN-платформой OVN при помощи интеграции Open vSwitch с connection tracking модулем.

Для оценки «состояния здоровья» целевых узлов (health checks) используется механизм «пробинга». В случае TCP балансировщика каждому бекенду отправляется TCP пакет с выставленным SYN-флагом на указанный порт и ожидается SYN+ACK в ответ. Если ответ получен — узел считается доступным. Для UDP-проверок отправляется UDP-пакет, и если в ответ не приходит ICMP-сообщение «Destination Unreachable», узел также считается доступным – в данном случае предполагается, что если мы получили «Destination Unreachable», то операционная система виртуальной машины работает, но никакое приложение не обслуживает запрашиваемый порт. На такой бекенд балансировать трафик нельзя.

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

Ключевое преимущество сетевых балансировщиков в том, что это управляемый сервис, глубоко интегрированный с инфраструктурой K2 Cloud. Вся логика балансировки реализована внутри SDN-платформы, поэтому обработка трафика начинается сразу на уровне виртуальной сети, без необходимости централизованного балансировщика. Это исключает узкие места (бутылочные горлышки) и единые точки отказа.

Способ 4. Application Load Balancers

Application Load Balancer — это самый новый тип балансировщика в K2 Cloud, доступный с конца 2024 года. Он предназначен для распределения HTTP(s)-трафика и подходит для сценариев, когда требуется анализировать содержимое HTTP-запросов и выполнять действия на основе его параметров, таких как HTTP-заголовки, например, host header или URL. В отличие от сетевых балансировщиков, ALB предоставляет расширенные возможности на уровне приложений.

Алгоритм распределения нагрузки — взвешенный round robin (weighted round robin), что позволяет задавать различный вес разным группам целевых ресурсов, давая пользователю возможность управлять долей трафика, передающегося той или иной группе. Значение веса в том числе может быть равным нулю. Это означает, что трафик этой группе не будет передаваться совсем — такое нужно, например, для плавного введения бекендов в эксплуатацию или выведения из неё.

Для проверки доступности целевых сервисов ALB также как и его L4-собрат использует активные health checks. Но уже более интеллектуальные. Балансировщик выполняет HTTP GET-запрос к целевому ресурсу и ожидает успешный ответ с кодом состояния  2xx, либо 3xx. При получении такого ответа ресурс считается «здоровым» и включается в балансировку.

Также поддерживается TLS-терминация: балансировщик может принимать HTTPS-трафик, расшифровывать его и направлять уже в открытом виде к целевым сервисам. Для этого используется TLS-сертификат, загруженный пользователем в облако.

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

Обработка трафика Application Load Balancer настраивается через правила обработчиков (listeners). Когда приходит HTTP-запрос, балансировщик сопоставляет его параметры с заданными правилами: например, если в конфигурации указано, что для определённого значения заголовка Host нужно вернуть фиксированный ответ с кодом 404, или перенаправить на HTTPS-схему, ALB выполнит это локально, без проксирования на backend. В других случаях запрос может быть перенаправлен на одну или несколько целевых групп (target groups), при этом возможно задать различные веса для распределения нагрузки.

Ещё одно преимущество ALB — это управляемость и глубокая интеграция с сетевой инфраструктурой K2 Cloud. Балансировщик работает с любым способом подключения к VPC, включая Transit Gateway, Direct Connect и VPNaaS. Это делает его гибким инструментом для построения отказоустойчивой архитектуры приложений.

Балансировщик доступен бесплатно, однако в будущем возможны изменения по мере развития сервиса. Как и все сервисы, работающие через интернет, внешний ALB зависит от качества интернет-соединения и подвержен влиянию сетевых сбоев, включая проблему так называемой «погоды в интернете».

Как и предыдущий тип балансировщика, Application Load Balancer — управляемый сервис. Он снимает с пользователей необходимость заботиться об инфраструктуре балансировки: отказоустойчивость и высокие возможности масштабирования — на стороне облачной платформы и производятся незаметно.

Способ 5. Внешние сети

Следующий способ подключения к инфраструктуре — использование внешних сетей. Этот вариант позволяет протянуть L2-домен подсети с виртуальными машинами из облака в нужное место — например, в on-premise инфраструктуру заказчика. В наших ЦОДах доступны скорости подключения 1, 10 и 25 Гбит/с.

Важно учитывать, что внешняя сеть сама по себе не является отказоустойчивой: она использует конкретное физическое оборудование, которое может периодически выводиться в плановое обслуживание, согласованное с клиентами. Для тех клиентов, кому критична высокая доступность, есть возможность организовать резервирование — например, создать две внешние сети и запросить их размещение на разном оборудовании через механизм Placement Group.

Существенное преимущество внешних сетей заключается в том, что они позволяют напрямую протянуть L2-домен от виртуальной машины в облаке до нужной точки — будь то on-premise инфраструктура или другая площадка. Этот подход востребован при миграции в облако, а также для поддержки legacy-решений, полагающихся на L2-технологии, от которых компания пока не может отказаться. Например, для миграции в облако при необходимости сохранения адресации сервисов, можно растянуть L2-сеть из on-premise, отключить локальный сервис и поднять его в облаке с тем же IP-адресом, не меняя остальную инфраструктуру. Это упрощает перенос сервисов поэтапно, без необходимости глобальной перестройки сетевой архитектуры.

Однако у сервиса есть ограничения: отказоустойчивость необходимо организовывать самостоятельно. Даже если заказаны две внешние сети, организация фейловера между ними ложится на клиента. Потребуется реализовать динамическую маршрутизацию и интегрировать её с таблицами маршрутизации, используя API. Поэтому внешние сети мы рассматриваем как решение для ограниченных сценариев — миграции, временного дублирования или поддержки специфичных legacy-систем. Интеграции с маршрутизацией «из коробки» у этого сервиса нет и мы не планируем её реализовывать. Основным способом подключения собственный инфраструктур и удалённых площадок выделенными соединениями является Direct Connect. О нём – ниже.

Способ 6. Direct Connect

В 2024 году мы запустили новый сервис для организации внешних подключений — Direct Connect. Он предназначен для создания выделенных каналов связи как к приватным сегментам в облаке (VPC), так и к публичным облачным сервисам, таким как S3 или Elastic IP. В отличие от подключений через интернет, Direct Connect обеспечивает стабильную и предсказуемую сетевую связность, невосприимчивую к «погоде в интернете» — колебаниям маршрутов и доступности у провайдеров.

С помощью Direct Connect можно, например, передавать бэкапы напрямую в S3 по выделенному каналу, минуя публичный интернет. В наших точках присутствия доступны подключения от множества провайдеров: вы можете использовать L2, L3 VPN, организовать L1-лямбда-канал или арендовать выделенное оптоволокно. Это позволяет гибко интегрировать свою локальную (on-premises) инфраструктуру с облачной и выстраивать устойчивую гибридную архитектуру.

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

В случае, если вы анонсируете один и тот же префикс по нескольким каналам, для равномерного распределения трафика применяется механизм ECMP (Equal-Cost Multi-Path). Это позволяет эффективно использовать все доступные соединения параллельно, обеспечивая высокую пропускную способность и отказоустойчивость.

Управление BGP-анонсами, как и просмотр полученных маршрутов на стороне облака, доступны через удобный API и веб-интерфейс. Эти возможности относятся к приватным подключениям и позволяют точно контролировать маршрутизацию на уровне вашей гибридной инфраструктуры.

Представим, что у вас уже есть инфраструктура в облаке и on-premise-среда. Для интеграции этих сред вы организуете прямое подключение к облаку через выбранного провайдера и одну из доступных точек присутствия. Это базовый сценарий, позволяющий наладить стабильный канал связи между двумя площадками без резервирования, в случае, если это подходит решаемой задаче: например, dev/test.

Если со временем у вас возрастут требования к доступности: провайдер может запланировать технические работы, либо профилактика потребуется на стороне облачного оборудования. Чтобы исключить влияние подобных факторов, вы организуете второе подключение через другую точку присутствия и альтернативного провайдера. Это обеспечивает избыточность и позволяет реализовать отказоустойчивую архитектуру на разных уровнях: физических локаций, инфраструктур провайдера, инфраструктуры сети клиента и К2 Облака.

Далее возникает логичный шаг: использовать уже существующие физические каналы не только для подключения к приватным сегментам VPC, но и для доступа к публичным сервисам облака — например, к S3. Такой подход снижает нагрузку на интернет-каналы on-premise-инфраструктуры, поскольку позволяет передавать, например, резервные копии напрямую по выделенному каналу.

Через те же подключения можно также обращаться к Elastic IP, балансировщикам, VPN-сервисам и другим публичным компонентам облачной платформы. Это делает Direct Connect универсальным решением как для приватного, так и для публичного взаимодействия с облачной инфраструктурой.

Как подключить Direct Connect к VPC?

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

После обработки заявки вы получите необходимое количество физических соединений (connections), которые будут организованы в указанных точках. На этих каналах вы сможете построить «Виртуальные интерфейсы»— BGP-сессии, по которым будет передаваться трафик между вашей инфраструктурой и VPC.

Далее можно будет настроить маршруты, определить, какие префиксы вы анонсируете в облако, какие префиксы получаете от облака, а также настроить фейловер и балансировку при помощи ECMP. Все эти действия доступны как через API и наш Terraform-провайдер, так и через интерфейс управления в панели облака.

Следующим шагом необходимо создать в облаке объект Direct Connect Gateway. Это отдельный тип облачного маршрутизатора, с которым ваше оборудование будет обмениваться маршрутами по протоколу BGP.

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

Третьим шагом необходимо настроить BGP-пиринги со стороны облака для каждого физического соединения.

Вы указываете параметры BGP-сессий: IP-адреса, ASN (автономные системы), которые будут использоваться на стороне облака и на стороне вашей физической инфраструктуры. После того как конфигурация на стороне облака создана, требуется произвести конфигурацию BGP на вашем оборудовании.

Если всё выполнено корректно, BGP-сессии поднимаются, и начинается обмен маршрутной информацией.

Теперь всё это необходимо подключить к VPC. У вас уже есть настроенный Direct Connect Gateway, через который установлены BGP-сессии и маршруты из on-premise прилетают в облако. Также есть Transit Gateway, который обеспечивает связность между облачными VPC. Чтобы завершить настройку подключения, достаточно соединить Direct Connect Gateway с Transit Gateway. Это делается через привязку (attachment), которая позволяет маршрутам, полученным по Direct Connect, быть доступными из VPC и наоборот.

На этом этапе Direct Connect становится полностью рабочим: маршруты из вашей on-premise инфраструктуры начинают передаваться в облако, а облачные маршруты — в вашу локальную сеть.

После этого весь трафик между вашей on-premise инфраструктурой и VPC в облаке будет проходить по выделенному каналу Direct Connect. Это обеспечивает повышенную надёжность, управляемость маршрутизации и снижение задержек.

 Инфраструктура Direct Connect на общей схеме сети:

Особенность подключения через Direct Connect — в необходимости явно задать список допустимых (allowed) префиксов — это те сетевые адреса, которые будут анонсироваться в облако по BGP. Со стороны облака, чтобы маршруты от Direct Connect стали доступны в транзитном шлюзе, достаточно включить опцию Route Propagation на уровне таблицы маршрутизации Transit Gateway. Это позволит транзитному шлюзу автоматически принимать маршруты, полученные через Direct Connect. Динамические маршруты, полученные в Transit Gateway из Direct Connect Gateway не могут автоматически распространяться в VPC, поэтому последним шагом остаётся сконфигурировать статический маршрут в VPC в сторону Direct Connect (то есть вашей «физической» инфраструктуры).

Преимущества Direct Connect:

• Глубокая интеграция с сетевой инфраструктурой облака;

• Поддержка высоко доступного соединения с фейловером  при помощи BGP;

• При использовании дублирующих соединений исходящий из облака трафик распределяется между ними;

• Возможность передачи трафика как в VPC, так и к публичным сервисам (например, S3, Elastic IP и т.д.).

Мы продолжаем активно развивать этот сервис, расширяя его функциональность и дорабатывая по запросам клиентов. Например, совсем недавно интегрировали его с сервисом облачного мониторинга, так что теперь можно отслеживать различные показатели соединений: от переданных/полученных данных до количества BGP-маршрутов и статусов сессий. Каждой метрике можно настраивать алармы.

Ограничения:

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

• Максимальная пропускная способность одного физического соединения — 25 Гбит/с. Если требуется больше, можно использовать агрегацию каналов с помощью LACP или объединение на третьем уровне средствами BGP.

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

Выводы

В экосистеме K2 Облака представлено широкое множество сетевых сервисов: от Elastic IP и VPN как сервиса — до балансировщиков нагрузки, внешних сетей и Direct Connect. Каждый из них закрывает конкретные задачи, имеет свои особенности отказоустойчивости, производительности, удобства эксплуатации и глубины интеграции в облачную инфраструктуру.

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

• если вы разворачиваете публичный сервис — Elastic IP или внешний балансировщик могут быть решением;

• для организации безопасных связей между филиалами — VPN или Direct Connect;

• для высоконагруженных сервисов с особыми требованиями к отказоустойчивости — стоит рассмотреть внутренние балансировщики, маршрутизацию через Transit Gateway.

У каждого сервиса — свои преимущества и особенности. Например, VPN-соединения зависят от состояния интернета, а Direct Connect требует оборудования с поддержкой BGP и выделенных каналов. Некоторые инструменты удобно использовать временно (например, внешние сети при миграции), другие — как основное решение в production.

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

Спасибо за внимание и до встречи в облаке!