Licencjonowanie oprogramowania to jeden z najbardziej pomijanych czynników kosztowych w projektach migracji do chmury. Nie pojawia się w kalkulatorach cenowych AWS, jest zakopane w warunkach poszczególnych dostawców, a błąd może oznaczać sześciocyfrowe luki compliance odkryte podczas audytu. Ten post wyjaśnia, jak działa licencjonowanie przy migracji do AWS, co w praktyce oznacza Bring Your Own License (BYOL), jak serwery licencji wpisują się w architekturę chmurową i które decyzje mają największy wpływ finansowy.
Dlaczego koszty licencji zmieniają się w chmurze
Licencjonowanie on-premise jest zazwyczaj oparte na fizycznych rdzeniach, fizycznych socketach lub named users. Kupujesz serwer z 2 socketami i 16 rdzeniami, licencja pokrywa ten sprzęt. Proste.
Chmura zmienia model, ponieważ:
- Wirtualne rdzenie nie mapują się 1:1 na fizyczne rdzenie. Większość dostawców definiuje własne przeliczniki. Oracle liczy każdy vCPU jako 0,5 rdzenia na potrzeby licencjonowania na AWS (ale tylko na zatwierdzonych typach instancji). Microsoft ma inne zasady w zależności od produktu.
- Multi-tenancy komplikuje sprawy. Na współdzielonej infrastrukturze (domyślne EC2) nie kontrolujesz, na jakim fizycznym hoście działa Twoja instancja. Niektóre umowy licencyjne wymagają znajomości i deklaracji fizycznego sprzętu.
- Elastyczność konflikuje ze stałymi licencjami. Jeśli skalajesz z 4 do 16 instancji w szczycie ruchu, czy potrzebujesz licencji na 16? A co z auto-scaling groups?
- Prawa mobilności licencji różnią się między dostawcami. Niektórzy pozwalają przenosić licencje do chmury swobodnie. Inni wymagają dodatkowych umów lub ograniczają, którzy dostawcy chmury się kwalifikują.
Rezultat: to, co wyglądało na proste porównanie kosztów compute, staje się znacznie bardziej złożone po uwzględnieniu licencjonowania.
Bring Your Own License (BYOL) na AWS
BYOL oznacza wykorzystanie istniejących licencji oprogramowania na infrastrukturze AWS zamiast kupowania nowych licencji chmurowych lub korzystania z licencji wliczonych w cenę (wbudowanych w godzinową stawkę instancji).
Kiedy BYOL ma sens finansowy
BYOL jest zazwyczaj korzystne, gdy:
- Masz aktywne Software Assurance (SA) lub równoważne umowy utrzymaniowe dające prawa mobilności
- Twoje licencje nie są w pełni wykorzystane on-premise (i tak za nie płacisz)
- Cena AWS z wliczoną licencją jest znacznie droższa niż Twój obecny koszt per-core
- Uruchamiasz workloady na Dedicated Hosts z innych powodów (compliance, izolacja wydajności)
Kiedy licencja wliczona w cenę jest lepsza
Licencja wliczona (płacenie stawki godzinowej AWS zawierającej licencję) jest często lepsza, gdy:
- Nie masz istniejących licencji do przeniesienia
- Twoje workloady są małe lub zmienne (płacisz tylko za wykorzystane godziny)
- Chcesz całkowicie uniknąć śledzenia compliance licencyjnego
- Różnica kosztowa jest marginalna, a prostota operacyjna ma wartość
Kluczowe scenariusze licencyjne wg dostawcy oprogramowania
Microsoft Windows Server i SQL Server
Licencjonowanie Microsoft na AWS ma określone zasady, które bezpośrednio wpływają na koszt migracji:
Windows Server:
- Licencja wliczona: Dostępna na standardowych instancjach EC2. Dopłata za Windows jest wbudowana w stawkę godzinową (zazwyczaj 30-50% więcej niż równoważna instancja Linux).
- BYOL: Wymaga Dedicated Hosts lub Dedicated Instances. Potrzebujesz licencji Windows Server z aktywnym Software Assurance. Każdy Dedicated Host jest licencjonowany na podstawie liczby fizycznych rdzeni.
SQL Server:
- Licencja wliczona: Dostępna na RDS for SQL Server (edycje Express, Web, Standard, Enterprise). Stawka godzinowa zawiera licencję.
- BYOL na EC2: Wymaga Dedicated Hosts dla SQL Server Standard i Enterprise. Przypisujesz licencje core do fizycznego hosta. Minimum 4 licencje core na fizyczny rdzeń.
- BYOL na RDS: Dostępne w modelach “License Included” i “Bring Your Own License” w RDS. Opcja BYOL RDS obniża stawkę godzinową, ponieważ dostarczasz licencję.
Przykład wpływu na koszty: db.m5.4xlarge RDS SQL Server Enterprise (licencja wliczona) kosztuje około $5,50/h. Ta sama instancja jako RDS BYOL to około $1,40/h. Jeśli posiadasz licencje Enterprise core z SA, to ~$4 100/miesiąc oszczędności na instancję.
Oracle Database
Licencjonowanie Oracle na AWS jest notoryjnie złożone, ale opiera się na tych zasadach:
- Oracle liczy vCPU, nie fizyczne rdzenie. Każdy vCPU = 0,5 licencji procesorowej (na “Authorized Cloud Environments”, co obejmuje AWS).
- Tylko określone typy instancji są zatwierdzone. Polityka licencjonowania chmurowego Oracle określa, które typy instancji są dozwolone dla BYOL. Uruchamianie na niezatwierdzonych typach może oznaczać niezgodność licencyjną.
- Standard Edition 2 (SE2) jest ograniczone do instancji z max 8 vCPU (4 licencje procesorowe). Przekroczenie wymaga Enterprise Edition.
- Minimalna liczba Named User Plus (NUP): 10 NUP na licencję procesorową dla SE2.
Opcje na AWS:
- RDS for Oracle (licencja wliczona lub BYOL) - usługa zarządzana, ograniczona do zatwierdzonych klas instancji
- EC2 BYOL - pełna kontrola, zarządzasz bazą samodzielnie, licencja per vCPU
- Dedicated Hosts - daje widoczność liczby fizycznych rdzeni dla compliance licencyjnego
Krytyczna uwaga: Jeśli obecnie korzystasz z Oracle on-premise z umowami Unlimited License Agreement (ULA), zazwyczaj nie można ich rozszerzyć na chmurę. Sprawdź warunki ULA przed założeniem pokrycia chmurowego.
Inne popularne oprogramowanie komercyjne
- SAP: Wymaga certyfikowanych typów instancji AWS. SAP BYOL jest dobrze udokumentowany w programie SAP on AWS. Licencja jest per-user lub per-engine, nie per-core.
- Red Hat Enterprise Linux: BYOL via Dedicated Hosts lub transfer subskrypcji. Program Cloud Access pozwala używać istniejących subskrypcji na AWS.
- VMware: Cloud on AWS działa na dedykowanej infrastrukturze VMware, a istniejące licencje vSphere mogą mieć zastosowanie w zależności od umowy.
AWS Dedicated Hosts: enabler BYOL
Dedicated Hosts to fizyczne serwery alokowane wyłącznie do Twojego konta AWS. Są głównym mechanizmem zapewnienia compliance BYOL, ponieważ dają:
- Widoczność liczby fizycznych rdzeni - wymagana przez większość umów licencyjnych per-core
- Stałe rozmieszczenie na hoście - Twoje instancje zawsze działają na tym samym fizycznym sprzęcie
- Śledzenie compliance licencyjnego - AWS License Manager integruje się z Dedicated Hosts do śledzenia zużycia licencji
Implikacje kosztowe
Dedicated Hosts są rozliczane per host per godzinę, niezależnie od tego ile instancji na nich uruchamiasz. Host c5.large Dedicated (który może uruchomić wiele instancji c5.large) kosztuje tyle samo czy jest wykorzystany w 10% czy 100%.
To oznacza:
- Wysokie wykorzystanie = BYOL wygrywa. Jeśli wypełnisz Dedicated Host instancjami, koszt per-instancja spada znacznie poniżej cen z licencją wliczoną.
- Niskie wykorzystanie = licencja wliczona wygrywa. W połowie pusty Dedicated Host z licencjami BYOL jest droższy niż standardowe instancje z wliczoną licencją.
Kalkulacja progu rentowności: porównaj zamortyzowany koszt istniejącej licencji + koszt Dedicated Host ze stawką godzinową z licencją wliczoną × oczekiwane godziny.
Serwery licencji w architekturze chmurowej
Wiele produktów enterprise używa serwerów licencji (FlexLM, RLM, Sentinel, Reprise) do zarządzania pływającymi licencjami (floating licenses). Wymagają one specjalnej uwagi podczas migracji.
Wzorce architektoniczne dla serwerów licencji na AWS
Wzorzec 1: Serwer licencji na EC2 (prosty)
Uruchom serwer licencji na małej instancji EC2 (t3.medium zazwyczaj wystarcza) w prywatnej sieci. Skonfiguruj security groups, aby zezwolić na ruch check-out licencji z instancji aplikacyjnych.
Uwagi:
- Wymaga statycznego prywatnego IP (przypisz Elastic Network Interface)
- Wiele serwerów licencji używa dongli zablokowanych na MAC - działa z ENI (adres MAC przetrwa stop/start)
- Wysoka dostępność: użyj ENI, które może być przenoszone między instancjami w Auto Scaling Group o rozmiarze 1
Wzorzec 2: Serwer licencji z licencjami zablokowanymi na host
Niektórzy dostawcy blokują licencje na konkretny identyfikator sprzętu. Na AWS mapuje się to na:
- Adres MAC ENI (najbardziej elastyczne - przetrwa stop/start instancji i może być przeniesione)
- ID instancji (mniej elastyczne - traci się przy terminacji)
- Dongle USB via host-based licensing (wymaga Dedicated Host z USB passthrough - rzadkie i złożone)
Wzorzec 3: Hybrydowy serwer licencji
Pozostaw serwer licencji on-premise i pozwól instancjom chmurowym pobierać licencje przez VPN lub Direct Connect. Działa dobrze podczas migracji fazowych, gdzie część workloadów pozostaje on-premise.
Kompromisy:
- Dodaje latencję do check-out licencji (zazwyczaj akceptowalne - dzieje się przy starcie aplikacji)
- Tworzy zależność od dostępności VPN/DirectConnect
- Prostsze licencjonowanie: nie trzeba przenosić serwera licencji ani prosić dostawcę o nowe host ID
Wysoka dostępność serwera licencji
Serwery licencji są często single points of failure. On-premise jest to tolerowane, bo serwer rzadko się zmienia. W chmurze musisz projektować pod awarie instancji:
- Failover oparty na ENI: Podłącz ENI serwera licencji do Auto Scaling Group o rozmiarze 1. Jeśli instancja padnie, ASG uruchomi nową i ENI (z MAC i IP) się ponownie podłączy.
- Redundantne serwery licencji: Niektóre license managery (FlexLM) wspierają redundantne triady. Wdróż 3 instancje w różnych AZ.
- Recovery ze snapshotów EBS: Regularne snapshoty EBS wolumenu serwera licencji pozwalają na szybkie odtworzenie.
AWS License Manager
AWS License Manager to darmowa usługa pomagająca śledzić i zarządzać licencjami oprogramowania w środowisku AWS. Jest szczególnie wartościowa w scenariuszach BYOL:
- Definiowanie reguł licencyjnych - ustawianie limitów core/vCPU, ograniczeń typów instancji i wymagań tenancy
- Automatyczne wymuszanie - blokowanie uruchomień, które przekroczyłyby limity licencji
- Śledzenie zużycia - dashboard pokazujący bieżące zużycie vs. uprawnienia
- Integracja z Dedicated Hosts - automatyczne śledzenie alokacji hostów i rozmieszczenia instancji
- Wsparcie cross-account - zarządzanie licencjami w ramach AWS Organisation
Konfiguracja License Manager jest czymś, co włączamy w każdy projekt migracyjny obejmujący BYOL. To różnica między nadzieją na zgodność a wiedzą o niej.
Typowe pułapki licencyjne w migracji do chmury
1. Założenie, że licencje on-premise automatycznie się przenoszą
Większość licencji domyślnie nie przenosi się do chmury. Potrzebujesz specyficznych praw mobilności (Microsoft SA), programów cloud access (Red Hat) lub zgody dostawcy. Uruchamianie oprogramowania bez weryfikacji praw chmurowych to ryzyko compliance.
2. Ignorowanie przelicznika vCPU na rdzenie
AWS vCPU nie równa się fizycznym rdzeniom. m5.4xlarge ma 16 vCPU, ale działa na hoście z włączonym hyper-threadingiem - więc to 8 fizycznych rdzeni. Licencjonowanie na podstawie liczby vCPU, gdy umowa mówi “per core”, oznacza że możesz być over-licensed (przepłacasz) lub under-licensed (ryzyko compliance).
3. Zapominanie o auto-scalingu
Jeśli aplikacja auto-skaluje się z 2 do 10 instancji i każda potrzebuje komercyjnej licencji, potrzebujesz licencji na szczyt. To czyni BYOL ze stałymi pulami licencji mniej atrakcyjnym dla elastycznych workloadów. Rozważ licencję wliczoną dla mocno zmiennych obciążeń.
4. Brak reewaluacji podczas migracji
Migracja to najlepszy moment, by zapytać: czy nadal potrzebujemy tego oprogramowania? Czy PostgreSQL może zastąpić Oracle dla tego obciążenia? Czy Linux może zastąpić Windows Server dla tej usługi? Re-platforming na alternatywy open source eliminuje koszty licencyjne całkowicie.
5. Pominięcie kalkulacji wykorzystania Dedicated Host
BYOL na Dedicated Hosts oszczędza pieniądze tylko przy wysokim wykorzystaniu. Dedicated Host z 2 małymi instancjami, gdy mógłby zmieścić 16, marnuje koszt hosta na zbyt mało workloadów. Konsoliduj workloady per host, aby zmaksymalizować korzyść finansową.
Framework decyzyjny: licencja wliczona vs. BYOL
Użyj tego frameworka do oceny każdego obciążenia:
Jak licencjonowanie wpisuje się w model kosztowy migracji
Gdy dostarczamy migrację do chmury, analiza licencyjna jest częścią początkowej fazy oceny. Mapujemy każdy komponent oprogramowania komercyjnego, weryfikujemy prawa chmurowe i modelujemy koszty w różnych scenariuszach (BYOL vs. licencja wliczona vs. re-platforming na open source).
Dla większości migracji SMB odpowiedź jest prosta: używaj licencji wliczonej dla Windows i SQL Server, chyba że masz duże wdrożenia z istniejącym SA. Dla migracji enterprise z Oracle, SAP lub dużymi środowiskami Microsoft, sama analiza licencyjna może zidentyfikować sześciocyfrowe roczne oszczędności dzięki właściwej strategii BYOL.
Decyzja licencyjna wpływa również na architekturę:
- BYOL Oracle może wymusić Dedicated Hosts → wpływa na rozmieszczenie instancji i projekt dostępności
- Re-platforming z SQL Server na PostgreSQL eliminuje licencjonowanie całkowicie → wymaga zmian w aplikacji, ale redukuje długoterminowe TCO
- Migracja z Windows na Linux usuwa 30-50% dopłatę za Windows → możliwe dla aplikacji .NET działających na .NET 6+ (cross-platform)
Jak możemy pomóc
Analiza licencyjna jest zawarta w każdej ocenie migracji do chmury, którą dostarczamy. Identyfikujemy oprogramowanie komercyjne w Twoim środowisku, weryfikujemy prawa chmurowe z każdym dostawcą, modelujemy scenariusze kosztowe i rekomendujemy optymalną strategię. Dla złożonych środowisk Microsoft lub Oracle współpracujemy ze specjalistami ds. licencjonowania chmurowego dostawców, aby potwierdzić zgodność przed rozpoczęciem migracji.
Jeśli planujesz migrację i nie jesteś pewien, jak Twoje obecne licencje przenoszą się do chmury - to dokładnie ten rodzaj pytania, na który odpowiadamy w fazie oceny.
Nie wiesz, jak wyglądają koszty licencji na AWS?
Umów bezpłatną 30-minutową rozmowę. Omówimy Twoje oprogramowanie i zidentyfikujemy najlepszą strategię licencyjną dla migracji.
FAQ
Czy mogę używać istniejących licencji Windows Server na AWS?
Tak, ale tylko na Dedicated Hosts lub Dedicated Instances i tylko jeśli Twoje licencje mają aktywne Software Assurance. Standardowe instancje EC2 używają współdzielonego sprzętu, gdzie BYOL Windows nie jest dozwolone przez warunki Microsoft. Dla większości małych wdrożeń opcja z licencją wliczoną (płacenie dopłaty za Windows per godzinę) jest prostsza i często tańsza.
Jaka jest różnica między licencją wliczoną a BYOL na RDS?
Licencja wliczona oznacza, że koszt licencji oprogramowania jest wbudowany w stawkę godzinową RDS. BYOL oznacza, że dostarczasz własną licencję i płacisz obniżoną stawkę godzinową tylko za zarządzaną infrastrukturę. BYOL na RDS jest dostępne dla Oracle i SQL Server i wymaga utrzymywania ważnych licencji niezależnie.
Czy do każdego scenariusza BYOL potrzebuję Dedicated Hosts?
Nie. Niektóre produkty (jak Oracle na RDS BYOL czy niektóre subskrypcje Red Hat) mogą być używane na współdzielonej infrastrukturze. Jednak licencje per-core lub per-socket dla Windows Server i SQL Server zazwyczaj wymagają Dedicated Hosts, ponieważ musisz znać i zadeklarować fizyczny sprzęt. Zawsze weryfikuj z polityką licencjonowania chmurowego konkretnego dostawcy.
Co dzieje się z licencjami Oracle przy migracji do AWS?
Oracle zezwala na BYOL na AWS w ramach polityki “Authorized Cloud Environment”. Każdy vCPU liczy się jako 0,5 licencji procesorowej. Tylko określone typy instancji są zatwierdzone. Standard Edition 2 jest ograniczone do 8 vCPU. Jeśli masz Unlimited License Agreement (ULA), sprawdź czy obejmuje wdrożenia chmurowe - większość domyślnie nie.
Czy taniej jest zrobić re-platforming na open source niż przenosić licencje do chmury?
Często tak - w perspektywie długoterminowej. Migracja z SQL Server do PostgreSQL lub z Oracle do Aurora PostgreSQL eliminuje koszty licencyjne całkowicie. Kompromis to nakład pracy na migrację: konwersja schematu, przepisanie zapytań, testy aplikacji. Dla dużych środowisk Oracle porównanie TCO na 2-3 lata prawie zawsze faworyzuje re-platforming, ale wymaga inwestycji w samą migrację.
