Ви розміщуєте його в одному місці, скажімо, у Центрі обробки даних у Вірджинії. Для клієнтів у Нью-Йорку чи Чикаго це працює добре, але як щодо когось у Токіо, Лондоні чи Сіднеї. Щоразу, коли ця людина відвідує ваш сайт, її запит має долати океани і континенти, щоб дістатися вашого сервера. Кожне зображення, кожне завантаження сторінки, кожен виклик АРІ здійснює ту саму довгу подорож, і ця затримка швидко накопичується. Дослідження показують, що навіть одна секундна затримка завантаження сторінки може коштувати вам конверсій і відлякувати розчарованих відвідувачів. Але ось у чому річ, що станеться, коли ваш сайт стане віральним або ботнет вирішить його атакувати. Ваш єдиний сервер у Вірджинії буде перевантажений. Він сповільниться, а може навіть повністю вийти з ладу. Ви залишитеся без плану резервного копіювання. Ви можете вирішити проблему доступності, створивши копії вашого сайту в різних регіонах Токіо, Лондоні, Сан-Павлу.

Це допомагає. Але тепер у вас з'являється нова проблема. Як спрямувати кожного відвідувача до потрібного місця? Ви ж не хочете, щоб хтось із Японії випадково потрапив на ваш американський сервер. Вам потрібен розумний спосіб маршрутизації трафіку, і саме тут на допомогу приходить Azure Front Do. Знайомтеся з глобальним регулювальником трафіку, ось що таке Azure Front Do. Уявіть Azure Front Do як глобального регулювальника не одного на перехресті, а тисячі таких, що стоять на головних вузлах по всьому світу. Щоразу, коли хтось відвідує ваш сайт, найближчий регулювальник втручається і каже «Ви в Токіо. Найшвидше сховище для вас знаходиться в Сінгапурі. Дозвольте мені відправити вас туди». Отже, чим це відрізняється від звичайного балансувальника навантаження? Більшість балансувальників працюють на четвертому рівні, дивлячись на IP-адреси та порти для маршрутизації трафіку. Це добре для базових потреб, але Azure Front Do працює на сьомому рівні, тобто він розуміє трафіки HTTP та HTTPS.

Він може аналізувати URL-адресу, яку ввів користувач, перевіряти заголовки браузера, бачити, який контент запитується і приймати розумні рішення щодо маршрутизації на основі всього цього. Замість того, щоб просто сказати «Цей IP йде на той сервер», Front Do може сказати «Цей запит для користувачів АРІ йде на ваш сервер у США, а запит на зображення – докешованої копії в Токіо». Ось що робить це можливим залаштунками. Azure Front Do працює на глобальній мережі Microsoft, що налічує понад 210 точок присутності в більш ніж 130 містах по всьому світу. Уявіть кожну точку присутності як невеликий пункт регулювання, місцевий офіс у кожному великому місті, який може швидко обробити початковий запит. Коли користувач відвідує ваш сайт, він підключається до найближчого вузла замість того, щоб подорожувати до вашого вихідного сервера у Вірджинії. Потім цей вузол спрямовує їхній запит через приватну магістраль Microsoft до вашого бекенду.

Це важливо, оскільки публічний інтернет не передбачуваний. Ваш трафік може пройти через десяток мереж, кожна з яких додає затримку та ризик втрати пакетів. Магістральна мережа Microsoft, навпаки, є приватною високошвидкісною мережею, що безпосередньо з'єднує їхні дата-центри. Тож, як тільки ваш запит потрапляє до найближчої точки присутності, решта шляху проходить швидкою та надійною магістралью. Ви отримуєте швидке завантаження, меншу затримку та кращий досвід для користувачів всюди, чи то в Токіо, Лондоні або Сан-Паулу. І все це відбувається автоматично, безвідома ваших відвідувачів.

