Felhő exit-stratégia — kilépési terv lock-in nélkül

01A lényeg 30 másodpercben

A felhő exit-stratégia egy dokumentált (és tesztelt) terv arról, hogyan tudnál kiköltözni egy szolgáltatótól — másik felhőre, hibridbe vagy vissza saját infrastruktúrára —, anélkül, hogy a működésed leállna vagy az adatod veszne.

• Miért: a vendor lock-in valós (lásd a 2024-es VMware/Broadcom árazási sokkot), a szolgáltató meghibásodhat vagy felvásárolhatják, és pénzügyi szektorban a DORA kifejezetten megköveteli.
• Mit: triggerek, cél-forgatókönyv, adathordozhatóság, függőség-leltár, átállási futamterv, költségbecslés — és időszakos teszt.
• Költség: a kötődés mélysége dönt — a hordozható (konténeres) terhelés olcsón megy, a mély felhő-natív rész újraírást kér.
• Cél: nem a teljes lock-in-mentesség, hanem a tudatos, dokumentált kompromisszum.

02Miért kell exit-terv?

A felhő óriási előny — de a függőség kockázat is. Három ok, amiért az exit-tervet nem szabad halogatni:

• Üzleti/árazási sokk: a 2024-es VMware/Broadcom-történet megmutatta, milyen gyorsan változhat egy szolgáltató árazása és licencmodellje — aki nem volt felkészülve, kényszerhelyzetbe került. Ugyanez bármelyik felhőnél megtörténhet (lásd a VMware-alternatíva elemzést).
• Szolgáltatói kockázat: a szolgáltató meghibásodhat, megszűnhet, felvásárolhatják, vagy egy régiót kivezethet — a működésed folytonossága nem múlhat azon, hogy reménykedsz, ez nem történik meg.
• Szabályozói elvárás: a pénzügyi szektorban a DORA a kritikus vagy fontos funkciókat támogató ICT-szolgáltatásokra dokumentált exit-stratégiát ír elő, és az exit-feltételeket a register of information nyilvántartásban is rögzíteni kell.

Az exit-terv valójában a DR-gondolkodás kiterjesztése a szolgáltató-kockázatra: ahogy a katasztrófára felkészülsz, úgy a szolgáltatótól való függésre is.

Az exit-stratégia nem a kilépés szándéka, hanem a képesség rá. Ez ad tárgyalási pozíciót és rezilienciát.

03Exit-triggerek

Az exit-terv akkor működik, ha előre meghatározod, mely események indítják a mérlegelést vagy a kilépést:

04Mit tartalmazzon az exit-terv?

Egy működőképes exit-terv minimumtartalma:

1. Exit-triggerek — a fenti események, küszöbökkel.
2. Cél-forgatókönyv — másik felhő, hibrid vagy on-prem visszaköltözés.
3. Adathordozhatóság — milyen formátumban, mekkora adat, milyen csatornán hozható ki (egress); titkosítás és kulcskezelés.
4. Függőség-leltár — mely felhő-natív szolgáltatásra épülsz, és annak mi a hordozható alternatívája.
5. Átállási futamterv — sorrend, mérföldkövek, becsült idő (lásd a 6R migrációs keretet visszafelé is).
6. Felelősök & szerződés — felmondási és adatkiadási feltételek, átállási támogatás.
7. Költségbecslés — stranded cost (átmeneti dupla környezet), egress, újraépítés.
8. Teszt — időszakos próba: a nem tesztelt terv csak papír.

05A kiköltözés költsége — a kötődés mélysége dönt

A kilépés ára és ideje elsősorban attól függ, milyen mélyen épültél a felhő-specifikus szolgáltatásokra. Egy indikatív kép a relatív erőfeszítésről architektúra-típus szerint:

