Azure Virtual Desktop vs RDS — porównanie pulpitów zdalnych [2026]

Wstęp / TLDR

Azure Virtual Desktop i klasyczne Remote Desktop Services rozwiązują podobny problem: dają pracownikom dostęp do aplikacji oraz pulpitu Windows poza lokalnym komputerem. Różnica zaczyna się tam, gdzie kończy się sam protokół zdalny. AVD jest usługą chmurową, w której Microsoft utrzymuje warstwę brokera, bram, dostęp webowy i integrację z Azure; Państwo projektują host poole, obrazy, profile użytkowników, sieć, zabezpieczenia oraz koszty zużycia. RDS jest rolą Windows Server, najczęściej uruchamianą lokalnie lub w prywatnym centrum danych, gdzie po Państwa stronie zostaje RD Connection Broker, RD Session Host, RD Gateway, RD Web Access, RD Licensing Server, kopie zapasowe i wysoka dostępność. W 2026 roku wybór nie sprowadza się do pytania, co jest nowsze. Dla organizacji z Microsoft 365 E3, E5, A3, A5 albo Business Premium AVD bywa naturalnym kierunkiem, bo prawa użytkownika są już częścią subskrypcji, a płaci się za zużycie Azure. Firmy z przewidywalnym obciążeniem, własną serwerownią i licencjami Windows Server nadal mogą uzyskać niższy koszt jednostkowy w RDS. W praktyce architekt powinien porównać cenę VM, profil użytkownika, SLA, DR, GPU, opóźnienia i model tożsamości. W artykule porównujemy oba modele dla 50 użytkowników, 8 godzin dziennie, z perspektywy CIO oraz architekta IT. Przy okazji warto uporządkować bazę licencji: Microsoft 365 i Windows Server mają tu różne role.

AVD vs RDS — architektura

Azure Virtual Desktop to usługa DaaS oparta o Azure, ale nie jest zwykłym „serwerem RDP w chmurze”. Microsoft dostarcza kontrolną warstwę usługi: brokery sesji, bramy dostępu, endpointy webowe, zarządzanie połączeniami i integrację z Entra ID. Państwa zespół utrzymuje hosty sesji, obrazy systemu, aplikacje, profile, sieć wirtualną, polityki bezpieczeństwa i budżet. Najczęściej hostami są maszyny z Windows 11 Enterprise multi-session, czyli edycją przeznaczoną specjalnie dla AVD. Pozwala ona uruchamiać wiele jednoczesnych sesji użytkowników na klienckim systemie Windows.

Typowa architektura AVD składa się z host poola, grup aplikacji, workspace, hostów sesji, profili FSLogix oraz integracji z tożsamością. Host pool można traktować jako logiczną farmę maszyn, które przyjmują sesje użytkowników. W trybie pooled wielu użytkowników współdzieli hosty i wraca do swojego środowiska dzięki kontenerom profili FSLogix. W trybie personal użytkownik ma przypisany konkretny pulpit, co bywa potrzebne dla stanowisk deweloperskich, aplikacji CAD, narzędzi finansowych lub wymagań audytowych. FSLogix zapisuje profil użytkownika w kontenerze VHD lub VHDX, zwykle na Azure Files, Azure NetApp Files albo udziale SMB z odpowiednimi uprawnieniami. Dzięki temu profil nie „przykleja się” do jednej maszyny, a użytkownik może przechodzić między hostami bez utraty konfiguracji Outlooka, Teams, cache przeglądarki czy ustawień aplikacji.

W AVD nie instaluje się własnego RD Gateway ani RD Web Access. To ważne operacyjnie. Nie trzeba aktualizować publicznej bramy RDP, projektować pary brokerów ani wystawiać portu 3389 do Internetu. Dostęp odbywa się przez klienta Remote Desktop lub przeglądarkę, a ruch kontrolny przechodzi przez usługę Microsoft. Z punktu widzenia bezpieczeństwa łatwiej wymusić MFA, Conditional Access, urządzenia zgodne z Intune oraz zasady Zero Trust. Z punktu widzenia finansów trzeba jednak pilnować automatycznego skalowania, godzin pracy, typów VM, kosztu dysków, storage profili, transferu i ewentualnych licencji aplikacji. Sama subskrypcja Microsoft 365 nie sprawia, że maszyny Azure są darmowe.

