Разбираем, как устройства Fortinet с ASIC снижают стоимость обработки трафика и почему подписочные сервисы делают покупку долгосрочно выгодной.
Рынок сетевой безопасности давно устроен так: устройство — это не «разовая покупка коробки», а аппаратная платформа, на которую затем наслаиваются сервисы, обновления и поддержка. У Fortinet этот подход особенно заметен: NGFW часто выбирают как производительную базу, а реальную ценность (и предсказуемость защиты) получают через подписки FortiGuard и регулярные обновления.
На этапе закупки нередко сравнивают цены устройств и цифры в даташитах. Но в эксплуатации важнее другое: как стабильно платформа переваривает реальный трафик (включая инспекцию и шифрование) и насколько своевременно она получает новые сигнатуры, категории веб‑фильтра, репутационные данные и защиты от свежих техник атак.
Платформа даёт базовую «пропускную способность бизнеса», а сервисы — актуальность и управляемость рисков. Поэтому в расчётах рядом стоят CAPEX (покупка устройства) и OPEX (подписки, поддержка, операционные затраты).
ASIC ценен не просто «скоростью ради скорости». В сетевой безопасности нагрузка неритмичная и многослойная: политики, сессии, NAT, IPS, контроль приложений, SSL/TLS‑инспекция. Когда часть этих операций эффективно выполняется аппаратно, выигрывают сразу несколько параметров:
Ниже разложим экономику «железа» (стоимость, энергия, стойка), обсудим, какие функции выгоднее ускорять аппаратно и где у ускорения есть ограничения. Отдельно — почему в ИБ решают подписки и обновления и как считать TCO для связки «ASIC‑платформа + сервисы».
Материал ориентирован на инженеров ИБ и сетевой инфраструктуры, архитекторов, а также на закупки и финансовых менеджеров, которым нужно сравнивать варианты по CAPEX/OPEX и рискам, а не только по пиковым цифрам в спецификациях.
ASIC (Application-Specific Integrated Circuit) — специализированный чип, «заточенный» под ограниченный набор операций. В сетевой безопасности такими операциями часто становятся обработка пакетов, поиск совпадений по сигнатурам/шаблонам, работа с таблицами сессий, шифрование/расшифрование и служебные функции, которые нужно выполнять быстро и стабильно при любой нагрузке.
CPU (центральный процессор) — наоборот, универсален. Он хорош там, где логика чаще меняется: новые функции, сложные ветвления, разные сценарии обработки данных. Поэтому в NGFW часть задач остаётся на CPU — например, сложная логика политик, оркестрация, управление и интеграции.
Представьте трассу с разными типами движения:
У вендоров, включая Fortinet, специализированные ASIC обычно берут на себя «тяжёлую» рутину обработки трафика, чтобы разгрузить CPU и удерживать стабильную производительность.
ASIC даёт прирост не только в «Гбит/с», но и в практичных показателях:
Ускорение имеет смысл только при корректных тестах. Сравнивайте устройства в одинаковых условиях: включены ли SSL/TLS‑инспекция, IPS, контроль приложений, одинаковые профили угроз и реалистичные размеры пакетов. Иначе легко получить «рекордные» цифры на упрощённом профиле, которые не повторятся в вашей сети.
Покупка NGFW часто выглядит как разовая статья CAPEX, но в реальности «железо» быстро превращается в набор измеримых параметров: сколько трафика вы получаете за рубль, сколько ватт уходит на каждый Гбит/с и сколько пространства/портов занимают эти Гбит/с в стойке или шкафу. ASIC‑подход Fortinet делает эти метрики более предсказуемыми — и именно поэтому их удобно считать.
Практичный ориентир — условная стоимость за Гбит/с в нужном режиме работы. Важно сразу договориться, что сравниваем: «голый» межсетевой экран, NGFW с IPS/AV, или SSL/TLS‑инспекцию (она обычно самая дорогая по ресурсам).
Если у двух моделей близкая цена, но одна держит заметно больше реальной NGFW‑пропускной способности с включёнными проверками, она часто выигрывает по TCO: ниже риск преждевременного апгрейда при росте каналов, числе филиалов или ужесточении политик.
Электричество и охлаждение — это OPEX, и он становится ощутимым даже в небольшом офисе (ограничения по ИБП, шуму, теплу) и тем более в ЦОД (лимиты по мощности на стойку).
Сравнивайте не только «максимальные ватты», а ватт на Гбит/с в целевом профиле (например, NGFW + IPS + частичная TLS‑инспекция). Аппаратное ускорение даёт шанс получить больше полезной безопасности в тех же энергетических рамках.
Иногда решает не скорость, а физика: 1U против 2U, наличие нужных 10/25/40/100G портов, достаточное число SFP/SFP+ слотов, возможность агрегации. Чем выше плотность портов и производительности, тем меньше коммутаторов «вокруг», короче трассы, проще резервирование и дешевле расширение.
Аппаратная база влияет на срок эксплуатации больше, чем кажется. Если устройство работает близко к пределу уже на старте, любое увеличение трафика, рост доли шифрованного трафика или включение дополнительных функций ускорит замену.
Хорошее правило: закладывайте запас под рост и плановые изменения (новые филиалы, больше TLS‑инспекции, расширение удалённого доступа). Тогда платформа служит дольше, а сервисы и обновления раскрывают её потенциал без вынужденного апгрейда через 1–2 года.
Аппаратное ускорение в NGFW имеет смысл там, где много однотипных операций повторяются для каждого пакета или сессии. Чем выше скорость каналов и чем больше параллельных соединений, тем заметнее разница между универсальным CPU и специализированным ASIC.
Первый кандидат — «базовая» работа с трафиком: классификация потоков, NAT, VLAN, маршрутизация, stateful inspection и управление таблицами сессий. Это постоянный фон, который присутствует всегда — даже если вы не включили продвинутые проверки.
Когда эти задачи вынесены в ASIC, устройство лучше держит высокий PPS (packets per second) и большое число одновременных сессий без скачков задержек. На практике это важно для филиалов с большим количеством пользователей, Wi‑Fi, VoIP и приложений, чувствительных к джиттеру.
IPS/IDS и глубокая инспекция содержимого (DPI) — второй по выгоде класс функций. Здесь «железо» особенно помогает, когда нужно проверять много трафика по сигнатурам и шаблонам и делать это на скорости линии.
Нюанс: ускорение даёт максимум при типовых сценариях инспекции (потоковая проверка, известные сигнатуры, стандартные протоколы). Если включать сложные комбинации политик, нестандартные декодеры или редкие режимы, часть нагрузки может вернуться на CPU — и тогда реальная производительность будет ближе к «threat/IPS throughput», а не к рекламному «firewall throughput».
IPsec‑VPN и особенно SSL/TLS — зона, где всё упирается в криптографию: рукопожатия, обмен ключами, симметричное шифрование, проверка сертификатов. При росте числа удалённых пользователей и приложений на HTTPS именно SSL/TLS‑инспекция часто становится «узким горлом».
Если криптооперации ускоряются аппаратно, проще удерживать требуемую пропускную способность и задержки без раздувания парка устройств. Но смотреть нужно не только на «VPN throughput», а на показатели под нагрузкой с включённой инспекцией и реальными наборами шифров.
Даже при сильном ASIC‑ускорении в программной части остаётся всё, что связано со «смыслом» безопасности: логика политик и приоритетов, обработка исключений, оркестрация, интеграции (SIEM/SOAR), журналы и аналитика, а также обновления сигнатур и категорий через подписки (например, FortiGuard). Поэтому «железо» даёт эффективность на трафике, а актуальность защиты во времени поддерживает именно программная и сервисная составляющая.
Аппаратное ускорение (ASIC) даёт высокую и предсказуемую производительность, но у него есть обратная сторона: часть логики «зашита» в кремний. Это влияет на гибкость функций, темп внедрения новинок и то, как корректно сравнивать модели между собой.
Когда критический путь обработки трафика оптимизирован под ASIC, проще всего ускорять стабильные, хорошо формализуемые операции: пересылку пакетов, шифрование, базовые проверки. Но если появляется новая техника атак или нестандартная телеметрия, которую нужно учитывать «на лету», её зачастую быстрее реализовать в программном тракте.
Практический вывод: часть возможностей может быть доступна, но работать медленнее (через CPU) — и итоговая производительность окажется ниже «паспортной».
ASIC не отменяет необходимости в постоянных обновлениях: сигнатуры, модели обнаружения, категории URL, правила IPS и эвристики приходят через сервисы (например, FortiGuard). Новые классы угроз часто требуют изменений именно в софте: в движках инспекции, разборщиках протоколов, логике корреляции.
Если вы покупаете устройство без актуальных подписок и обновлений, аппаратная мощность не превращается автоматически в актуальную защиту — она лишь ускоряет то, что умеет текущая версия ПО.
Чем сильнее вы завязаны на конкретные аппаратные функции, тем важнее экосистема: форматы конфигураций, совместимость версий, доступность аналогов по производительности и лицензированию. При миграции между поколениями или моделями могут всплывать различия в:
Ключевая ловушка — измерять производительность без тех функций, которые реально включены в вашей политике. Инспекция SSL/TLS, IPS и веб‑фильтрация могут перевести трафик в более «тяжёлый» режим обработки.
Перед выбором модели фиксируйте тестовый профиль: долю TLS, размер пакетов, количество одновременных сессий, включённые профили безопасности. И сравнивайте одинаковые режимы: «NGFW с SSL‑инспекцией» против «NGFW с SSL‑инспекцией», а не против bare routing.
«Железо» (даже с ASIC) даёт предсказуемую производительность, но само по себе не делает защиту актуальной. Угрозы меняются ежедневно: появляются новые домены для фишинга, вредоносные семейства, уязвимости в популярных продуктах и приёмы обхода фильтров. Поэтому в практической безопасности выигрывает тот, кто быстрее получает и применяет знания о новых атаках.
Большая часть эффективности NGFW держится на данных, которые нужно постоянно обновлять:
У Fortinet это обычно поставляется через сервисы семейства FortiGuard: устройство получает обновления и применяет их на потоке, а вы получаете более стабильный уровень защиты без ежедневной «ручной охоты» за угрозами.
Подписочные сервисы покупают не только «ради базы». Они уменьшают трудозатраты: меньше исключений, меньше разовых интеграций, меньше разбирательств после инцидента. Типовой набор ценности выглядит так:
Во многих требованиях (внутренние политики, аудиты, отраслевые стандарты) подразумевается, что средства защиты поддерживаются и обновляются. Активная подписка упрощает доказательство «должной осмотрительности»: вы можете показать, что используете актуальные базы, получаете патчи и реагируете в рамках согласованного уровня сервиса. Это напрямую снижает вероятность успешной атаки и стоимость последствий, даже если аппаратная платформа остаётся той же.
Покупка NGFW на базе ASIC обычно состоит из трёх частей: устройство, подписки на сервисы безопасности и поддержка. Если «железо» — это точка исполнения политик (фильтрация, VPN, инспекция трафика), то сервисы — это «мозг», который делает защиту актуальной: сигнатуры, репутации, категории URL, антибот/антивирус, обновления для IPS и другие данные FortiGuard.
Подписка превращает разовую покупку (CAPEX) в управляемую статью OPEX: вы платите не только за функции, но и за их свежесть. Это особенно заметно в сценариях, где важны производительность шифрования и точность детектирования: без регулярных обновлений даже мощная платформа окупается хуже из‑за роста риска пропуска угроз и увеличения ручной работы.
Также со временем появляются новые методы атак и требования комплаенса, и именно сервисы/обновления добавляют или улучшают функции без замены платформы.
Ключевые параметры в коммерческом предложении — уровни сервисов, срок (1/3/5 лет), правила продления и состав пакета. Разные «бандлы» могут включать похожие названия, но отличаться по наполнению. Важно сопоставить пакет с реальными задачами: удалённые пользователи, филиалы, ЦОД, требования к NGFW и объёмы SSL/TLS.
Заранее разделите «критично» и «опционально».
Практика: фиксируйте календарь продлений, владельца процесса и минимальный набор подписок на 12–36 месяцев вперёд — это упрощает планирование TCO и предотвращает паузы в защите.
TCO (совокупную стоимость владения) для NGFW на ASIC имеет смысл считать не как «сколько стоит коробка», а как «сколько стоит защищённый гигабит в бизнес‑нагрузке» за 3–5 лет. Тогда становится видно, где экономия от аппаратного ускорения (энергия, плотность, запас по шифрованию), а где — от правильного набора подписок и поддержки.
Отдельный практический момент: чтобы не вести расчёты и согласования в разрозненных таблицах, многие команды делают внутренние калькуляторы TCO, чек‑листы пилота и шаблоны КП. Такой инструмент можно быстро собрать на TakProsto.AI: в формате простого веб‑приложения с формами (CAPEX/OPEX, профили нагрузки, сценарии роста), выгрузкой отчётов и хранением версий. Платформа работает на инфраструктуре в России и позволяет экспортировать исходники — удобно, если нужно встроить калькулятор в корпоративный контур.
CAPEX: покупка устройств, запас мощности «на рост», лицензии/опции на порты, резервирование (N+1 или Active‑Passive), первичная инсталляция.
OPEX: подписки на сервисы безопасности (например, FortiGuard), продление поддержки, обновления, трудозатраты команды (эксплуатация, реакции на инциденты), электроэнергия и место в стойке (для ЦОД).
Скрытые статьи часто дают больший разброс, чем разница в прайсе:
Сделайте 2–3 сценария нагрузки: «сейчас», «рост +30%», «пик (сканирование + массовый VPN)». Для каждого возьмите ключевые метрики из спецификаций: производительность с включёнными проверками, SSL/TLS, количество сессий, VPN‑пользователи.
Далее сведите в одну таблицу:
Финальная метрика: TCO / средняя полезная пропускная способность (Гбит/с) и отдельно TCO / защищённый удалённый пользователь. Это помогает честно сравнить модели и понять, где переплата за «запас» оправдана, а где достаточно более компактной платформы с правильными подписками.
Выигрыш от ASIC лучше всего виден не в «синтетических гигабитах», а в конкретных сценариях: где важны задержка, плотность портов, SSL/TLS‑инспекция и стоимость владения.
В филиале часто нет выделенной команды ИБ, а требования при этом растут: IPS, веб‑фильтрация, контроль приложений, иногда — инспекция SSL/TLS. Именно здесь метрика «стоимость за Гбит/с» и энергопотребление становятся заметными строками TCO.
Аппаратное ускорение помогает держать приемлемую производительность при включённых политиках безопасности, не раздувая бюджет на более старшую модель «на всякий случай». Плюс филиалу важна предсказуемость: меньше сюрпризов от пиковой нагрузки (например, обновления ОС или видеоконференции), проще планировать каналы и рост.
В ЦОД требования другие: восток‑запад трафик, микросегментация, много правил, высокая плотность соединений и чувствительность к задержкам. Здесь «просто гигабиты» не показатель — важнее, как устройство ведёт себя при реальных политиках и при росте количества сессий.
ASIC‑ускорение особенно полезно, когда нужно одновременно держать высокую пропускную способность, много параллельных соединений и строгие функции (IPS, контроль приложений). Если планируется активная SSL/TLS‑инспекция, заранее проверьте спецификации именно для этого режима: у разных моделей разница может быть кратной.
Для удалённого доступа ключевой вопрос — сколько «съедает» безопасность: шифрование, проверка, применение политик доступа. В VPN‑сценариях важно смотреть не только на общую производительность, но и на показатели шифрования и числа одновременных пользователей.
Если вы строите Zero Trust‑подходы, роль подписок (например, FortiGuard) возрастает: качество сигнатур, категорий и обновлений напрямую влияет на реальную защиту, а не на паспортные цифры.
Одна крупная платформа проще в управлении, но может стать «точкой роста» по CAPEX и риску единой аварии. Несколько устройств дают масштабирование по мере необходимости и часто лучше ложатся на географию (филиалы/площадки), но требуют аккуратной унификации политик.
Практическое правило: если узкое место — SSL/TLS‑инспекция или количество сессий, выбирайте архитектуру по этим метрикам, а не по «максимальным Гбит/с» в даташите.
Спецификации NGFW часто выглядят как витрина: большие цифры по «пропускной способности» и «сессиям». Ошибка возникает, когда эти показатели сравнивают напрямую, не уточняя режимы работы. Для устройств с ASIC это особенно важно: ускорение проявляется по‑разному в зависимости от включённых функций.
В таблицах обычно есть несколько строк: firewall throughput (L3/L4), IPS, NGFW (с App Control), Threat Protection и отдельно SSL/TLS inspection. Эти значения нельзя складывать и нельзя считать взаимозаменяемыми.
Практическое правило: ориентируйтесь на самый «тяжёлый» профиль, который реально будет включён постоянно (часто Threat Protection + веб‑фильтрация, иногда ещё и инспекция TLS). Если в пилоте вы планируете включить больше проверок, чем в проде, фиксируйте это явно — иначе модель выберут «впритык».
Пиковая пропускная способность важна, но для реальных сервисов часто критичнее задержка (latency) и количество одновременных сессий.
Если у вас много коротких соединений (SaaS, веб‑приложения, VDI, частые API‑запросы), вы упрётесь не только в Гбит/с, но и в:
Низкая задержка и высокий темп установления сессий уменьшают «подвисания» при пиковых нагрузках, особенно в филиалах с ограниченным каналом.
Показатель SSL/TLS inspection throughput — отдельная история. Сравнивайте именно его, если собираетесь расшифровывать трафик для IPS/антивируса/контроля приложений.
На пилоте уточните:
Чем больше событий вы пишете (DNS, URL, приложения, IPS‑срабатывания), тем выше нагрузка на устройство и систему хранения логов. В спецификациях это отражено косвенно, поэтому проверьте на практике: включите нужную детализацию и измерьте, как меняются CPU/память, скорость обработки и объём логов в сутки.
Итог: выбирайте модель не по одной «красивой» цифре, а по профилю функций, который будет включён постоянно, и подтверждайте его измерениями на пилоте.
Внедрение NGFW с ASIC‑ускорением имеет смысл планировать как проект на 2–3 года вперёд: от пилота до продления подписок. Ниже — шаблон, который помогает избежать сюрпризов в производительности и бюджете.
Начните с короткого пилота (1–2 недели), но прогоните «обязательные» режимы, а не только голый фаервол.
Проверьте:
Критерии успеха фиксируйте цифрами: «не ниже X Гбит/с при включённых профилях», «latency не выше Y мс», «загрузка ниже Z% в пике».
Минимум — то, что обеспечивает актуальные сигнатуры и категорийные базы (например, сервисы FortiGuard) плюс поддержка.
Опции на рост: расширенная песочница, DLP/Zero Trust‑компоненты, дополнительные журналы/аналитика. Важно заранее определить, что включается «с первого дня», а что — по триггеру (рост пользователей, переход в ЦОД, увеличение доли удалёнки).
Заранее закрепите процесс:
За 90–120 дней до конца подписок: снимите фактическую нагрузку, проверьте, какие функции реально использовались, и сопоставьте это с текущими требованиями.
Закладывайте бюджет с учётом OPEX (подписки/поддержка) и планируйте продление под окно изменений, чтобы обновления и ключи лицензий не пришлись на пиковые периоды бизнеса.
ASIC действительно снимает часть нагрузки с CPU и помогает держать высокую пропускную способность (включая инспекцию трафика и SSL/TLS), но он не заменяет правильную архитектуру.
Если сеть спроектирована с «узкими местами» (неверная сегментация, перегруженные каналы, неподходящий размер таблиц сессий, некорректные политики), аппаратное ускорение не спасёт от задержек и сбоев. Кроме того, всегда останутся задачи, где важнее память, логика политики и оптимизация правил: маршрутизация, сложные сценарии с VPN, интеграции, журналирование, аналитика.
Подписки дают эффект там, где угрозы и методы атак меняются быстрее, чем обновляется «железо». Базы сигнатур, репутационные списки, обновления движков инспекции, категории веб‑фильтра, телеметрия — это не разовая покупка, а постоянная поддержка актуальности.
Практический критерий: если вы включаете IPS/AV/Web Filter/SSL inspection и ожидаете предсказуемую защиту весь срок службы устройства, без подписок это быстро превращается в «историческую справку», а не в защиту.
Попросите результаты тестов именно для ваших функций: включены ли SSL/TLS, IPS, контроль приложений, логирование.
Уточните SLA на обновления и поддержку, условия замены/ремонта, совместимость версий прошивок, а также сценарий миграции: перенос политик, объектов, VPN, адресных книг, интеграций (SIEM, NAC).
Сведите выбор к четырём осям:
ASIC — специализированный чип под ограниченный набор операций (обработка пакетов/сессий, NAT, часть DPI, криптография), который выполняет их быстрее и стабильнее, чем универсальный CPU.
CPU остаётся важным для «сложной логики»: обработка политик, исключений, интеграций, управления, журналирования и функций, которые часто меняются в софте.
Смотрите на метрики в нужном режиме, а не на «максимальные Гбит/с»:
И обязательно уточняйте условия теста: доля TLS, размер пакетов, профили угроз, логирование.
Потому что ускорение сильнее всего проявляется на массовых однотипных операциях:
А вот сложные/нестандартные сценарии могут частично уходить на CPU и снижать итоговую пропускную способность.
SSL/TLS‑инспекция — одна из самых «дорогих» функций: нужно расшифровать трафик, прогнать проверки (IPS/AV/контроль приложений), затем зашифровать обратно.
Практика:
Не всегда. Если включаются функции, которые не полностью ложатся на аппаратный тракт, часть обработки возвращается в программный путь.
Чтобы избежать сюрпризов:
Потому что актуальность защиты держится на данных и обновлениях:
Без подписок устройство остаётся мощной платформой, но со временем защищает «вчерашними» знаниями и требует больше ручной работы.
Разделите затраты на CAPEX и OPEX и считайте на горизонте 3–5 лет.
Итоговые метрики для сравнения:
Часто «скрытые» расходы дают больший эффект, чем разница в прайсе:
Добавьте эти статьи в расчёт — иначе сравнение моделей будет искажено.
Попросите подтверждение цифр в вашем профиле и заранее снимите риски миграции:
Лучше иметь короткий пилот с измеримыми критериями, чем полагаться на «паспортные» данные.
Планируйте как проект с контрольными точками:
Так вы уменьшите риск «неожиданной» просадки производительности и пауз в защите из‑за просрочки подписок.
