Разбираем, как Akamai эволюционировала от CDN‑кэширования к безопасности и edge compute, и почему эта смена фокуса важна для компаний.
Akamai часто вспоминают как «классическую CDN»: сеть узлов по всему миру, которая ускоряет загрузку сайтов и приложений за счёт доставки контента ближе к пользователю. И это правда — исторически Akamai стала одним из символов глобальной доставки контента (и до сих пор остаётся заметным игроком в этой категории).
Но сегодня Akamai интересна не только скоростью. Компания постепенно превратилась в платформу, где доставка, безопасность и пограничные вычисления (edge compute) взаимно усиливают друг друга. Этот сдвиг хорошо иллюстрирует общий тренд: одной оптимизации кэша уже недостаточно, когда риски, трафик и архитектуры приложений меняются быстрее, чем успевают переписываться «правила ускорения».
Материал будет полезен:
Разберём, как работала модель «CDN как кэш» и почему её стало мало; почему безопасность логично «переезжает» ближе к краю сети; что такое edge compute на практике; где в этой картине появляются Zero Trust и SASE; и по каким метрикам оценивать зрелость платформы.
Цель — не рекламировать конкретное решение, а дать оптику, с которой проще принимать решения: что оставлять в CDN, что выносить на edge, а что строить как слой корпоративной защиты.
Исторически CDN воспринимали как «распределённый кэш»: сеть серверов по всему миру хранит копии популярных файлов ближе к пользователям. Вместо того чтобы каждый запрос летел на ваш основной сервер (origin), значительная часть трафика обслуживается на краю сети — быстрее и дешевле.
CDN берёт на себя несколько практичных задач:
Задержка — это не только «мощность сервера», но и расстояние, количество сетевых переходов и перегруженные магистрали. Распределение узлов CDN по регионам помогает переживать локальные сбои и перегрузки: если один маршрут деградирует, трафик можно увести на другой узел ближе к пользователю.
Лучше всего работают сценарии, где контент повторно запрашивается многими людьми:
Классическая модель слабо помогает там, где ответ зависит от пользователя и меняется каждую секунду: персонализация, корзина, поиск, часть API. Второй важный предел — атаки и злоупотребления: один кэш не отличит легитимный всплеск интереса от DDoS и не остановит сложные попытки взлома на уровне приложений. Именно эти пробелы и подтолкнули рынок расширять роль CDN далеко за рамки кэширования.
Когда-то идея «CDN как кэш» решала почти всё: статические файлы ближе к пользователю — меньше задержка, ниже нагрузка на origin, дешевле трафик. Но по мере взросления рынка кэширование перестало быть конкурентным преимуществом и стало базовой гигиеной.
Стандартные функции CDN (кэш, сжатие, TLS, базовая оптимизация) доступны у многих поставщиков и часто воспринимаются как взаимозаменяемые. Разница в миллисекундах уже редко оправдывает стратегический выбор платформы — бизнес ждёт измеримого эффекта шире, чем просто ускорение.
Большая часть критичного трафика сегодня — динамика: персонализированные страницы, поиск, корзина, рекомендации, real‑time API. Даже если фронтенд частично кэшируется, «ценность» и риски сосредоточены в запросах к API и логике на сервере. В итоге кэширование экономит ресурсы, но не решает главные проблемы доступности и безопасности.
Смещается и профиль угроз: боты, credential stuffing, атаки на бизнес‑логику, эксплуатация уязвимостей, перегрузка L7. Для компании это не только «инцидент ИБ», а прямые потери: простои, мошенничество, утечки, штрафы и деградация пользовательского опыта. Кэш не отличает легитимный запрос от вредоносного и не управляет риском.
Мультиоблако, микросервисы и глобальные команды размывают периметр: origin’ов больше, маршрутов больше, изменений больше. Ускорение доставки остаётся важным, но без контроля доступа, защиты API и управляемости на границе сети (edge) бизнес получает быстрый, но уязвимый и трудноуправляемый контур.
В результате ожидания сместились: от «быстрее» к «быстрее и безопаснее», где снижение рисков становится таким же KPI, как производительность.
CDN изначально строились как «большая распределённая сеть узлов рядом с пользователем». И эта же особенность стала удобной базой для информационной безопасности: если у вас тысячи точек присутствия, вы видите трафик раньше, чем он попадёт в origin, и можете принимать решения там же — на периметре сети.
Сеть доставки — это не только ускорение. Это постоянное «наблюдательное окно» в то, что происходит с приложением: всплески запросов, аномальные паттерны, попытки перебора, бот‑активность, нетипичные географии. Чем ближе контроль к пользователю, тем меньше лишнего трафика доходит до инфраструктуры клиента и тем проще масштабироваться во время атак.
Ключевая идея разворота к безопасности проста: блокировать вредоносный трафик на edge, не перегружая origin и каналы связи.
Так DDoS‑потоки «рассеиваются» по узлам сети, а не концентрируются у входа в дата‑центр. WAF и защита API получают возможность отсеивать атаки ещё до того, как запрос начнёт потреблять ресурсы приложения и базы данных.
Когда CDN и защита работают в одном прокси‑слое, появляется единая точка политики: один набор правил, единое TLS‑завершение, консистентные логи и единое управление ботами. На практике это означает, что оптимизация (сжатие, HTTP/2/3, cache‑control) и контроль (WAF, rate limiting, проверка токенов) не спорят за порядок обработки — они идут одной цепочкой.
Безопасность на edge добавляет проверки, а значит — потенциальные миллисекунды задержки. Второй риск — ложные срабатывания, когда правила WAF или антибота блокируют легитимных пользователей. Поэтому критичны режимы «наблюдения» перед включением блокировок, аккуратная настройка rate limits и понятный процесс исключений и отката правил.
Важно помнить, что универсальных политик нет: правила почти всегда требуют адаптации под конкретные пути, методы, заголовки и поведение клиентских приложений.
Когда безопасность «прикручена» к доставке, защита оказывается ближе к пользователю и атакующему трафику — то есть там, где легче увидеть аномалии и отсечь лишнее до того, как оно дойдёт до ваших серверов. Но важно понимать, что это не один продукт, а набор слоёв, каждый из которых закрывает свой класс рисков.
WAF (web application firewall) фильтрует HTTP(S)‑запросы к сайту и веб‑приложению. Практическая ценность — в блокировке типовых атак на уровень приложения: попыток внедрения команд/запросов, обхода авторизации, вредоносных полезных нагрузок в параметрах, сканирования уязвимостей.
На что смотреть в эксплуатации: есть ли режим «наблюдения» (log/monitor), насколько удобно настраиваются исключения и как быстро команда может безопасно включить более строгие правила без всплеска ложных срабатываний.
DDoS бывает разным: от перегрузки канала до «умного» давления на приложение. Поэтому важны не только обещанные «Тбит/с», но и метрики и контроль:
API часто атакуют тише, чем сайты: перебором токенов, чрезмерными запросами, нетипичными параметрами. Хорошая защита API обычно включает проверку и «гигиену» токенов (формат, срок, контекст), rate limiting/квоты, а также валидацию схемы запросов (ожидаемые поля, типы, размеры). Это снижает риск утечек и уменьшает нагрузку на бэкенд.
Боты вредят по‑разному: скрейпинг, подбор учётных данных, накрутка, выкуп слотов, «псевдопользовательская» нагрузка. Бот‑менеджмент помогает отделять автоматизацию от живых пользователей, но критично избегать блокировки реальных клиентов. На практике помогают поэтапное ужесточение, отдельные политики для логина/поиска/корзины и прозрачный процесс разборов false positive.
Шифрование — это не только «включить HTTPS». Управление TLS/сертификатами на периметре влияет на скорость внедрения, устойчивость и соответствие требованиям: ротация сертификатов, поддержка современных наборов шифров, HSTS, контроль сроков и единая политика для всех доменов и сервисов. Такой слой снижает риск ошибок конфигурации и упрощает аудит.
Edge compute (пограничные вычисления) — это выполнение части прикладной логики не в центральном облаке или на вашем origin‑сервере, а максимально близко к пользователю: на узлах CDN по всему миру. Идея простая: если решение можно принять «на краю», запрос не обязательно гонять через океан до дата‑центра.
Классический CDN давно умеет переписывать заголовки, делать редиректы, выбирать origin, применять правила маршрутизации и кэш‑политики. Edge compute идёт дальше: вы запускаете небольшой кусок кода, который может:
Это уже не «набор правил», а мини‑приложение на распределённой сети.
Чаще всего выигрывают сценарии, где важны миллисекунды и быстрые изменения без тяжёлых релизов: персонализация витрины без похода на origin, A/B‑тесты и фичефлаги, гео‑логика (региональные ограничения/каталоги), лёгкие интеграции вроде проверки промокода, подписи URL, валидации токена или проклейки идентификаторов.
На краю обычно сложно хранить состояние (state), есть лимиты на время выполнения и ресурсы, возможны «холодные старты». Отладка и наблюдаемость тоже требуют дисциплины: логирование, трассировка, контроль версий и безопасные секреты.
Оценивайте по трём вопросам: даёт ли это заметное снижение задержек, окупается ли стоимость выполнения на edge по сравнению с origin/облаком, и не увеличивает ли это риски (ошибки на периметре, сложность релизов, требования к тестированию). Если выигрыши измеримы, edge становится естественным продолжением CDN, а не модным «дополнением».
Когда функции безопасности работают прямо на edge, проверка запросов происходит до того, как трафик доберётся до вашего приложения или облака. Это уменьшает стоимость лишнего трафика, помогает быстрее реагировать на атаки и часто снижает задержки (не нужно отправлять запросы в отдельные контуры очистки).
Edge‑платформа видит реальный пользовательский поток, включая всплески, аномалии и «шум» ботов. Поэтому защитные решения могут принимать решения на основе контекста доставки: география, тип клиента, поведение сессии, «нормальность» URL и заголовков.
Часто выигрывают самые приземлённые вещи:
Практика «security as code» — это когда правила (ACL, rate limiting, WAF‑исключения, API‑политики) живут рядом с конфигурацией сервиса и проходят тот же цикл, что и релизы: код‑ревью, тесты, постепенный rollout. Так меньше ручных правок «в проде» и проще откатываться.
В реальности почти всегда нужны и внутренние инструменты: каталоги правил, согласование изменений, дешборды по эффекту. Такие вещи удобно быстро собирать в формате «виб‑программирования» на TakProsto.AI — например, сделать веб‑панель для управления политиками, выгрузки логов и сравнения метрик «до/после», а затем экспортировать исходники и развернуть в своём контуре (в том числе с данными, остающимися в России).
Важно измерять не только «сколько атак отбили», но и «как это влияет на пользователей». Задайте SLO (например, p95 задержки, доля ошибок 4xx/5xx, успешность логина) и настройте алерты, где коррелируют события WAF/DDoS и деградация метрик. Это помогает отличать реальную атаку от неудачного релиза и быстрее находить первопричину.
Подробнее о выборе показателей — в разделе про метрики и зрелость платформы (/blog/metriki-zrelosti-platformy).
Когда Akamai и подобные платформы расширяются за пределы «ускорения сайтов», они неизбежно приходят к корпоративным сценариям: доступ сотрудников к внутренним приложениям, контроль подрядчиков, защита филиалов и облачных сервисов. Здесь важны два понятия — Zero Trust и SASE.
Zero Trust — это подход «никому не доверяем по умолчанию». На практике это означает, что доступ выдают не «в сеть целиком» (как в классическом VPN), а точечно — к конкретному приложению или сервису, с проверкой контекста.
Обычно учитываются:
Результат — меньше бокового перемещения внутри инфраструктуры и более понятная модель «кто и зачем вошёл».
SASE (Secure Access Service Edge) — идея собрать сетевой доступ и защиту в единую облачную услугу. Вместо набора разрозненных коробок и правил по филиалам компания получает централизованные политики и единый путь трафика через проверки: фильтрацию, контроль приложений, инспекцию, предотвращение утечек и т. п.
Ключевые вопросы — не только про «есть ли функция», но и про управляемость:
Граница между «доставкой» и «защитой» размывается: клиенты всё чаще сравнивают CDN не только по скорости и покрытию, но и по тому, насколько хорошо платформа закрывает риски — от ботов и API‑атак до больших DDoS. В результате конкуренция смещается с уровня «чей кэш быстрее» на уровень «кто лучше управляет трафиком и угрозами на edge».
Единая платформа особенно выигрывает там, где важны простота эксплуатации и единые политики:
Ключевой эффект — меньше «стыков» между провайдерами и меньше времени на разбор инцидентов: кто отфильтровал, кто проксировал, где возникла задержка.
Разделение часто оправдано, если:
Облака сильны интеграцией с собственными сервисами и удобством для workloads «внутри облака». CDN‑платформы с упором на безопасность сильны там, где трафик и пользователи распределены глобально и важна защита ближе к клиенту — независимо от того, где размещён origin.
Сравнивайте не названия услуг, а практику: качество сигналов (телеметрия), скорость реакции на новые типы атак, управление правилами и то, как легко вам переносить конфигурации между средами.
Vendor lock‑in проявляется в правилах WAF, логике маршрутизации, форматах логов и API управления. Снижать риск помогают:
Так конкуренция становится здоровее: выигрывает не тот, кто продаёт больше функций, а тот, кто даёт измеримый контроль над трафиком, рисками и изменениями.
Когда CDN превращается в «платформу на периметре» (доставка + защита + edge), оценивать её по одному показателю вроде скорости раздачи уже недостаточно. Важно смотреть на метрики по пяти направлениям — и проверять их на реальном трафике и инцидентах.
Для пользовательского опыта полезнее всего TTFB (время до первого байта) и его распределение (p50/p95), а не только «средняя скорость». Второй ключевой показатель — cache hit ratio: высокий процент попаданий в кэш снижает задержку и стоимость.
Отдельно зафиксируйте долю динамического трафика (что не кэшируется) и как платформа ускоряет именно его: оптимизация TCP/TLS, маршрутизация, сжатие, edge‑логика.
Смотрите аптайм по факту, но дополняйте его операционными метриками: частота инцидентов, MTTR (время восстановления) и «радиус поражения» — насколько инцидент локализуется по регионам/PoP.
Зрелость защиты — это не «сколько атак видим», а сколько корректно блокируем. Отслеживайте:
Проверьте модель тарификации: что считается отдельно (запросы, правила, TLS, DDoS, логирование, edge‑функции). Критично — поведение на пиковых нагрузках и прогнозируемость: можно ли заранее оценить бюджет при росте трафика и атак.
Оцените, насколько удобно жить с правилами: скорость деплоя, наличие dev/stage, откат, шаблоны, CI/CD. Для безопасности важны роли и аудит: кто менял политики, что именно, и можно ли это быстро расследовать.
Переход от «просто ускоряем» к «ускоряем + защищаем + выполняем логику на edge» проще всего делать как продуктовый релиз: с измеримыми целями, малым риском и понятным откатом. Ниже — практичный маршрут, который подходит для Akamai и в целом для CDN‑платформ.
Соберите базовую «карту трафика»: какие домены и поддомены несут выручку, какие регионы критичны по задержке, какие приложения/пути самые нагруженные, где проходят API (включая мобильные). Это нужно не для отчёта, а чтобы правильно выбрать порядок подключения: сначала то, что даёт максимум эффекта при минимальном риске.
Параллельно включайте «безопасные дефолты» и кэш там, где почти невозможно навредить:
Выберите 1–2 edge‑сценария с измеримым эффектом: например, нормализация заголовков и маршрутизация, проверка токена перед обращением к origin, A/B‑разметка или простая персонализация без похода в центральный бэкенд. Важно заранее определить метрики: снижение нагрузки на origin, уменьшение p95 задержки, падение доли 4xx/5xx, экономия трафика.
Любые правила на периметре — это «продакшен‑код». Нужны управление правилами (версии и владельцы), тестирование на стейджинге/канареечные выкладки, быстрый откат, централизованное журналирование и понятный разбор инцидентов.
Такой подход позволяет развивать CDN, безопасность и edge compute как последовательные улучшения, а не как один рискованный «большой переход».
CDN‑провайдеры всё чаще строят единую «пограничную» платформу: контент доставляется ближе к пользователю, там же фильтруется вредоносный трафик и запускается логика приложений. Это снижает задержки, упрощает архитектуру и позволяет применять единые политики безопасности для веба, API и edge‑функций.
По мере роста машинного трафика (включая сбор данных, автоматизированные покупки, подбор учётных данных и «серые» сценарии вокруг ИИ) смещается фокус: защищать нужно не только страницы, но и API‑методы, бизнес‑логики и цепочки интеграций. Классический WAF уже недостаточен без анализа поведения, контроля аномалий и защиты от злоупотреблений (abuse).
Покупателям важна не «ещё одна консоль», а сквозная управляемость: единые политики, версионирование конфигураций, быстрый rollback, готовые интеграции с SIEM/SOAR и понятные отчёты для бизнеса. Наблюдаемость (observability) постепенно объединяет метрики доставки, инциденты безопасности и производительность edge‑логики.
Эти вопросы помогают заранее понять, не превратится ли «переезд на платформу» в набор разрозненных сервисов и ручных процедур.
CDN ускоряет доставку контента, обслуживая запросы с узлов, расположенных ближе к пользователю, и уменьшая долю обращений к origin.
Практический эффект:
Лучше всего кэшируются повторяющиеся ответы, одинаковые для многих пользователей:
Плохо кэшируются персонализированные страницы и API-ответы, зависящие от пользователя, токена, корзины, поиска и т. п. — там ценность смещается в ускорение динамики и защиту, а не в кэш.
Потому что современные риски находятся «выше» кэша:
Поэтому платформа на edge всё чаще сочетает ускорение и контроль трафика в одном прокси‑слое.
WAF фильтрует HTTP(S)‑запросы и помогает блокировать типовые атаки на веб‑уровне (инъекции, сканирование уязвимостей, попытки обхода авторизации).
Практика внедрения:
Смотрите не только на «мощность в Тбит/с», а на управляемые метрики:
Важно заранее продумать лимиты и исключения для ключевых сценариев (распродажи, релизы, партнёрские интеграции).
API часто атакуют «тихо»: перебор токенов, завышенные частоты запросов, неожиданные поля и размеры payload.
Полезный минимум на периметре:
Это уменьшает риск утечек и снижает нагрузку на бэкенд.
Бот‑менеджмент отделяет автоматизированный трафик от пользователей и снижает ущерб от скрейпинга, credential stuffing и накруток.
Чтобы не «сломать» конверсию:
Пограничные вычисления — это запуск небольших функций на узлах сети доставки, чтобы принимать решения ближе к пользователю.
Типовые кейсы:
Ограничения обычно связаны с временем выполнения, ресурсами и сложностью наблюдаемости (логи/трассировка/версии).
Zero Trust — это выдача доступа не «в сеть целиком», а к конкретным приложениям с проверкой контекста (пользователь, MFA, устройство, риск‑сигналы).
SASE — модель, где сетевой доступ и проверки безопасности предоставляются как единый сервис с централизованными политиками.
Полезно, если нужно:
Сведите оценку к измеримым показателям в пяти группах:
Для практики удобно закрепить метрики и SLO и сверяться с ними при изменениях; см. также /blog/metriki-zrelosti-platformy.