Két külön tétel: az egress (az adat kihozatalának díja) és a stranded cost (a régi és az új környezet átmeneti párhuzamos költsége). Teljes kiköltözésnél az egress-nél jó hír van: az AWS, az Azure és a Google Cloud 2024 óta kérésre, feltételekkel elengedi a kihozatali díjat, az EU Data Act pedig 2027. január 12-től megtiltja a szolgáltatóváltási díjakat (az egress-t is beleértve). A részleges kilépés és a párhuzamos (hibrid, multi-cloud) működés adatforgalma viszont továbbra is fizetős lehet, a stranded cost pedig mindenképp megmarad. Ezekkel előre számolni kell — a FinOps-szemlélet itt is segít.

06Exit-érettségi szintek

Az exit-felkészültség nem bináris (van/nincs terv), hanem érettségi szintek mentén nő — és a kockázat-csökkenés ezzel együtt:

07Gyakori hibák

• Nincs terv, csak bizakodás: „velünk ez nem történhet meg" — a VMware-sokk pont ezt cáfolta.
• Papír-terv teszt nélkül: a le nem próbált exit-terv a baj pillanatában derül ki, hogy nem működik.
• Egress és stranded cost kihagyása: a kihozatali díj (részleges kilépésnél, vagy ha nem kéred az elengedését) és az átmeneti dupla környezet komoly tétel — előre kell számolni.
• Teljes lock-in-mentesség hajszolása: mindent hordozhatóra építeni gyakran drágább, mint amennyit ér — a cél a tudatos kompromisszum.
• Elavult terv: a környezet változik; az exit-tervet élő dokumentumként kell karbantartani.

08GYIK

Az exit-stratégia azt jelenti, hogy ki akarunk lépni a felhőből?

Nem. Azt jelenti, hogy képesek lennétek rá, ha kell — ez ad tárgyalási pozíciót és rezilienciát. A legtöbb cég a fő felhőjén marad; az exit-terv biztosíték, nem szándék.

Mennyire reális a felhőből visszaköltözni on-premre?

Reális, főleg a hordozható (konténeres) terheléseknél és szuverenitási igénynél — itt a felhő vs. on-prem TCO és a hazai infrastruktúra jön képbe. A mély felhő-natív rész viszont újraírást kér, ezért fontos a függőség-leltár.

Multi-cloud megoldja a lock-int?

Részben, de ára van: a multi-cloud bonyolultságot, megosztott szakértelmet és egress-költséget hoz. A legtöbb KKV-nak nem éri meg csak a lock-in miatt — jobb egy fő felhő + hordozható alapok + tesztelt exit-terv.

Kell hozzá külső szakértő?

A függőség-leltár és a reális futamterv tapasztalatot igényel — egy felmérés + a kritikus rendszerek exit-tervének felállítása és egy próbafutás megtérül. Pont ezt csináljuk: banki/nagyvállalati cloud-tapasztalatból, KKV-léptékre szabva.

Mi a felhő exit-stratégia és miért kell?

A felhő exit-stratégia egy dokumentált terv arra, hogyan tudsz kiköltözni egy felhőszolgáltatótól — vagy átállni egy másikra, illetve vissza saját infrastruktúrára (in-sourcing) — anélkül, hogy a működésed leállna vagy az adatod elveszne. Azért kell, mert (1) a vendor lock-in valós kockázat: a 2024-es VMware/Broadcom árazási sokk megmutatta, milyen gyorsan változhatnak a feltételek; (2) a szolgáltató meghibásodhat, megszűnhet vagy felvásárolhatják; (3) szabályozói elvárás is lehet — a pénzügyi szektorban a DORA kifejezetten megköveteli a kritikus vagy fontos funkciókat támogató ICT-szolgáltatásokra a dokumentált, tesztelt exit-tervet. Az exit-stratégia nem azt jelenti, hogy ki akarsz lépni — hanem hogy képes lennél rá, ha kell.

Mit tartalmazzon egy exit-terv?

A minimum: (1) exit-triggerek — mely események indítják (árazás, teljesítmény, meghibásodás, M&A, compliance); (2) cél-forgatókönyv — másik felhő, hibrid vagy on-prem visszaköltözés; (3) adathordozhatóság — milyen formátumban, mekkora adat, milyen csatornán hozható ki (egress); (4) az alkalmazás-függőségek leltára (mely felhő-natív szolgáltatásra épül, és annak mi az alternatívája); (5) átállási idő és sorrend (futamterv); (6) felelősök és a szerződéses felmondási/adatkiadási feltételek; (7) becsült költség (stranded cost, egress, újraépítés); és kulcsfontosságú: (8) a terv időszakos tesztelése. A nem tesztelt exit-terv csak papír.