Можливо, ви думаєте, ідея глобального регулювальника трафіку чудова, але що буде, якщо він сам вийде з ладу? Якщо Azure FrontDo – це єдина точка входу для вашого застосунку, то це серйозна точка відмови, чи не так? Компанія Microsoft передбачила це. Вони вбудували три рівні стійкості у FrontDo, тому сервіс майже ніколи не вимикається. Дозвольте розповісти про них детальніше. Перший рівень – інтерфейс – FrontEnd. Пам'ятаєте ті понад 210 точок присутності, про які я згадував? Кожна з них є повністю незалежним вузлом обробки трафіку. Ці точки розташовані у понад 130 містах світу, працюючи в дата-центрах Microsoft та партнерських колокаційних центрах. Кожна точка має декілька стійок серверів з периферійними контролерами, що діють як вбудований балансувальник навантаження. Якщо один сервер у точці виходить з ладу, контролер перенаправляє трафік на справний у тій самій точці. А якщо виходить з ладу ціла точка, вступає в дію IP-адресація Anycast.

Запит вашого відвідувача автоматично спрямовується до наступної найближчої точки. Жодних перебоїв чи ручного втручання – усе відбувається самостійно. Другий рівень – резервний – фолбек. Але що, якщо точка перевантажена? Скажімо, стався величезний стрибок трафіку, або кілька точок у регіоні відключилися одночасно. Решта точок можуть не впоратися з таким навантаженням. Саме тоді в гру вступає резервний рівень. Це окремий набір точок і їх десятки, а не сотні, що працюють на тому самому програмному забезпеченні та архітектурі. Вони розміщуються лише в дата-центрах Microsoft, а не в партнерських об'єктах. Коли фронтальній точці потрібно зменшити навантаження, вона перекидає запити на цей резервний рівень. Таке саме кешування, маршрутизація та безпека. Ваші відвідувачі ніколи не помітять різниці. Можливо, контент завантажиться трохи повільніше, але вони все одно його отримають. Третій рівень – це захисний екран трафіку.

Це головний наглядач. Уявіть це як глобальний командний центр, що стежить за всією мережею фронт-до. Він моніторить моделі трафіку, рівні навантаження та стан усіх точок присутності POP. Коли він виявляє, що певні точки перевантажені, він не просто чекає на активацію резервного рівня. Він проактивно перенаправляє трафік, оновлюючи те, як DNS розпізнає ваш кінцевий вузол фронт-до. Він може перемикатися з глобальної Anycast IP-адреси на регіональну, повністю переводячи клієнтів на інші набори точок. За потреби він може навіть долати континенти. Саме захисний екран робить фронт-до майже магічним. Він постійно оптимізує роботу у фоновому режимі, коригуючи маршрути ще до виникнення проблем. Тепер я маю дещо зазначити. У жовтні 2025 року Azure Frontdo зазнав значного збою. Зміна конфігурації оминула перевірки безпеки, що спричинило масштабні проблеми в Microsoft 365, Xbox Live та тисячах клієнтських сайтів.

Microsoft зробила з цього висновки. Вони прибрали всю асинхронну обробку з конвейера конфігурації. Тепер кожен шлях коду тестується під час розгортання. Вони скоротили час відкату з 4 годин до 1 і планують досягти 10 хвилин до березню 2026 року року. Вони також впроваджують мікрокоміркову сегментацію, щоб обмежити майбутній вплив до менш ніж 1% корендерів. Суть у тому, що жодна система не є ідеальною, але трирівнева архітектура Frontdo розроблена так, щоб витримувати регіональні збої, сплески трафіку і навіть деякі помилки конфігурації. Для більшості програм цього цілком достатньо. Для критично важливих систем ви можете додати Azure Traffic Manager перед Frontdo як аварійний шлях, але це вже складна тема для іншого разу. Як він спрямовує трафік, маршрутизація та групи джерел. Отже, у нас є цей глобальний регулювальник трафіку з понад 210 точками та трьома рівнями резервування, але як він насправді вирішує, куди відправити кожного відвідувача?

