- Nem „olcsóbb” vagy „drágább”: a felhő OpEx-bérlet, az on-premise CapEx-beruházás — más a költségszerkezet.
- A döntés egy mutató: kihasználtság × kiszámíthatóság — ingadozó terhelésnél a felhő, stabil 24/7-nél az on-prem nyer.
- TCO = teljes 3–5 éves költség, nem a beszerzési ár; a leggyakrabban kifelejtett tétel a csapat-munkaidő és az áram (on-prem), illetve az egress-díj (felhő).
- Indikatív 5 éves példa (50 fő, stabil profil): on-prem ~36–63 M Ft, felhő ~41–75 M Ft, hibrid ~32–58 M Ft — a profil dönt, nem a modell.
- A hibrid a reális magyar válasz: a stabil mag helyben, a csúcs és a kísérlet felhőben, egységesen kezelve.
01A döntés 30 másodpercben
A felhő nem „olcsóbb" vagy „drágább" önmagában — más a költségszerkezete. A felhő bérlet (OpEx): rugalmas, gyorsan indul, és a változó vagy kiszámíthatatlan terhelést bünteti a legkevésbé. A saját szerver (on-premise) beruházás (CapEx): a stabil, magas kihasználtságú, kiszámítható terhelést jutalmazza 3–5 éves távon.
A leggyakoribb hiba a két szélsőség: „minden menjen felhőbe" (drága lesz a folyamatosan futó nagy gépeken) vagy „a felhő úgyis drága, marad minden helyben" (lemaradsz a rugalmasságról és a menedzselt szolgáltatásokról). A valós válasz a legtöbb magyar középvállalatnál a hibrid: a stabil mag helyben, a csúcs és a kísérlet felhőben.
| Ha ez igaz rád… | …akkor jellemzően ez nyer |
|---|---|
| Ingadozó / kiszámíthatatlan / gyorsan növő terhelés, kis induló méret | Felhő |
| Stabil, 24/7 magas kihasználtság, kiszámítható kapacitásigény, van tőke | On-premise |
| Vegyes: stabil mag + változó/kísérleti rész, adatszuverenitási elvárás | Hibrid |
02A három modell röviden
On-premise (saját szerver): a hardvert megveszed és a saját vagy bérelt adatközpontodban üzemelteted. Tőkeberuházás (CapEx), amit 3–5 év alatt írsz le. Teljes kontroll az adat és a hardver felett, de te viseled a kapacitástervezés, a hibatűrés és a frissítés terhét.
Nyilvános felhő (AWS / Azure / GCP): a kapacitást igény szerint béreled, másodperc/óra/hó alapon. Nincs előzetes beruházás (OpEx), percek alatt skálázol fel és le, és menedzselt szolgáltatásokat (adatbázis, üzenetsor, AI) kapsz készen. Cserébe folyamatosan fizetsz, és a számla gyorsan elszáll kontroll nélkül.
Hibrid: a kettő egységesen kezelt kombinációja. A stabil, érzékeny vagy alacsony latenciát igénylő workload helyben fut, a változó vagy globális rész felhőben — közös identitás-, hálózat- és monitoring-réteggel.
Megjegyzés a teljességhez: a privát felhő (pl. VMware, OpenStack, Proxmox saját hardveren, felhő-szerű önkiszolgálással) az on-premise egy érettebb formája — a TCO-logikája az on-prem oldalhoz tartozik.
Nem a modell dönt, hanem a profil. A stabil terhelést a saját szerver, az ingadozót a felhő jutalmazza.
03Mi a TCO — és mi van benne
A TCO (Total Cost of Ownership) a rendszer teljes, jellemzően 3–5 éves költsége — nem a beszerzési ár. A leggyakoribb döntési hiba, hogy csak a látható tételt (hardver-ár vs. havi felhő-számla) hasonlítják össze, és kimaradnak a rejtett, de valós tételek. A tisztességes összehasonlításhoz mindkét oldalon ugyanazt kell számolni:
| Költségelem | On-premise | Felhő |
|---|---|---|
| Számítási kapacitás | Szerver-hardver (CapEx, 3–5 év amortizáció) | Compute instance (OpEx, óradíj) |
| Tárhely | Diszk / SAN / NAS | Block + object storage + IOPS-díj |
| Szoftverlicenc | Hypervisor, OS, adatbázis | Licenc beépítve vagy BYOL |
| Áram + hűtés | Jelentős, és emelkedik | A díjban (nem látod külön) |
| Hely | Rack / adatközpont-bérlet | — |
| Hálózat | Switch, tűzfal, internet | Sávszélesség + egress-díj |
| Hibatűrés / DR | Második telephely, mentés-infra | Multi-AZ / régió (felár) |
| Üzemeltető csapat | Magasabb (te kezelsz mindent) | Alacsonyabb infra, de + FinOps |
| Frissítés / hardvercsere | 3–5 évente újra-beruházás | A szolgáltatóé |
A két leggyakrabban kifelejtett tétel: az on-prem oldalon a csapat munkaideje és az áram, a felhő oldalon az egress-díj (a felhőből kifelé mozgatott adat) és a menedzselt szolgáltatások felára.
045 éves TCO-példa — egy 50 fős cég
Az alábbi indikatív példa egy 50 fős magyar szolgáltató cég stabil belső rendszereire vonatkozik (ERP, fájlmegosztás, néhány belső alkalmazás, adatbázisok, mentés). A számok 2026 első felének magyar piaci nagyságrendjei, kerekítve — a saját helyzeted ettől eltér; ez a módszertant mutatja, nem árajánlat.
Feltevések: ~12 szerver-workload egyenértékű kapacitás, stabil, ~65% átlagos kihasználtság, 18 TB adat, mérsékelt kifelé irányuló forgalom.
| Tétel | On-premise (5 év) | Nyilvános felhő (5 év) |
|---|---|---|
| Hardver (szerver + storage + hálózat) | 14–22 M Ft (CapEx) | — |
| Compute + tárhely bérlet | — | 26–42 M Ft |
| Szoftverlicenc (hypervisor, OS, DB) | 3–7 M Ft | 4–9 M Ft |
| Áram + hűtés + rack | 4–8 M Ft | — |
| Hálózat / egress | 2–4 M Ft | 2–6 M Ft |
| Mentés + DR | 3–6 M Ft | 3–7 M Ft |
| Üzemeltetés (csapat-idő, 5 év) | 10–16 M Ft | 6–11 M Ft + FinOps |
| Indikatív 5 éves TCO | ~36–63 M Ft | ~41–75 M Ft |
A tanulság nem az, hogy „az on-prem olcsóbb". A tanulság a profil: ennél a stabil, kiszámítható terhelésnél az on-prem a sáv alján versenyképes, mert nincs folyamatos bérleti díj a 24/7 futó gépeken. Ha viszont a terhelés ingadozna (pl. szezonális csúcsok, kísérleti projektek), a felhő oldal fix tételei eltűnnének a le-skálázással, és a kép megfordulna. Pontosan ezért nyer a gyakorlatban a hibrid: a stabil részt on-premen, a változót felhőben tartod.
05Break-even: mikor melyik olcsóbb
A döntés egyetlen mutatóra egyszerűsíthető: kihasználtság × kiszámíthatóság.
- Felhő nyer, ha: a terhelés ingadozó vagy kiszámíthatatlan; gyorsan és bizonytalanul nő; kicsi az induló méret; sok a kísérleti/rövid életű workload; vagy menedzselt szolgáltatásokra (AI, adatbázis, üzenetsor) van szükség gyorsan, csapat nélkül.
- On-premise nyer, ha: a terhelés stabil és 24/7 magas kihasználtságú; nagy és állandó a kapacitásigény; szigorú az adatszuverenitás vagy a latencia; nagy a kifelé irányuló forgalom (drága egress); és van tőke a beruházásra.
Ökölszabály: a felhőben a folyamatosan, magas kihasználtsággal futó nagy instance a legdrágább dolog — pont az, amit on-premen érdemes tartani. A felhő ereje a rugalmasság: amit le tudsz kapcsolni, amikor nem kell. Ha egy workload sosem kapcsol le, a felhő bérlet-logikája ellened dolgozik.
06Rejtett költségek — mindkét oldalon
Felhő — amit utólag vesznek észre:
- Egress-díj: a felhőbe tölteni jellemzően ingyenes, kifelé mozgatni viszont fizetős — folyamatos multi-cloud vagy hibrid adatforgalomnál jelentős tétel. (Teljes kiköltözéskor a három nagy 2024 óta kérésre elengedi, és az EU Data Act 2027. január 12-től tiltja a szolgáltatóváltási díjakat.)
- Over-provisioning: a könnyű skálázás miatt a csapat túlméretez; a számla 20–40%-a tipikusan felesleges kapacitás right-sizing nélkül.
- Menedzselt szolgáltatások felára: kényelmesek, de prémium áron; sok kis szolgáltatás összeadódik.
- Exit-költség (lock-in): a felhő-natív szolgáltatásokról visszaköltözni drága és lassú.
On-premise — amit alábecsülnek:
- Csapat-idő: a kapacitástervezés, patchelés, hibakeresés valós munkaóra — gyakran a TCO legnagyobb rejtett tétele.
- Túlméretezés a csúcsra: a hardvert a maximális terhelésre kell venni, ami az idő nagy részében áll.
- Áram és hűtés: emelkedő energiaárak mellett egyre nagyobb tétel.
- Frissítési ciklus: 3–5 évente újabb tőkeberuházás, nem egyszeri kiadás.
On-premen a csapat munkaideje és az áram, felhőben az egress-díj és a menedzselt szolgáltatások felára a leggyakrabban kifelejtett tételek. Ha csak a hardver-árat és a havi számlát veted össze, a TCO-döntésed félrevezet.
07Nem-pénzügyi szempontok
A TCO fontos, de nem minden a pénz. A magyar és EU kontextusban gyakran ezek döntenek:
- Adatszuverenitás és megfelelőség: hol tárolódik az adat? A NIS2, a GDPR és pénzügyi szektorban a DORA mind befolyásolja, mi mehet felhőbe és milyen feltétellel. EU-régió, adatfeldolgozói szerződés (DPA), titkosítás kulcskezeléssel — ezek alapfeltételek.
- Latencia: gyártósori (OT), ipari vagy valós idejű rendszereknél a helyi feldolgozás (on-prem / edge) gyorsabb és megbízhatóbb, mint a felhő körüljárás.
- Skálázási sebesség: ha holnap 3×-os kapacitás kell, a felhőben percek, on-premen hetek-hónapok (beszerzés).
- Csapat-kompetencia: a felhő más készségeket igényel (FinOps, IaC, felhő-natív biztonság); on-premen a klasszikus üzemeltetés.
- Üzletmenet-folytonosság: az RTO/RPO célok és a DR-stratégia mindkét modellben kulcs — lásd a DR/BCP megközelítést.
08Döntési mátrix workload szerint
A jó döntés nem cég-, hanem workload-szintű: ugyanaz a cég az egyik rendszert helyben, a másikat felhőben tartja. Ez a hibrid lényege.
| Workload-típus | Ajánlott modell | Miért |
|---|---|---|
| Stabil, 24/7 ERP / adatbázis-mag | On-premise / privát felhő | Állandó magas kihasználtság, érzékeny adat |
| Webes / publikus front-end, kampány-csúcsok | Felhő | Ingadozó terhelés, gyors skálázás |
| Fejlesztői / teszt / kísérleti környezet | Felhő | Rövid életű, le-kapcsolható, pay-per-use |
| AI / ML betanítás, batch-feldolgozás | Felhő (spot) | Csúcsidős GPU igény, ritka futás |
| Ipari / OT / valós idejű vezérlés | On-prem / edge | Latencia, megbízhatóság, szuverenitás |
| Archív / hideg mentés | Felhő (object/cold) | Olcsó tárhely, ritkán olvasott |
| Szabályozott pénzügyi / egészségügyi adat | Hibrid (feltételekkel) | Compliance dönt, EU-régió + DPA |
Ne cég-, hanem workload-szinten dönts: ugyanaz a cég a stabil ERP-magot on-premen, a kampány-csúcsot és a dev/test környezetet felhőben tartja. Ez a workloadonkénti besorolás a hibrid lényege — és a legjobb TCO forrása.
09Hibrid: a reális magyar válasz
A legtöbb magyar középvállalat nem zöldmezős — van meglévő hardver-beruházása, futó rendszerei és megfelelőségi elvárásai. Számukra a hibrid nem kompromisszum, hanem a legjobb TCO: megtartja a meglévő beruházás értékét, kihasználja a felhő rugalmasságát, és kezeli a szuverenitást.
A hibrid akkor működik, ha nem két külön sziget, hanem egységesen kezelt rendszer:
- Egységes identitás (SSO, központi jogosultság on-prem és felhő felett).
- Összekötött hálózat (VPN / dedikált kapcsolat, egységes címzés és tűzfal-politika).
- Közös monitoring és riasztás — egy NOC lát mindkét oldalt, ugyanazokkal az SLO-kkal.
- Egységes mentés és DR — a 3-2-1-1-0 elv mindkét oldalra érvényes.
- Költség-átláthatóság — FinOps, hogy a felhő-oldal ne szaladjon el.
Ezt az egységesítést hívják a gyakorlatban rendszerintegrációnak és enterprise architektúrának — a hibrid sikere nem a technológián, hanem a koherens architektúrán múlik.
10Migráció: a 6R keret a gyakorlatban
Ha a döntés a felhő vagy hibrid irányába esik, a migrációt nem egyben, hanem workloadonként tervezed. Az AWS által 2016-ban népszerűsített (a Gartner korábbi 5R-modelljére épülő) 6R keret minden alkalmazáshoz egy stratégiát rendel — az AWS ma hetedikként a Relocate-et is ide sorolja (7R):
- Retire (leállítás): a felmérés tipikusan kiderít 10–20% felesleges, senki által nem használt rendszert — ezeket nem migrálod, hanem kivezeted.
- Retain (megtartás): ami egyelőre helyben marad (compliance, latencia, vagy mert még nem éri meg mozgatni).
- Rehost (lift-and-shift): változatlanul áthelyezed felhőbe — leggyorsabb, de nem használja ki a felhő-natív előnyöket.
- Replatform: migráció közben kisebb optimalizálás, pl. saját adatbázis helyett menedzselt szolgáltatás.
- Repurchase: a saját rendszert SaaS-ra cseréled (pl. saját levelező → Microsoft 365).
- Refactor: újraírás felhő-natív architektúrára (konténer, szerver nélküli) — legnagyobb érték, legnagyobb befektetés.
A migráció sikerének kulcsa, hogy nem egyszeri projekt: a tényleges megtakarítás a folyamatos FinOps-optimalizálásból (right-sizing, foglalt kapacitás, autoscaling, felesleges erőforrások kikapcsolása) jön — különben a felhő-számla a régi on-prem TCO fölé kúszik.
11GYIK
Olcsóbb-e a felhő, mint a saját szerver?
Attól függ: a felhő az ingadozó, kiszámíthatatlan vagy gyorsan növő terhelésnél és kis méretben szinte mindig olcsóbb; a stabil, 24/7 magas kihasználtságú terhelésnél viszont az on-premise 3–5 éves távon gyakran kedvezőbb, mert nincs folyamatos bérleti díj. A kihasználtság és a kiszámíthatóság dönt, nem a modell maga.
Mi az a vendor lock-in és hogyan kerülöm el?
A lock-in az, amikor egy szolgáltató felhő-natív szolgáltatásaira annyira ráépülsz, hogy a kiköltözés aránytalanul drága és lassú. Csökkenthető nyílt szabványokkal (konténer, Kubernetes), infrastruktúra mint kód (IaC) használatával és a kritikus adatok hordozhatóságának fenntartásával — de teljesen ritkán éri meg kiküszöbölni, inkább tudatosan kezeled.
Privát felhő vagy nyilvános felhő?
A privát felhő (saját hardveren futó, felhő-szerű önkiszolgáló réteg, pl. VMware/OpenStack/Proxmox) az on-premise érettebb formája: megtartja a kontrollt és a szuverenitást, miközben rugalmasabb üzemeltetést ad. A nyilvános felhő a külső szolgáltató (AWS/Azure/GCP) megosztott kapacitása. A hibrid sokszor pont a privát felhő + nyilvános felhő párosítás.
Mennyi idő egy felhő-migráció?
Egy közepes méretű (20–60 workload) migráció a felméréstől az éles üzemig jellemzően 3–6 hónap, ha többségében rehost/replatform; refaktorálás-igényes (felhő-natív átírás) workloadoknál ez workloadonként hónapokkal hosszabb. A felmérés + üzleti eset (TCO + 6R-terv) önmagában 3–6 hét.
Mikor éri meg az on-premise 2026-ban?
Akkor, ha (1) a terhelés stabil és 24/7 magas kihasználtságú (a felhőben a folyamatosan futó nagy instance a legdrágább), (2) szigorú adatszuverenitási vagy latencia-követelmény van (helyi gyártás, OT/ipari rendszer, egészségügyi adat), (3) van eszköz a tőkeberuházásra és 3–5 éves amortizációra, (4) nagy a kifelé irányuló adatforgalom (a felhő egress-díja jelentős tétel). Ilyenkor egy jól méretezett saját klaszter 3–5 éves TCO-ja az egyenértékű felhő-kapacitás alatt lehet.
Mi a hibrid felhő és kinek való?
A hibrid felhő on-premise és nyilvános felhő (AWS/Azure/GCP) kombinációja egy egységesen kezelt rendszerben. A stabil, érzékeny vagy alacsony latenciát igénylő workload helyben fut, a változó, kísérleti vagy globálisan skálázódó rész felhőben. A legtöbb magyar középvállalat reális válasza ez: megtartja a meglévő hardver-beruházás értékét, közben kihasználja a felhő rugalmasságát, és kezeli a NIS2/GDPR adatszuverenitási elvárásokat. Igényel viszont egységes identitás-, hálózat- és monitoring-réteget.
Mi a TCO és mit tartalmaz?
A TCO (Total Cost of Ownership, teljes birtoklási költség) egy rendszer teljes, jellemzően 3–5 éves költsége, nem csak a beszerzési ár. On-premise esetén: hardver, szoftverlicenc, áram és hűtés, rack/adatközpont-bérlet, hálózat, mentés, karbantartás, és az üzemeltető csapat ideje. Felhő esetén: compute, tárhely, hálózati/egress-díj, licenc, menedzselt szolgáltatások, valamint a FinOps és üzemeltetés munkaideje. A valós összehasonlításhoz mindkét oldalon bele kell számolni a rejtett tételeket és a csapat munkaóráját.
Mennyibe kerül egy felhő-migráció Magyarországon?
Indikatív keretek: felmérés + üzleti eset (TCO + migrációs terv) 600 e – 2 M Ft; egy közepes (20–60 szerver/workload) lift-and-shift migráció kivitelezése 4–15 M Ft egyszeri, a komplexitástól és a refaktorálás mértékétől függően; ezt követően a havi felhő-üzemeltetés + FinOps 150–500 e Ft/hó. A legnagyobb tévedés a migrációt egyszeri projektként kezelni: költségmegtakarítás csak folyamatos FinOps-optimalizálással (right-sizing, foglalt kapacitás, autoscaling) jön ki. Ezek piaci keretek; mi a ti rendszereitek felmérése után adunk személyre szabott ajánlatot, a futó akcióinkkal együtt.
12Konzultáció
Ha konkrét döntés előtt állsz — maradjon helyben, menjen felhőbe, vagy legyen hibrid —, egy felmérés a saját rendszereiden többet ér minden általános cikkél. Egy 30 perces ingyenes konzultáció után számszerű TCO-összevetést és workload-szintű 6R-tervet adunk, a saját kihasználtsági és megfelelőségi profilodra szabva.
A kivitelezést a Cloud & Hibrid, az IT Infrastruktúra és az Enterprise Architecture szolgáltatásaink keretrendszerével támogatjuk — 25+ év banki és nagyvállalati IT-integrátori háttérrel, 50+ felhő-migrációs projekt tapasztalatával.