Remote Desktop Services w Windows Server 2022 i Windows Server 2025 ma bardziej klasyczną, modułową architekturę. Rdzeniem jest RD Session Host, czyli serwer, na którym działają sesje użytkowników i aplikacje RemoteApp. RD Connection Broker rozdziela użytkowników między hosty, obsługuje ponowne połączenia i kolekcje. RD Gateway publikuje dostęp przez HTTPS, dzięki czemu użytkownik z Internetu nie łączy się bezpośrednio do RDP. RD Web Access udostępnia portal z aplikacjami i pulpitami. RD Licensing Server wydaje oraz śledzi licencje RDS CAL. W większych środowiskach dochodzą bazy SQL dla brokera, load balancing, certyfikaty, segmentacja sieci, osobna strefa DMZ oraz procesy aktualizacji.

Model licencjonowania

Licencjonowanie jest obszarem, w którym AVD i RDS różnią się najbardziej. W AVD prawo użytkownika do korzystania z usługi może być zawarte w wybranych planach Microsoft 365, Windows Enterprise i edukacyjnych. W praktyce dla średniej firmy najczęściej mówimy o Microsoft 365 E3, Microsoft 365 E5, Microsoft 365 Business Premium, a w edukacji A3 lub A5. To nie kasuje kosztu Azure, ale upraszcza prawo dostępu do pulpitu Windows 11 Enterprise multi-session. W RDS nadal potrzebują Państwo licencji Windows Server, licencji dostępowych Windows Server CAL oraz dodatkowych RDS CAL w wariancie per-user albo per-device. Jeśli firma używa lokalnego Active Directory i serwerów aplikacyjnych, te składniki często już istnieją, ale warto policzyć je jawnie.

W KluczeSoft.pl często widzimy, że realny problem nie leży w samej technologii pulpitu, ale w rozjechaniu warstwy prawnej i technicznej. Przykładowo organizacja kupuje Windows Server, uruchamia RDS dla księgowości, lecz zapomina, że zwykłe CAL serwerowe nie są tym samym co RDS CAL. Przed migracją warto zrobić tabelę użytkowników, urządzeń, aplikacji i danych, a dopiero potem uczciwie policzyć model konsumpcyjny albo lokalny.

Porównanie kosztów 3-letnich

Poniższy przykład jest modelem decyzyjnym, a nie ofertą cenową Azure. Przyjmujemy 50 użytkowników biurowych, 8 godzin dziennie, 22 dni w miesiącu, standardową pracę w aplikacjach Office, przeglądarce, ERP i kilku narzędziach liniowych. Dla AVD zakładamy środowisko pooled z Windows 11 Enterprise multi-session, automatycznym skalowaniem hostów, profilami FSLogix na Azure Files i istniejącymi licencjami Microsoft 365 Business Premium lub E3. Dla RDS zakładamy lokalną wirtualizację, dwa hosty RD Session Host, rolę brokera i bramy w wysokiej dostępności, Windows Server 2025 oraz RDS CAL per-user. Kwoty są zaokrąglone i mają pokazać strukturę TCO, nie zastąpić kalkulatora Azure ani wyceny sprzętu.

W tym scenariuszu AVD wygrywa przy rozproszonych zespołach, sezonowości, wysokim koszcie lokalnego utrzymania, potrzebie szybkiego DR lub standaryzacji na Microsoft 365. RDS wygrywa, gdy użytkownicy pracują cały dzień, aplikacje i dane stoją lokalnie, a firma ma kompetentny zespół infrastruktury oraz kupioną platformę serwerową.

Scenariusze biznesowe

