Посібник з ціноутворення для зовнішніх ідентифікацій у Microsoft Entra

By Mirko Peters · 2026-04-29 · Updated 2026-07-28

Дізнайтеся про ціноутворення для зовнішніх ідентифікацій у Microsoft Entra: практичні рекомендації щодо архітектури, безпеки, управління, впровадження та реального використання.

Automatically translated with AI from the original post. Read the English original

Ціноутворення для зовнішніх ідентифікацій у Microsoft Entra базується на кількості активних користувачів на місяць і на службах, які використовує ваш сценарій для клієнтів, партнерів або гостей. Щоб оцінити вартість, визначте тип ідентифікації, очікувану кількість активних користувачів на місяць, методи автентифікації та будь-які вимоги до преміальних функцій безпеки чи підтримки. Завжди перевіряйте актуальну пропозицію та регіональні ціни, перш ніж затверджувати архітектуру або бюджет.

Якщо ви зараз впроваджуєте Microsoft Entra ID для зовнішніх користувачів, напевно, уже зіткнулися з питанням ціни. Ціноутворення для зовнішніх ідентифікацій у Entra — це не дрібниця з примітки, а ключова тема в кожній розмові про доступ, співпрацю та безпеку сучасних організацій. Насправді ви платите за те, how often ваші зовнішні користувачі працюють із вашими ресурсами, а це відстежується за моделлю оплати за активних користувачів на місяць (MAU).

Розуміння того, як Entra рахує користувачів, пов’язує клієнти з підписками та підсумовує методи автентифікації, є обов’язковим для ІТ-адміністраторів і керівників проєктів. Хибні припущення можуть призвести до несподіваного рахунку або підірвати вашу стратегію управління користувачами. Кожен вхід і кожна конфігурація клієнта може змінити операційні витрати, тож знання правил заздалегідь дає змогу планувати, бюджетувати та масштабувати без неприємних сюрпризів.

Як працює модель зовнішньої оплати в Entra ID

Основа моделі зовнішньої оплати Microsoft Entra ID — це MAU, або активний користувач на місяць. Entra ID не ліцензує кожен зовнішній контакт, а стягує плату лише з тих осіб, які справді входять в обліковий запис або інакше проходять автентифікацію протягом місяця. Такий підхід допомагає організаціям узгоджувати витрати з реальним використанням і робить прогнози вартості значно передбачуванішими.

Entra ID застосовує цінові рівні залежно від кількості MAU. Менші організації можуть залишатися в безкоштовному рівні, який покриває визначену кількість зовнішніх MAU на місяць. Коли використання зростає, витрати на зовнішні ідентифікації переходять до платних діапазонів, а ціна за користувача трохи знижується зі зростанням обсягу. Модель пропонує низку функцій на різних рівнях, зокрема базову автентифікацію та самообслуговування скидання пароля, а преміальні функції доступні на вищих рівнях.

Платіжні цикли в Entra ID зазвичай тривають один місяць і збігаються зі скиданням MAU. Кожен цикл враховує, хто виконав кваліфіковану автентифікацію, незалежно від того, скільки разів ця людина входила протягом місяця. Ваш рахунок відображає пікову кількість унікальних активних користувачів у будь-який період, тож один активний користувач, який зробив десять входів, усе одно рахується як один і впливає на витрати лише один раз. Організації можуть відстежувати ці закономірності в реальному часі, що спрощує планування піків навантаження чи сезонних кампаній і відповідне моделювання бюджетів.

Зрештою, ця модель оплати заохочує уважне відстеження закономірностей автентифікації, налаштування клієнта та використання функцій. Розуміння того, як активність перетворюється на нарахування, дає змогу оптимізувати як досвід користувачів, так і витрати, плануючи зростання та тримаючи фінансовий результат під контролем.

Що вважається активним користувачем на місяць для входів і оплати

У світі Entra ID не кожен «користувач» підлягає оплаті: важливі лише ті, кого визнано активним користувачем на місяць (MAU) для цього платіжного циклу. Тож що вмикає лічильник? MAU — це будь-яка зовнішня ідентифікація, яка успішно проходить автентифікацію в вашому клієнті Entra протягом місяця. Це стосується і стандартного входу за іменем користувача та паролем, і одноразових кодів (OTP), і входу через соцмережі, і федеративних постачальників.