Тут у гру вступають групи джерел. Група джерел – це, по суті, колекція ваших серверів беккенду. Уявіть, це як ваш список магазинів, реальні місця, де працює ваш сайт чи програма. У вас може бути один сервер у Північній Америці, один у Європі та один в Азії. Усі вони входять до однієї групи джерел. Тепер Франт До не просто сліпо надсилає трафік на всі з них. Він постійно перевіряє, чи вони працюють. Це називається перевіркою стану HealthPro. Кожні кілька секунд кожна точка Франт До пінгує ваші сервери, звертаючись до певного шляху, зазвичай до корення сайту або спеціальної кінцевої точки перевірки стану, як от Health. Якщо сервер не відповідає або видає код помилки, Франт До позначає його як непрацездатний і припиняє надсилати туди трафік. Це наче регулювальник, який перевіряє, чи відкритий магазин, перш ніж впускати покупців. Але коли у вас є кілька справних серверів, виникає питання, який із них має прийняти відвідувача.

Франт До використовує три фактори для прийняття рішення – пріоритет, затримка та вага. І вони працюють разом у певному порядку. Перший – це пріоритет. Ви можете призначити один сервер основним, а інший – резервним. Встановіть для основного перший пріоритет, а для резервного – другий. За звичайних умов увесь трафік йде на основний сервер. Тож, якщо основний виходить з ладу, трафік перемикається на резервний. Просто чи не так? Це чудово підходить для схем «активний-пасивний», де ви хочете, щоб один регіон обробляв усе, поки він справний. Але що, якщо ви хочете, щоб обидва сервери були активними? Тут у гру вступає затримка. Якщо кілька серверів мають однаковий пріоритет, Франт До надсилає трафік на той, що має найменшу затримку, тобто найшвидший відвук із місця розташування відвідувача. Отже, користувач у Лондоні спрямовується на ваш європейський сервер, а користувач у Токіо – на азійський.

Також існує налаштування чутливості, за замовчуванням це 50 мілісекунд. Якщо різниця в часі відповіді двох серверів становить менше, ніж 50 мілісекунд, Франт довважає їх однаково швидкими. Це запобігає постійному перемиканню між серверами, які мають приблизно однакову швидкість. А коли затримка однакова, у справу вступає вага. Ви можете призначити вагу, щоб розподілити трафік між серверами. Припустімо, ви хочете протестувати нову версію свого застосунку. Ви можете надати своєму поточному серверу вагу 90, а новому – вагу 10. Це означає, що приблизно 9 із 10 відвідувачів підуть на стару версію, а один із 10 – на нову. Це ідеально підходить для поступового розгортання, A-B-тестування або просто балансування навантаження між серверами з різною потужністю. Ось що важливо. Усе це відбувається автоматично. Ви один раз налаштовуєте групу джерел, а решту бере на себе Франт До. Він перевіряє ваші сервери, вимірює затримку, дотримується пріоритетів і розподіляє трафік залежно від ваги.

І робить це все на периферії, ще до того, як запит дійде до вашої серверної частини. Це означає, що вашим серверам не потрібно визначати, звідки прийшов трафік або як його спрямувати. Вони лише обслуговують контент. Безпека на периферії, WAF та подальший захист. Тепер давайте поговоримо про безпеку. Оскільки Франт До розташований на самому краю мережі Microsoft, це ідеальне місце, щоб зупинити атаки ще до того, як вони досягнуть ваших серверів. Сприймайте це як контрольно-пропускний пункт на вході до будівлі. Кожен, хто хоче увійти, має спершу пройти через нього. Цей контрольний пункт називається BrandMaurum Web-додатків або WAF, і він вбудований як у Франт До Стендад, так і в преміум. Він автоматично блокує поширені веб-загрози. Наприклад, SQL-ін'єкції, коли зловмисник намагається впровадити шкідливі команди бази даних у поле форми або міжсайтовий скриптинг, де в сторінки впроваджуються скрипти або ДОС-атаки, спрямовані на перевантаження серверів трафіком.