Mennyibe kerül kiköltözni a felhőből?

A költséget főleg az dönti el, milyen mélyen épültél a felhő-natív szolgáltatásokra. A lift-and-shift (rehost) jellegű, hordozható konténeres terhelést viszonylag gyorsan és olcsón át lehet vinni. Ha viszont menedzselt adatbázisra, szerver nélküli (serverless) és felhő-specifikus szolgáltatásokra építettél mélyen, az átállás újraírást (refactor) igényel — ez a legdrágább és leglassabb. Plusz ott az egress-díj (az adat kihozatalának költsége — teljes kiköltözésnél az AWS, az Azure és a Google Cloud kérésre elengedi, az EU-ban 2027. január 12-től a Data Act alapján szolgáltatóváltási díj nem számítható fel) és a stranded cost (a párhuzamosan futó régi+új környezet átmeneti dupla költsége). Épp ezért a lock-in mértékét tudatosan érdemes menedzselni, nem csak a kilépéskor szembesülni vele.

Hogyan csökkenthető a vendor lock-in előre?

Néhány bevált elv: (1) konténerizálás és Kubernetes a hordozható részeknél; (2) infrastruktúra mint kód (IaC), hogy a környezet újraépíthető legyen máshol; (3) nyílt szabványok és hordozható adatformátumok a kritikus adatoknál; (4) a mély felhő-natív függőséget tudatosan, csak ott vállald, ahol az érték (sebesség, költség) egyértelműen megéri; (5) a kritikus adatok rendszeres, hordozható exportja. A cél nem a teljes lock-in-mentesség — az gyakran drágább, mint amennyit ér —, hanem a tudatos, dokumentált kompromisszum: hol vállalsz kötődést, és hol tartasz nyitva kiutat.

A DORA tényleg megköveteli az exit-stratégiát?

Igen. A DORA-rendelet a kritikus vagy fontos funkciókat támogató ICT-szolgáltatásokra elvárja a dokumentált exit-stratégiát: a pénzügyi szervezetnek képesnek kell lennie kilépni a szolgáltatótól a működés folytonosságának veszélyeztetése és a megfelelőség sérülése nélkül. Az exit-feltételeket a register of information nyilvántartásban is rögzíteni kell. Nem pénzügyi cégnél jogi kötelezettség nincs, de a józan üzleti reziliencia ugyanezt diktálja — a VMware-sokk minden szektorban tanulság volt.

Elég, ha egyszer leírjuk az exit-tervet?

Nem. A le nem tesztelt exit-terv csak papír — ahogy a disaster recovery tervnél is, a valós érték a gyakorlásból jön. Legalább a kritikus rendszereknél érdemes időszakosan próbát végezni: egy szolgáltatás kihozatala, egy adat-export visszatöltése egy alternatív környezetbe, az átállási idő mérése. A környezet folyamatosan változik (új szolgáltatások, új függőségek), ezért az exit-tervet élő dokumentumként kell karbantartani — különben csendben elavul, és a baj pillanatában derül ki, hogy nem működik.

09Konzultáció

Ha a felhő-függőséged kockázatát szeretnéd kézbe venni — akár DORA-kötelezettségből, akár józan rezilienciából —, egy felmérés a rendszereid és szerződéseid alapján megmutatja a kritikus függőségeket és a reális kiutat. Egy 30 perces ingyenes konzultáció után konkrét exit-tervet és érettség-emelési lépéseket adunk.

A kivitelezést a Cloud & Hibrid, az IT Infrastruktúra és a Monitoring & NOC szolgáltatásainkkal kötjük össze — 25+ év és 50+ felhő-projekt tapasztalatával, KKV-méretre szabva.

Ingyenes 30 perces konzultáció