Щоразу, коли користувач завершує нову автентифікацію, тобто виконує свіжий вхід або будь-яку дію, яка вимагає повторного введення облікових даних, Entra це фіксує. Але ось важлива деталь: повторні входи чи відновлені сеанси в межах того самого місяця не створюють додаткових витрат для тієї самої особи. Навіть якщо користувач заходить десяток разів, це все одно один MAU, а не дванадцять, і це захищає вас від неконтрольованих рахунків у дні активності.

Деякі події можуть здаватися такими, що мали б враховуватися, але не завжди змінюють лічильник MAU. Наприклад, відновлення сеансів за допомогою токенів оновлення або події тихого SSO, які не передбачають повної повторної автентифікації користувача, зазвичай не збільшують лічильник MAU, якщо відбуваються в межах тієї самої комбінації «користувач/місяць». Так само, якщо гість переходить між кількома застосунками в одному клієнті, зараховується лише його перша кваліфікована автентифікація.

Варто також зазначити, що соціальні входи, OTP та федеративна автентифікація враховуються так само, як і звичайні входи, коли взаємодіють із вашим клієнтом. Однак користувачі, які працюють у кількох клієнтах, мусять автентифікуватися окремо в кожному з них. Тож якщо зовнішні ідентичності працюють між клієнтами, та сама електронна адреса може з’являтися як кілька MAU (по одному на кожен клієнт). Розуміння цих особливостей заздалегідь допомагає уникнути несподіванок і дає змогу спланувати потоки ідентифікації з оглядкою на витрати.

Ефективне пов’язування зовнішніх клієнтів із передплатами Azure

Щоб мати зрозумілу та прозору тарифікацію і тримати зовнішні ідентичності Entra ID під надійним контролем, потрібно переконатися, що кожен зовнішній клієнт належно пов’язаний із передплатою Azure. Цей зв’язок виконує роль містка для тарифікації, керування життєвим циклом і загальної адміністративної ясності.

Правильно налаштований зв’язок між зовнішнім клієнтом і передплатою Azure робить витрати відстежуваними та передбачуваними. Без такого налаштування відстежувати нарахування, виставляти внутрішні перерозподіли витрат і запобігати «осиротілим» ресурсам дуже швидко стає кошмаром. Якщо все зроблено правильно, пов’язування дає бізнесу цілісне уявлення про активність зовнішніх користувачів, ресурси, які вони використовують, і те, на кого лягають ці витрати.

Зі зростанням вашої інфраструктури ідентифікацій, особливо між проєктами чи кількома бізнес-підрозділами, упорядковані зв’язки між клієнтами та передплатами підтримують підзвітність і управління. Вони допомагають помітити перетин доступів, прибрати невикористовувані ідентичності та швидше реагувати на проблеми. Далі ми розберемо покроковий процес пов’язування клієнтів і усунення несправностей, якщо передплата не відображається, щоб ви були готові як до проактивних дій, так і до виправлення наслідків пропущеного з’єднання.

Кроки для пов’язування зовнішнього клієнта з передплатою

1. Увійдіть на портал Azure як глобальний адміністратор або власник цільової передплати. Для внесення змін на рівні передплати потрібна відповідна роль.
2. Перейдіть до розділу Azure Active Directory, а потім перемкніться на клієнта, який хочете пов’язати як зовнішнього.
3. У клієнті перейдіть до Subscriptions і виберіть Add або Associate. Оберіть передплату Azure, яку хочете пов’язати.
4. Підтвердіть пов’язування та призначте необхідні дозволи, щоб адміністратори могли керувати тарифікацією та налаштуваннями як для клієнта, так і для пов’язаної передплати.
5. Після пов’язування ще раз перевірте дані про тарифікацію та рахунки в розділі Cost Management + Billing. Це допоможе вчасно помітити помилки в налаштуваннях, поки вони не спричинили проблем.

Усунення несправностей: що робити, якщо клієнт не пов’язаний із передплатою?

• Перевірте стан клієнта: переконайтеся на порталі Azure, що клієнт справді не має передплати, а не лише некоректно відображається. Для цього перегляньте Subscription ID для вашого клієнта Entra.
• Призначте передплату: якщо зв’язку немає, використайте адміністративні права, щоб пов’язати клієнта з дійсною передплатою в розділі Cost Management + Billing. Шукайте опцію «Link tenant».
• Проблеми з дозволами: переконайтеся, що маєте потрібну адміністративну роль (Owner, Billing Administrator), щоб уникнути помилок доступу під час пов’язування.
• Вирішіть конфлікти власності: якщо клієнт не вдається пов’язати, перевірте попередні зв’язки чи передачі, а за стійких проблем зверніться до служби підтримки Microsoft.