WAF перехоплює все це на периферії та відхиляє запити до того, як вони досягнуть вашого джерела. Окрім автоматичного захисту, ви також можете створювати власні правила. Наприклад, якщо ваш сайт призначений лише для клієнтів у Європі, ви можете повністю заблокувати трафік з інших регіонів. Або якщо ви помітили певний діапазон IP-адрес, що постійно сканує ваш сайт, ви можете заблокувати і його. Ви також можете фільтрувати трафік на основі заголовків запитів, шаблонів URL або навіть браузера, який використовує користувач. WAF надає дуже точний контроль над тим, хто отримує доступ, а хто ні. Ось тут і стають важливими ці нові рівні. Рівень Standard надає власні правила WAF, де ви самі визначаєте, що блокувати, а що дозволяти. Рівень Premium іде далі, додаючи керовані набори правил на основі аналізу загроз від Microsoft, який постійно оновлюється з урахуванням реальних атак, виявлених у всій мережі Microsoft.

Premium також містить захист від ботів, що автоматично блокує скрапери, підбір облікових даних та інші типи ботів. Крім того, він додає підтримку Private Link, яка дозволяє підключатися до джерел через приватне мережеве з'єднання замість публічного інтернету. Це означає, що ваші серверні частини можуть бути повністю приховані від зовнішнього світу. Тільки FrontDo може отримати до них доступ. Це надзвичайно важливо для безпеки. Багато атак спрямовані не на FrontDo. Вони намагаються знайти чорний хід. Якщо ваш вихідний сервер має публічну IP-адресу, зловмисники можуть сканувати її напряму, оминаючи всі засоби захисту FrontDo. З Private Link це неможливо, оскільки джерело не має публічної кінцевої точки і доступне лише через FrontDo. Тож навіть якщо хтось дізнається IP вашого сервера, він не зможе до нього підключитися. Результат – ешелонований захист. WAF блокує атаки на рівні додатків. Власні правила вирішують ваші специфічні завдання.

Захист від ботів зупиняє автоматизовані загрози. А Private Link робить ваші джерела невидимими. Усе це відбувається на периферії ще до того, як трафік досягне вашої інфраструктури, тому ваші сервери зосереджені на обслуговуванні контенту, а не на боротьбі з атаками. Кешування – пришвидшення роботи. Отже, ми розглянули маршрути за цію та безпеку, але є ще одна функція, яка робить FrontDo дуже корисною – кешування. Ось у чому ідея. Багато контенту вашого веб-сайту змінюється не дуже часто. Зображення, CSS-файли, бібліотеки JavaScript, фотографії продуктів, можливо, навіть деякі HTML-сторінки. Якщо кожен окремий відвідувач повинен завантажувати їх з вашого вихідного сервера, ви марнуєте час і пропускну здатність, оскільки сервер змушений обробляти один і той самий запит знову і знову, щоразу відправляючи ті самі байти через інтернет. Кешування виправляє це, зберігаючи копію статичного контенту на периферійному вузлі POP.

Коли хтось наступного разу запитає той самий файл, вузл POP надасть його миттєво, навіть не звертаючись до вашого вихідного сервера. Це ніби мати невеликий склад біля кожного пункту пропуску. Замість того, щоб відправляти кожного клієнта назад на головний завод, ви просто даєте їм те, що вже є на полиці. Різниця в продуктивності вражаюча. Замість подорожі через океан і назад, відповідь приходить із сервера в тому самому місті. Мілісекунди замість секунд. А ваш вихідний сервер отримує перепочинок, оскільки він обробляє менше запитів і може зосередитися на динамічних завданнях, які дійсно потребують обробки. Отже, кешування не є автоматичним для всього. Ви самі контролюєте, що саме кешувати і як довго. Frant.do дотримується стандартних заголовків керування кешем з вашого сервера, як от Maxage або Smaxage, і ви також можете налаштовувати правила кешування безпосередньо, замінюючи заголовки вашого сервера, якщо це потрібно.