• Biuro rachunkowe z oddziałami zwykle korzysta z aplikacji finansowo-księgowych, podpisów, skanerów i pracy sezonowej. AVD ułatwia dostęp z różnych lokalizacji, ale trzeba sprawdzić integracje z urządzeniami lokalnymi oraz licencje aplikacji księgowych. RDS pozostaje sensowny, jeśli baza danych działa lokalnie i wymaga bardzo niskich opóźnień.
• Firma produkcyjna często ma ERP, MES, pliki technologiczne i sieć OT blisko zakładu. RDS może być prostszy, gdy użytkownicy pracują w tej samej lokalizacji. AVD ma sens dla handlowców, serwisu, projektantów lub centrali, która potrzebuje dostępu spoza zakładu.
• Software house lub dział inżynieryjny może używać AVD personal desktop, maszyn GPU, izolowanych środowisk testowych i automatycznego tworzenia hostów. RDS będzie mniej elastyczny dla zespołów projektowych, ale tańszy dla stałych narzędzi administracyjnych.
• Call center i back office z pracą zmianową dobrze pasuje do AVD pooled, bo hosty można skalować według grafików. Jeżeli stanowiska są stacjonarne, a obciążenie niemal stałe, RDS z per-device CAL może dać niższy koszt licencji.
• Organizacja regulowana powinna rozważyć lokalizację danych, logowanie, szyfrowanie, kontrolę administratorów i procedury audytowe. AVD daje mocne narzędzia Entra ID, Conditional Access i Azure Monitor, natomiast RDS daje pełniejszą kontrolę nad lokalnym przetwarzaniem danych.
• Sieć sklepów lub punktów usługowych może wybrać RDS per-device, jeżeli wiele osób pracuje na tych samych terminalach. Jeżeli pracownicy rotują między lokalizacjami i korzystają z różnych urządzeń, per-user oraz AVD bywają łatwiejsze do zarządzania.

Kiedy wybrać AVD

AVD warto wybrać, gdy firma chce budować środowisko pracy jako usługę, a nie jako kolejną lokalną farmę serwerów. Najmocniejsze argumenty pojawiają się w organizacjach rozproszonych, hybrydowych, projektowych i sezonowych. Jeśli 50 użytkowników pracuje nierównomiernie, część loguje się tylko na kilka godzin, a część potrzebuje mocniejszych maszyn tylko w wybranych okresach miesiąca, autoskalowanie AVD ma realną wartość. Można utrzymywać minimalną liczbę hostów poza godzinami pracy, uruchamiać dodatkowe maszyny rano i wyłączać je wieczorem. W RDS lokalny serwer zwykle stoi gotowy przez cały czas, nawet gdy nikt z niego nie korzysta.

Kolejna przewaga AVD to Windows 11 Enterprise multi-session. Użytkownik widzi środowisko bliższe nowoczesnemu desktopowi niż serwerowemu pulpitowi RDS. Ma to znaczenie przy Microsoft 365 Apps, Teams, OneDrive, nowoczesnych mechanizmach bezpieczeństwa i aplikacjach, które są testowane głównie na klienckim Windows. Warto jednak pilnować rozmiaru VM oraz liczby użytkowników na hosta. Zbyt agresywna konsolidacja niszczy doświadczenie użytkownika i powoduje pozorne oszczędności. Dobrze zaprojektowane AVD zaczyna się od pomiaru CPU, RAM, IOPS, logon time, profili FSLogix i opóźnienia sieci, nie od wyboru najtańszej maszyny.

AVD dobrze obsługuje także scenariusze GPU. Dla projektantów, analityków, użytkowników aplikacji 3D, akcelerowanego renderingu lub narzędzi wymagających vGPU można użyć odpowiednich serii maszyn Azure z GPU, publikować pulpit osobisty albo aplikacje, a moc obliczeniową włączać tylko wtedy, gdy jest potrzebna. Lokalny RDS z GPU jest możliwy, ale wymaga sprzętu, wsparcia sterowników, zgodności z hypervisorem i często większego nakładu początkowego. W chmurze szybciej uruchamia się pilotaż i łatwiej policzyć, czy dana grupa naprawdę potrzebuje GPU codziennie.

Kiedy RDS

RDS pozostaje dobrym wyborem, gdy lokalność, przewidywalność i kontrola są ważniejsze niż elastyczność. Jeżeli firma ma własną serwerownię, kupione hosty wirtualizacji, lokalne bazy danych i użytkowników pracujących w jednym miejscu przez pełny dzień, klasyczna farma RDS może być racjonalna finansowo. W takim modelu koszt CAPEX jest znany z góry, a po wdrożeniu nie ma miesięcznej niespodzianki za compute. Przy dużej liczbie stałych sesji i dobrym wykorzystaniu sprzętu RDS potrafi wypaść lepiej niż AVD, zwłaszcza gdy organizacja nie posiada jeszcze kwalifikujących planów Microsoft 365 E3 ani Business Premium.