Методи автентифікації та їх вплив на ціноутворення Entra ID

Коли йдеться про зовнішні ідентичності в Entra ID, спосіб автентифікації користувачів безпосередньо впливає на суму до сплати. Комбінація варіантів входу, будь то одноразові коди (OTP), соціальні входи, звичайні логін і пароль, OpenID Connect чи вхід через нативні застосунки, визначає, хто зараховується як платний MAU і коли саме.

Не всі способи входу однакові з погляду безпеки та вартості. Для організацій, які прагнуть і зручного досвіду гостьових користувачів, і контролю над бюджетом, кожен метод несе свої компроміси. Соціальні входи можуть спростити доступ, але іноді ускладнюють керування життєвим циклом. OTP простий, проте може призводити до повторного використання автентифікації чи зростання кількості звернень до підтримки. OpenID Connect і нативні для браузера потоки відкривають ширші інтеграції, але змінюють і характер взаємодії користувачів, і розмір рахунку.

Розуміти ці відмінності вкрай важливо, особливо тому, що атаки на ідентичності та ризики безпеки виникають через складні сценарії автентифікації. Щоб глибше розібратися в ризиках, пов’язаних з ідентичностями, і практичних способах керування складними потоками доступу в Entra, ознайомтеся з детальним розглядом умовного доступу та управління.

Далі розберемо, які витрати несуть різні сценарії автентифікації, щоб ви могли проєктувати потоки ідентифікації, які враховують і потреби користувачів, і бюджет.

Використання OTP і соціальних входів: наслідки для ціноутворення

• Входи через OTP: Кожна успішна автентифікація за допомогою одноразового коду (наприклад, електронною поштою або SMS) зараховується як один MAU за місяць. Якщо користувач входить через OTP кілька разів на місяць, це все одно один MAU, але кожна перша автентифікація в кожному періоді запускає нарахування.
• Соціальні постачальники ідентифікації: Входи через популярні сервіси, як-от Google, Facebook чи LinkedIn, реєструють користувача як MAU, щойно він отримує доступ до ресурсу. Наступні входи того самого місяця повторно не враховуються, але використання різних соціальних облікових записів для однієї й тієї самої електронної адреси може призвести до появи нових MAU.
• Нестандартні випадки: Якщо зовнішній користувач переходить між клієнтами (наприклад, у вас є дочірні компанії), кожен унікальний вхід у інший клієнт запускає ще один MAU, тож об’єднання та консолідація ідентичностей там, де це можливо, може знизити ваші витрати.

Сценарії OpenID Connect, нативних застосунків і автентифікації в браузері

• OpenID Connect (OIDC): Коли користувачі автентифікуються через OIDC, кожен успішний перший вхід у місячному циклі є одним MAU. Втім, OIDC підтримує оновлювані токени, тож поки токени дійсні і сеанси не завершилися, користувач не зараховується повторно як новий MAU.
• Автентифікація в нативних застосунках: Застосунки, які використовують нативні бібліотеки Entra ID (наприклад, MSAL), діють за подібними правилами: перша автентифікація зараховується, а тихе оновлення токена — ні. Різні застосунки в одному клієнті не створюють додаткових MAU, якщо користувач залишається активним.
• Потоки в браузері: Сеанси в браузері можуть бути непередбачуваними: очищення cookie або завершення сеансів може примусити до повторної автентифікації, що може виглядати як нові MAU, якщо це відбувається в новому календарному місяці. Усвідомлення цього допоможе краще керувати сеансами та витратами.

Порівняльна таблиця: ціни Entra External ID і Azure AD B2C

• Модель ціноутворення: Entra External ID використовує рівні на основі MAU, тобто організації платять лише за унікальних активних користувачів за місяць. Azure AD B2C раніше基于 transactions або витрат за кожну автентифікацію, хоча останні моделі перейшли на MAU для спрощення.
• Включені функції: Обидва сервіси на базовому рівні пропонують скидання пароля самостійно, багатофакторну автентифікацію та керування користувачами. Entra External ID, як правило, глибше інтегрується з Microsoft 365, тоді як B2C орієнтований на сценарії для клієнтів із настроюваними користувацькими сценаріями.
• Варіанти підтримки: Підтримка Entra External ID є частиною основних каналів підтримки Microsoft. B2C має власні рівні підтримки, але для відповідей із гарантією SLA може знадобитися преміум-план.
• Сценарії використання: Entra External ID найкраще підходить для взаємодії між бізнесами (B2B), партнерів або гостьової співпраці (особливо в екосистемах M365/Azure). Azure AD B2C краще підходить для застосунків «бізнес для клієнта» (B2C), яким потрібні білий брендинг і гнучкі шляхи входу.
• Питання міграції: Перехід із B2C на Entra ID потребує ретельного зіставлення ідентичностей, але дає жорсткіше керування та водночас ризик прив’язки до постачальника. Щодо міграції шукайте рекомендації щодо залежності від постачальника та поетапного розгортання.

