Néhány hete készítettem egy rövid videót azoknak, akik most ismerkednek a Google Cloud-ökoszisztémával vagy a Geminivel, mert azt tapasztalom, hogy sokan itt akadnak el már az első lépésnél. Pedig ennél egyszerűbb dolog nem is lehetne.
Az első lépések nem egyszerűek, de itt más a helyzet: az ember azt hiszi, hogy a Google AI-hoz és a Google Cloudhoz külön-külön fiókokat kell létrehoznia. Ez nem igaz. Egy meglévő Gmail-fiók pontosan elég ahhoz, hogy az egész ökoszisztémát bejárd.
Négy URL, egy fiók
A videóban négy belépési pontot mutatok meg, mindegyiket ugyanazzal az e-mail-címmel:
Ez a négy hely gyakorlatilag lefedi a Google AI és Cloud ökoszisztémájának egészét. Nincs itt semmi extra regisztráció, nincs elveszett jelszó egy külön fejlesztői fiókhoz, nincs felesleges adminisztráció.
Miért fontos ez?
Aki most vág bele a felhő vagy az AI világába, annak az első akadály gyakran nem technikai, hanem szervezési: hova is kattintsak, melyik fiókkal, melyik felületen. Ha ez az első lépés egyszerű, sokkal nagyobb eséllyel megy tovább valaki a következőre is. Ez pontosan az a simplicity-elv, amit enterprise környezetben is vallok: előbb működjön egyszerűen, utána lehet bővíteni.
Mielőtt megnézed
Ha eddig azt hitted, hogy a Google Cloud vagy a Gemini kipróbálásához külön fiókra vagy bonyolult regisztrációra van szükséged, a videó pontosan azt mutatja meg, hogy ez nem így van. Egy fiók, négy URL, és már úton is vagy a felhő és az AI világába.
Amikor valaki felhő alapú projektet tervez, általában csak egy szolgáltatóban gondolkozik. Ez a természetes irány, és nem is meglepő – egy rendszer, egy számla, minden egy helyen. Ez az általános trend.
Pedig aki alaposan ismeri az AWS-t, az Azure-t és a Google Cloud-ot, hamar rájön: mindegyiknek vannak erősségei, és mindegyiknek vannak gyengeségei. Ha valaki engem kérdezne, hogy mi lenne egy nagy, vállalati szintű megoldás tökéletes kivitelezése, azt mondanám: mindegyikből a legjobbat használjuk. Azonban ez sajnos a legtöbb esetben nem lehetséges.
Miért ragad be mindenki egyetlen szolgáltatónál?
A válasz általában nem technikai – hanem emberi. Aki egyszer megismerte az AWS konzolt, az ott érzi magát otthon. A csapat ott szerzett tapasztalatot, azzal kapcsolatban vannak a tanúsítványok, és az architektúra is arra épül. Váltani vagy párhuzamosan üzemeltetni látszólag bonyolultabb, drágább, és több kockázattal jár.
Ehhez jön hozzá a vendor lock-in jelensége. Az iparági ajánlás egyértelmű: kerüld el, maradj hordozható, ne függj egyetlen szolgáltatótól. A valóságban azonban ez szinte lehetetlen.
Minél mélyebbre ásol egy platform saját szolgáltatásaiban – saját adatbázisok, saját AI eszközök, saját hálózati megoldások – annál inkább benne vagy. És ha egyszer erre építed az architektúrát, a váltás költsége a legtöbb esetben meghaladja a maradás kényelmetlenségét. A nagy szolgáltatók pontosan tudják ezt, és az árazásuk is ezt tükrözi. Aki már látott hosszú távú enterprise szerződést egy nagy felhőszolgáltatóval, az tudja, miről beszélek.
A multicloud lényege egyszerű: nem egy szolgáltatóban gondolkozol, hanem oda teszed a munkaterhelést, ahol az adott feladatra a legjobb eszközök vannak. Az analitika mehet Google Cloud-ra, a gépi tanulási infrastruktúra AWS-re, a Microsoft-integrációk Azure-ra.
A hybrid cloud pedig azt jelenti, hogy a saját adatközpontod és a felhő együtt dolgozik – nem vagy kénytelen mindent kiszervezni.
A valóságban persze ez sem ilyen egyszerű. Mert ha két felhő között adatot kell mozgatni, azonnal felmerül a kérdés: hogyan? A nyilvános interneten keresztül? Az lassabb, kiszámíthatatlanabb, és biztonsági szempontból sem ideális. Dedikált fizikai kapcsolattal? Az drága, lassan kivitelezhető, és komoly hálózati szaktudást igényel. Pontosan itt jön képbe az AWS Interconnect.
Mi az AWS Interconnect?
Az AWS Interconnect egy viszonylag friss szolgáltatás, amelyet pontosan erre a problémára terveztek. A hagyományos megközelítésben privát kapcsolatot létrehozni két felhő között fizikai routerek konfigurálását, BGP peering beállítást és cross-connect megrendeléseket jelentett – ez hónapokat és komoly szakértelmet igényelt. Az Interconnect ezt váltja ki.
A folyamat leegyszerűsödik: kiválasztod a régiót, a szükséges sávszélességet és a szolgáltatót, az AWS és a partner pedig percek alatt előkészíti a kapcsolatot. A felhasználó mindebből egyetlen logikai objektumot lát a konzolban – a háttérben zajló redundáns infrastruktúra, a fizikai helyszínek és az MACsec titkosítás mind el van rejtve.
A szolgáltatásnak két arca van:
A multicloud változat, amely AWS VPC-ket köt össze más felhőszolgáltatók hálózataival – jelenleg Google Cloud és Oracle Cloud Infrastructure oldalán érhető el, az Azure integráció még 2026 folyamán érkezik.
Az úgynevezett last mile kapcsolat, amely irodákat, adatközpontokat és távoli helyszíneket köt az AWS-hez partnerek meglévő hálózatain keresztül.
Minden Interconnect legalább két fizikailag elkülönült helyszínen fut, független áramellátással és hálózattal, négy kapcsolatból álló redundáns modellben ECMP terheléselosztással. Ez enterprise szinten azt jelenti, hogy egyetlen eszköz vagy épület meghibásodása nem ejti ki a kapcsolatot.
Az ingyenes 500 Mbps – miért érdemes figyelni erre?
Az AWS most bevezette az ingyenes 500 Mbps-os multicloud Interconnect csomagot, amellyel a cégek tesztelhetik és élesben is futtathatják munkaterheléseiket anélkül, hogy az AWS oldalán bármilyen díjat fizetnének.
500 Mbps sávszélességgel havonta nagyjából 160 TB adat mozgatható – ez elegendő komoly multicloud munkaterhelések, adatreplikáció vagy hibrid alkalmazásarchitektúrák üzemeltetéséhez.
Fontos megérteni: az ingyenesség az AWS oldalára vonatkozik. A másik felhőszolgáltató saját maga határozza meg a díjszabást a saját infrastruktúrájára, ezért érdemes az ő árazásukat is megnézni az Interconnect létrehozása előtt. A szint régiónként és szolgáltatónként egy helyi Interconnect-re korlátozódik, és minden kapcsolat mellé egy Amazon CloudWatchNetwork Synthetic Monitor is jár külön díj nélkül – ez azt jelenti, hogy a latenciát és a csomagveszteséget folyamatosan monitorozhatod, riasztásokkal együtt.
Két valós eset, hogy érezzük a lényegét
Adatreplikáció: Egy közepes méretű pénzügyi cégnél az analitikai platform Google BigQuery-n fut, a tranzakciós rendszer viszont AWS-en. A napi szinkron eddig vagy nyilvános interneten ment – lassabban, kevésbé stabilan – vagy drága dedikált kapcsolaton. Egy 500 Mbps-os ingyenes Interconnect-tel ez privát, alacsony késleltetésű csatornán zajlik, a monitoring pedig alapból adott.
Szolgáltatás migráció: Egy vállalat Google Cloud-ról akar részben AWS-re költözni, de nem egyszerre. A két környezetnek hónapokig párhuzamosan kell futnia. Korábban ezt a hibrid fázist hálózatilag kompromisszumokkal kellett áthidalni. Most a 500 Mbps elegendő arra, hogy a migráció alatt a két oldal privát csatornán kommunikáljon, és csak akkor kell fizetős szintre lépni, ha a forgalom ezt megköveteli.
Mit érdemes tudni, mielőtt kipróbálod?
A régiós elérhetősége egyelőre korlátozott. Európában Frankfurt és London érhető el AWS–Google Cloud párban, ami a legtöbb európai vállalat számára releváns kiindulópont, de érdemes ellenőrizni, hogy a saját régiód szerepel-e a listán.
Ha az Azure az elsődleges másik felhőd, még türelem kell – az integráció az AWS közlése szerint 2026 folyamán érkezik, konkrét dátum nélkül.
Amit viszont biztosan mondani lehet: az ingyenes 500 Mbps-os szint vonzó belépési pont. Nem kell azonnal fizetős infrastruktúrában gondolkodni. Ki lehet próbálni, le lehet mérni, és csak akkor kell skálázni, ha a forgalom ezt megköveteli. Ha multicloud környezetben dolgozol, vagy csak tervezed, ez az a fajta ajánlat, amit nem érdemes figyelmen kívül hagyni.
Aki valaha megpróbált egy egyszerűnek tűnő AI agentet éles környezetbe juttatni Google Cloud-on, az tudja, milyen küzdelmes tud lenni a teljes folyamat. A prototípus pillanatok alatt összeáll. Aztán jön az időigényes rész: hogyan kerül ez Cloud Run-ra? Hogy legyen a CI/CD konfiguráció? Melyik dokumentáció a hasznos? Hogyan kapcsolódik az Agent Platform a deployment pipeline-hoz? Minden egyes lépéshez más szolgáltatás, más parancssori (CLI) eszköz, és más dokumentáció kell. Ez az a pont, ahol az ígéretes projekt lelassul, és a lelkesedés is alábbhagy.
A Google Cloud erre a problémára adott választ 2026 áprilisában, amikor bemutatta az Agents CLI-t az Agent Platform részeként.
Mi az Agents CLI, és miért most jött?
Az Agents CLI az Agent Development Lifecycle – röviden ADLC – központi vezérlő eszköze, amely az első sortól az éles üzemig egyetlen parancssori eszközből kezeli a teljes folyamatot. Ez nem egy újabb absztrakciós réteg a meglévő szolgáltatások fölé. Inkább egy összekötő, amely a korábban szétszórt komponensekből – Agent Platform, Cloud Run, Infrastructure as Code, CI/CD – egyetlen, követhető munkafolyamatot csinál.
Az eszköz nyílt forráskódú, elérhető PyPI-n, és közvetlenül működik olyan coding agentek-kel, mint a Gemini CLI, Claude Code, Codex vagy bármilyen más kompatibilis eszköz.
Fontos megjegyezni: az Agents CLI nem maga a coding agent. Hanem az a valami, amit a coding agent használ ahhoz, hogy értelmesen tudjon dolgozni a Google Cloud ökoszisztémájában.
A valódi probléma: a kontextus és a fragmentáció
Mielőtt megnéznénk, mit tud az eszköz, érdemes megérteni, miért volt erre egyáltalán szükség.
Fejlesztők és coding assistentjeik sokszor azzal küzdenek, hogy hatalmas mennyiségű dokumentációt kell feldolgozniuk ahhoz, hogy áthidalják a helyi fejlesztés és a felhős deployment közötti szakadékot. Egy AI coding agent, ha nem tudja pontosan, hogyan kapcsolódnak egymáshoz a cloud komponensek, végtelen próbálkozási hurokba kerül. Ez token-pazarlás, időpazarlás, és a végén nem csak drága lesz az egész, hanem csalódott is lesz a fejlesztő.
Az Agents CLI egy központi réteget biztosít, amely előre definiált „skill”-eket és API referenciákat ad a coding agent-nek. Ez lehetővé teszi, hogy a fejlesztők minimális manuális konfiguráció mellett, gyorsan hozzák létre és indítsák el a projekteket.
Hogyan néz ki ez a gyakorlatban?
Képzeld el, hogy egy utazási költségelszámolást kezelő agent-et szeretnél építeni, amely 20 000 Ft alatt automatikusan jóváhagyja a tételeket, efölött pedig emberi döntést kér. Hagyományos úton ez azt jelenti: ADK projekt felállítása, Cloud Run konfiguráció, IAM jogosultságok, deployment pipeline, evaluation setup, stb. Mindez külön-külön. Idegörlő és bonyolult.
Az Agents CLI esetén egyetlen parancs elegendő ahhoz, hogy a coding agent megkapja az összes szükséges „tudást” a Google Cloud szolgáltatásokról. Ezután a fejlesztőnek nem kell fejből tudnia, hogyan kell konfigurálni minden egyes service-t – az agent elolvassa, amit kap, és elvégzi a lépéseket.
Ez nagyon jól hangzik, igaz?
Az életciklus négy fő szakaszon halad át:
Scaffold: a projekt struktúra és az alap konfiguráció automatikusan generálódik, az ADK (Agent Development Kit) framework alapján.
Eval: az eszköz beépített támogatást ad helyi szimulációhoz és kiértékelési pipeline-ok futtatásához, ahol különböző futtatások eredményeit lehet összehasonlítani referencia adatbázisokkal szemben, mielőtt bármi éles környezetbe kerülne.
Deploy: az Agents CLI automatizálja a teljes deployment fázist – Infrastructure as Code generálása, CI/CD pipeline konfigurálása, majd közvetlen deployment Cloud Runra, Agent Runtime-ra vagy GKE-re.
Publish: a kész agent regisztrálható a Gemini Enterprise környezetbe, ahol vállalati felhasználók számára érhető el.
Human Mode: amikor az ember veszi át az irányítást
Amit én különösen értékelek az eszköz tervezésében a Human Mode bevezetése. Ez lehetővé teszi, hogy a fejlesztők közvetlenül hajtsák végre a CLI parancsokat, ahelyett hogy teljesen az agent-vezérelt automatizálásra hagynának mindent – ez akkor különösen hasznos, amikor valaki pontosan látni akarja, mi történik a folyamatban. Így megmarad a kontroll a teljes folyamaton.
És ez nem csak egy kiegészítő funkció. Az AI agentekkel szembeni egyik jogos kritika pontosan az, hogy fekete dobozként működnek, és nem lehet közbeavatkozni, ha valami nem úgy megy, ahogy kellene.
A Human Mode ezt a problémát oldja meg: ugyanazok a parancsok, amelyeket a coding agent automatikusan futtat, terminálból is végrehajthatók, szkriptekbe szervezhetők, és pontosan ellenőrizhetők.
Cloud Run, GKE, vagy mindkettő?
Érdemes kiemelni még a cloud infrastruktúra oldali támogatást is, mert itt mutatkozik meg a Google Cloud valódi előnye.
Az Agents CLI natív integrációt biztosít a Google Cloud szolgáltatásokkal – Agent Platform, Cloud Run, GKE, és az A2A protokoll az agent-agent kommunikációhoz – manuális konfigurációk nélkül. Ez azon csapatoknak a leghasznosabb, amelyek növelni szeretnék az AI fejlesztés ütemét anélkül, hogy az üzemeltetési terhet is növelni szeretnék.
A Cloud Run az egyszerűbb, serverless megközelítés – az agent konténer alapon fut, és csak akkor fizetsz, ha valóban hívás érkezik (Pay-As-You-Go). A GKE (Google Kubernetes Engine) rugalmasabb, de több konfigurációt igényel. A legtöbb alap felhasználási esethez a Cloud Run a praktikusabb választás, és az Agents CLI alapból erre van optimalizálva.
Ami kimarad ebből a beállításból – szándékosan: monitoring részletei, availability zone konfiguráció, spot VM optimalizálás. Ezek mind fontosak lesznek, ha a terhelés megköveteli, de az első éles deploymentnél nem az a kérdés. Az a kérdés, hogy működik-e.
Pre-GA: mit jelent ez a valóságban?
Fontos megjegyezni: az Agents CLI jelenleg Pre-GA (pre-generally available) státuszban van, ami azt jelenti, hogy az eszköz csak korlátozott támogatással érhető wel. A deployment-ekkel együtt a felhasználó saját Google Cloud projektjében hozza létre az erőforrásokat, és azokért a felelősség is az övé.
Ez nem azt jelenti, hogy ne lehetne érdemi munkát végezni vele. De érdemes tudatosan kezelni: production kritikus rendszereknél ne ez legyen az egyetlen eszköz, amire támaszkodunk, amíg GA státuszt nem ér el. Prototipizáláshoz, POC-okhoz és fejlesztési pipeline-ok felállításához viszont már most teljesen értelmes választás.
Mit is jelet ez?
A Cloud CLI eszközök általában addig működnek jól, amíg a dokumentáció tart. Utána jön a valóság: tíz lépés, három service, és ugyanolyan rendetlenség, csak más köntösben.
Az Agents CLI esetén más a megközelítés, mert nem az embert próbálja meg helyettesíteni a cloud konfigurációban. Inkább a coding agent számára érthetővé teszi a Google Cloud agent ökoszisztémát. Ez egy finomabb, de fontosabb különbség. Az a fejlesztő, aki eddig az ADK-t, a Cloud Run deploymentet és a CI/CD pipeline konfigurációt három különböző helyen kereste, most egyetlen, közös formátumban olvasható „skill” rendszerből kapja meg. A coding agent pedig nem találgat többé és így spórol a token-ekkel is.
Ez egy nagyon ígéretes irány és kíváncsian várom merre fejlődik tovább.
Én a napokban ki fogom próbálni. Ha van kedved, tedd meg te is – a GitHub repository nyilvánosan elérhető, az installation guide mindössze néhány előfeltételt igényel.
Még az év első felében hallhattad a videómban, hogy miért jó a Google Cloud. Ebben a videóban röviden összefoglaltam a legfontosabb dolgokat. Említettem, hogy a Google, mint AI-first cég, már nagyon régen használ mesterséges intelligenciát a mindennapi működése során. Ennek ellenére, még mindig csak a harmadik „nagy” felhő-szolgáltató az AWS és az Azure mögött.
Már akkor is azt mondtam, hogy náluk az AI lehet az a pont, ahol van lehetőségük a kiugrásra és a felzárkózásra. Úgy tűnik, ők is így gondolják és most tettek efelé egy lépést.
Nem feltétlenül forradalmi dologra kell gondolni, inkább amolyan „rájöttünk, hogy hogyan kell pozícionálnunk magunkat” lépésre.
Aki régóta dolgozik cloud platformokkal, az már megszokhatta, hogy a nagy szolgáltatók időnként újracímkéznek egy-egy terméket, finomhangolják a portfóliót, aztán megy tovább az élet. Ami viszont 2026. április 22-én a Google Cloud Next konferencián történt, az ennél kicsivel több: a Google Cloud egyszerre nevezte át az egyik legismertebb AI-platformját valamint több adat- és analitikai termékét is, és közben egy új gondolkodásmódot is bevezetett.
Mi változott a néven?
A legfontosabb bejelentés: a Vertex AI Platform beleolvad egy nagyobb ernyőbe, aminek a neve Gemini Enterprise Agent Platform. A hivatalos közlés szerint ez a Vertex AI evolúciója, és mostantól minden Vertex AI szolgáltatás és új fejlesztés ezen a platformon keresztül érhető el, önálló szolgáltatásként nem.
Emellett a Data Analytics oldalon több termék is beszédesebb nevet kapott. A Dataplex Universal Catalog mostantól Knowledge Catalog. A BigLake új neve Lakehouse. A Dataproc mostantól Managed Service for Apache Spark. A Composer új neve Managed Service for Apache Airflow. A Looker Studio pedig Data Studio néven fut tovább.
Ez elsőre soknak tűnhet, de van egy jó hír: a nevek logikája egyszerűbb lett. A „Managed Service for Apache Spark” önmagában elárulja, hogy egy felügyelt Spark szolgáltatásról van szó. Nem kell kitalálnod, mit takar a „Dataproc” márkanév. Ez különösen segít azoknak, akik most ismerkednek a GCP világával, és eddig a saját termékneveket kellett bemagolniuk.
Régi név
Új név
Mit takar?
Vertex AI Platform
Gemini Enterprise Agent Platform
A Google Cloud AI-platformja, mostantól agent-fókusszal: építés, skálázás, kormányzás, optimalizálás egy ernyő alatt
Dataplex Universal Catalog
Knowledge Catalog
Központi adatkatalógus és governance réteg, amely átláthatóvá teszi, hol milyen adat található és ki férhet hozzá
BigLake
Lakehouse
Egységes tárolási réteg a data lake és data warehouse világ között, nyílt formátumokkal
Dataproc
Managed Service for Apache Spark
Menedzselt Spark környezet nagy adatmennyiségek feldolgozásához, klaszterkezelés nélkül
Composer
Managed Service for Apache Airflow
Menedzselt Airflow szolgáltatás data pipeline-ok ütemezésére és orchestrálására
Looker Studio
Data Studio
Vizualizációs és riportkészítő eszköz dashboardokhoz és adatmegjelenítéshez
Ebből a táblázatból kiolvasható, az egy tudatos iránymutatás a Google részéről. Az AI-platform nevében megjelenik a Gemini és az Agent szó, ami egyértelműen kijelöli, merre megy a termékstratégia. A Data Analytics oldalon pedig a saját márkanevek helyett leíró, iparági szabvány szerinti elnevezések kerültek előtérbe: Spark, Airflow, Lakehouse. Ez sokak számára hasznos, mert ezek a fogalmak más cloudokban és on-premise világban is ugyanezt jelentik.
Mi marad változatlan?
A Google Cloud kommunikációja ebben a kérdésben egyértelmű: a projektjeid, a konfigurációk és az árazás nem változik. A számlázásod ugyanúgy fut tovább, és a meglévő elmentett linkek automatikus átirányítással működnek a konzolon belül. Az SKU megjelenítési nevek és leírások ugyan frissülnek a következő hónapokban, de a Data Analytics SKU-k nevei változatlanok maradnak.
Ez fontos üzenet: Egy enterprise ügyfél számára a legnagyobb kockázat nem egy új név, hanem ha egy átnevezés mögött rejtett árváltozás vagy kényszerű migráció áll. Itt most nem ez a helyzet. Mégis azt tanácsolom, hogy ha céges környezetben dolgozol, érdemes átfésülni a belső dokumentációt, runbook-okat és oktatási anyagokat, mert a kollégák fél év múlva már az új neveken fogják keresni ezeket a szolgáltatásokat.
Miért Agent Platform?
A Gemini Enterprise Agent Platform neve nem véletlen. A Google Cloud hivatalos bejelentése szerint a platform négy fő képességre épül: Build, Scale, Govern és Optimize. Olyan komponensek tartoznak ide, mint az Agent Studio a low-code építéshez, az Agent Development Kit a kódalapú fejlesztéshez, az Agent Runtime a futtatáshoz, a Memory Bank a hosszú távú kontextushoz, valamint az Agent Identity, Agent Registry és Agent Gateway a kormányzáshoz.
Mit is jelentenek ezek?
Build: az agentek felépítése, legyen szó low-code vizuális eszközről (Agent Studio) vagy kódalapú fejlesztésről (Agent Development Kit).
Scale: az agentek futtatása éles környezetben, stabil teljesítménnyel, hosszú távú kontextussal és memóriakezeléssel (Agent Runtime, Memory Bank).
Govern: az agentek felügyelete: minden agent saját azonosítót kap, központi regiszterbe kerül, és egységes biztonsági szabályok mentén működik (Agent Identity, Agent Registry, Agent Gateway).
Optimize: az agentek viselkedésének mérése és finomhangolása éles forgalom alapján, tesztekkel, megfigyelhetőséggel és automatikus javaslatokkal (Agent Simulation, Agent Evaluation, Agent Observability).
Hogy ez mit jelent a gyakorlatban, arra mondok egy egyszerű példát:
Képzelj el egy biztosítót, amelynél egy AI-agent fogadja az ügyféligényeket, lekérdezi a belső rendszereket, majd ha kell, átad egy másik agentnek, aki a kárrendezést indítja el. Eddig ehhez sok külön eszközt kellett összedrótozni. Az Agent Platform ígérete az, hogy ezek egy közös platformon, egységes identitással, auditálhatóan és biztonsági kontrollokkal futnak. Azt, hogy ez a gyakorlatban minden környezetben problémamentesen működik-e, még nem tudom biztosan, de a koncepció iránya egyértelmű: az egyedi AI-feladatoktól haladni egy kormányzott agent-ökoszisztéma felé.
Hogyan illeszkedik ez a többi cloudhoz?
Érdemes megnézni, mit csinálnak a nagy versenytársak. Az AWS-nél a Bedrock és az Amazon Q köré épül az agentek világa, az Azure-nál pedig az Azure AI Foundry és a Microsoft Copilot Studio vonal adja a hasonló irányt. Mindhárom szereplő ugyanabba az irányba megy: nem elég egy jó modell, szükség van futtatókörnyezetre, identitáskezelésre, megfigyelhetőségre és governance-re.
Ez karriertervezés szempontjából is fontos jelzés. Ha most lépsz be a cloud vagy AI világába, ne csak a modellekkel és a prompttal foglalkozz. Sokkal értékesebb tudás, ha érted, hogyan kell egy agentet biztonságosan integrálni egy vállalati környezetbe, hogyan figyeli a csapat a működését, és hogyan kontrollálja a költségeit.
Hasznos tippek a folytatáshoz
Ahogy a hagyományos cloud workloadok esetén, az AI-agenteknél is ugyanazok a hibák jönnek elő, amelyeket sok cégnél elrontanak. Az első klasszikus csapda a tervezés nélküli használat: valaki elindít egy agentet teszteléshez, aztán elfelejti leállítani, és hónapokig fut a háttérben. Ez ugyanaz a történet, mint amikor egy fejlesztői VM-et nem állítanak le éjszakára, és a hónap végén megérkezik a meglepetés a számlán.
A második ilyen a governance hiánya. Ha bárki szabadon hozhat létre agenteket, saját jogosultságokkal, saját eszközökkel, akkor hamar ott állsz egy átláthatatlan ökoszisztéma közepén. Pontosan ezért emeli ki a Google az Agent Identity és az Agent Registry szerepét: minden agentnek legyen azonosítója, és legyen egy központi hely, ahol látható, mi fut, milyen jogosultsággal.
A harmadik terület a biztonsági alapok kihagyása. A legtöbb startup jellegű projektben érthetően először az a cél, hogy egyáltalán működjön valami. Ez rendben is van, a simplicity elv szerint először legyen egy működő megoldás. De még mielőtt élesbe kerülne, érdemes átgondolni a legalapvetőbb kérdéseket: milyen adatokhoz fér hozzá az agent, ki láthatja a logokat, és mi történik hiba esetén.
Záró gondolatok
Három gondolatot szeretnék ezzel átadni neked. Az első: ne memorizálj szolgáltatásneveket, inkább értsd meg a mögöttes fogalmakat és összefüggéseket. Egy felügyelt Spark szolgáltatás az AWS-en EMR, a Google Cloud-on Managed Service for Apache Spark, és az Azure-on Synapse vagy Fabric környezetben találsz hasonlót. A fogalom ugyanaz, a csomagolás más. (Erről hamarosan majd közzé is teszek egy interaktív szótárat.)
A második: a költségtudatosság sosem megy ki a divatból. Minden új agent, minden új adatpipeline pénzbe kerül, és a leggyakoribb hiba, hogy ezt csak utólag vesszük észre. Váljon szokásoddá, hogy minden erőforráshoz hozzágondolod a kérdést: mit kapcsoljak ki, ha nem használom?
A harmadik: a jövőállóság nem jóslás, hanem kíváncsiság. Nem tudjuk pontosan, merre megy a piac öt év múlva, de azt látjuk, hogy az agent-alapú világ egyre több felületen jelenik meg. Aki most megérti a governance, az identity és az observability szerepét, az bármelyik platformon könnyen átül.
Habár a név megváltozott, de a tanulság a régi: a Cloud-ban és az AI-ban nem feltétlenül az nyer, aki a leggyorsabban vág bele, hanem aki tudatosan építkezik.
Korábban írtam, hogy a tanúsítvány nem helyettesíti a tapasztalatot. Valójában arra alkalmas, hogy felmérjük, hol állunk az egyes szolgáltatók mércéje szerint a piacon.
Nálam emellett más szerepe is van, hiszen rendszeresen készítek fel szakembereket Cloud-os vagy AI-os vizsgákra a mentor programom keretében. Ezért nekem is kell ismernem a vizsgák tartalmát.
Emiatt az idei évre egy érdekes kihívást találtam ki magamnak: A terv az, hogy az év első felében minden hónapban leteszek egy felhővel vagy AI-val kapcsolatos vizsgát.
Februárban a Google Cloud Generative AI Leader vizsgára esett a választás. Ez számomra észszerű lépés volt. Bár alapvetően felhővel foglalkozom, az AI világával már több mint három éve foglalkozom mélyebben. Az elmúlt években rengeteg projektben találkoztam LLM modellekkel, prompt engineering-el, RAG architektúrákkal és különböző AI szolgáltatásokkal. Így ez a vizsga egy logikus lépésnek tűnt.
Miről szól a Generative AI Leader vizsga?
A Generative AI Leader vizsga azt méri, hogy mennyire érted a generatív AI működésének alapjait, és hogy képes vagy-e felismerni, milyen üzleti problémákra érdemes AI megoldásokat alkalmazni.
Fontos kiemelni, hogy ez nem egy mély technikai vizsga. Nem kell modelleket tréningezni vagy kódot írni.
Ennek ellenére nem nevezném kezdő szintűnek sem. A vizsga feltételez egy alap AI tudást, például az alábbi területeken:
generatív AI működése
LLM modellek alapjai
prompt engineering alapfogalmak
AI használati esetek
felelős AI használat
A kérdések nagy része inkább szituációs jellegű. Például egy adott üzleti problémára kell kiválasztani a megfelelő AI megközelítést vagy szolgáltatást. Ez az ilyen vizsgáknál ugyan alapvető, de biztosan vannak olyan olvasóim, akik még nem vettek részt ilyen vizsgán. Nekik segítség lehet, ha el tudják képzelni, hogy milyen típusú kérdésekre lehet számítani.
Google Cloud generatív AI szolgáltatások
A felkészülés során több Google Cloud AI szolgáltatás is előkerül. Ezek közül néhány a generatív AI ökoszisztéma fontos része.
Vertex AI
A Vertex AI a Google Cloud központi machine learning és AI platformja. Itt lehet modelleket tréningezni, finomhangolni és éles környezetben futtatni.
Generatív AI esetén a Vertex AI biztosít hozzáférést különböző foundation modellekhez, valamint eszközöket a modellek kiértékelésére és üzembehelyezésére.
Vertex AI Studio
A Vertex AI Studio egy olyan fejlesztői környezet, ahol gyorsan ki lehet próbálni generatív modelleket.
Például itt lehet:
promptokat tesztelni
model paramétereket állítani
prototípus AI alkalmazásokat készíteni
Ez egy nagyon jó eszköz kísérletezésre és tanulásra.
Gemini modellek
A Gemini a Google generatív AI modellcsaládja. Ezek a modellek képesek többek között:
szöveg generálásra
kód generálásra
multimodális feladatok kezelésére
A Gemini modellek integrálhatók különböző Google Cloud szolgáltatásokkal és alkalmazásokkal.
Model Garden
A Model Garden egy olyan gyűjtemény a Vertex AI környezeten belül, ahol különböző előre elkészített modellek érhetők el. Ezek lehetnek Google által készített modellek vagy nyílt forrású modellek.
Ez segít abban, hogy a fejlesztők gyorsan kipróbálhassanak különböző modelleket anélkül, hogy mindent a nulláról kellene felépíteni.
Hogyan készültem fel a vizsgára?
A felkészülés meglepően élvezetes volt.
Habár már több projekten is dolgoztam ezeken a szolgáltatásokon, jó volt rendszereznem magamban is az ezzel kapcsolatos tudást és tapasztalatot. Ehhez a Google saját tananyaga nagyon jó alapot ad a vizsga témáinak megértéséhez. Ezek az anyagok strukturáltan mutatják be a generatív AI koncepciókat és a Google Cloud AI szolgáltatásait.
Emellett a YouTube-on is rengeteg ingyenes tananyag található. Több olyan videós kurzus is van, amely kifejezetten erre a vizsgára készít fel. Ezek közül, talán ez freeCodeCamp.org Google Generative AI Leader Certification Course videója a leghasznosabb.
Ami nekem külön tetszett, hogy a vizsga nem csak technológiáról szól.
Hanem arról is, hogy:
mikor érdemes AI-t használni
mikor nem
milyen kockázatai vannak
hogyan lehet felelősen bevezetni
Ez a gondolkodásmód egyre fontosabb a vállalati környezetben.
A vizsga élménye
Őszintén szólva nagyon élveztem.
A kérdések sok esetben valóshoz hasonló helyzeteket modelleznek. Nem az a típusú vizsga, ahol definíciókat kell visszamondani. Sokkal inkább arról szól, hogy érted-e az AI működésének alapjait, és képes vagy-e alkalmazni ezt a tudást egy adott problémára.
És igen…Megvan ez a vizsga is.
Mi jön ezután?
A következő cél már a márciusi vizsga: az Azure AI-900.
Ez egy alap AI vizsga a Microsoft ökoszisztémában, amely az AI alapfogalmait, az Azure AI szolgáltatásokat és a generatív AI megoldásokat mutatja be. Ez azonban elvileg jóval nehezebb, mint a Google Generative AI Leader.
Ha minden a terv szerint halad, hamarosan erről a vizsgáról is írok majd egy külön cikket.
És ne feledd: a tanúsítvány nem helyettesíti a tapasztalatot.
Már láthattad, mire elég az Azure és az AWS Free Tier szolgáltatásai. Biztos vagyok benne, hogy kíváncsi vagy arra is, mit ad ingyen a Google Cloud – és vajon ez mennyire használható valódi projektekhez.
A GCP sokszor csendesebb szereplő, mégis vannak területek, ahol kifejezetten erős. Nézzük meg, mit kapsz ingyen, és mit nem.
A GCP Free Tier három pillére
Ahogy a többi szolgáltató esetén, a Google Cloudingyenes lehetőségei is három fő részből állnak:
90 napos induló kredit (jellemzően 300 USD)
Mindig ingyenes (Always Free) szolgáltatások (időkorlát nélkül, havi kvótával)
Bizonyos szolgáltatások limitált, ingyenes használata kvótához kötve
90 napos induló kredit – nem kevés
Regisztráció után a Google jellemzően 300 USD kreditet biztosít, amely 90 napig használható.
Ez arra való, hogy:
kipróbáld a Compute Engine nagyobb VM-jeit
indíts GKE (Kubernetes) cluster-t
tesztelj Cloud SQL-t
AI/ML szolgáltatásokat próbálj ki
felépíts egy kisebb környezetet, ahol valóban gyakorolhatsz.
Ez tanulási és teszt környezet építésre való, nem éles üzleti rendszerre.
Mindig ingyenes – kvótatáblázat
Az alábbi táblázat a főbb Always Free kvótákat foglalja össze havi bontásban. Régiós korlátozások érvényesek (bizonyos USA régiók). A teljes, folyamatosan frissülő listát itt találod.
Compute és infrastruktúra
Szolgáltatás
Havi Always Free kvóta
Compute Engine (e2-micro)
1 db e2-micro VM (kijelölt régiók)
Persistent Disk (standard)
30 GB
Snapshot
5 GB
Cloud Storage (Standard)
5 GB
Cloud Storage Class A művelet
5 000 / hó
Cloud Storage Class B művelet
50 000 / hó
Serverless és konténer
Szolgáltatás
Havi Always Free kvóta
Cloud Run
2 millió request
Cloud Run CPU
180 000 vCPU-másodperc
Cloud Run memória
360 000 GB-másodperc
Cloud Functions
2 millió invokáció
Pub/Sub
10 GB üzenetforgalom
Adat és analitika
Szolgáltatás
Havi Always Free kvóta
BigQuery lekérdezés
1 TB
BigQuery storage
10 GB aktív tárolás
Firestore
50 000 olvasás / nap
Firestore
20 000 írás / nap
Firestore
20 000 törlés / nap
CI/CD és fejlesztés
Szolgáltatás
Havi Always Free kvóta
Cloud Build
120 build perc / nap
Artifact Registry
Limitált tárolás
Mire elég ez valójában?
Most jöjjenek a példák, hogy mire is lehet elég az ingyen felhő. A GCP kicsit más mint a többi szolgáltató, így itt kicsit más példákat is hoztam.
1. Személyes költségkimutatás
Képzeld el, hogy építesz egy saját pénzügyi dashboard-ot.
Cloud Run: backend API
Firestore: tranzakciók tárolása
BigQuery: havi aggregált kimutatások
Cloud Storage: CSV import
Ezzel kipróbálhatod az adatmodellezést, a jelentés készítést és az SQL analitika építést.
2. Naplóbejegyzések gyűjtse és elemzése
Ha DevOps irányba mész, építhetsz egy egyszerűnek tűnő, mégis hasznos log pipeline-t.
Pub/Sub: log események fogadása és továbbítása
Cloud Run: feldolgozó logika
BigQuery: tárolás és lekérdezés
Megtanulod, hogy mi az event-driven architektúra, az adatfolyam modellezés és a költséghatékony adattárolás. A havi 1 TB lekérdezési keret tanulásra bőven elég.
3. AI asszisztens backend a weboldaladhoz
Egészítsd ki a weboldalad egy chatbottal, aki válaszol a látogatók kérdéseire.
Arra is figyelj , ha nagy mennyiségű adatot kérdezel le BigQuery-ben rendszeresen, az 1 TB gyorsan elfogy. Valamint jelentős egress forgalom esetén, az nem „mindig ingyenes”. Amikor GPU-s AI training instance-et indítasz, a 90 napos kredit is gyorsan kimerülhet.
Általános költségkezelési problémák és megoldásuk
Minden képzésemen el szoktam mondani az alábbiakat, mert sosem árt ismételni.
Használj lifecycle szabályokat és rendszeres takarítást
A Billing menüpont alatt könnyen beállítható:
költségkeret
értesítés
projektenkénti költségkontroll
A felhő mindig egy másfajta szemléletet kíván. Ez csak az elején nehéz, utána belerázódsz.
Összegzés
A GCP Free Tier nem arra való, hogy production rendszert építs rá.
Arra viszont nagyon is jó, hogy megtanuld a Google Cloud gondolkodásmódját: serverless működés, adatközpontú tervezés, menedzselt szolgáltatások és az AI szolgáltatások integrálása.
Fel tudsz vele építeni valós, bemutatható projekteket – akár adat-elemzési, akár AI asszisztens jellegű megoldásokat.
Korábban már beszéltem az Azure-ről és az AWS-ről, mint lehetséges felhőplatformról 2026-ban. Ebben a videóban a Google Cloud Platformot (GCP) mutatom be, ami egy AI-first szemléletű felhő.
Az AI-first stratégia lényege, hogy a Google a mesterséges intelligenciát tette minden terméke és szolgáltatása alapvető mozgatórugójává, így az már nem csak egy extra funkció, hanem az elsődleges fejlesztési szempont. Ez a szemléletmód a felhasználóhoz alkalmazkodó, segítőkész technológiát és saját, specifikus hardveres infrastruktúrát (például TPU-kat) állít a cég teljes működésének középpontjába.
A Google Cloud egyik legnagyobb erőssége, hogy itt az AI nem kiegészítő, hanem alapértelmezett része a platformnak. A videóban szó lesz a Gemini modellcsaládról, a Vertex AI-ról, az adatplatformok szerepéről, és arról is, hogy kinek lehet jó választás a GCP.
Azt is elmondom, mikor nem ideális a Google Cloud, például klasszikus enterprise lift-and-shift megközelítés esetén.
Itt az év elején kiváló alkalom kínálkozik arra, hogy megválaszoljam az egyik leggyakrabban felmerülő kérdést a cloud világában, amit rendszeresen feltesznek nekem a diákjaim és a mentoráltjaim is:
Azure, AWS vagy GCP?
Ez a kérdés szinte mindenkinél előjön. Kezdőknél, karrierváltóknál, de még olyanoknál is, akik már dolgoztak valamelyik platformmal. Megnézel pár videót, elolvasol néhány cikket, és könnyen azt érzed, hogy most azonnal döntened kell. Mintha ez egy végleges választás lenne.
Én viszont mást tapasztaltam. Az elmúlt években többször változott, hogy melyik platform áll közelebb hozzám, és ez teljesen rendben van. A cikk végén el is árulom, 2026 elején én személy szerint melyiket kedvelem jobban – és miért.
Ez az írás nem egy részletes összehasonlítás, hanem egy iránymutatás és gondolatindító, amely segít csökkenteni a döntés körüli bizonytalanságot.
Ez azt jelenti, hogy hosszú távon egyik platform sem korlátoz technikailag. A különbség inkább ott jön elő, mennyire könnyű elindulni és átlátni, hogy mi történik a háttérben.
Azure – érthető nyelv, strukturált gondolkodás
A Microsoft Azure egyik legnagyobb előnye az őszinte, egyértelmű elnevezés.
Ez tanulás közben óriási segítség. Nem kell egy külön „cloud nyelvet” megtanulnod ahhoz, hogy megértsd az alapokat, hanem mindent úgy használhatsz, ahogy eddig hallottad, olvastad vagy tudtad.
A portál megjelenése sokszor konzervatív, de cserébe nagyon jól támogatja az átláthatóságot. Az erőforráscsoportok, címkék és szűrők segítenek rendet tartani, ami később költség és üzemeltetés szempontjából is kritikus.
Fontos különbség kezdőknek: az Azure felülete és dokumentációja magyar nyelven is elérhető. Ez nem kötelező, de az elején komoly mentális terhet vesz le a válladról. Azt azonban fontos szem előtt tartani, hogy a magyar nyelv gépi fordítású, tehát bizonyos esetekben nem a legkellemesebb olvasni azt. Ezen felül a portálon is észrevehető több esetben hogy egy-egy szolgáltatás több néven szerepel, attól függően, hová kattintunk. Ez zavaró lehet.
2026. elején az Azure iránti érdeklődés különösen erős az AI-integrációk miatt, főleg az OpenAI-hoz kapcsolódó szolgáltatások és az enterprise fókusz miatt.
AWS – cloud-native szemlélet, maximális rugalmasság
Az Amazon Web Services filozófiája más. Itt szolgáltatásokban gondolkodsz, nem projektekben.
A konzol letisztult, gyors, viszont nem mutat meg mindent egy helyen. Kezdőként ez zavaró lehet, később viszont sokkal hasznosabb lehet, mert nagy rendszereknél jobban átlátható, ahol egy-egy szolgáltatást szeretnénk csupán egyszerre kezelni.
Az integrációk erősek, az automatizálás természetesen konfigurálható, a cloud-native irány itt nagyon hangsúlyos. Ha valaki szeret mélyebben rendszerekben gondolkodni, az AWS kiváló terep.
A klasszikus nehézség a jogosultságkezelés. Az IAM nagyon erős, de kezdőként könnyű túlbonyolítani. Ha egyszer összeáll a kép, utána már nem probléma – de az elején hosszabb a tanulási folyamat. Ezt tovább nehezíti, hogy kifinomult jogosultságokat több módon is be lehet állítani, amelyeket nagyrészt JSON objektumokon keresztül érhetünk el. Semmi esetre sem hátrány ez, csupán egy lassabban elsajátítható tulajdonság.
Fontos különbség: AWS esetén nincs magyar nyelvű felület vagy dokumentáció, minden angolul érhető el.
GCP – mérnöki logika, adat és AI fókusz
A Google Cloud Platform sokszor kevesebb figyelmet kap, pedig technikailag nagyon erős.
A GCP egyik legnagyobb előnye a letisztult, mérnöki megközelítés. Sok szolgáltatás mögött ugyanaz a technológia van, amit a Google saját rendszereinél is használ. Ez különösen az adatfeldolgozás és AI területén érződik.
A felület általában egyszerűbb, kevésbé zsúfolt, mint a másik kettőnél. Elsőre is könnyű átlátni, mi történik, viszont kisebb az „enterprise cucc”, mint Azure vagy AWS esetén. Ez nem azt jelenti, hogy nem alkalmas nagyvállalati megoldások megvalósítására.
A GCP erős:
adatplatformokban
gépi tanulásban
Kubernetes-közeli megoldásokban
Ugyanakkor fontos látni: GCP-nél sincs magyar nyelvű felület vagy dokumentáció, minden angolul érhető el, és bizonyos enterprise minták kevésbé nyilvánvalóak, mint Azure-ban.
Mesterséges Intelligencia 2026-ban – mindhárom jó választás
Azure, AWS és GCP is komolyan veszi az AI-t. Más hangsúlyokkal, más eszközökkel, de mindhárom platform alkalmas valós üzleti megoldásokra.
Amit viszont mindig hangsúlyozok: az AI sem varázslat. Cloud alapokra épül, hálózatra, biztonságra, költségkeretekre. Ha ezek nincsenek rendben, az AI sem fog csodát tenni.
A felhő is csak akkor költséghatékony, ha okosan használjuk.
Hogyan válassz, ha most kezdesz bele?
Én ezt a gondolkodást javaslom:
ne technológiát válassz, hanem tanulási élményt: melyik esik kézre, melyik megértése egyszerűbb számodra
melyik motivál hosszabb távon: amelyik tetszik, azt válaszd
ne akarj mindent egyszerre megtanulni: a fokozatosság a kulcs
fogadd el, hogy a döntés nem végleges: a szolgáltatók is változnak és Te is. Ma még ezt kedveled, holnap a másikat. Ez rendben van.
Ha számodra a Microsoft-os háttér és az OpenAI a fontos, akkor merülj el az Azure világában. Cloud-native megoldások érdekelnek és a mély technikai megvalósítások, ez esetben az AWS lesz a Te utad. Ha pedig az adat, vagy a gépi tanulás, esetleg a Kubernetes-közeli világ foglalkoztat, akkor nézd meg a GCP-t.
Amit vállalati oldalon látok
A nagyvállalati valóság az, hogy a cégek többsége egyetlen hyperscaler-re fókuszál. Nem azért, mert ne ismernék a vendor lock-in kockázatát, hanem mert a gyorsaság, az egyszerűbb működés és a költségkezelés fontosabb számukra.
Sok esetben a vendor lock-in tudatos kompromisszum. Mire valódi problémává válna, a rendszer már annyira mélyen beágyazódott az adott felhő ökoszisztémájába, hogy a kiszállás csak jelentős költségek és komoly átalakítás árán lenne lehetséges. Ilyenkor inkább együtt élnek vele.
Reális alternatívaként gyakran hibrid megoldások jelennek meg, főleg hagyományos rendszerek, adatvédelmi vagy compliance okok miatt. Ez sokszor kezelhetőbb, mint több hyperscaler párhuzamos használata.
Én az ideális állapotot máshogy látom. Egy olyan több-felhős megközelítésben, ahol minden szolgáltatótól azt használom, amiben valóban erős, miközben tudatosan figyelek arra, hogy ne zárjam be magam visszafordíthatatlanul egyetlen platformba.
Számomra ez olyan, mintha egy különleges menüt állítanék össze a legjobb éttermek kínálatából. A végeredmény kiváló lehet, de több tervezést, nagyobb szakmai érettséget és folyamatos odafigyelést igényel. Nem a legegyszerűbb út, de hosszú távon a legkiegyensúlyozottabb.
A siker nem azon múlik, melyik platformot választod, hanem azon, hogy:
érted-e az alapelveket
költségtudatosan tervezel-e
biztonságban gondolkodsz-e már az elején
egyszerű és a megfelelő megoldásokkal indulsz-e
Számomra melyik?
2026 elején összességében az AWS áll közelebb hozzám. Nem azért, mert az Azure rossz lenne – sőt, AI területen jelenleg egyértelműen erős, különösen enterprise környezetben. Ezt kár lenne vitatni.
Amiért nálam most mégis az AWS a „nyerő”, az inkább rendszerszintű gondolkodás kérdése. Az AWS szolgáltatásai, integrációi és a cloud-native szemlélet sok esetben jobban illeszkednek ahhoz, ahogyan ma infrastruktúrát és platformokat tervezek. Nagyobb szabadságot ad, kevesebb röghöz kötött megoldással, ami számomra most előny.
Hangsúlyozom: Ez nem végleges álláspont. Volt már olyan időszak, amikor az Azure volt előrébb, és könnyen lehet, hogy lesz még ilyen. A cloud világában a technológia és az igények is gyorsan változnak – ezzel együtt a preferenciák is.
A lényeg nem az, hogy melyik platform jobb, hanem az, hogy tudd, miért választasz egyet egy adott helyzetben.
Zárásképpen
Az Azure, az AWS és a GCP valós piaci versenytársak. Más üzleti fókusz, más ökoszisztéma, más erősségek mentén fejlődnek. A gyakorlatban viszont a legtöbb mérnök és cég nem „platformhűség”, hanem konkrét problémák és költségek alapján dönt.
Továbbra sem az a legfontosabb kérdés, hogy melyiket választod elsőre, hanem az, hogy:
értsd a cloud alapelveket,
tudd, mikor melyik platform miért jó választás,
és képes legyél később váltani vagy több platformban gondolkodni.
A platformválasztás csak egy döntés. A valódi érték abból jön, ha tudatosan és magabiztosan használod.
Ha ebben szeretnél előrébb lépni, több módon is tudlak támogatni:
Az előző cikk végén ott hagytuk abba, hogy 2026-ban a cloud már nem cél, hanem eszköz. Egy gondolkodásmód, amire a legtöbb digitális rendszer épül. A következő lépés viszont már nem pusztán erről szól. Az igazi változás ott kezdődik, amikor az AI nem csak használja ezt az alapot, hanem formálni is kezdi a felhőt.
Ez a cikk erről a személetváltásról szól. Nem arról, hogy melyik modell jobb, és nem is technikai útmutató. Sokkal inkább arról, milyen szerepe lett és lesz az AI-nak a cloud működésében, és milyen következményei vannak ennek technológiai, gazdasági és döntési szinten.
Az AI szerepe a Cloud-ban megváltozott
Az AI ma már nem külön projektként jelenik meg a felhőben. Nem egy újabb doboz a sok közül, hanem platformszintű képesség. A cloud szolgáltatók nem egyszerűen futtatási környezetet adnak hozzá, hanem olyan rétegeket építenek köré, amelyek az AI-t beemelik a mindennapi működésbe. Mindehol ott a Co-Pilot jellegű működés, amely arra hivatott, hogy segítse a mindennapjainkat. Bár néha kifejezetten idegesítő.
Ez jól látszik abban, ahogyan a hyperscalerek pozicionálják az AI-t. Nem egyetlen „AI termékről” beszélnek, hanem olyan szolgáltatásokról, amelyek architektúra-tervezést, skálázást, költségoptimalizálást vagy incidensek értelmezését is támogatják. Fontos: Az AI nem helyettesít, hanem döntési teret alakít át.
Azure, AWS és GCP – „minden út Budára vezet”
A Microsoft Azure esetében az AI erősen az LLM-vonal köré szerveződik. Az Azure OpenAI Service és az erre épülő enterprise megoldások azt mutatják, hogy az AI szorosan integrálódik az üzleti folyamatokba. Nem önmagában érdekes, hanem azért, mert ott jelenik meg, ahol a felhasználók dolgoznak. Persze ez csak egy nagyon apró része annak az AI funkcionalitásnak és trendnek, amit ma ismerünk.
Az AWS más irányból érkezett. Régóta erős a machine learning területén, és ezt a tapasztalatot vitte tovább platformlogikába. A Bedrock a generatív AI-t teszi elérhetővé felügyelt módon, míg a SageMaker AI a klasszikus ML-életciklust fedi le. Az üzenet itt nem a modell, hanem az eszköztár és az irányíthatóság.
A Google Cloud Platform pedig azért érdekes, mert az AI nem új irány nála. A Google belső rendszerei évek óta AI-ra épülnek, és ez a szemlélet jelent meg a Vertex AI köré szervezett cloud kínálatban. Itt az adat és az AI szoros összekapcsolása kerül fókuszba.
A közös pont mindhárom esetben az, hogy az AI nem kiegészítő, hanem a platform működésének része lett.
Miért lett a cloud az AI természetes közege?
Sokan még mindig hardveroldalról közelítik meg az AI-t: milyen GPU kell hozzá, mennyi memória, elég-e egy erős otthoni gép. Ez a gondolkodás érthető, de egyre kevésbé írja le a valóságot.
A cloud egyik legnagyobb előnye az AI esetében nem pusztán a teljesítmény, hanem a skálázhatóság és az időbeliség. Olyan erőforrások érhetők el rövid időre is – több terabájt memória, több nagy teljesítményű GPU egy környezetben –, amelyek otthoni vagy kisebb on-prem környezetben nem reálisak.
A valódi szemléletváltás azonban ott történik, hogy az AI jellemzően felügyelt (managed) szolgáltatásként jelenik meg. Nem kell CPU-, RAM- vagy GPU-konfigurációval foglalkozni, nem kell drivereket, frameworköket karbantartani. Ezeket a problémákat a platform kezeli.
Személyes megjegyzésként idekívánkozik, hogy 2026-ban én is szert tettem egy aránylag erős helyi gépre, kifejezetten AI-val való kísérletezésre és fejlesztésre. Egy Ryzen 7 7800X3D, 64 GB RAM és egy RTX 3090 24GB körüli konfiguráció már alkalmas arra, hogy kis- és közepes modellekkel dolgozzak, tanuljak, prototípusokat építsek.
De ez a tapasztalat inkább megerősítette bennem: amit helyben lehet, az tanulás és kísérletezés.Amint skálázni, párhuzamosítani vagy üzemszerűen használni szeretnék, a cloud egyszerűen más ligában játszik.
És itt előtérbe kerül az árazás és az árazási modellek megértése a felhőben. Otthon az a kérdés, hogy elég-e a gép. A felhőben az, hogy mennyibe kerül, ha így használom. Ez az egyik oka annak, hogy az AI a cloud-ban nem hobbi-megoldásként, hanem üzemszerűen terjedt el.
Az AI hatása a hardverpiacra
Az AI és a cloud együtt nem csak szoftveres változást hozott. A hardverpiacon is érezhető a hatása. Az adatközponti AI igény nem csak GPU-kat szív fel, hanem memóriát is – különösen nagy sávszélességű és szerveroldali megoldásokat.
A piaci elemzések és üzleti hírek egyre gyakrabban kötik össze a memóriaárak alakulását az AI-adatközpontok növekvő igényével. A hangsúly eltolódott: a gyártók és beszállítók számára a hyperscalerek váltak a legfontosabb ügyfelekké.
A változás egyik leglátványosabb következménye az árakon látszik. Egyes GPU- és memóriaszegmensekben 2024–2025 során 1,5–3× közötti áremelkedés volt tapasztalható, különösen ott, ahol az adatközponti AI-igény közvetlenül megjelent. Ez nem egységes a teljes piacon, de jól mutatja az irányt: amikor a hyperscalerek és nagyvállalatok tömegesen vásárolnak, a fogyasztói és kisebb üzleti piac háttérbe szorul.
Ezt a folyamatot jól szemlélteti az NVIDIA bevételeit bemutató ábra. A sávok azt mutatják, hogyan vált a Data Center (DC) üzletág – vagyis a Cloud-os, AI-fókuszú infrastruktúra – a domináns bevételi forrássá, miközben a Gaming és az egyéb szegmensek aránya háttérbe szorult. A grafikon nem csak növekedést, hanem súlypont-eltolódást jelez: az AI ma már elsősorban adatközpontokban él.
Adatbiztonság és a félreértések
Az AI + Cloud kapcsán az egyik legtöbb bizonytalanságot az adatkezelés okozza. Sok félelem nem konkrét tapasztalatból, hanem feltételezésekből fakad. Gyakori gondolat, hogy a Cloud-os AI „biztos betanítja az adatokat”.
A valóság ennél árnyaltabb. A nagy cloud szolgáltatók dokumentációja különbséget tesz az alapértelmezett működés és az explicit engedélyezett tréning között. Enterprise környezetben az ügyféladatok jellemzően elkülönítve maradnak, és nem kerülnek más ügyfelekhez vagy alapmodell-tréningbe engedély nélkül.
Ugyanakkor fontos kimondani: a cloud nem varázslat. Az adatbiztonság nem automatikus. A shared responsibility modell itt is érvényes. A platform adja az alapokat, de a jogosultságkezelés, a hozzáférések és az adathasználat kontrollja továbbra is az ügyfél döntése.
A félelmek egy része abból fakad, hogy sokan a mai napig nem értik pontosan, hogyan működik egy AI. A modell, a tréning, az inference és az adatkezelés gyakran egyetlen „fekete dobozzá” mosódik össze a fejekben. Ha nem világos, mi történik egy kérdés elküldésekor, hol fut a feldolgozás, és mi marad meg belőle, akkor természetes reakció a bizalmatlanság. Ez a bizonytalanság nem rosszindulatból fakad, hanem információhiányból.
Ezért a zavar valószínűleg 2026-ban sem fog teljesen eltűnni. Nem azért, mert a szolgáltatók ne lennének egyre transzparensebbek, hanem mert az AI használata gyorsabban terjed, mint ahogy a szervezetek megtanulják helyesen értelmezni a működését.
Mit várhatunk 2026-ban az AI + Cloud területén?
Az AI és a Cloud együtt nem új trend, hanem új működési környezet. Kevesebb manuális döntés látszik, de több döntés történik a háttérben. Kevesebb technikai akadály, de nagyobb felelősség.
Azok járnak jól ebben a világban, akik nem csodát várnak az AI-tól, hanem értik, mire használják, és hajlandók felelősséget vállalni a döntéseikért.
2026-ban az AI nem egy kísérleti technológia lesz, hanem egy stratégiai alapvetés, amely a cloud működésének mindennapi részévé válik. A nagy technológiai szolgáltatók és elemzők szerint több irányban is érdemes felkészülni:
• Az AI szerepe tovább mélyül: A korábbi „AI mint eszköz” fázist teljesen felváltja az „AI mint partner” logika – az AI nem csak kérdésekre válaszol, hanem támogatja a döntéseket, együttműködik munkafolyamatokban és gyorsítja a kutatást. Ez nem csak technikai előny, hanem szervezeti és működési átalakulás is.
• Agentic AI és intelligens automatizálás erősödik: A vállalati környezetben 2026-ra szélesebb körben terjednek az olyan AI-agentek, amelyek nem csak input-output feladatokat végeznek, hanem autonómabban lépnek kölcsönhatásba rendszerekkel és döntési folyamatokkal.
• Adat és AI governance fókuszba kerül: A fogyasztók és szervezetek egyre nagyobb figyelmet fordítanak arra, hogyan használja az AI az adatokat, hogyan magyarázható és kontrollálható a működése. Ez nem csupán technikai kérdés, hanem a bizalom és jogi megfelelés alapja.
• Biztonság és infrastruktúra kiemelt téma: A növekvő AI-használat új támadási felületeket és identitás-vezérelt kihívásokat hoz, ezért a kiberbiztonság nem csak háttérfeladat, hanem stratégiai prioritás lesz az AI + Cloud környezetben.
Ezek az irányok nem csupán az én gondolataim, hanema legfrissebb szakmai előrejelzésekkel egybevágó vélemény is.
Az AI nem külön dolog többé, hanem a Cloud működésének szerves, strukturális része lesz.
2026-ban már nem az a kérdés, használod-e az AI-t a Cloudban, hanem az, hogy jól használod-e. Ha ebben szeretnél biztosabb lenni, iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeimet.
Amikor több mint egy évtizeddel ezelőtt először dolgoztam felhővel, még egészen más kérdések foglalkoztatták a cégeket. Mekkora szervert vegyünk? Elég lesz-e két év múlva is? Mikor kell új vasat rendelni, és mennyi idő alatt ér ide? A döntések hónapokra, vagy évekre előre szóltak, és minden hibának ára volt.
Ma, 2026 elején, egészen másról beszélünk. A kérdés már nem az, hogy „használjunk-e felhőt”, hanem az, hogy hogyan használjuk jól.
Ez a cikk nem arról szól, hogyan kell kattintgatni a konzolon, inkább egy helyzetkép: hol tart most a cloud, mit tanultunk az elmúlt években, és mire érdemes készülni rövid távon.
Mi a cloud computing ma, röviden és érthetően
A cloud computing nem egy konkrét technológia, hanem egy működési modell. A lényege egyszerű: erőforrásokat használsz akkor, amikor kell, és csak addig fizetsz értük, amíg valóban szükséged van rájuk. Nem te vásárolsz szervert, nem te cseréled a meghibásodott alkatrészt, és nem neked kell minden részletet kézben tartani.
Fontos kimondani azt is, ami sokszor kimarad: a cloud nem ingyenes, és nem varázslat. Nem lesz tőle automatikusan gyorsabb vagy jobb egy alkalmazás. Viszont ad egy rugalmasságot, amit korábban csak nagyvállalatok tudtak megfizetni.
Egy egyszerű példa: egy webalkalmazás elindítása saját szerverrel ma is működik. Viszont ha hirtelen tízszer annyi felhasználó kezdi el használni, a cloud adja azt a mozgásteret, amivel ezt különösebb kapkodás és túlterhelés miatti leállás nélkül le lehet kezelni.
Mi változott az elmúlt években, és miért fontos ez 2026-ban
Néhány évvel ezelőtt sok helyen uralkodó gondolat volt, hogy „mindent vigyünk fel a felhőbe”. Ez azonban hibás gondolat, úgy ahogy a Scrum sem való minden projekthez. Emiatt ez a hozzáállás ma már egyértelműen kiforrottabb lett. A cégek megtanulták, hogy a cloud nem automatikusan olcsóbb, és a rosszul megtervezett rendszerek itt is gyorsan drágává és átláthatatlanná válhatnak.
2026-ra a cloud érett technológiává vált. Nem a kísérletezésről szól, hanem a tudatos döntésekről. Egyre több szervezet ismeri fel, hogy kevesebb szolgáltatás, egyszerűbb architektúra és átgondolt működés sokszor többet ér, mint a legújabb megoldások halmozása. Annak ellenére, hogy a felhőszolgáltatók sokszor mást sugallnak.
A cloud nem lett rosszabb. Mi lettünk tapasztaltabbak. És elkezdtük hatékonyabban használni.
Mire használják a cégek a felhőt 2026-ban valójában
A legtöbb vállalat ma nem csupán „innovációs lehetőségként” tekint a felhőre. Sokkal inkább stabil alapként. Tipikus felhasználási területek:
üzleti webalkalmazások futtatása
belső rendszerek és API-k
adatfeldolgozás és jelentéskészítés
fejlesztői és tesztkörnyezetek gyors létrehozása
Ezekben a felhasználási esetekben a cloud legnagyobb értéke a gyors indulás és a skálázhatóság. Nem kell mindent előre megtervezni évekre. Lehet kipróbálni, tapasztalni, majd dönteni.
Itt jelenik meg egyre természetesebben az AI is. Nem külön projektként, hanem funkcióként. Keresésben, ügyfélszolgálati automatizmusokban, vagy éppen adatok értelmezésében. A cloud biztosítja azt az alapot, amely nélkül ezek a megoldások nem lennének gazdaságosan működtethetők.
Hogyan indul ma egy kis cég?
Vegyünk egy mai, valós helyzetet. Egy kisebb cég szeretne egy webes alkalmazást indítani, aminek eleinte csak néhány száz felhasználója van, de nem tudják, fél év múlva mi lesz belőle.
2026-ban ilyenkor már ritkán merül fel az, hogy saját szervert vegyenek. Ehelyett:
és tárolják az adatokat egy felhőalapú storage-ban.
Ha az alkalmazás sikeres lesz, a rendszer skálázható. Ha nem válik be, egyszerűen leállítható, nagy veszteség nélkül.
Ez a cloud egyik legnagyobb ereje: nem kell előre mindent tudni, mégis van mozgástér. Ez üzleti oldalról legalább akkora előny, mint technikai szempontból.
Hol találkozol a felhővel a gyakorlatban?
Sokan úgy gondolnak a felhőre, mint valami elvont, „nagyvállalati” dologra, pedig a legtöbben már most is naponta használják – csak nem így hívják. Ha azt mondom: Instagram, TikTok, Gmail, OneDrive és Netflix, akkor azoknak a szolgáltatásoknak a nevét sorolom, ahol naponta találkozol Te is a felhővel.
Amikor egy webalkalmazás gyorsan betölt, amikor egy online rendszer gond nélkül kiszolgál sok felhasználót egyszerre, vagy amikor egy szolgáltatás mögött nincs látható leállás, ott nagyon gyakran „cloud fut a háttérben”.
A felhő a nagy szolgáltatóknál nagyon hasonló alapokra épül.
Például:
Microsoft Azure esetén tipikusan virtuális gépek, menedzselt adatbázisok és tárolószolgáltatások adják az alapot.
Amazon Web Services ugyanezt az elvet követi, csak más elnevezésekkel, megközelítéssel és hangsúlyokkal.
A lényeg nem az, hogy melyik platformon vagy, hanem az, hogy nem nulláról építkezel, hanem kész, kipróbált építőelemekből dolgozol.
Mit jelent a cloud a felhasználók számára
A legtöbb végfelhasználó nem gondolkodik cloudban. Nem is kell. Ők gyors, megbízható szolgáltatásokat várnak el, lehetőség szerint zéró leállással és elfogadható válaszidőkkel. Ha egy alkalmazás lassú vagy elérhetetlen, nem az érdekli őket, hogy hol fut, hanem az, hogy miért nem működik.
2026-ra a cloud ebből a szempontból láthatatlanná vált. Ott van minden mögött, de csak akkor kerül szóba, ha valami nem úgy működik, ahogy kellene. Ez önmagában jelzi az érettségét. Pontosan olyan alapszolgáltatásként tekintünk rá, mint a vezetékes vízre vagy az áramra.
Mit jelent a cloud a karrierváltóknak és pályakezdőknek
Sokan kérdezik tőlem, hogy érdemes-e ma még cloud irányba indulni. A válaszom röviden: igen, de másképp, mint pár éve. Nem az számít, hogy hány szolgáltatás nevét ismered, hanem az, hogy érted-e az alapokat.
2026-ban a cloud jó belépési pont az IT világába azoknak is, akik nem szeretnének mélyen programozni. A rendszerszemlélet, az alap biztonsági gondolkodás és az üzleti igények megértése sokkal fontosabb lett, mint a konkrét implementációs részletek.
Az AI ebben a tanulási folyamatban segíthet, magyarázhat és irányt mutathat, de nem veszi le a döntés terhét a válladról.
A cloud szakember nem attól lesz jó, hogy mindent automatizál vagy mindent tud, hanem attól, hogy felelősséget vállal a döntéseiért és tanul a hibáiból.
Az AI szerepe röviden
Talán észrevetted az AI itt nem főszereplő még, de nem lehet megkerülni. 2026-ban egyértelműen látszik, hogy az AI felerősíti a cloud jelentőségét. Skálázás, költségoptimalizálás, automatizált elemzés mind olyan területek, ahol a kettő együtt ad valódi értéket.
Ugyanakkor fontos határt húzni. A cloud itt még az alap, az infrastruktúra és a platform. Az igazi változás ott kezdődik, amikor az AI már nem csak használja a felhőt, hanem formálja is. Erről szól majd a következő cikkem.
Korlátok, amik 2026-ban is megmaradnak
A cloud nem old meg rossz döntéseket. Nem helyettesíti a gondolkodást, és nem javítja ki a szervezeti problémákat. Rosszul használva továbbra is drága, és könnyen átláthatatlanná válik.
Ez AI-val együtt sincs másképp. Ha nincs világos cél, nincs felelősség és nincs kontroll, akkor a legmodernebb technológia is csak gyorsabban visz rossz irányba.
Útravaló
2026-ban a cloud nem trend, hanem alap. Nem cél, hanem eszköz. Azok a csapatok és szakemberek járnak jól, akik nem csodát várnak tőle, hanem tudatosan használják. A következő lépés viszont már nem csak erről szól. Az AI és a cloud együtt új kérdéseket vet fel, és új válaszokat kényszerít ki.
Erről fog szólni a folytatás…
Ha érdekel, merre halad ez az irány, és hogyan érdemes rá felkészülni, akkor iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeim.