Drugi mocny argument to aplikacje blisko danych. Wiele systemów ERP, starszych aplikacji magazynowych, narzędzi produkcyjnych i baz plikowych działa najlepiej, gdy aplikacja i baza są w tej samej sieci LAN. Przeniesienie samego pulpitu do Azure, gdy baza zostaje lokalnie, może pogorszyć opóźnienia i stabilność. Oczywiście można zbudować łącze ExpressRoute, replikację danych lub przenieść także backendy, ale to już większy projekt migracyjny. RDS bywa wtedy rozsądnym etapem, bo użytkownik łączy się zdalnie do środowiska, które nadal znajduje się obok danych.

W 2026 roku RDS najlepiej planować na Windows Server 2025, jeżeli budują Państwo nowe środowisko, lub na Windows Server 2022, jeżeli priorytetem jest zgodność z istniejącymi aplikacjami. W obu przypadkach trzeba policzyć system bazowy, CAL, RDS CAL, backup, antywirus, monitoring i ewentualne licencje SQL. Zakup Windows Server 2025 bez RDS CAL nie wystarczy, aby legalnie udostępniać pulpity wielu użytkownikom. To częsty błąd w MŚP: serwer działa technicznie, ale model licencyjny nie jest kompletny.

Hybrydowe podejście

Najdojrzalsze organizacje rzadko wybierają AVD albo RDS jako dogmat. Często najlepsza architektura jest hybrydowa. RDS zostaje blisko aplikacji, które są trudne do migracji, zależą od lokalnej bazy danych lub wymagają urządzeń w zakładzie. AVD obsługuje zespoły mobilne, nowych użytkowników, podwykonawców, środowiska projektowe, pracę zdalną i DR dla wybranych funkcji. Takie podejście pozwala ograniczyć ryzyko migracji, a jednocześnie korzystać z nowoczesnych mechanizmów bezpieczeństwa i skalowania tam, gdzie dają one największą wartość.

Hybryda wymaga jednak dyscypliny. Tożsamość powinna być spójna: Active Directory, Entra ID, synchronizacja, MFA i grupy dostępu muszą mieć jasne właścicielstwo. Profile użytkowników nie powinny być przypadkowo rozproszone między kilkoma farmami. Trzeba zdecydować, gdzie znajduje się dane źródłowe, gdzie działa aplikacja, gdzie zapisują się pliki tymczasowe i kto odpowiada za backup. Dwa środowiska pulpitu zdalnego bez wspólnego katalogu usług, monitoringu i procesu zmian szybko generują chaos. CIO powinien wymagać macierzy aplikacji: nazwa systemu, właściciel biznesowy, lokalizacja danych, krytyczność, wymagania RTO/RPO, grupa użytkowników, preferowany model publikacji i zależności licencyjne.

Wysoka dostępność i disaster recovery różnią się w obu modelach. W AVD można rozłożyć host poole między strefy dostępności, odtwarzać hosty z obrazów, replikować profile i przygotować drugi region. Nie zwalnia to z testów. Jeżeli FSLogix nie ma poprawnych uprawnień albo profile są uszkodzone, sama dostępność brokera Microsoft nie uratuje logowania. W RDS HA wymaga co najmniej redundantnych brokerów, bram, Session Hostów, storage, certyfikatów, DNS, load balancingu i procedury odtworzenia RD Licensing. Wiele firm ma backup VM, ale nie ma udokumentowanego kroku po kroku powrotu usługi RDS po awarii domeny, SQL albo macierzy. W porównaniu TCO należy więc doliczyć testy DR, nie tylko narzędzia backupowe.

FAQ — najczęściej zadawane pytania

Czy Azure Virtual Desktop wymaga licencji RDS CAL?

W typowym scenariuszu natywnego AVD nie kupuje się RDS CAL, jeżeli użytkownicy mają kwalifikujące uprawnienia, na przykład Microsoft 365 E3, E5, A3, A5 albo Business Premium. Nadal płaci się za zasoby Azure: maszyny wirtualne, dyski, storage profili, backup, monitoring i transfer. Trzeba też prawidłowo licencjonować aplikacje uruchamiane na pulpitach, w tym Microsoft 365 Apps, aplikacje ERP, CAD, SQL i narzędzia branżowe. Jeżeli używają Państwo Windows Server jako hosta sesji w innym modelu, zasady mogą być inne, dlatego warto rozdzielić AVD od klasycznej farmy RDS.

