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!
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 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.
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?
Az S3 20 éve szolgál már minket, mint az egyik legjobb felhő alapú tároló a piacon. Ez alatt a 20 év alatt talán a legidegesítőbb mindig a bucket-ek nevének kiválasztása volt. A kezdetektől – hiszen már az AWS is 20 éves – globálisan egyedi nevet kellett megadnunk, amikor egy S3 bucket-et létrehoztunk.
Aki dolgozott már AWS-sel, biztos belefutott ebba a klasszikus hibába: kiválasztasz egy tökéletes bucket nevet… majd jön a hiba, hogy már foglalt.
És ilyenkor jön a kreatív káosz: alkalmazas-adatok-prod-123
Nem túl elegáns. És ami fontosabb: enterprise környezetben ez nem csak esztétikai probléma, hanem governance és skálázási kérdés is.
Aki régóta dolgozik AWS-el, mint én is, annak az Amazon S3 szinte természetes része lett a mindennapoknak. Olyan, mint a levegő: nem gondolunk rá külön, de mindenhol ott van.
Amikor az Amazon S3 2006-ban megjelent (és vele az S3 is elsőként), még nem beszéltünk microservices-ről, Kubernetes-ről vagy AI modellekről napi szinten. Az adat viszont már a kezdetektől létezett. Csak nem volt ilyen egyszerű kezelni.
Ma pedig ott tartunk, hogy az S3 nem csak egy storage megoldás, hanem egy alapréteg. Egy csendes infrastruktúra elem, ami nélkül a modern cloud gyakorlatilag nem működik.
És most, hogy az AWS a 20. születésnapját ünnepli, érdemes egy pillanatra megállni, és megnézni: mit adott nekünk, és merre tartunk tovább.
Miért volt ennyire meghatározó az S3?
Erre könnyű a válasz: mert egyszerű volt.
Az S3 egy object storage szolgáltatás. Ez azt jelenti, hogy fájlokat (object-eket) tárolunk benne, kulcs-alapú eléréssel, nem klasszikus fájlrendszerként.
A valódi ereje nem ebben van, hanem abban, hogy:
gyakorlatilag korlátlanul skálázódik
nem kell szervereket kezelni
API-n keresztül bárhonnan elérhető
és nagyon magas tartósságot biztosít (durability)
Ez a kombináció 2006-ban forradalmi volt. És szerintem még ma is az.
Mire használják valójában az S3-at?
Sokan azt gondolják, hogy az S3 „csak egy fájltároló”.
A valóságban viszont rengeteg különböző use case épül rá. Nézzünk meg néhányat, amikkel én is rendszeresen találkozom.
1. Backup és archiválás
Ez a klasszikus.
adatbázis mentések
logok tárolása
hosszú távú archiválás (pl. törvényi megfelelőség miatt)
Az S3 lifecycle policy segítségével az adatokat automatikusan lehet költséghatékonyabb ú.n. storage class-ba mozgatni (pl. Glacier, Deep Archive).
Sok cég esetében azonban néha hiba csúszik a gépezetbe: feltöltik az adatokat az S3-ba, de lifecycle szabály nincs létrehozva, majd csodálkoznak, hogy a költségek elszállnak.
Nem kell VM, nem kell Kubernetes. Ez az a „simplicity”, amit sokan túl korán elfelejtenek. Pedig itt szinte ingyen van.
3. Data lake alap
Ez már egy komolyabb use case.
Az S3 gyakran a data lake alapja:
raw adatok tárolása
strukturált és strukturálatlan adatok együtt
későbbi feldolgozás (pl. Athena, Glue)
Itt már megjelenik az adatstratégia, amely egy új színtere egy cég életének. És itt szokott elcsúszni a legtöbb projekt: nincs naming convention, nincs partitioning, így később nehéz kezelni.
4. AI és machine learning
Az elmúlt évek egyik legnagyobb változása. Az S3 ma már az AI pipeline-ok egyik alapja:
training datasetek tárolása
model artifactek mentése
inference input/output tárolás
AWS oldalon például a SageMaker is erősen épít rá, de ugyanez igaz más platformokra is. Nehéz olyan megoldást találni, ahol az S3-at nem használjuk. Igazi alappillér.
5. CI/CD és DevOps
Ezt kevesebben említik, pedig napi szinten használjuk.
Egy egyszerű példa: Egy pipeline build-el egy alkalmazást, majd feltölti S3-ba, és onnan olvassa fel a kódot az AWS Lambda.
Egyszerű, stabil, jól működik.
6. Log és observability adatgyűjtés
Sok rendszer logjai végül S3-ban landolnak:
Terheléselosztó és alkalmazás naplófájlok
CloudTrail események
Hálózati információs naplófájlok
Innen tovább lehet őket feldolgozni (pl. Athena vagy más tool-ok).
Mi változott 20 év alatt?
Őszintén? Az alap koncepció szinte semmit és nekem pont ez tetszik.
Ami változott:
több storage class (költségoptimalizálás)
jobb biztonsági kontrollok (IAM, encryption, bucket policy)
esemény alapú működés (S3 event → Lambda)
integráció más szolgáltatásokkal
Az alap modell ugyanaz maradt. Ez ritka az IT-ban és a jelenlegi világunkban.
És mi jöhet ezután?
Itt érdemes kicsit megállni. Igyekszem biztos dolgokat írni és nem csupán találgatni.
1. S3 mint adatplatform alap
Egyre több rendszer épít közvetlenül S3-ra, nem csak tárolásként, hanem:
query layer-rel
metadata kezeléssel
verziózással
Ez már nem a klasszikus storage használat.
2. AI-first adatkezelés
Az AI miatt az adatok szerepe megváltozott:
nem csak tároljuk, hanem használjuk is folyamatosan
nem csak a struktúrált adat értékes, hanem minden adat számít
Az S3 ebben központi szereplő maradhat.
3. Egyszerűség visszatérése
Ebben a túlbonyolított világban, szükség van az egyszerű és megbízható dolgokra és ilyenkor sokan visszatérnek az alapokhoz:
S3
egyszerű pipeline
kevesebb komponens
Ez nem visszalépés, hanem érettség.
Buktatók S3 használat közben
Ez fontos, mert könnyű belefutni:
nincs lifecycle policy: drága lesz
nem megfelelő access control: biztonsági kockázat
hiányzó elnevezési stratégia: káosz
minden adat egy bucket-ben: kezelhetetlen
Ezek nem technikai problémák, hanem tervezési hibák, amelyek átgondoltsággal könnyen orvosolhatók.
A következő 20 év előtt
Az S3 nem látványos. Nincs UI varázslat, nincs „wow” élmény, de ott van minden mögött.
Az elmúlt 20 évben az egyik legstabilabb alapköve lett a cloud világnak és nem csak az AWS-ben lakó szolgáltatásoknak.
És ha valamit érdemes megérteni mélyen – akár kezdőként is –, akkor ez az. Mert nem csak egy szolgáltatást tanulsz meg. Hanem azt, hogyan gondolkodik a modern infrastruktúra az adatokról.
Amikor elkezdtem az informatikával foglalkozni, teljesen természetes volt, hogy ha egy cégnek új alkalmazás kellett, akkor először szervereket kellett rendelni. Fizikai vas, rack szekrény, kábelek, és rengeteg várakozás…Hetek, néha hónapok.
És ha valamit rosszul méreteztünk? Akkor annak komoly következménye volt. Vagy alacsony volt a kapacitás, vagy túl sok volt. a felesleges erőforrás. Nehéz volt pontosan megbecsülni, hogy mennyi az optimális.
Majd 2006 környékén megjelent valami, ami akkor még sokaknak csak egy furcsa kísérletnek tűnt: az Amazon Web Services.
Ma, 20 évvel később, visszanézve egészen elképesztő, hogy mennyire természetessé vált az, ami akkor hihetetlenül új volt.
Az első lépések: S3 és EC2
Az AWS indulásakor két szolgáltatás volt igazán meghatározó:
Az S3 egy végtelennek tűnő tárhelyet adott, ahol nem kellett többé diszkeket kezelni. Az EC2 pedig azt mondta: nem kell szervert venned, csak kérj egyet.
Ez ma már természetesnek hat, akkor viszont paradigmaváltás volt.
Persze eleinte mindenki ugyanúgy használta a cloud-ot, mint a saját adatközpontját. Lift-and-shift, csak máshol futott a VM.
Ez azonban nem a felhő valódi ereje.
A cloud nem infrastruktúra, hanem szemlélet
Az elmúlt években igyekszem minden tanítványomnak és mentoráltamnak elmondani, hogy a cloud nem csupán technológia. Ez egy másik gondolkodásmód.
Például:
Nem előre vásárolsz kapacitást, hanem használat alapján fizetsz. (Pay-As-You-Go)
Nem szerverekben gondolkodsz, hanem szolgáltatásokban.
Nem “mi van ha kelleni fog”, hanem “ma mire van szükségem”
Ha nem használod, kapcsold le!
Ez elsőre egyszerűnek hangzik, de amikor sokan átköltöznek a cloud-ba, a gondolkodásuk marad on-premise. Emiatt sokkal drágábban és kevésbé hatékonyan tudják kihasználni a felhőszolgáltatók által kínált megoldásokat és lehetőségeket.
Ebből jönnek a klasszikus problémák:
túlméretezett VM-ek: elszállnak a költségek
le nem állított fejlesztői környezetek: felesleges kiadások
manuális folyamatok: nincs valódi skálázódás, nincs valódi felügyelet
És ami fontos: Nem kell mindent egyszerre megcsinálni.
Sokan ott rontják el, hogy nem fokozstosan alakítják ki a környezetet, hanem mindent egyszerre akarnak. Ez sokször akkora falat, hogy elbukik a teljes megvalósítás.
Én azt javasolom, hogy lépésenként haladjon mindenki: Először tervezzük meg a minimálisan elegendő, de biztonságos architektúrát. Utána érjük el, hogy működjön. Aztán legyen szép. Végül legyen skálázható.
Azure és GCP – ugyanaz a történet más szemszögből
Az AWS elindította ezt a hullámot, de ma már nem egyedül van.
Mindkettő ugyanazt a problémát oldja meg: Hogyan tudunk gyorsan, rugalmasan és biztonságosan rendszereket építeni?
Azure-nál például egy Azure VM vagy Azure SQL Database ugyanazt a gondolatot viszi tovább, mint EC2 és RDS. GCP-nél pedig a felügyelt szolgáltatások még erősebben jelen vannak. A különbség inkább filozófia és integráció. Az alap minden esetben ugyanaz.
Amit 20 év alatt megtanultunk
Ha visszanézek erre a 20 évre, van néhány dolog, ami nagyon tisztán látszik:
1. A komplexitás nőtt – de a belépési küszöb csökkent Ma bárki elindíthat egy alkalmazást percek alatt. Látványosan és stabilan. Azonban egy jól működő, biztonságos rendszer már komoly tervezést igényel.
2. A költség optimalizálás nem opcionális A cloud egyik legnagyobb előnye a rugalmasság. És egyben a legnagyobb csapda is. Hiszen:
A felhő is csak akkor gazdaságos, ha okosan használjuk
3. A DevOps már nem lehetőség csupán CI/CD, IaC, automatizálás – ezek nélkül ma már nem lehet hatékonyan működni.
4. A biztonság az alapoktól kezdődik IAM, hálózat, access control – ha ezek nincsenek rendben, minden más kockázatos.
És az AI
Az elmúlt 2-3 évben egyértelműen egy új irány alakult ki: AI.
A felhő továbbra is ugyanarra az alapra épül, amit az elmúlt 20 évben, de komolyabb, komplexebb és meghatározó lett.
Egy személyes gondolat a végére
Ha valaki ma kezd bele a cloud-ba, lehet, hogy azt látja: rengeteg szolgáltatás, rengeteg opció, rengeteg zaj. És ez igaz is.
Ha azonban kicsit mélyebbre nézünk, akkor ugyanaz a történet, mint 20 éve:
hogyan tárolunk adatot
miként futtatunk alkalmazásokat
mit tesszük azért, hogy ez biztonságosan és költséghatékonyan működjön
Csak most már sokkal több eszközünk van rá. És talán ez a legérdekesebb az egészben: Nem az változott meg, amit csinálunk, hanem az, ahogyan csináljuk.
Merre tovább?
Ha most ismerkedsz a clouddal, ne akarj mindent egyszerre megérteni.
Kezdd egyszerűen:
néhány VM
egy storage
majd az alap hálózat
végül az adatbázis
És értsd meg, mi történik a háttérben. Ha pedig már benne vagy: érdemes néha megállni, és visszanézni.
Mert könnyű elveszni a napi taskokban, és nem észrevenni, hogy közben egy teljes iparág alakult át körülöttünk.
Az informatikában az ember ritkán áll meg egy pillanatra. Aki régóta dolgozik cloud technológiákkal, az tudja, hogy ebben a világban folyamatos a tanulás. Új szolgáltatások jelennek meg, architektúrák változnak, és ami tegnap még modernnek számított, az ma már lehet, hogy alapkövetelmény.
Most viszont történt valami, amit jó érzés megállva is megélni.
Számomra ez nem egyszerűen egy cím vagy egy badge. Sokkal inkább egy visszajelzés arra, hogy annak a munkának, amit évek óta a technológiai közösségért végzek, van értelme.
Ez azonban nem csupán nekem szól. Szeretném mindenkinek megköszönni, akik támogatnak és támogattak, hogy lehetőségem legyen eljutni ideáig. Elsősorban a feleségemnek, aki mindig mellettem áll és támogat a szakmai utamon is. És szeretnék köszönetet mondani a Mentor Klub dolgozóinak és tagjainak is.
Mi az AWS Community Builder program?
Az AWS Community Builder program egy globális kezdeményezés, amely olyan szakembereket támogat, akik aktívan segítik a technológiai közösséget.
A program tagjai világszerte olyan mérnökök, architektek és fejlesztők, akik:
– cikkeket írnak – előadásokat tartanak – technológiai tapasztalatokat osztanak meg – segítik a tanulni vágyókat
A cél nagyon egyszerű: a tudás gyorsabban terjedjen a közösségen belül.
A cloud világában ez különösen fontos. AWS, Azure és Google Cloud szolgáltatások folyamatosan fejlődnek, és sokszor a legértékesebb tudás nem a dokumentációból, hanem a valódi tapasztalatokból jön.
Miért fontos ez számomra?
Több mint húsz éve dolgozom informatikában, és az elmúlt tíz évben szinte kizárólag cloud technológiákkal foglalkozom.
AWS, Azure és Google Cloud platformokon dolgozva azt láttam, hogy rengeteg cég és mérnök ugyanazokkal a kérdésekkel küzd:
– hogyan tervezzünk jó cloud architektúrát – hogyan maradjon kezelhető a komplexitás – hogyan ne szálljanak el a költségek – hogyan építsünk biztonságos rendszereket
Ezek a rendszerek leggyakrabban a cloud infrastruktúrán futnak, így a két világ egyre jobban összekapcsolódik.
Mit jelent ez a közösségnek?
Az AWS Community Builder programban való részvétel számomra egy új motiváció arra, hogy még több tapasztalatot osszak meg.
A célom továbbra is az, hogy olyan tartalmakat készítsek, amelyek:
– érthetőek kezdőknek – hasznosak gyakorló mérnököknek – és valós tapasztalatokon alapulnak
A cloud és az AI világa gyorsan változik. Éppen ezért fontos, hogy legyenek olyan helyek és emberek, akik segítenek eligazodni benne.
Ha követed a munkámat, a jövőben még több olyan tartalomra számíthatsz, amely a cloud infrastruktúra, Kubernetes, DevOps és AI rendszerek gyakorlati oldalát mutatja be.
Egy új fejezet
Számomra az AWS Community Builder tagság egy új fejezet kezdete is.
Nem azért, mert mostantól más dolgokat fogok csinálni, hanem azért, mert még nagyobb lendülettel szeretném folytatni azt, amit eddig is csináltam: tudást megosztani és segíteni mások fejlődését.
2025-ben látványosan megváltozott az AI rendszerek iránya. A fókusz egyre inkább az úgynevezett Agentic AI felé fordult. Ebben a folyamatban nagy szerepe volt az MCP (Model Context Protocol) megjelenésének is, amely jelentősen megkönnyítette az AI rendszerek és különböző eszközök közötti integrációt.
Korábban főleg chat alapú AI rendszereket használtunk. A működés egyszerű volt: kérdeztünk valamit, az AI válaszolt. Ez sok esetben hasznos, de nem mindenre alkalmas nekünk.
Azóta az AI agentek rengeteget fejlődtek. Egyre ügyesebbek lettek, és sokkal könnyebben integrálhatók különböző rendszerekkel. Ennek köszönhetően egy új szintre léptek: megjelentek az autonóm AI agentek.
Ezek már nem csak válaszolnak egy kérdésre. Folyamatosan futnak a háttérben, figyelnek, reagálnak, feladatokat hajtanak végre, és különböző rendszerekkel kommunikálnak.
Ha belegondolunk, ez valójában nem egy teljesen új koncepció. Inkább egy természetes következő lépés. Az eddig különálló technológiák – AI modellek, automatizációk, integrációk – most kezdenek igazán összeérni.
Pont ezt a hullámot lovagolja meg az OpenClaw is. Valójában semmi újat nem hoz, hanem okosan összerakja azokat az elemeket, amelyek eddig is léteztek. A különbség inkább az, hogy nagyon alacsonyra teszi a belépési küszöböt ebbe a világba.
És most már az Amazon Lightsail segítségével ezt még könnyebb kipróbálni az AWS-ben.
Mi az az OpenClaw?
Az OpenClaw egy nyílt forráskódú autonóm AI agent.
Korábban Clawdbot vagy Moltbot néven is ismert volt, de a projekt most már OpenClaw néven fut tovább.
A működési modellje eltér attól, amit a klasszikus chat AI rendszereknél megszoktunk.
Az OpenClaw:
folyamatosan fut a háttérben
üzenetküldő platformokon keresztül kommunikál
képes feladatokat végrehajtani
kódot futtatni
fájlokat kezelni
weboldalakat böngészni
automatizált munkafolyamatokat kezelni
Alapvető kommunikációs csatornái például:
Slack (én ezt használom)
Telegram
WhatsApp
Discord
Ez azt jelenti, hogy a felhasználó egy üzenetküldő alkalmazáson keresztül kommunikál az agent-el, miközben az a háttérben egy szerveren fut.
Miért érdekes a Lightsail integráció?
Az OpenClaw eddig is telepíthető volt saját infrastruktúrára.
Viszont ezek sok esetben túl bonyolultak lehetnek egy gyors kipróbáláshoz.
Ahogy arról már írtam az Amazon Lightsail pont ilyen a problémákra ad egyszerű megoldást: A Lightsail egy leegyszerűsített AWS szolgáltatás, amely előre konfigurált szolgáltatásokat kínál fix havi áron.
Most már az OpenClaw egy előre elkészített megoldásként is elérhető ezen a platformon.
A 90 napos ingyenes lehetőség
Ahogy megszoktuk az egyes szoplgáltatásokhoz több csomagot is igénybe vehetünk. Így van ez most is, viszont a Lightsail egyik csomagja különösen érdekes.
A konfiguráció:
2 vCPU
2 GB RAM
60 GB SSD
3 TB adatforgalom
Normál esetben ez 12 USD / hó.
Most azonban az AWS 90 napos ingyenes időszakot kínál erre a csomagra.
Ez gyakorlatilag azt jelenti, hogy három hónapig teljesen inygenesen lehet kipróbálni egy saját AI agent futtatását.
Hogyan illeszkedik ez a modern AI agent trendbe?
Az AI világában most egyre többet beszélünk az úgynevezett agentic AI rendszerekről.
A különbség egyszerűen megfogalmazva:
Chat AI: A felhasználó kérdez, a modell válaszol.
AI agent: A rendszer folyamatosan fut és feladatokat hajt végre.
Az agentek általában képesek:
több eszközt használni
API-kat hívni
fájlokat feldolgozni
automatizált workflow-kat futtatni
Az OpenClaw ebbe a kategóriába tartozik. Ezért sok érdeklődő, fejlesztő és AI mérnök számára érdekes projekt.
Mire lehet használni egy ilyen AI agentet?
Az OpenClaw mögött az az elképzelés áll, hogy az AI ne csak „beszéljen”, hanem dolgozzon is.
Néhány egyszerű példa:
Automatizált Slack asszisztens: Egy csatornában figyeli a kérdéseket és segít dokumentációk alapján válaszolni.
Monitoring jelzések feldolgozása: Alert esetén információkat gyűjt és jelentést készít.
Kisebb automatizációk: Weboldalak ellenőrzése, adatgyűjtés, riportok generálása.
Nyilván ezekhez további konfiguráció és integráció szükséges, de az alap koncepció már működőképes.
Mire figyelj az AI agenteknél!
Az AI agent rendszerek körül most nagyon nagy a hype.
Úgy látom, hogy túl gyorsan próbálnak valami nagyon komplex rendszert építeni. És ebben sokszor elvesznek.
Pedig az ilyen technológiáknál sokkal fontosabb: először kísérletezni. (valami egyszerűvel)
Ezért jó a Lightsail alapú megközelítés.
Egy kis VM-en el lehet kezdeni:
tesztelni
integrációkat kipróbálni
promptokat finomítani
agent workflow-kat építeni
Ha pedig megvan a tapasztalat, és komolyabb, kreatívabb megoldás kell, akkor lehet tovább lépni.
Én is ki fogom próbálni
Az OpenClaw bizonyos szempontból számomra is érdekes projekt, ezért a következő hetekben ki fogom próbálni a Lightsail alapú megoldást, és össze fogom hasonlítani azzal a környezettel, amit jelenleg itthon futtatok a saját mikro szerveremen.
Kíváncsi vagyok például:
ugyanolyan stabil
milyen teljesítményre képes
mennyire egyszerű integrálni különböző rendszerekkel
ugyanannyi hiba van-e benne mint a helyi szerveren futó verzióban
Ha lesznek érdekes tapasztalataim, arról külön cikkben is fogok írni.
Fontos: ezekkel az agentekkel óvatosan kell bánni
Szeretném azonban mindenki figyelmét felhívni, hogy felelősséggel használja.
Az autonóm AI agentek nem csak válaszolnak, hanem aktívan cselekszenek. Kódot futtathatnak, fájlokat kezelhetnek, API-kat hívhatnak, vagy akár külső rendszerekkel is kommunikálhatnak.
Ez hatalmas lehetőség, de egyben kockázat is.
Ha egy agent túl széles jogosultságot kap, vagy rosszul konfiguráljuk, akkor könnyen okozhat problémát – akár saját rendszereinkben, akár más szolgáltatásokban.
Ezért az ilyen rendszereket mindig:
korlátozott jogosultságokkal érdemes futtatni
izolált környezetben tesztelni
és tudatosan felügyelni
Az AI agentek nagyon erős eszközök lehetnek, ezért felelősséggel kell használni őket.
Pont ezért érdemes először kísérletezni velük, mielőtt komolyabb rendszerekbe integrálnánk őket.
Összegzés
Az OpenClaw sokak szerint egy izgalmas új irányt képvisel az AI rendszerek világában. Ezzel kapcsolatban én kicsit szkeptikus vagyok. Az azonban tény, hogy felkavarta az állóvizet.
Akik eddig nem merték kipróbálni az autonóm AI agenteket, azoknak most jó lehetőség nyílik rá. Az Amazon Lightsail integráció jelentősen leegyszerűsíti az indulást.
A 90 napos ingyenes csomag kifejezetten jó lehet arra, hogy valaki elkezdjen kísérletezni ezekkel a rendszerekkel, és saját tapasztalatot szerezzen.
És egy dolgot érdemes mindig szem előtt tartani: az ilyen rendszereket mindig csak felelősséggel használjuk.
