A tanulás fontos, és sokszor nehéz jó anyagot találni hozzá. A felhő esetén ez hatványozottan igaz, hiszen sok anyag van, de a minőségük vegyes. Az igazán jók pedig még fizetősek is. Ennek mondott ellent az AWS Cloud Quest, ahol például egy digitális világon és különböző küldetéseken keresztül barangolhatunk be egy várost, miközben megismerkedünk az AWS alap szolgáltatásaival. Ez igazán innovatív megoldás volt, ezért ajánlottam már több mentoráltamnak is.
Most pedig itt a hír: augusztus 11-én érkezik a teljesen megújult 2.0-s verzió, és az AWS Community Builder közösségben is érezhető a felfokozott hangulat körülötte.
Mi változik pontosan
A legnagyobb újdonság az úgynevezett AI Dialogue: a feladatok elején egy virtuális ügyféllel folytatsz AI-alapú beszélgetést, ahol jó kérdéseket kell feltenned, mielőtt megoldást tervezel. Ez pontosan az a gondolkodásmód, amit enterprise környezetben is elvárnak egy architect-től. Fontos, hogy ez az egyetlen pont a játékban, ahol AI-t használnak, a labor-feladatok, videók és kvízek továbbra is szakértők által összeállítottak.
Amit érdemes tudni
Kilenc szerepkör épül be, mindegyikhez saját AWS badge jár. A Cloud Practitioner és a Generative AI Practitioner ingyenes, a többi hét a Skill Builder előfizetéshez kötött. Újdonság, hogy a labor-feladatok újrajátszása mostantól az ingyenes szinten is elérhető. A meglévő játékosok badge-ei, előrehaladása és teljesített feladatai automatikusan átkerülnek, és egy welcome-back ajándék is vár rájuk.
„Save the date”
Augusztus 11. 15:00 – ekkor válik élessé az új Cloud Quest az AWS Skill Builder-en. Ha eddig csak hallottál róla, ez jó alkalom, hogy nekifuss.
Én már nagyon kíváncsi vagyok milyen lesz testközelből. Nézd meg Te is!
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.
Egy ideje már nem írtam cikket a Kubernetes-ről, pedig mint tudjátok szeretem ezt a témát. Amikor a Kubernetes API-ról írtam, sokan kérdezték, hogy jó, de mi történik egy deployment esetén valójában, amikor kiadunk egy kubectl apply parancsot. Most erről szeretnék írni nektek: mi zajlik a színfalak mögött, amikor egy Deployment-et létrehozunk, frissítünk, vagy éppen visszaállítunk egy korábbi verzióra.
Mi történik, amikor létrehozunk egy Deployment-et
A Deployment egy YAML vagy JSON specifikációból épül fel. Amint bekerül a clusterbe, a controller automatikusan létrehoz egy ReplicaSet-et, az pedig legenerálja a Podokat. Ha egy egyszerű nginx web szervert szeretnénk futtatni, a parancs ennyi:
A rendszer válasza egyszerű visszaigazolás, hogy a deployment létrejött. Ha meg akarjuk nézni, mi került létre a háttérben, a kubectl get deployments,rs,pods -o yaml paranccsal kérhetjük le a teljes objektumfát. Én gyakran ezzel kezdek, amikor egy hibát próbálok visszakövetni, mert így látom, hogy a Deployment, a ReplicaSet és a Pod pontosan hogyan kapcsolódik egymáshoz.
Hogyan is néz ez akkor ki? Mik a fő összetevői?
A metadata blokk – mit érdemes tudni róla
Minden objektumnak van egy metadata szekciója, amiben nem a működést, hanem az azonosítást és a nyomon követést segítő adatok vannak. Itt találjuk a labeleket, az annotációkat, a létrehozás időpontját (creationTimestamp), valamint egy uid mezőt, amely az objektum egész életciklusa alatt egyedi marad. A generation mező azt mutatja, hányszor módosították az objektumot – ez praktikus, ha egy rollout történetét szeretnénk visszakövetni.
Fontos különbség, hogy az annotációk nem használhatók objektumok kiválasztására kubectl paranccsal, ellentétben a labelekkel. Ezt sokan összekeverik kezdőként, pedig a különbség lényegi: az annotáció információt hordoz, a label viszont szelekciós eszköz.
A spec – itt dől el, hogyan frissül a rendszer
A Deployment specifikációjában két külön spec blokk van: az egyik a ReplicaSet-et, a másik a Podot konfigurálja. A ReplicaSet szintű spec tartalmazza a replikák számát (replicas), a selector.matchLabels mezőt, amely meghatározza, mely Podokat tekinti a rendszer a sajátjának, valamint a frissítési stratégiát.
A strategy mező alapértelmezetten RollingUpdate, ami azt jelenti, hogy a frissítés fokozatosan történik: a maxSurge határozza meg, hány új Pod jöhet létre a régiek törlése előtt, a maxUnavailable pedig azt, hány Pod lehet átmenetileg nem elérhető. Ha ezt Recreate-re állítjuk, a rendszer előbb töröl minden meglévő Podot, és csak azután hozza létre az újakat – ez egyszerűbb, de rövid kiesést okoz.
A Pod template – a konténer tényleges beállításai
A Deployment egyik legfontosabb része a Pod template, mert ez határozza meg, milyen konténer fut valójában. Itt szerepel az image neve és verziója, az imagePullPolicy, amely azt szabályozza, mikor töltse le újra a rendszer az image-et, valamint a restartPolicy, amely biztosítja, hogy egy leállt konténer automatikusan újrainduljon.
Érdemes megjegyezni, hogy a resources mező alapértelmezetten üres. Ez azt jelenti, hogy ha nem állítunk be CPU vagy memória limitet, a konténer korlátlanul foglalhatja ezeket az erőforrásokat. Ez az egyik leggyakoribb kezdő hiba, amit én is sokszor láttam: valaki elindít egy tesztelési célú Podot limit nélkül, és napok múlva veszi észre, hogy az felzabálja a node erőforrásait.
A status – amit a rendszer visszamond
A status blokk nem konfiguráció, hanem visszajelzés. Az availableReplicas és a readyReplicas összevetésével látjuk, hogy a kívánt állapot valóban létrejött-e. A conditions mezőben szöveges üzenetek is megjelennek, például hogy a Deployment elérte a minimális elérhetőséget, vagy hogy egy új ReplicaSet sikeresen kigördült. Az observedGeneration pedig azt mutatja, hányszor követte a rendszer a konfiguráció változását – ez jó kiindulópont, ha egy rollout állapotát szeretnénk diagnosztizálni.
A replikák száma egy egyszerű paranccsal módosítható:
kubectl scale deploy/dev-web --replicas=4
Ha a replikák számát nullára állítjuk, a konténerek megszűnnek, de a Deployment és a ReplicaSet objektum megmarad – ez pontosan az, ami a háttérben történik, amikor egy Deployment-et törlünk.
Nem minden mező módosítható szabadon, egyes értékek immutable-ek, ez verziófüggő. Az image verziójának módosítása viszont mindig lehetséges, és kubectl edit deployment paranccsal élőben is elvégezhető. Egy ilyen módosítás automatikusan elindítja a rolling update-et.
Ha valami elromlik – rollback
Az egyik legmegnyugtatóbb tulajdonsága a Deployment-eknek, hogy a korábbi ReplicaSet verziók megmaradnak, így vissza lehet állítani egy működő állapotot. Ha egy image frissítés hibás verzióra mutat, és a Podok ImagePullBackOff állapotba kerülnek, a kubectl rollout undo deployment/ghost paranccsal egyszerűen visszaléphetünk. Konkrét revízióra is visszaállhatunk a --to-revision opcióval. A kubectl rollout pause és resume parancsok pedig lehetővé teszik, hogy egy rollout közepén megállítsuk, majd később folytassuk a folyamatot.
DaemonSet – amikor minden node-on kell egy Pod
A DaemonSet más logikát követ, mint a Deployment: biztosítja, hogy minden node-on pontosan egy Pod fusson ugyanazzal az image-dzsel. Ha új node kerül a clusterbe, a DaemonSet automatikusan odatelepíti a Podot, ha egy node kikerül, a Pod is törlődik vele. Ez tipikusan logolási vagy metrika-gyűjtő ügynökök esetén hasznos, ahol fontos, hogy minden node-on futnia kelljen az adott komponensnek, anélkül, hogy erről manuálisan kellene gondoskodni.
Labelek – a cluster rendezésének kulcsa
A labelek nem API objektumok, mégis a Kubernetes-alapú üzemeltetés egyik legfontosabb eszközei. Bármilyen objektumhoz rendelhetünk kulcs-érték párokat, és ezek alapján szűrhetünk, csoportosíthatunk. A kubectl get pods -l run=ghost parancs pontosan ezt teszi lehetővé. Fontos, hogy egy Deployment label selectora apps/v1 API verziótól kezdve immutable, tehát létrehozás után már nem módosítható.
A labelek gyakorlati haszna a nodeSelector alkalmazásánál a legszemléletesebb: ha egy node-hoz disktype: ssd labelt rendelünk, egy Pod specifikációjában megadhatjuk, hogy csak ilyen node-ra kerüljön ki. Ez egyszerű, de sokat elárul arról, hogy a Kubernetes tervezésekor mennyire tudatosan gondolták végig a rugalmas, ám átlátható erőforrás-kezelést.
És mi a lényeg?
A Deployment látszólag egyszerű objektum, de a mögötte húzódó réteges struktúra – metadata, spec, template, status – valójában egy jól megtervezett állapotgép. Aki most kezd Kubernetes-szel dolgozni, annak érdemes megszokni, hogy minden változás egy új ReplicaSet-et generál, és hogy a resources mező üresen hagyása előbb-utóbb kellemetlen meglepetést hoz. Ez az egyik legjellemzőbb kezdő csapda, amivel én is sokszor szembesültem: a rendszer működik, csak épp senki nem korlátozta, mennyi erőforrást használhat.
Ha valaki mélyebben szeretné megérteni ezt a réteges logikát, a managed Kubernetes szolgáltatások, mint az AzureAKS, az AWS EKS vagy a Google CloudGKE, jó kiindulópontot adnak, mert ugyanezt az alapstruktúrát használják, csak a klaszter üzemeltetését veszik le a fejlesztő kezéből.
Rendszeresen készítek videós képzéseket, és minden alkalommal ugyanazzal a kihívással szembesülök. A videók szépen ott vannak az S3-on, mappákba rendezve, de minden, ami ezen felül fontos lenne, egy külön jegyzetben van: melyik anyaghoz milyen felirat tartozik, milyen kapcsolódo linkek vannak, melyik leckéhez kell még kiegészítő információ. Ezt a jegyzetet frissítgetem, és ezt küldöm el a Mentor Klubnak minden alkalommal, amikor egy új anyag elkészül.
Az AWS most pont ebben könnyítette meg a mindennapjaim: az S3-ba egy új funkciót épített be, az annotációt, amivel ez a fajta extra kontextus nem a videó mellett, hanem magában az objektumban lehet.
Mi az annotáció?
Az S3-hoz mostantól objektumonként akár 1000 darab, egyenként 1 MB méretű, összesen 1 GB-os annotációt lehet csatolni. A formátum kötetlen: JSON, XML, YAML vagy sima szöveg is lehet. A lényeg, hogy ez nem statikus.
Bármikor módosíthatod vagy törölheted, anélkül hogy az objektumot újra kellene írni. Ha az objektum másolódik, replikálódik vagy régiók között mozog, az annotáció vele megy. Ha törlöd az objektumot, az annotáció is eltűnik vele.
Hogy viszonyul ez a korábbiakhoz?
Az S3-ban eddig is volt pár módja annak, hogy infót tegyél egy objektumra, csak mindegyiknek volt egy szűk korlátja. A system-defined metadata fix dolgokat ad, mint a méret vagy a storage class, ezt nem te írod. A user-defined metadata feltöltéskor írható, de csak 2 KB-ig, és utána már nem módosítható. Az object tag-ek jól jönnek hozzáférés-vezérléshez vagy lifecycle szabályokhoz, de korlátozott számban definiálhatók, és messze nem elég nagyok komolyabb kontextushoz.
Így néz ki ez egymás mellett:
Metaadat típus
Max méret
Módosítható?
Mire jó
System-defined metadata
Fix
Nem
Objektum tulajdonságok: méret, storage class, létrehozás ideje
Az annotáció pont azt a hiányt tölti be, amit a másik három együtt sem tud: nagy méret, rugalmas formátum, és bármikor módosítható tartalom.
Hogyan állítod be valójában?
Tegyük fel, hogy van egy videód az S3-ban, és hozzá akarod csatolni a technikai specifikációit, vagy felitaror, vagy egy linket. Készítesz egy mediainfo.json fájlt a gépeden, benne a kódolással, felbontással, hangsávok számával és minden szükséges információval. Aztán az AWS CLI-vel egyetlen paranccsal csatolod az objektumhoz:
Ha egy másik csapat ugyanerre a videóra egy AI-generált összefoglalót is rátenne, simán megteheti egy másik annotáció néven, mondjuk ai_summary alatt, anélkül hogy a mediainfo annotációhoz hozzáérne. A kettő egymástól függetlenül él, frissül, törlődik.
Ha meg akarod nézni, mi van összesen egy objektumon, a list-object-annotations parancs kilistázza az összeset, a delete-object-annotation pedig eltávolít egyet, ha már nincs rá szükség.
A lekérdezhetőség, ahol a legjobb
A valódi potenciál nem az egyedi objektumokban van, hanem abban, hogy az annotációkat egyszerre, sok ezer vagy millió objektumon át is le tudod kérdezni. Ha bekapcsolod az S3 Metadata funkciót, az annotációk automatikusan bekerülnek egy felügyelt Apache Iceberg táblába, amit Amazon Athenával lekérdezhetsz.
Egy egyszerű SQL lekérdezéssel megtalálod például az összes videót, amelynek nyolcnál több hangsávja van, anélkül hogy egyenként át kellene nézned a fájlokat. És itt jön be az agentic AI: az S3 Tables MCP szerveren keresztül egy AI agent természetes nyelven is rákérdezhet az adatokra, mondjuk hogy keresse meg az összes AWS képzésekhez tartozó videót ami AI témájú, és a válasz másodperceken belül megjön.
Ezt a fajta szétcsúszást bárki jól ismeri, még ha nem is S3 vagy videók tekintetében. Nehéz az ilyen jellegű információkat összehangolni. Persze az annotáció sem oldja ezt meg varázsütésre, de legalább segít helyre tenni a dolgokat, tehát: az információ nem egy külön fájlban, hanem magán a videón van.
Mire figyelj?
Két dologra biztosan figyelj.
Az első a jogosultság: az IAM policy-ban vagy bucket policy-ban explicit engedélyezni kell az s3:PutObjectAnnotation és s3:GetObjectAnnotation action-öket, ezek nélkül semmi nem fog működni.
A második, és ebbe szerintem sokan bele fognak futni: az annotáció tárolása mindig S3 Standard díjszabás szerint történik, függetlenül attól, hogy az alapobjektum melyik storage class-ban van. Ha archív, Glacier-ben pihenő objektumokra kezdesz el nagy, JSON-ös annotációkat pakolni csak mert lehet, simán meglepődhetsz a számlán a hónap végén. Pont az a fajta tervezés nélküli felhőhasználat ez, amitől általában óvni szoktam mindenkit.
Kinek hasznos, és kinek nem
Tudom, hogy a magyar piacon még kevés cég épít komoly multi-agent rendszereket, ezért jogos a kérdés, hogy ez most kinek szól. A válaszom: nem csak azoknak, akik már AI agenteket futtatnak élesben. Ha bármilyen S3-ban tárolt „adatvagyonod” van, médiafájlok, dokumentumok, log-ok, exportok, és eddig külön rendszerben tartottad nyilván, hogy mi van bennük, az annotáció egy egyszerűbb és olcsóbb módja annak, hogy ezt egy helyen kezeld.
Érdemes tudni, hogy az Azure Blob Storage-nak és a Google Cloud Storage-nak is van saját metadata és tag mechanizmusa, de ezek mérete és rugalmassága jellemzően jóval kisebb ennél. Az S3 annotáció abban hoz újat, hogy ilyen méretben, akár 1 GB-ig, ilyen formátum-szabadsággal, és ennyire szorosan az AI agent munkafolyamatokhoz illesztve teszi ezt elérhetővé.
Amit szándékosan nem fejtek ki most: hogyan tervezd meg az annotációk séma-struktúráját nagy skálán, hogyan optimalizáld az Athena lekérdezések költségét, vagy hogyan állítsd fel a governance modellt arra, ki írhat és törölhet annotációkat nagyvállalati környezetben. Ezek mind valós kérdések, amint egy csapat mérete megnövekszik, de ez már egy külön cikk témája lehetne.
Habár elsőre nem nagy dolog, én látom a pozitív hozadékát. Sokak életét fogja megkönnyíteni ez az apró funkció: nálam a videós képzéseknél, máshol talán egy egész csapatnál, ahol eddig külön rendszerben tartották nyilván, mi tartozik egy fájlhoz. Kis lépés, de ettől nem kisebb a haszna.
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.
A Kubernetes számomra egy megunhatatlan téma. Nem csupán azért, mert a mikroszolgáltatások futtatásának központi eleme, hanem egy olyan izgalmas világ, ami komplexitása ellenére, logikusan működik.
A vállalatok digitális jelenlétének erősítésében ma már kulcsszerepet játszik az, hogy az alkalmazások gyorsan telepíthetők, skálázhatók és megbízhatóan működtethetők legyenek. A Kubernetes pontosan erre van kitalálva. Egy jól felépített rendszerben az alkalmazások nem egyetlen szerveren futnak, hanem egy cluster több node-ján oszlanak el. Ez a megközelítés nemcsak nagyobb rendelkezésre állást biztosít, hanem lehetővé teszi a dinamikus skálázást és az automatizált működést is.
Ma néhány olyan Kubernetes API objektumot fogunk megnézni, amelyek az alkalmazások futtatásának és működtetésének alapját jelentik. Ezek az objektumok határozzák meg, hogyan indulnak el a Pod-ok, hogyan skálázódnak az alkalmazások, hogyan futnak batch feladatok, illetve hogyan kezelhető a hozzáférés a cluster erőforrásaihoz.
Deployment és az alkalmazások telepítése
Amikor egy alkalmazást telepítünk Kubernetes-ben, ritkán hozunk létre közvetlenül Pod-ot. A gyakorlatban szinte mindig egy magasabb szintű vezérlő objektumot használunk.
A leggyakoribb ilyen objektum a Deployment. A Deployment egy controller, amely a ReplicaSetek és a Podok állapotát kezeli. Ez a magasabb szintű absztrakció lehetővé teszi, hogy az alkalmazások frissítése, skálázása és adminisztrációja rugalmasabb legyen.
A működés láncolata a következő:
Deployment → ReplicaSet → Pod
A Pod a Kubernetes legkisebb kezelhető egysége. Egy Pod tipikusan egy vagy több konténert tartalmaz, amelyek együtt futnak és ugyanazt a hálózati valamint tárolási környezetet használják.
A ReplicaSet feladata, hogy biztosítsa a kívánt számú Pod folyamatos működését. Ha például három Pod futását határozzuk meg, a ReplicaSet gondoskodik arról, hogy mindig három példány fusson. Ha egy Pod leáll, a rendszer automatikusan újat indít.
A Deployment ezen a szinten egy további irányítási réteget ad. Lehetővé teszi például a rolling update frissítéseket, amikor az új verziók fokozatosan kerülnek bevezetésre anélkül, hogy az alkalmazás leállna.
DaemonSet: Pod minden node-on
Bizonyos típusú alkalmazásoknak minden node-on futniuk kell egy clusterben. Erre szolgál a DaemonSet.
A DaemonSet biztosítja, hogy egy adott Pod minden node-on fusson a clusterben. Amikor egy új node kerül a clusterbe, a DaemonSet automatikusan elindítja rajta a megfelelő Podot. Amikor pedig egy node eltávolításra kerül, a hozzá tartozó Pod is megszűnik.
Ez a megközelítés különösen hasznos olyan rendszerszintű komponensek esetében, mint például:
loggyűjtő rendszerek
monitoring agentek
biztonsági ellenőrző komponensek
Ezeknek az alkalmazásoknak minden node-on jelen kell lenniük ahhoz, hogy teljes képet kapjanak a cluster állapotáról.
StatefulSet: állapotot kezelő alkalmazások
A legtöbb konténeres alkalmazás stateless módon működik, vagyis a Podok felcserélhetők. Egy Pod megszűnése vagy újraindulása nem jelent problémát.
Vannak azonban olyan alkalmazások, ahol a Pod identitása fontos. Ilyenek például az adatbázisok.
Ezek kezelésére szolgál a StatefulSet. A StatefulSet olyan Kubernetes workload objektum, amely állapotot kezelő alkalmazások működtetésére készült.
A StatefulSet egyik legfontosabb tulajdonsága, hogy minden Pod egyedi identitással rendelkezik. Ez az identitás három elemből áll:
stabil tároló
stabil hálózati azonosító
sorszámozás (ordinal)
A Podok tipikusan sorban indulnak el, például:
app-0
app-1
app-2
Az új Pod csak akkor indul el, ha az előző már sikeresen fut. Ez eltér a Deployment viselkedésétől, ahol a Pod-ok párhuzamosan indulnak.
Ez a viselkedés kulcsfontosságú olyan rendszerek esetében, ahol az indulási sorrend vagy az állapotmegőrzés kritikus.
Autoscaling: automatikus skálázás
A Kubernetes egyik legerősebb képessége az automatikus skálázás.
Az egyik leggyakrabban használt megoldás a Horizontal Pod Autoscaler, röviden HPA. Ez az objektum automatikusan növeli vagy csökkenti a Podok számát egy Deployment, ReplicaSet vagy Replication Controller esetében.
Alapértelmezés szerint a HPA a CPU használat alapján skáláz. Ha a CPU kihasználtság eléri a 80 százalékot, a rendszer új Pod-okat indíthat. A metrikákat a kubelet gyűjti, majd a Metrics Server API-n keresztül érhetők el.
Amikor több Pod-ra van szükség, a rendszer azonnal reagál. Ha viszont csökkenteni kell a Pod-ok számát, a HPA alapértelmezés szerint 300 másodpercet vár, mielőtt új döntést hozna.
A Kubernetes-ben létezik egy másik autoscaling mechanizmus is, a Cluster Autoscaler. Ez már nem Pod-okat, hanem node-okat kezel.
Ha egy Pod nem helyezhető el a cluster-en a rendelkezésre álló erőforrások miatt, a Cluster Autoscaler új node-okat hozhat létre. Ha pedig a node-ok kihasználtsága alacsony, a rendszer idővel eltávolíthatja őket.
Ez különösen fontos felhő környezetben, ahol a nem használt erőforrások költséget jelentenek.
Jobs és CronJobs
Nem minden Kubernetes workload egy folyamatosan futó alkalmazás.
Vannak olyan feladatok, amelyeknek csak egyszer kell lefutniuk, vagy meghatározott időpontokban kell végrehajtódniuk. Erre szolgálnak a Job és a CronJob objektumok.
A Job egy batch feldolgozási mechanizmus, amely meghatározott számú Pod sikeres lefutását biztosítja. Ha egy Pod hibával áll le, a rendszer újraindítja addig, amíg a feladat sikeresen be nem fejeződik.
A Job specifikációjában két fontos paraméter található:
parallelism: ez határozza meg, hogy hány Pod futhat egyszerre.
completions: hány sikeres futás szükséges a Job befejezéséhez.
A CronJob a Linux cron működéséhez hasonló időzített futtatást biztosít. Ugyanazt az időszintaxist használja, így például könnyen létrehozható egy napi vagy óránként futó feladat.
Fontos megjegyezni, hogy egy CronJob esetében a futó Podnak idempotensnek kell lennie, mert bizonyos esetekben előfordulhat, hogy egy feladat kétszer is elindul.
RBAC: hozzáférések kezelése
Egy Kubernetes clusterben a biztonság és a hozzáféréskezelés kulcsfontosságú kérdés.
ClusterRoleBinding (cluster szintű szerepkör-hozzárendelés)
Ezek segítségével meghatározhatjuk, hogy egy felhasználó vagy szolgáltatás milyen műveleteket hajthat végre a cluster-ben.
Például létrehozhatunk egy Role-t, amely csak Pod-ok olvasását engedélyezi egy adott namespace-ben. Egy másik Role pedig lehetőséget adhat Deployment objektumok létrehozására, de például Service objektumokra már nem.
A RoleBinding és a ClusterRoleBinding feladata az, hogy ezeket a szerepköröket felhasználókhoz vagy szolgáltatásfiókokhoz rendeljék.
Ez a modell lehetővé teszi a legkisebb szükséges jogosultság elvének alkalmazását, ami alapvető biztonsági gyakorlat a modern infrastruktúrákban.
Összegzés
A Kubernetes működésének megértéséhez elengedhetetlen az API objektumok ismerete. A Deployment, DaemonSet, StatefulSet, Job, valamint az autoscaling és az RBAC mind olyan alapvető építőelemek, amelyek meghatározzák, hogyan futnak és működnek az alkalmazások egy clusterben.
A Deployment segít az alkalmazások verziókezelésében és skálázásában. A DaemonSet biztosítja a node-szintű komponensek működését. A StatefulSet lehetővé teszi az állapotot kezelő rendszerek stabil működését. A Job és a CronJob batch feldolgozási feladatokat old meg, míg az autoscaling mechanizmusok a dinamikus terheléshez igazítják az infrastruktúrát.
Végül az RBAC gondoskodik arról, hogy a hozzáférések biztonságosan és kontrollált módon legyenek kezelve.
Ha megértjük ezeknek az objektumoknak a szerepét, akkor már nemcsak alkalmazásokat tudunk futtatni Kubernetesben, hanem valóban képesek leszünk megbízható, skálázható és biztonságos rendszereket építeni.
A DevOps és SRE világ egyik legrégibb fájdalma nem a leállás maga, hanem az, hogy a leállás mindig meglepetés. Nem azért, mert senki sem figyelt, hanem azért, mert a rendszerek közötti függőségek olyan szövevényessé váltak, hogy egy ember vagy akár egy egész csapat sem képes azt mindig fejben tartani.
Aki dolgozott már éles környezetben futó, több száz mikroszolgáltatásból álló alkalmazáson, az pontosan tudja ezt az érzést: valami leáll, és az első tíz perc azzal megy el, hogy egyáltalán megértsük, melyik ponton lehet a hiba.
Az AWS most érdemi frissítést adott ki a Resilience Hub következő generációjaként, és ez nem kozmetikai változás. Az eszköz eddig is segített mérni és értékelni az alkalmazások megbízhatóságát, de lényegében passzívan dolgozott: megmondta, hol állsz, és javasolt. Az új verzió aktívabb szerepet vesz fel.
Mi változott valójában?
Az első komolyabb változás a moduláris resilience policy. Korábban előre definiált sablonból kellett választani. Most a csapatok összerakhatják a saját elvárásrendszerüket: meghatározhatják például, hogy az alkalmazás 99,95%-os rendelkezésre állást kell teljesítsen, 15 perces RTO-val és 5 perces RPO-val, multi-region disaster recovery konfigurációval.
Ezt a policy-t aztán újra felhasználhatják több alkalmazáson is, ami nagyvállalati környezetben különösen hasznos.
A második változás az üzleti modell alapú szervezés. Az Resilience Hub most nem csak AWS-erőforrásokat lát, hanem üzleti logikát is próbál leképezni. Egy System egy teljes üzleti alkalmazást jelent, a „user journey”-k a kritikus üzleti folyamatokat írják le, a service-ek pedig ezeket alkotó telepíthető egységek. Ez az absztrakciós szint közelebb hozza az eszközt a valós döntési folyamatokhoz.
A harmadik, és valószínűleg a legfontosabb: a generatív AI-alapú „failure mode assessment”. Az elemzés nem csak az AWS Well-Architected keretrendszer elleőrzőlistáját futtatja le. A rendszer az alkalmazás topológiáját és a megadott házirendet figyelembe véve azonosítja a lehetséges hibamódokat, és konkrét, az adott service-re szabott javaslatokat ad. Ez az a pont, ahol az eszköz valóban új szintet jelent.
A negyedik az automatikus dependency discovery. A legtöbb csapat ezt manuálisan próbálja karbantartani, rendszerint sikertelenül. Az Resilience Hub a VPCDNS lekérdezési bejegyzéseket elemzi, és feltérképezi, hogy az alkalmazás valójában mitől függ: belső végpontoktól, más AWS szolgáltatásoktől, vagy éppen külső, harmadik fél által üzemeltetett végpontoktól. Azokat a cross-region hívásokat is megtalálja, amelyekről a csapat esetleg nem is tudott.
Miért érdekes ez SRE szempontból?
Az SRE-munka nagy részét az teszi nehézzé, hogy a megbízhatóság nem egy esemény, hanem egy folyamat. Folyamatosan változó rendszerekben folyamatosan kell tudni, hogy az elvárásokhoz képest hol tartunk. Erre eddig nem volt jó, skálázható eszköz AWS-en belül.
Az AWS Organizations integráció ezt a problémát oldja meg nagyvállalati szinten. Egy delegált administrator account-ból az összes szervezeti account resilience posture-je áttekinthető egyszerre, anélkül, hogy minden egyes fiókba be kellene lépni és külön riportokat kellene összefésülni. Száz alkalmazás esetén ez nem kényelmi funkció, hanem napi munkát érintő változás.
Hogy jobban értsük
Képzeld el, hogy egy pénzügyi alkalmazást üzemeltetsz AWS-en, több régióban. A payment service kommunikál egy külső banki API-val és egy belső fraud detection service-szel. A csapda ebben a helyzetben az, hogy a külső banki API-t senki sem monitorozza aktívan függőségként, mert egyszer valaki azt mondta, hogy az megbízható. Aztán az API elkezd belassulni, nő a válaszidő, a fraud detection service timeout-ot kap, a payment service hibát dob – és az ügyeletes kolléga egy olyan riasztást kap, amelyből nem derül ki egyértelműen, hogy mi a valódi ok.
A Resilience Hub a DNS naplókból azonosítja ezt a függőséget, és a hibaelemzés során felszínre hozza, hogy egy kritikus külső végpont nincs monitorozva. A javaslat konkrét: legyen megfelelő korlát beépítve, figyeljenek a válaszidőre, és határozzanak meg tartalék viselkedést arra az esetre, ha a külső szolgáltatás nem elérhető.
Ezt is érdemes tudni
Az Resilience Hub nem helyettesíti a Chaos Engineering eszközöket, és nem váltja le a részletes monitoring konfigurációt. Megmutatja, hogy hol vannak a gyenge pontok és mit kellene tenni, de a tényleges tesztelést, a kontrollált hibaszimulációt és a fokozatos verzióváltást ettől még a csapatnak kell elvégeznie.
Ez egy elemző és irányító eszköz, nem öngyógyító rendszer.
Az árazás is változott. Az új modell szolgáltatásonként számol, és havonta két ingyenes hibaelemzést tartalmaz minden egyes szolgáltatáshoz. A függőségtérkép automatikus feltérképezése opcionális, és külön kerül számlázásra.
Mikor hasznos valójában?
Azoknak, akik most találkoznak először az eszközzel: az Resilience Hub akkor éri meg megismerkedni, amikor az infrastruktúra már kellően komplex ahhoz, hogy a fejben tartott függőségi térkép megbízhatatlanná vált. Ahol SRE-szerep van, ahol van külön csapat a megbízhatóságért, ahol AWS Organizations-t használnak – ott ez az eszköz valódi értéket adhat.
Az, hogy generatív AI-t ültetnek bele az ilyen elemző folyamatokba, nem meglepő irány. Az viszont figyelemre méltó, hogy az AWS itt nem egy kísérleti feature-t dobott be, hanem egy meglévő, éles eszköz alapvető értékelési logikáját cserélte le AI-ra.
Amikor virtuális gépeken futnak a céges alkalmazások, hamar eljutunk a VMSS (virtuális gép-méretezési csoportok) használatának dilemmájához, hiszen könnyen skálázható, jól konfigurálható, magas rendelkezésre állású rendszereket lehet építeni. Ráadásul egyetlen ilyen cluster akár 1000 VM-ig is bővíthető.
Azonban ebben az esetben a VM-ek frissítése mindig extra időt és odafigyelést igényelt, mert általában nehézkes. Én magam is láttam olyan infrastruktúrát, ahol a DevOps csapat pontosan tudta, mit kellene frissíteni, de senki nem merte „megnyomni a gombot”, mert bármennyire is felkészültél, az élő rendszeren előfordult némi meglepetés.
Erre a problémára ad választ a Golden Image refresh stratégia, amely Azure-on ez egy strukturált, eszköztámogatott folyamat, így jelentősen megkönnyíti a verziókövetést, a pipeline-alapú frissítést és az auditálhatóságot azokhoz az időkhöz képest, amikor mindenki maga találta ki, hogyan tartja karban a szerver parkját.
Mi az a Golden Image?
A Golden Image egy előre összeállított, jóváhagyott rendszerkép – egy rögzített, verziókezelt sablon, amelyből az összes VM-et létrehozzák. A Golden Image általában négy dolgot tartalmaz kötelezően:
előre telepített szoftverkörnyezet
a szervezet belső compliance elvárásaihoz igazodó beállítások
konfigurált és biztonsági szempontból „megerősített” operációs rendszer
aktuális biztonsági frissírtések
Korábban a legelterjedtebb megközelítés az úgynevezett „update in place” volt: bejelentkeztél egy futó VM-be, elvégezted a frissítést, és reménykedtél, hogy a többi gép is hasonló állapotban van. Az idő előrehaladtával minden egyes gép máshogy nézett ki belülről – más kernel verzió, maradt tesztelési csomag, valaki feltelepített valamit, amit aztán elfelejtett eltávolítani. Ezt hívják snowflake server jelenségnek: minden gép egyedi és megismételhetetlen, és ezért egyre nehezebben kezelhető.
A Golden Image refresh ezzel szemben az immutable infrastructure (megváltoztathatatlan infrastruktúra) elvén alapul: a futó rendszert nem módosítod, hanem kicseréled egy tiszta, ellenőrzött állapotból indított új példányra.
Hogyan épül fel az architektúra?
A Golden Image refresh három rétegben működik, és a rétegek egymásra épülnek – ez az image dependency flow.
Az első réteg maga a Golden Image, amelyet egy dedikált „Golden Image Team” publikál és verziókezel. Minden környezet – dev, staging, prod – saját fájlban rögzíti, hogy melyik Golden Image verziót használja. Automatikus frissítés nem történik: minden változás explicit, Git-ben követett döntés.
A második réteg a custom image (egyedi képfájl), amelyet egy pipeline épít a Golden Image fölé. Ez tartalmazza az alkalmazásspecifikus konfigurációkat és függőségeket, és ez az, amit a VMSS deployment ténylegesen használ.
A harmadik réteg a VMSS telepítés, amely a custom image alapján indítja a példányokat, és frissítéskor fokozatosan lecseréli azokat az új verzióra.
Ha a Golden Image frissül, az egész lánc lefut újra: a Golden Image Team publikál egy új verziót, a custom image pipeline lefut, új custom image verzió készül, és a VMSS instance-ek az új verzióra váltanak. A forgalom fokozatosan kerül át az új instance-ekre, a régieket pedig fázisosan vonják ki – így a szolgáltatás elérhető marad a folyamat alatt.
A VMSS frissítési folyamata lépésről lépésre
Azonosítod az új Golden Image verziót a megfelelő Image Gallery-ben
Feature branch-en frissíted a pkrvariables fájlt az új verzióra
Merge request-en jóváhagyatod és beolvasztod a változást
Lefuttatod a custom image pipeline-t, amely elkészíti az új custom image-t
Telepíted az új képfájlt az operational pipeline-on keresztül vagy Terraform-al
Manual vs. automatic upgrade – és miért számít a különbség
VMSS esetén az alábbi két frissítési metódust használtuk korábban:
Az automatic upgrade esetén az összes instance egyszerre frissül. Ez gyors, de teljes vagy részleges leállással járhat – az alkalmazás addig nem elérhető, amíg az új instance-ek fel nem állnak. Ez az alapértelmezett mód.
A manual upgrade esetén a példányokat egyenként frissíted. A többi közben fut, az alkalmazás elérhető marad. Ez 10-15 percnyi teljesítménycsökkenéssel jár, de leállás nélkül.
Ami fölött még tapasztalt mérnökök is gyakran elsiklanak, hogy amikor frissítik a Terraform-kódot, majd lefuttatják a terraform apply parancsot a megfelelő beállítások ellenőrzése nélkül, akkor éles környezetben akár az összes instance egyszerre leállhat.
A manual módhoz először a provider.tf fájlban kell explicit beállítás:
Ezután a VMSS resource Terraform kódjában frissíteni kell a source_image_id értékét az új custom image verzióra, és az upgrade_mode paramétert "Manual"-ra kell állítani:
A terraform apply lefuttatása után a VMSS szerver tagokat egyenként kell manuálisan frissíteni, hogy a szolgáltatás folyamatosan elérhető maradjon.
Hogyan oldja meg ezt a Golden Image refresh?
Az új image verzió publikálása után az instance-ek fokozatosan cserélődnek le. Az új, frissített image-ből épülő instance-ek fokozatosan veszik át a forgalmat, miközben a régi instance-ek még futnak. Csak akkor vonják ki a régieket, ha az újak már stabilan működnek. Ez azt jelenti, hogy sem teljes leállás, sem hosszú kézi folyamat nem szükséges – a frissítés kontrollált, visszakövethető és biztonságos.
Standalone VM-ek frissítése
A VMSS-sel ellentétben standalone VM-eknél nincs fleet és nincs fokozatos instance-csere, hanem minden VM önálló egység, amelyet külön kell kezelni. A Golden Image refresh itt is ugyanazt a célt szolgálja, de a folyamat egyszerűbb, és kevesebb mozgó részből áll.
Nem minden operációs rendszer verzióhoz készül automatikusan Golden Image. Ha egy adott OS verzióhoz már létezik Golden Image, a frissítés egyszerű: az új verzióra hivatkozol, és a folyamat a már ismert módon zajlik.
Ha viszont egy OS verzióhoz még nincs Golden Image – mert például régebbi vagy kevésbé elterjedt rendszerről van szó, amelyre a Golden Image Team még nem készített sablont – akkor custom image-t kell létrehozni. Ez azt jelenti, hogy te magad állítod össze azt a rendszerképet, amelyből a VM-et indítod, és a frissítés ennek verzióváltásával történik – például 1.0-ról 1.1-re.
Amit mindkét esetben fontos előre tudni: amikor a Terraform kódban megváltoztatod a source_image_id értékét, a Terraform nem frissíti a meglévő VM-et – hanem lecseréli. VMSS esetén ez fokozatosan, instance-enként történik. Standalone VM esetén viszont az egész erőforráscsoport érintett lehet. A terraform plan futtatásakor replace műveleteket fogsz látni az alábbi erőforrásokon:
a VM maga
az OS disk
a data disk attachment-ek
a role assignment-ek
a VM extension
Ami megmarad és helyben frissül:
a network interface
a disk encryption set
Ez nem hiba – ez a várt viselkedés. De ha valaki nincs felkészülve rá, a terraform plan kimenete ijesztőnek tűnhet. Érdemes előre tudni, hogy pontosan ez fog történni, és ez a helyes működés.
Validáció és ellenőrzés
A deployment után nem elég, hogy lefutott a pipeline. Az elvárható ellenőrzési lépések: az instance-ek egészségi állapotának ellenőrzése, a sikeres provisionálás visszaigazolása, az alkalmazás és a szolgáltatások működésének verifikációja, valamint a scale set frissítési státuszának és hibamutatóinak figyelemmel kísérése.
Röviden:
instance-ek egészségi állapotának ellenőrzése
sikeres provisionálás visszaigazolása
alkalmazás és szolgáltatások működésének verifikációja
scale set frissítési státuszának és hibamutatóinak figyelemmel kísérése
Ez az a lépés, amelyet időnyomás alatt a legtöbben igyekeznek kihagyni, vagy lerövidíteni – és ahol a legtöbb utólagos incidens gyökere kereshető.
Ami ebből a legfontosabb
A Golden Image refresh nem egy bonyolult megoldás. Csupán egy másfajta szemlélet, amely bármekkora infrastruktúrán alkalmazható: ne frissíts futó rendszert, helyette cseréld ki egy tiszta, ellenőrzött állapotból indítottra. Az eszközök – Azure Image Gallery, Packer, Terraform – ma már elérhetők és jól dokumentáltak. A nehéz rész nem a technika, hanem a következetesség: verziókezelés, jóváhagyási folyamat, és az a döntés, hogy nem nyúlsz hozzá közvetlenül az élő géphez.
Szándékosan hagytam ki ebből a cikkből a monitoring konfigurációját, a health probe beállítását és az availability zone-ok közötti elosztást. Nem azért, mert nem fontosak – hanem mert ezeket csak akkor érdemes beállítani, ha az alapfolyamat már működik és érthető. Aki ezekre is kíváncsi, annak lesz folytatás.
Van abban valami különösen jó érzés, amikor az ember nemcsak tanul valamit, hanem közben érzi is, hogy a korábbi tudása elkezd jobban összeállni. Mint tudjátok, idén egy olyan kihívást adtam magamnak, hogy az év első felében minden hónapban leteszek egy felhős vagy AI-hoz kapcsolódó vizsgát. Nem azért, mert a tanúsítvány önmagában mindent megold, hanem azért, mert szerettem volna újra és újra megmérettetni magam a nagy felhőszolgáltatók világában. Ezzel is inspirálni azokat, akik évek óta tanulnak, hogy időnként mérettessék meg magukat.
Februárban a Google Generative AI Leader vizsgára esett a választás. Ez logikus lépés volt, mert az AI-val már több mint három éve foglalkozom mélyebben, természetesen a cloud mellett. Márciusban jött az Azure AI-900, amely szintén sikeres lett. Áprilisban pedig következett az AWS Certified AI Practitioner, vagyis az AIF-C01 vizsga. Ezt is sikeresen teljesítettem.
Őszintén bevallom, hogy a három közül ezt élveztem a legjobban.
Nem mély technikai vizsga, de nem is üres elmélet
Az AWS Certified AI Practitioner nem fejlesztői vagy mély machine learning vizsga. Nem kell modelleket kódolni, nem kell ML pipeline-t építeni, és nem kell matematikai részletekben elveszni. Ettől viszont még nem nevezném könnyűnek.
A vizsga hivatalos leírása szerint az AIF-C01 célja, hogy igazolja az AI, ML, generative AI fogalmak, az AWS AI eszközök, a felelős AI használat, valamint a security, compliance és governance alapvető ismeretét. Ez nekem nagyon szimpatikus irány, mert pontosan erre van szüksége sok cégnek is: nem mindenki akar modellt tréningezni, de egyre több embernek kell értenie, mire jó az AI, mikor hasznos, mikor kockázatos, és milyen szolgáltatásokkal lehet elindulni.
A vizsga szerintem azoknak különösen hasznos, akik cloud, data, governance, security vagy üzleti technológiai irányból közelítenek az AI felé. Kezdőknek is jó lehet, de csak akkor, ha nem csak vizsgakérdéseket magolnak, hanem tényleg megértik az alapfogalmakat.
Ami miatt az AWS AI világa különösen izgalmas
A felkészülés közben újra feltűnt, mennyire sokféle AI szolgáltatás létezik AWS-en belül. Nem csak az Amazon Bedrockról van szó, bár kétségtelenül ez az egyik legfontosabb szolgáltatás a generative AI alkalmazások építéséhez.
Érdemes ismerni például az Amazon SageMaker AI-t, ha valaki modellek építésével, tanításával vagy deploymenttel foglalkozna a gépi tanulás világában (ML). Ott van az Amazon Q Business és az Amazon Q Developer, amelyek már sokkal inkább a vállalati tudás, fejlesztői munka és produktivitás irányából érdekesek. Az Amazon Nova az AWS saját foundation model családja. Az Amazon BedrockAgentCore és a Strands Agents SDK pedig már az agentic AI világ felé mutat.
És akkor még nem beszéltünk az olyan érdekesebb irányokról, mint az AWS Health AI Hub, amely az egészségügyi AI megoldásokra koncentrál, vagy az AI Stylist demó, amely jól megmutatja, hogyan lehet generative AI-t kiskereskedelmi vállalkozások és személyre szabott ajánlások köré építeni. A PartyRock pedig egy nagyon jó játszótér azoknak, akik kódolás nélkül szeretnének generative AI app-okat kipróbálni.
Miért volt ez nekem ennyire hasznos?
A legnagyobb értéke számomra az volt, hogy rendszerezte a korábbi tudásomat. Az AI világában nagyon könnyű elveszni a modellek, agentek, RAG megoldások, embeddingek, governance kérdések és platformszolgáltatások között. Ez a vizsga segíthet mindenkinek újra átlátni, melyik építőkocka mire való.
A felkészüléshez YouTube-on is találhatók ingyenes tananyagok vagy az Udemy-n fizetős képzések, de én azt javaslom, hogy senki ne csak egy forrásból készüljön. Érdemes mellé megnézni a hivatalos AWS exam guide-ot, az AWS Skill Builder anyagokat, és közben kipróbálni legalább néhány szolgáltatást. Nem kell mindent mélyen konfigurálni. Első körben bőven elég megérteni, mire való az Amazon Bedrock, hogyan illeszkedik ide a SageMaker AI, és milyen problémákra adnak gyors választ a purpose-built AI szolgáltatások. Ez utóbbira van már képzésem is a Mentor Klubnál.
Én nagyon élveztem a felkészülést, és maga a vizsga is jó élmény volt. Ha jól emlékszem, hamar végeztem. Ez nem azt jelenti, hogy minden kérdés triviális volt, hanem azt, hogy az elmúlt évek tapasztalata és a felkészülés alatt sikerült annyira összerakni a képet, hogy magabiztosan tudtam haladni.
Mi jön ezután?
Megvan ez a vizsgám is, és ennek nagyon örülök. Most már mindegyik felhő-szolgáltatónál sikerrel megmérettettem magam.
Májusban egy Google tanúsítvány megújítása következik. Erről is írni fogok, utána viszont egy rövid szünetet tartok a vizsgák világában. Ennek nagyon jó oka van: felkérést kaptam hat (6) AI képzés elkészítésére a Mentor Klubnál, és most erre szeretnék fókuszálni.
Hogy az AI mely területét fedik le ezek a képzések, az legyen egyelőre titok. Annyit azonban szívesen elárulok, hogy mindegyik a Google Cloud és a Gemini világába segít elmélyedni.
Tehát a cloud-os képzéseim mellett már az Mesterséges Intelligencia világába is elkalauzollak, ha tagja vagy a Mentor Klubnak.
Ha te is most ismerkedsz az AI és a cloud világával, szerintem az AWS Certified AI Practitioner jó irány lehet. Nem azért, mert ettől valaki azonnal AI architect lesz, hanem azért, mert segít tisztábban látni. Márpedig ma ez óriási érték, mert hamar el lehet veszni a hatalmas zajban.
Ha érdekelnek a felhős és AI-os tanulási utak, érdemes követned a következő bejegyzéseket is, mert hamarosan jön a Google tanúsítvány megújításának története, utána pedig még több gyakorlati AI és Cloud téma. Ugye Te is várod már?
Aki az elmúlt évek fejlesztői eszközeinek átalakulása során figyelemmel kísérte, hogyan változott a GitHub Copilot, az tudja, hogy ez az eszköz ma már egészen más valami, mint amivel 2022-ben találkoztunk.
Akkor még egy okos kódkiegészítő volt. Ma már autonóm módon képes végigmenni egy teljes repository módosításain, több lépéses feladatokat old meg önállóan, és elég jó nagy nyelvi modelleket használ közben. Ez a fejlődés szép, de számolni kell azzal, hogy komoly infrastrukturális igénnyel jár a hátterben.
Nem véletlen tehát, hogy a GitHub nemrég bejelentette: 2026. június 1-jétől az összes Copilot csomag áttér a felhasználás alapú számlázásra, angolul usage-based billing modellre. Ez az egyik legjelentősebb árképzési változás, ami az eszköz életében eddig történt. Érdemes pontosan megérteni, mit jelent ez a gyakorlatban.
Mi volt eddig, és mi változik
Az eddigi rendszer úgynevezett premium request unit-okra (PRU) épített. Minden Copilot csomag tartalmazott egy havi kvótát ezekből az egységekből, és ha valaki elfogyasztotta a keretét, egy olcsóbb modellre esett vissza, de tovább tudott dolgozni.
Június 1-jétől ezt a rendszert felváltják a GitHub AI Credits. A lényeg: a kreditfogyasztás token-alapon számolódik, beleértve a bemeneti, kimeneti és gyorsítótárazott tokeneket is, a GitHub által nyilvánosan közzétett API árak szerint. Fontos kiemelni, hogy az alap kódkiegészítés és a Next Edit Suggestions funkció nem fogyaszt kreditet – ezek minden csomagban megmaradnak korlátozás nélkül.
A visszaeső modellre való automatikus átkapcsolás viszont megszűnik. Ha valaki elfogy a kreditjeiből, a rendszergazda által beállított keret vagy a kreditvásárlás az egyetlen megoldás. Ez egy komoly szemléletváltás: az eddig „láthatatlan” korlát mostantól pénzben is megjelenik.
Mennyit kap mindenki a csomagjával
Az alaptervek ára nem változik, ez fontos. Amit kap az ember, az most már kredit formájában van meghatározva:
Csomag
Havi ár
Kapott havi AI Credit
Copilot Pro
10 USD
1 000 kredit
Copilot Pro+
39 USD
3 900 kredit
Copilot Business
19 USD/fő
1 900 kredit/fő
Copilot Enterprise
39 USD/fő
3 900 kredit/fő
Az átváltás egyértelmű: 1 AI Credit = 0,01 USD, tehát a Pro csomag 1 000 kreditje 10 USD értékű fogyasztást fed le. A különbség ott jelenik meg, ha valaki többet használ, mint amennyit a csomag tartalmaz: ekkor a GitHub nyilvánosan közzétett API árain lehet további kreditet vásárolni.
A Business és Enterprise ügyfelek egy átmeneti kedvezményes időszakot is kapnak. Június 1-jétől szeptember 1-jéig emelt kreditkeretet biztosít a GitHub: Business ügyfeleknek 3 000 kreditet, Enterprise ügyfeleknek 7 000 kreditet fejenként és havonta. A kreditek ráadásul nem egyénileg vannak elszámolva, hanem szervezeti szinten összeadódnak – ha egy Business csomagos cégnél 100 felhasználó van, az egy 190 000 kredites közös készletet jelent a normál időszakban, nem 100 különálló keretet.
Mit jelent ez vállalati szempontból
Aki enterprise környezetben dolgozik, annak ez az egyik legfontosabb változás. A GitHub most bevezeti az úgynevezett pooled usage modellt, ami azt jelenti, hogy a szervezeten belüli fel nem használt kreditek nem egyénileg „égnek el”, hanem egy közös készletbe kerülnek, amit más kollégák is felhasználhatnak. Ez egy nagyon is megfontolandó lépés: az eddigi rendszerben rengeteg vállalat fizetett license-eket, amelyek felét talán ki sem használták.
Mellé jön a rendszergazdai szintű budgetkontroll. Az adminisztrátorok mostantól vállalat, cost center és egyéni felhasználó szintjén is beállíthatnak kiadási küszöböt. Amikor a keret elfogy, eldönthetik, hogy a szervezet folytatja-e a használatot piaci áron, vagy kemény limitet állítanak be.
Amit én sok cégnél látok elkövetni: bevezetnek egy SaaS AI-eszközt, és aztán senki sem figyeli, hogy ki, mikor és mennyit használja. Usage-based modellnél ez a hozzáállás gyorsan fájni fog. A jó hír az, hogy a GitHub erre is gondolt: május elején elindít egy előnézeti számlázási felületet, ahol a felhasználók és az adminok előre láthatják, milyen várható költséget generál a jelenlegi használatuk, még mielőtt az éles rendszer június 1-jén elindul.
Hogyan érint ez egy fejlesztőt vagy karrierváltót
Ha valaki még most ismerkedik a Copilottal, és a Copilot Free csomagot használja, a változás egyelőre kevéssé érinti. A Free csomag az eddigi korlátok mellett marad, és az AI Credits rendszer elsősorban a fizetős tervekben válik érzékelhetővé.
Ha viszont valaki rendszeresen, komolyan használja az eszközt – különösen az agentic funkciókat, ahol a Copilot önállóan fut végig feladatokon –, érdemes számolni azzal, hogy az ilyen munkamenetek token-fogyasztása lényegesen magasabb, mint egy egyszerű kódkiegészítésé. A GitHub maga is elismeri, hogy ma egy gyors kérdés és egy többórás autonóm kódolási session ugyanannyiba kerül az eddigi rendszerben. Ez tarthatatlan volt, és a változtatás logikus.
Amit érdemes megjegyezni
Ez a váltás nem egyedi fejlemény. Pontosan ezt a trendet látom az egész cloud és AI iparágban: a flat-rate, havi díjas modellek lassan átadják helyüket a fogyasztásalapú árazásnak. Az AWS már régóta ezen az elven működik, és a nagy AI-szolgáltatók többsége is token-alapú számlázást alkalmaz.
A GitHub Copilot esetében ez egy nehéz, de szükséges lépés. Az agentic AI komoly számítási kapacitást igényel, és az egyáras modell hosszú távon fenntarthatatlan. Aki ezt megérti, az nem fejlesztői extra kiadásként tekint majd a Copilot-számlára, hanem üzleti döntésként: mennyit ér a csapat ideje, és mennyit spórol az AI-asszisztencia.
A legfontosabb teendő most: május elején nézd meg az előnézeti számlázási felületet a GitHub fiókodban vagy a céges adminfelületen, és ott mérd fel a valós fogyasztást, mielőtt a rendszer élesbe megy.