Найкращі практики оптимізації витрат у сценаріях із великим навантаженням

Якщо ваша організація обслуговує великі потоки людей або кількість зовнішніх користувачів раптово зростає за ніч, наприклад під час конференцій, роздрібних заходів чи швидкого запуску проєктів, ви знаєте, наскільки неприємними бувають непередбачувані рахунки. Хоча модель оплати зовнішніх користувачів в Entra ID є справедливою, ризик залишається, якщо не налаштувати як слід керування сеансами та потоки автентифікації.

Продумане налаштування строків дії токенів, політик оновлення та тайм-аутів простою значно допомагає стабілізувати кількість MAU. Продовжуючи сеанси та обережно повторно використовуючи токени, ви запобігаєте тому, що один надто активний гість розбалансує ваш рахунок через часті непотрібні входи. Це особливо актуально в середовищах із мобільними застосунками, B2B або гібридними сценаріями використання.

Гібридні сценарії, у яких одна й та сама людина є і «внутрішнім співробітником», і «зовнішнім гостем», потребують особливої уваги. Якщо архітектуру побудувати неправильно, можна подвійно сплачувати за послуги: цього користувача буде враховано і як ліцензований внутрішній ідентифікатор, і як зовнішній MAU. Узгоджене зіставлення рахунків для виставлення рахунків і призначення ролей зберігає точність обліку та заощаджує гроші, коли ролі змінюються.

Організаціям, які прагнуть до фінансової дисципліни, критично важливі такі підходи, як chargeback, showback і централізоване управління. Вони дають змогу прозоро розподіляти витрати та підвищують відповідальність між підрозділами. Щоб дізнатися більше про управління та обмеження моделей showback у реальних середовищах Microsoft 365, ознайомтеся з детальним оглядом відповідальності за витрати та важливістю керованого управління Azure. Далі ми розберемо практичні деталі управління сеансами, токенами та гібридною ідентифікацією.

Стратегії управління сеансами та токенами для зменшення MAU

• Оптимізуйте тайм-аути сеансів: Встановлюйте тривалість сеансів так, щоб користувачі не виходили з системи занадто часто. Так зменшується кількість нових MAU через повторну автентифікацію.
• Політики повторного використання токенів: Там, де це дозволяє безпека, використовуйте довші строки дії токенів оновлення. Користувачі залишаються в системі, а кожен із них враховується лише один раз на місяць.
• Налаштування тайм-ауту бездіяльності: Уникайте надто жорстких тайм-аутів бездіяльності, які змушують користувачів повторно входити в систему. У поєднанні з кількома клієнтами це безпідставно збільшує кількість MAU.
• Моніторте шаблони входу: Використовуйте звіти, щоб виявляти зайві або непотрібні входи, і налаштовуйте конфігурацію відповідно до реальної поведінки користувачів.

Керування гібридними потоками користувачів для уникнення подвійного виставлення рахунків

• Призначення на основі ролей: Чітко визначте та дотримуйтесь правил, коли користувач вважається «внутрішнім», а коли «зовнішнім», щоб не сплачувати двічі за одну й ту саму людину.
• Єдині сховища ідентифікаторів: Де це можливо, використовуйте одне джерело істини для ідентифікаторів, бажано в Azure AD/Entra, щоб запобігти дублюванню записів у різних середовищах.
• Автоматизовані групові політики: Використовуйте динамічні групи та автоматичні призначення в Entra, щоб змінювати статус і права користувача зі зміною його ролі.
• Аудит рахунків: Плануйте регулярні перевірки на предмет перетинів облікових записів або переходів між ролями та виправляйте їх, поки вони не збільшили ваш рахунок.

Висновок: головне та контрольний список впровадження ціноутворення Entra ID

Якщо ви працюєте із зовнішніми ідентифікаторами в Entra ID, добре продумана стратегія допоможе і бюджету, і керівництву. Ось ключові висновки та практики з реальних проєктів, які полегшать вашу роботу, а фінансистів зроблять значно спокійнішими:

1. Розумійте модель оплати: Оплата здійснюється за кількістю активних користувачів на місяць (MAU). Кожен унікальний зовнішній користувач, який входить у систему протягом місяця, враховується, тож більше входів означає більші витрати. Стежте за тим, що збільшує ваш MAU.
2. Керуйте прив'язкою клієнтів і підписок: Переконайтеся, що кожен зовнішній клієнт прив'язаний до правильної підписки Azure. Помилки тут можуть призвести до втрати даних про використання або несподіваних нарахувань.
3. Обирайте методи автентифікації обдумано: Не всі входи однакові. Одноразові коди на електронну пошту можуть збільшувати витрати через плату за доставку або звернення до служби підтримки, тоді як входи через соціальні мережі чи федеративні ідентифікатори можуть заощадити кошти в сценаріях із великим обсягом.
4. Оптимізуйте налаштування сеансів і токенів: Коригуйте тривалість сеансу та тайм-аути бездіяльності, щоб не збільшувати MAU через непотрібні повторні входи. Повторне використання токенів тут допоможе скоротити зайвих «активних» користувачів.
5. Плануйте гібридні потоки та точні ролі користувачів: Стежте за користувачами, які переходять між внутрішніми та зовнішніми статусами. Легко випадково подвійно виставити рахунок, якщо потоки не впорядковані, а категорії не чіткі.

Тримайте цей контрольний список під рукою, коли впроваджуєте або налаштовуєте зовнішні ідентифікатори Entra ID. Правильні рішення сьогодні означають менше сюрпризів у рахунках і simpler розмови про бюджет у майбутньому.

Вам також варто послухати

Якщо ви досліджуєте ціноутворення для зовнішніх ідентифікаторів Microsoft Entra, ці епізоди додадуть практичного контексту щодо безпеки ідентифікацій, управління, контролю доступу та операцій у Microsoft 365:

• Privileged Identity Management – Simply Explained — Розберіться з привілеями за потребою (just-in-time), погодженнями та переглядом доступу.
• Conditional Access – Simply Explained — Дізнайтеся, як політики з урахуванням контексту захищають користувачів і пристрої.
• Microsoft Defender XDR – Simply Explained — Поєднайте сигнали з ідентичностей із виявленням, розслідуванням і реагуванням.
• Microsoft Teams Governance – The Illusion of Control — Побачте, як governance формує відповідальність і повторювані механізми контролю.

Як оцінити вартість Microsoft Entra External Identities

1. Визначте сценарій: співпраця з гостями для співробітників, клієнтські ідентичності чи доступ партнерів.
2. Оцініть кількість активних користувачів на місяць, а не загальну кількість зареєстрованих облікових записів.
3. Складіть перелік вимог до входу, безпеки, брендингу, застосунків і підтримки, які можуть вплинути на дизайн.
4. Перш ніж обирати модель витрат, уточніть у Microsoft актуальну пропозицію, валюту, регіон і умови.

Скористайтеся офіційною сторінкою цін Microsoft Entra та документацією Microsoft Learn для External ID, щоб перевірити актуальний обсяг продукту. Ціни й умови можуть змінюватися, тож не використовуйте стару оцінку як основу для закупівельного рішення.

Чинники вартості external identities, які варто задокументувати

Поширені запитання

Чим зовнішня ідентичність відрізняється від гостьового облікового запису?

External identities — це ширша сфера можливостей Microsoft Entra для людей поза робочим клієнтом. Гостьовий доступ — типовий сценарій співпраці в межах цієї ширшої моделі зовнішнього доступу.

Чи можна спланувати вартість за кількістю надісланих запрошень?

Ні. Самі лише запрошення не показують, скільки користувачів справді автентифікуватимуться. Змоделюйте очікувану кількість активних користувачів на місяць і перевірте актуальні умови ціноутворення.

Востаннє перевірено: липень 2026.

🎧 Вам також варто послухати

• Управління ідентифікацією в Microsoft Entra

  Дізнайтеся, як відповідальність, перегляд доступу та засоби контролю життєвого циклу доповнюють рішення щодо вартості Microsoft Entra External Identities.

• Microsoft Entra Private Access – простими словами

  Ознайомтеся з пов'язаним патерном доступу Entra та архітектурними питаннями, що формують безпечні служби ідентифікації.

• Умовний доступ для гостей у Microsoft Entra ID

  Цей практичний посібник допомагає поєднати планування витрат на зовнішніх користувачів із засобами безпеки, потрібними для гостьового доступу.