Коли ви оновлюєте контент, ви можете очистити кеш і наказати Frant.do видалити старі копії та завантажити нові. Це важливо для таких речей, як запуск продуктів або зміна цін, де нова версія має стати видимою негайно. Ось у чому справа. Frant.do призначений не лише для статичного контенту. Навіть для динамічного контенту, як от АРІ, персоналізовані сторінки або кошики покупок, він прискорює доставку, оскільки як тільки запит потрапляє на найближчий вузол, він рухається до вашого сервера приватною магістралью Microsoft, а не через загальнодоступний інтернет. Ця приватна магістраль швидша та надійніша за відкриту мережу. Тож навіть не кешувані запити отримують прискорення. Це одна з ключових відмінностей між Frant.do і традиційною CDN. CDN кешує статичний контент і це, власне, все. Frant.do кешує статичний контент і прискорює все інше. Це угода два в одному. Тарифні плани, який з них обрати.

Гаразд, давайте поговоримо про гроші, бо це головне питання. Скільки це коштує і який саме рівень вам слід обрати? Перш ніж ми перейдемо до цифр, ось чому це важливо. Вибраний рівень впливає не лише на ціну, а й визначає безпеку та функції, доступні для захисту вашого додатка. Як ви знаєте, Frant.do має три версії. Classic – це стара версія. Вона все ще працює, але Microsoft не рекомендує використовувати її для нових проєктів. Версія Classic поступово виводиться з експлуатації. Жодних нових ресурсів після 2025 року та повне припинення роботи до 2027 року. Тож, якщо ви починаєте з нуля, вам слід обирати між Standard або Premium. Ось найпростіший огляд. Тариф Standard коштує 35 доларів на місяць, як базова плата. Тариф Premium коштує 330 доларів на місяць. Це значний стрибок, але ось найцікавіше. Тарифи на передачу даних за гігабайт ідентичні для обох рівнів. У Північній Америці та Європі вихідний трафік коштує близько 8,25 цента за гігабайт для перших 10 терабайтів.

Однакові для обох. Отже, що дають ці додаткові 300 доларів? Функціональні можливості. Premium додає керовані правила WAF на базі аналітики загроз Microsoft, які автоматично оновлюються на основі реальних моделей атак. Ви також отримуєте захист від ботів, підтримку Private Link, щоб ваше джерело залишалося прихованим від публічного інтернету та глибшу аналітику безпеки. Standard надає глобальне балансування навантаження, кешування, динамічне прискорення та користувацькі правила WAF. Ви можете блокувати діапазони IP-адрес, країни або шаблони запитів. Ви просто не отримуєте керовані набори правил або Private Link. Плата за запити також відрізняється. Standard коштує близько 9 центів за 10 тисяч запитів для перших 250 мільйонів. Premium коштує близько 15 центів за 10 тисяч запитів. При великих обсягах ця різниця стає відчутною. Тож як зробити вибір? Ось моє правило. Якщо ви керуєте типовим веб-сайтом або ARRI, яким потрібна глобальна продуктивність і базова безпека, почніть зі Standard.