Czy RDS na Windows Server 2025 jest nadal dobrym wyborem?

Tak, jeżeli pasuje do profilu firmy. RDS na Windows Server 2025 ma sens dla organizacji z lokalnymi aplikacjami, stabilną liczbą użytkowników, własną infrastrukturą, niskimi wymaganiami zmienności oraz kompetentnym zespołem administratorów. Szczególnie dobrze sprawdza się tam, gdzie aplikacje i bazy danych muszą pozostać w LAN, a koszt miesięczny chmury byłby trudny do zaakceptowania. Trzeba jednak uwzględnić pełny model licencyjny: Windows Server, Windows Server CAL oraz RDS CAL, a także backup, monitoring, HA, certyfikaty i testy odtworzeniowe.

Co jest tańsze dla 50 użytkowników: AVD czy RDS?

Nie ma jednej odpowiedzi bez profilu pracy. Dla 50 użytkowników pracujących 8 godzin dziennie AVD może być konkurencyjne, jeśli firma ma już kwalifikujące licencje Microsoft 365 i potrafi wyłączać hosty poza godzinami pracy. RDS może być tańszy, jeśli użytkownicy pracują stale, dane są lokalne, sprzęt jest już kupiony, a organizacja ma własny zespół IT. W trzyletnim TCO trzeba porównać licencje, compute, storage, administrację, HA/DR, aplikacje, łącza i koszt przestojów, nie tylko miesięczną fakturę Azure.

Jaką rolę pełni FSLogix w Azure Virtual Desktop?

FSLogix przechowuje profil użytkownika w kontenerze VHD lub VHDX i podłącza go podczas logowania do hosta sesji. Dzięki temu użytkownik może trafić na inny host w puli, a mimo to zachować ustawienia aplikacji, profil Outlooka, cache Teams, konfigurację przeglądarki i środowisko pracy. Bez poprawnie zaprojektowanych profili AVD szybko staje się niestabilne: logowania są wolne, profile się blokują, a użytkownicy tracą ustawienia. Kluczowe są storage, uprawnienia, wykluczenia antywirusa, monitoring logon time i procedury naprawy uszkodzonych kontenerów.

Czy można łączyć AVD i RDS w jednej organizacji?

Tak, a w średnich firmach często jest to najbardziej rozsądne podejście. RDS może obsługiwać starsze aplikacje i dane lokalne, a AVD zespoły zdalne, podwykonawców, projekty czasowe, GPU albo scenariusze disaster recovery. Warunkiem jest dobry ład architektoniczny: spójna tożsamość, jasne grupy dostępu, kontrola licencji, wspólny monitoring i mapa aplikacji. Bez tego hybryda staje się zbiorem wyjątków. Dobrze zaprojektowana pozwala natomiast migrować etapami i płacić za chmurę tylko tam, gdzie naprawdę wnosi przewagę.

Sprawdź klucze Microsoft z fakturą KSeF

Jeżeli planują Państwo modernizację pulpitów zdalnych, warto zacząć od porządku licencyjnego. KluczeSoft.pl, prowadzony przez Selected Supply Sp. z o.o. (NIP 7272834817), dostarcza licencje Microsoft dla firm z fakturą i dokumentacją zakupową. Zaufanie klientów potwierdza Trusted Shops 4,72/5 z 1 384 opinii (12 mies.). Dla projektu RDS najczęściej potrzebne będą Windows Server oraz RDS CAL. Dla AVD warto sprawdzić, czy użytkownicy mają właściwe plany Microsoft 365, na przykład Microsoft 365 E3. Przy większych wdrożeniach proszę potraktować zakup licencji jako część architektury, a nie etap po wdrożeniu technicznym.

Źródła: oficjalna dokumentacja Microsoft dotycząca Azure Virtual Desktop, Windows 11 Enterprise multi-session, FSLogix, Remote Desktop Services, licencji dostępowych RDS oraz cen i kalkulatorów Azure; data publikacji 2026-05-01.