BYOC (Bring Your Own Cloud)
BYOC (Bring Your Own Cloud) — це модель, за якої клієнт підключає свій наявний обліковий запис хмарного провайдера замість міграції на власну інфраструктуру постачальника або обліковий запис реселера. Обліковий запис, контракт і відносини з оплати впродовж усього часу залишаються між клієнтом і провайдером; постачальник керує ресурсами всередині нього, а не володіє ними.
BYOC визначає, кому юридично належить хмарний обліковий запис, у якому працює інфраструктура, а не хто керує нею щодня. У моделі BYOC організація зберігає власний обліковий запис у хмарного провайдера — Amazon Web Services, Google Cloud, Hetzner чи будь-якого іншого — разом із контрактом і рахунками, що до нього додаються. Окремому постачальнику, наприклад платформі управління, інструменту моніторингу або провайдеру керованих послуг, надається обмежений доступ для роботи всередині цього облікового запису: розгортання ресурсів, застосування конфігурації або збір телеметрії. Базові обчислювальні потужності, сховище чи мережа нікуди не переміщуються. Термін виник у контексті керованих баз даних і SaaS, де «bring your own cloud» відрізняє розгортання, яке працює всередині облікового запису клієнта, від розгортання, повністю розміщеного на власній інфраструктурі постачальника.
Альтернативою є повністю керована модель або модель реселера, за якої постачальник має власний обліковий запис у базового провайдера і або перепродає потужності клієнтам, або переносить їхні навантаження на інфраструктуру, якою повністю володіє сам. Така модель може спростити оплату — один постачальник, один рахунок — але це також означає, що інфраструктура клієнта існує всередині чужого облікового запису. Зміна постачальника, безпосередні переговори щодо цін провайдера або доведення аудитору, яка саме юридична особа тримає базовий контракт, стають складнішими. BYOC зберігає цю межу непорушною: клієнт може в будь-який момент відкликати доступ постачальника на рівні провайдера, а базовий обліковий запис, історія оплати та статус відповідності вимогам ніколи не переходять до інших рук.
На практиці доступ BYOC надається через облікові дані API або роль, яку постачальник отримує всередині облікового запису клієнта, обмежену тим, що йому дійсно потрібно, і яку можна відкликати незалежно від самих відносин із постачальником. Компроміс тут операційний: саме клієнт, а не постачальник, залишається стороною контракту з кожним хмарним провайдером, тож кілька провайдерів означають кілька контрактів і рахунків, якщо щось на рівні вище облікового запису їх не консолідує. Постачальники, які підтримують BYOC, зазвичай підтримують і протилежну модель — розгортання та оплату потужностей під власним обліковим записом від імені клієнта, — тож організація може поєднувати обидві моделі залежно від того, які ресурси вона хоче тримати під прямим контрактом з провайдером, а які готова повністю делегувати.
Чому BYOC має значення
Прив'язка до постачальника (lock-in) — це головний ризик, який вирішує BYOC. Коли інфраструктура перебуває всередині власного облікового запису постачальника, відмова від нього означає перенесення навантажень — проєкт, який вимірюється тижнями чи місяцями, а не одним запитом у підтримку. BYOC перетворює вихід на зміну прав доступу: досить відкликати облікові дані постачальника — і інфраструктура залишається точно там, де була, за тим самим контрактом. Це має найбільше значення там, де вагу для відповідності вимогам має саме базовий обліковий запис, а не лише дані, — у регульованих галузях, де конкретна юридична особа повинна залишатися прямою стороною контракту з провайдером інфраструктури від імені контролера даних, або в правилах державних закупівель, які вимагають, щоб організація-покупець мала власний контракт із хмарним провайдером, а не субконтракт. Це також зберігає будь-які знижки за обсягом чи корпоративну угоду, які організація вже безпосередньо узгодила зі своїм хмарним провайдером.
Як Sencai працює з BYOC
Sencai підтримує BYOC як одну з двох моделей, що можуть співіснувати в межах однієї організації. Підключіть наявний обліковий запис — і нічого не переміщується: облікові дані зашифровані в стані спокою, ви можете в будь-який момент відкликати доступ на рівні провайдера, а в момент підключення облікового запису Sencai одразу інвентаризує все, що вже працює, — інстанси, мережі, сховища, DNS — у всіх підключених провайдерів, із можливістю вибіркового переходу на активне управління для кожного ресурсу окремо. Обліковий запис, контракт і рахунки увесь час залишаються за вашим провайдером. Якщо ви не хочете тримати прямий контракт із провайдером, Sencai може замість цього розгортати й оплачувати потужності під власним обліковим записом — один рахунок, вартість провайдера плюс маржа 2%, зазначена окремим рядком у виписці, — і ви можете поєднувати обидві моделі залежно від потреб.
Дізнайтеся, як працює інвентаризація та розгортання →