Базова плата 35 доларів є доступною, а користувацькі правила WAF впораються з більшістю поширених загроз. Ви завжди можете оновитися пізніше, якщо ваші вимоги до безпеки зростуть. Якщо ви працюєте в регулюваній галузі, як-от охорона здоров'я, фінанси, державний сектор або обробляєте конфіденційні дані клієнтів, преміум вартий додаткових витрат. Керовані правила WAF виявляють загрози, про блокування яких ви могли навіть не подумати. Private Link робить ваші джерела невидимими, а захист від ботів зупиняє автоматизовані атаки, які Standard не зміг би виявити. Останнє, якщо ви надаєте лише статичний контент і вам не потрібна маршрутизація чи функції безпеки, традиційна мережа CDN може бути дешевшою. Azure CDN від Microsoft все ще існує, і для передачі сутостатичного контенту це часто вигідніше. Але для більшості реальних застосунків, де потрібні маршрутизація, безпека, кешування та прискорення, франт до Standard є ідеальним вибором.

Підсумовуючи, розглянемо реальний приклад. Дозвольте мені розповісти про реальний сценарій, щоб ви побачили, як саме ці компоненти працюють разом. Уявіть, що ви керуєте сайтом електронної комерції. Ви маєте сервери в трьох регіонах – Північній Америці, Європі та Азії. Ваші клієнти всюди – від Японії до Бразилії та Південної Африки. Без франт до клієнт у Токіо підключається безпосередньо до вашого сервера в США. Кожне зображення, сторінка продукту та запит на оформлення замовлення має перетнути тихий океан. Це повільно. А якщо ваш сервер у США вийде з ладу, клієнт просто побачить помилку. Тепер додайте франт до. Клієнт у Токіо відкриває ваш сайт. Його браузер звертається до найближчого вузла Azure, назвімо його Tokyo. Цей вузол перевіряє стан трьох ваших серверів, вони справні. Він вимірює затримку. Азійський сервер відповідає найшвидше, тому він спрямовує запит туди через приватну магістраль Microsoft.

Сторінка завантажується менш ніж за секунду замість трьох. Тепер уявіть, що азійський сервер перевантажений під час розпродажу. Зонди стану франт до виявляють підвищену затримку. Він починає перенаправляти трафік на європейський сервер, найкращий варіант після першого. Клієнти все одно отримують швидку роботу, можливо, не таку швидку, як з азійським сервером, але швидше, ніж через США. Увесь процес перемикання відбувається автоматично, без втручання в налаштування. Тим часом на периферії працює WAF. Він блокує спробу SQL-ін'єкції від ботнету, що сканує вашу форму оплати. Він блокує трафік із відомих шкідливих діапазонів IP-адрес. І обмежує частоту запитів від IP, який витягує дані з вашого каталогу товарів. Жодна з цих атак не доходить до ваших вихідних серверів. Ваша команда бекенду навіть не знає, що вони відбулися. А статичний контент, зображення товарів, файли CSS, бібліотеки JavaScript кешуються у вузлів Токіо.

Перший відвідувач завантажує їх з азійського джерела. Другий відвідувач миттєво отримує їх із периферійного кешу. Повторні відвідувачі бачать миттєве завантаження, бо все необхідне вже є на найближчому вузлі. Усе це швидка маршрутизація, автоматичне перемикання, захист і кешування працює разом бездоганно. Ваші клієнти навіть не здогадуються про це. Вони просто бачать швидкий і надійний сайт. Ось що варто запам'ятати. Azure Front.do діє як глобальний регулювальник, спрямовуючи користувачів на швидші сервери, кешуючи контент і блокуючи атаки. Він побудований на трьох рівнях стійкості, тому навіть якщо регіон вийде з ладу, ваш сайт працюватиме. Для більшості проєктів стандартний тариф за 35 доларів на місяць – це баланс продуктивності та вартості. Переходьте на преміум, якщо потрібна розширена безпека або приватний зв'язок. Починайте з одного джерела і масштабуйтеся. Front.do зростає разом із вами.

Якщо ваш застосунок має користувачів у різних регіонах, налаштуйте профіль Front.do вже сьогодні. Навіть один сервер отримує переваги глобального прискорення та безпеки. Підписуйтесь на вашу улюблену подкаст-платформу і діліться цим із тими, хто починає свій шлях у хмари.