Menu

cloud

aws_20_years

20 év AWS: felnőtt, mint egy gyerek – és mi vele változtunk

, , ,

| Olvasási idő: 4 perc |

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

Webalkalmazás régen és ma

Régen egy egyszerű webalkalmazás így nézett ki:

  • 2 fizikai szerver (web + adatbázis)
  • terheléselosztó külön hardveren
  • backup külön megoldással
  • manuális skálázás
  • napokig vagy hetekig tartó telepítés

Ma ugyanez AWS-ben:

  • Elastic Load Balancing
  • auto scaling EC2 instance-ok
  • Amazon RDS
  • Amazon S3 backup-hoz
  • Automatizált alkalmazás telepítés percek alatt

É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.

Az AWS-nél például a Amazon Bedrock, Azure-nál az Azure OpenAI, GCP-nél a Vertex AI.

A legfontosabb: Ez nem egy külön világ.

Ez a cloud következő rétege. Ezzel kapcsolatban olvasd el a AI + Cloud 2026: amikor a platform életre kel és gondolkodik című cikkemet.

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.

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Iratkozz fel az InfoPack hírlevélre
Kövess LinkedIn-en
Iratkozz fel a YouTube csatornámra
Keress meg TikTok-on is

Rendszeresen jelentkezem új, szakmai tartalmakkal, hogy ismerd a Cloud izgalmas világát.

k8s-02

Kubernetes API és hozzáférés: standard, mégis kiemelkedő

, , , , , , ,

| Olvasási idő: 5 perc |

Lassan egy éve, hogy elkezdtem írni a Kubernetes-ről és annak architektúrájáról, a microservice-alapú rendszerek működéséről és arról, hogyan vált a Kubernetes a modern alkalmazásfejlesztés egyik alappillérévé. Beszéltünk a klaszterek működéséről, a podok életciklusáról, a vezérlőkomponensek szerepéről.

Ezeken felül van egy réteg, amely mindezt összefogja. Beszéltünk már erről is több szempontból, de úgy éreztem érdemes további figyelem ennek a központi elemnek. Mert enélkül sem a kubectl, sem a vezérlők, sem az automatizmusok nem működnének.

Ez a réteg a Kubernetes API.

Olyan ez, mint egy jól szervezett város központi ügyfélszolgálata. Bármit szeretnénk elintézni – új erőforrást létrehozni, meglévőt módosítani, állapotot lekérdezni –, mindent ezen keresztül teszünk. A Kubernetes valójában egy API-vezérelt rendszer. Minden művelet, amit végrehajtunk, végső soron egy API-hívás.

Nézzük meg, hogyan érhetők el az API-erőforrások, milyen speciális végpontok léteznek, hogyan kapcsolódik ehhez a Swagger és az OpenAPI, valamint mit jelent az API-k érettségi modellje.

API erőforrások és a kubectl szerepe

A Kubernetes által publikált összes API-erőforrás elérhető a kubectl eszközön keresztül. A parancs alapformátuma:

kubectl [command] [type] [name] [flag]

A kubectl help parancs részletes információt ad az elérhető műveletekről és erőforrástípusokról.

A rendszer által elérhető API-erőforrások listája folyamatosan változhat, de az alapvető típusok közé tartoznak például:

  • pods (po)
  • services (svc)
  • deployments (deploy)
  • replicasets (rs)
  • statefulsets
  • daemonsets (ds)
  • jobs
  • cronjobs
  • configmaps (cm)
  • secrets
  • namespaces (ns)
  • nodes (no)
  • persistentvolumes (pv)
  • persistentvolumeclaims (pvc)
  • resourcequotas (quota)
  • limitranges (limits)
  • networkpolicies (netpol)
  • clusterroles
  • clusterrolebindings
  • roles
  • rolebindings
  • customresourcedefinition (crd)

Ez a lista jól mutatja, hogy a Kubernetes nem csupán podokat kezel. A klaszter működéséhez szükséges biztonsági, hálózati, tárolási és jogosultsági objektumok mind API-erőforrásként jelennek meg.

Fontos megérteni, hogy a kubectl valójában csak egy kliens az API server felé. Amikor például kiadjuk a következő parancsot:

kubectl get pods

a háttérben egy HTTP GET kérés történik az API server irányába. A kubectl nem tart fenn külön adatbázist, nem cache-el erőforrásokat önállóan. Minden információ az API-n keresztül érkezik.

Ez a modell teszi lehetővé, hogy a Kubernetes teljesen deklaratív és automatizálható rendszer legyen. Ugyanazokat az API-hívásokat használhatja egy operátor, egy CI/CD pipeline vagy egy egybinárisos vezérlőalkalmazás is.

További API-műveletek erőforrásokon

Az alapvető REST műveleteken túl a Kubernetes API speciális végpontokat is biztosít bizonyos erőforrásokhoz.

Például elérhetjük egy konténer naplóit közvetlen API-hívással:

GET /api/v1/namespaces/{namespace}/pods/{name}/log

Ez funkcionálisan megegyezik a következő paranccsal:

kubectl logs firstpod

Ha a konténer nem ír standard output-ra, akkor természetesen nem lesznek elérhető logok.

Hasonló módon létezik exec végpont is:

GET /api/v1/namespaces/{namespace}/pods/{name}/exec

Ez teszi lehetővé, hogy parancsot hajtsunk végre egy futó podban, például diagnosztikai célból.

Emellett létezik watch mechanizmus is:

GET /api/v1/watch/namespaces/{namespace}/pods/{name}

A watch végpont folyamatosan streameli az erőforrás változásait. Ez kulcsfontosságú a vezérlők működésében. A Kubernetes kontrollerei nem ciklikusan lekérdezik az állapotot, hanem figyelik az eseményeket, és a változásokra reagálnak.

Ez az eseményvezérelt működés biztosítja a rendszer hatékonyságát és skálázhatóságát.

Swagger és OpenAPI a Kubernetesben

A Kubernetes teljes API-ja eredetileg Swagger specifikáció alapján készült, és az idő múlásával az OpenAPI irányába fejlődött.

Ez rendkívül fontos, mert az OpenAPI leírás lehetővé teszi klienskód automatikus generálását. Ha rendelkezésre áll a specifikáció, abból generálható Go, Python, Java vagy más nyelvű klienskönyvtár.

A stabil erőforrás-definíciók elérhetők a hivatalos dokumentációban. Emellett a Swagger UI segítségével böngészhetők az API-csoportok, megtekinthetők a végpontok, paraméterek és válaszstruktúrák.

Ez a fajta formális API-leírás teszi lehetővé, hogy a Kubernetes ökoszisztéma ennyire gazdag legyen. Az operátorok, kliensek, SDK-k és automatizációs eszközök mind ugyanarra a formálisan definiált API-ra épülnek.

API-csoportok és verziózás

A Kubernetes API nem egy monolitikus struktúra. API-csoportokra és verziókra bontva épül fel.

Az API-csoportok és verziók használata lehetővé teszi, hogy a fejlesztés előrehaladjon anélkül, hogy egy meglévő API-csoport módosulna. Ez segíti a skálázható fejlesztést és a csapatok közötti munkamegosztást.

Fontos, hogy az API és a Kubernetes szoftververziója csak közvetetten kapcsolódik egymáshoz. Nem minden szoftverfrissítés jelent API-törést.

A Kubernetes API JSON és Google Protobuf szerializációs formátumokat használ, amelyek a kiadási irányelvekhez igazodnak.

Az API-verziók három érettségi szintbe sorolhatók:

  • Alpha
  • Beta
  • Stable

Alpha

Az alpha jelölésű funkciók kísérleti állapotban vannak. Alapértelmezetten le vannak tiltva. Hibásak lehetnek, bármikor változhatnak vagy eltűnhetnek, és nem garantált a visszafelé kompatibilitás.

Csak teszt klaszterben javasolt a használatuk, amelyet gyakran újraépítenek.

Beta

A beta szintű funkciók már jobban teszteltek, és alapértelmezetten engedélyezettek. A változások során figyelnek a visszafelé kompatibilitásra, de még nem tekinthetők teljesen stabilnak.

Előfordulhatnak hibák vagy viselkedésbeli módosulások.

Stable

A stable verziókat csak egy szám jelöli, például v1. Ezek stabil API-k, amelyekre hosszú távon lehet építeni. Jelenleg a v1 az egyetlen stabil verzió.

A verziózási rendszer biztosítja, hogy a klaszterben futó alkalmazások ne törjenek el egy frissítés során, és a platform evolúciója kontrollált módon történjen.

Miért fontos ez a gyakorlatban?

Ha Kubernetes környezetben dolgozol, akkor valójában folyamatosan az API-val dolgozol, akár tudatosan, akár nem.

Amikor YAML fájlt alkalmazol, amikor egy CI/CD pipeline deployol, amikor egy operátor létrehoz egy egyedi erőforrást CRD-n keresztül, minden az API-n keresztül történik.

Az API-csoportok és verziók ismerete segít:

• megérteni, hogy egy erőforrás mennyire stabil
• eldönteni, hogy production környezetben használható-e
• tervezni a frissítési stratégiát
• automatizálási eszközöket építeni

A Kubernetes nem egyszerűen konténer-orchestration eszköz. Egy deklaratív, API-vezérelt platform, amely formálisan definiált interfészeken keresztül működik.

Ha ezt a réteget érted, akkor nem csak használod a klasztert, hanem érted is, hogyan gondolkodik.

És ez az a pont, ahol a Kubernetes már nem csak technológia, hanem architektúra.

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Generative-AI-Leader-Badge

Tanúsítvány: Generative AI Leader vizsga a Google-nél

, , , , ,

| Olvasási idő: 4 perc |

Korábban írtam, hogy a tanúsítvány nem helyettesíti a tapasztalatot. Valójában arra alkalmas, hogy felmérjük, hol állunk az egyes szolgáltatók mércéje szerint a piacon.

Nálam emellett más szerepe is van, hiszen rendszeresen készítek fel szakembereket Cloud-os vagy AI-os vizsgákra a mentor programom keretében. Ezért nekem is kell ismernem a vizsgák tartalmát.

Emiatt az idei évre egy érdekes kihívást találtam ki magamnak:
A terv az, hogy az év első felében minden hónapban leteszek egy felhővel vagy AI-val kapcsolatos vizsgát.

Februárban a Google Cloud Generative AI Leader vizsgára esett a választás. Ez számomra észszerű lépés volt. Bár alapvetően felhővel foglalkozom, az AI világával már több mint három éve foglalkozom mélyebben. Az elmúlt években rengeteg projektben találkoztam LLM modellekkel, prompt engineering-el, RAG architektúrákkal és különböző AI szolgáltatásokkal. Így ez a vizsga egy logikus lépésnek tűnt.

Miről szól a Generative AI Leader vizsga?

A Generative AI Leader vizsga azt méri, hogy mennyire érted a generatív AI működésének alapjait, és hogy képes vagy-e felismerni, milyen üzleti problémákra érdemes AI megoldásokat alkalmazni.

Fontos kiemelni, hogy ez nem egy mély technikai vizsga. Nem kell modelleket tréningezni vagy kódot írni.

Ennek ellenére nem nevezném kezdő szintűnek sem. A vizsga feltételez egy alap AI tudást, például az alábbi területeken:

  • generatív AI működése
  • LLM modellek alapjai
  • prompt engineering alapfogalmak
  • AI használati esetek
  • felelős AI használat

A kérdések nagy része inkább szituációs jellegű. Például egy adott üzleti problémára kell kiválasztani a megfelelő AI megközelítést vagy szolgáltatást. Ez az ilyen vizsgáknál ugyan alapvető, de biztosan vannak olyan olvasóim, akik még nem vettek részt ilyen vizsgán. Nekik segítség lehet, ha el tudják képzelni, hogy milyen típusú kérdésekre lehet számítani.

Google Cloud generatív AI szolgáltatások

A felkészülés során több Google Cloud AI szolgáltatás is előkerül. Ezek közül néhány a generatív AI ökoszisztéma fontos része.

Vertex AI

A Vertex AI a Google Cloud központi machine learning és AI platformja. Itt lehet modelleket tréningezni, finomhangolni és éles környezetben futtatni.

Generatív AI esetén a Vertex AI biztosít hozzáférést különböző foundation modellekhez, valamint eszközöket a modellek kiértékelésére és üzembehelyezésére.

Vertex AI Studio

A Vertex AI Studio egy olyan fejlesztői környezet, ahol gyorsan ki lehet próbálni generatív modelleket.

Például itt lehet:

  • promptokat tesztelni
  • model paramétereket állítani
  • prototípus AI alkalmazásokat készíteni

Ez egy nagyon jó eszköz kísérletezésre és tanulásra.

Gemini modellek

A Gemini a Google generatív AI modellcsaládja. Ezek a modellek képesek többek között:

  • szöveg generálásra
  • kód generálásra
  • multimodális feladatok kezelésére

A Gemini modellek integrálhatók különböző Google Cloud szolgáltatásokkal és alkalmazásokkal.

Model Garden

A Model Garden egy olyan gyűjtemény a Vertex AI környezeten belül, ahol különböző előre elkészített modellek érhetők el. Ezek lehetnek Google által készített modellek vagy nyílt forrású modellek.

Ez segít abban, hogy a fejlesztők gyorsan kipróbálhassanak különböző modelleket anélkül, hogy mindent a nulláról kellene felépíteni.

Hogyan készültem fel a vizsgára?

A felkészülés meglepően élvezetes volt.

Habár már több projekten is dolgoztam ezeken a szolgáltatásokon, jó volt rendszereznem magamban is az ezzel kapcsolatos tudást és tapasztalatot. Ehhez a Google saját tananyaga nagyon jó alapot ad a vizsga témáinak megértéséhez. Ezek az anyagok strukturáltan mutatják be a generatív AI koncepciókat és a Google Cloud AI szolgáltatásait.

Emellett a YouTube-on is rengeteg ingyenes tananyag található. Több olyan videós kurzus is van, amely kifejezetten erre a vizsgára készít fel. Ezek közül, talán ez freeCodeCamp.org Google Generative AI Leader Certification Course videója a leghasznosabb.

Ami nekem külön tetszett, hogy a vizsga nem csak technológiáról szól.

Hanem arról is, hogy:

  • mikor érdemes AI-t használni
  • mikor nem
  • milyen kockázatai vannak
  • hogyan lehet felelősen bevezetni

Ez a gondolkodásmód egyre fontosabb a vállalati környezetben.

A vizsga élménye

Őszintén szólva nagyon élveztem.

A kérdések sok esetben valóshoz hasonló helyzeteket modelleznek. Nem az a típusú vizsga, ahol definíciókat kell visszamondani. Sokkal inkább arról szól, hogy érted-e az AI működésének alapjait, és képes vagy-e alkalmazni ezt a tudást egy adott problémára.

És igen…Megvan ez a vizsga is.

Mi jön ezután?

A következő cél már a márciusi vizsga: az Azure AI-900.

Ez egy alap AI vizsga a Microsoft ökoszisztémában, amely az AI alapfogalmait, az Azure AI szolgáltatásokat és a generatív AI megoldásokat mutatja be. Ez azonban elvileg jóval nehezebb, mint a Google Generative AI Leader.

Ha minden a terv szerint halad, hamarosan erről a vizsgáról is írok majd egy külön cikket.

És ne feledd: a tanúsítvány nem helyettesíti a tapasztalatot.

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Iratkozz fel az InfoPack hírlevélre
Kövess LinkedIn-en
Iratkozz fel a YouTube csatornámra
Keress meg TikTok-on is

Rendszeresen jelentkezem új, szakmai tartalmakkal, hogy ismerd a Cloud izgalmas világát.

AWS-Community-Builders-1024

AWS Community Builder lettem – Egy új és izgalmas időszak

, , , ,

| Olvasási idő: 3 perc |

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.

2026-tól hivatalosan is az AWS Community Builder program tagja lettem.

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

Az elmúlt három évben ehhez egy új terület is csatlakozott: a mesterséges intelligencia.

Egyre több projektben jelennek meg olyan megoldások, amelyek például:

– LLM modelleket használnak
– RAG architektúrára épülnek
– vagy agent rendszerekkel automatizálnak folyamatokat

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.

Köszönöm!

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Iratkozz fel az InfoPack hírlevélre
Kövess LinkedIn-en
Iratkozz fel a YouTube csatornámra
Keress meg TikTok-on is

Rendszeresen jelentkezem új, szakmai tartalmakkal, hogy ismerd a Cloud izgalmas világát.

openclaw_lightsail_featured

OpenClaw már Lightsail-en: autonóm AI agent percek alatt

, , , , , , , , , ,

| Olvasási idő: 5 perc |

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.

Például:

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.
  • Fejlesztői workflow támogatás: Feladatokat gyűjt, fájlokat generál, scriptet futtat.
  • 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.

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Iratkozz fel az InfoPack hírlevélre
Kövess LinkedIn-en
Iratkozz fel a YouTube csatornámra
Keress meg TikTok-on is

Rendszeresen jelentkezem új, szakmai tartalmakkal, hogy ismerd a Cloud izgalmas világát.

gcp_free_tier_kiemelt_kep

GCP Free Tier 2026 – Mit kapsz ingyen a Google felhőben?

, , , , ,

| Olvasási idő: 4 perc |

Már láthattad, mire elég az Azure és az AWS Free Tier szolgáltatásai. Biztos vagyok benne, hogy kíváncsi vagy arra is, mit ad ingyen a Google Cloud – és vajon ez mennyire használható valódi projektekhez.

A GCP sokszor csendesebb szereplő, mégis vannak területek, ahol kifejezetten erős. Nézzük meg, mit kapsz ingyen, és mit nem.

A GCP Free Tier három pillére

Ahogy a többi szolgáltató esetén, a Google Cloud ingyenes lehetőségei is három fő részből állnak:

  1. 90 napos induló kredit (jellemzően 300 USD)
  2. Mindig ingyenes (Always Free) szolgáltatások (időkorlát nélkül, havi kvótával)
  3. Bizonyos szolgáltatások limitált, ingyenes használata kvótához kötve

90 napos induló kredit – nem kevés

Regisztráció után a Google jellemzően 300 USD kreditet biztosít, amely 90 napig használható.

ingyen

Ez arra való, hogy:

  • kipróbáld a Compute Engine nagyobb VM-jeit
  • indíts GKE (Kubernetes) cluster-t
  • tesztelj Cloud SQL-t
  • AI/ML szolgáltatásokat próbálj ki
  • felépíts egy kisebb környezetet, ahol valóban gyakorolhatsz.

Ez tanulási és teszt környezet építésre való, nem éles üzleti rendszerre.

Mindig ingyenes – kvótatáblázat

Az alábbi táblázat a főbb Always Free kvótákat foglalja össze havi bontásban. Régiós korlátozások érvényesek (bizonyos USA régiók). A teljes, folyamatosan frissülő listát itt találod.

Compute és infrastruktúra

SzolgáltatásHavi Always Free kvóta
Compute Engine (e2-micro)1 db e2-micro VM (kijelölt régiók)
Persistent Disk (standard)30 GB
Snapshot5 GB
Cloud Storage (Standard)5 GB
Cloud Storage Class A művelet5 000 / hó
Cloud Storage Class B művelet50 000 / hó

Serverless és konténer

SzolgáltatásHavi Always Free kvóta
Cloud Run2 millió request
Cloud Run CPU180 000 vCPU-másodperc
Cloud Run memória360 000 GB-másodperc
Cloud Functions2 millió invokáció
Pub/Sub10 GB üzenetforgalom

Adat és analitika

SzolgáltatásHavi Always Free kvóta
BigQuery lekérdezés1 TB
BigQuery storage10 GB aktív tárolás
Firestore50 000 olvasás / nap
Firestore20 000 írás / nap
Firestore20 000 törlés / nap

CI/CD és fejlesztés

SzolgáltatásHavi Always Free kvóta
Cloud Build120 build perc / nap
Artifact RegistryLimitált tárolás

Mire elég ez valójában?

Most jöjjenek a példák, hogy mire is lehet elég az ingyen felhő. A GCP kicsit más mint a többi szolgáltató, így itt kicsit más példákat is hoztam.

1. Személyes költségkimutatás

Képzeld el, hogy építesz egy saját pénzügyi dashboard-ot.

  • Cloud Run: backend API
  • Firestore: tranzakciók tárolása
  • BigQuery: havi aggregált kimutatások
  • Cloud Storage: CSV import

Ezzel kipróbálhatod az adatmodellezést, a jelentés készítést és az SQL analitika építést.

2. Naplóbejegyzések gyűjtse és elemzése

Ha DevOps irányba mész, építhetsz egy egyszerűnek tűnő, mégis hasznos log pipeline-t.

  • Pub/Sub: log események fogadása és továbbítása
  • Cloud Run: feldolgozó logika
  • BigQuery: tárolás és lekérdezés

Megtanulod, hogy mi az event-driven architektúra, az adatfolyam modellezés és a költséghatékony adattárolás. A havi 1 TB lekérdezési keret tanulásra bőven elég.

3. AI asszisztens backend a weboldaladhoz

Egészítsd ki a weboldalad egy chatbottal, aki válaszol a látogatók kérdéseire.

  • Cloud Run: REST endpoint
  • Vertex AI: LLM
  • Firestore: prompt log

Megtanulod, az API integrációt, a mesterséges intelligenci modellek integrálását és a token alapú költségmonitorozást is megismered.

4. Automatizált jelentés generáló szolgáltatás

Készíts egy olyan backend szolgáltatást, amely adatból automatikusan PDF riportot generál.

  • Cloud Run: riport generáló REST endpoint
  • Cloud Storage: elkészült PDF tárolása
  • Pub/Sub: aszinkron feldolgozás

Megtanulod, az aszinkron feldolgozás logikáját, a fájlkezelést felhőben és az eseményvezérelt architektúra alapjait is megismered.

5. Egyszerű IoT adatgyűjtő backend

Készíts egy backend rendszert, amely szenzor adatokat fogad és eltárol.

  • Pub/Sub: eszköz adat fogadása
  • Cloud Run: adatfeldolgozás
  • BigQuery: történeti adat tárolás és lekérdezés

Megtanulod, az eseményvezérelt adatfeldolgozást, az időalapú adatok kezelését és a nagyobb adathalmazok SQL alapú elemzését is megismered.

Mire nem alkalmas?

Egy rövid lista arról, hogy mit ne:

  • production SaaS skálázásra
  • multi-region magas rendelkezésre állásra
  • nagy GKE cluster futtatására
  • komoly adatforgalmú weboldalra
  • nagy számításigényű MI modell tanításra

Arra is figyelj , ha nagy mennyiségű adatot kérdezel le BigQuery-ben rendszeresen, az 1 TB gyorsan elfogy. Valamint jelentős egress forgalom esetén, az nem „mindig ingyenes”. Amikor GPU-s AI training instance-et indítasz, a 90 napos kredit is gyorsan kimerülhet.

Általános költségkezelési problémák és megoldásuk

Minden képzésemen el szoktam mondani az alábbiakat, mert sosem árt ismételni.

ProblémaMegoldás
Fejlesztői virtuális gép fut éjszaka isKapcsold le, ha nem használod
Nincs költségkeret beállítvaÁllíts be Budget alertet a Billing alatt
Több projekt egy helyre számlázódikHasználj külön projektet környezetenként
Egress forgalmat nem számolodTervezésnél vedd figyelembe a kimenő adatot
BigQuery teljes táblát lekérdezedHasználj partitioninget és LIMIT-et
Teszt erőforrásokat nem törlödHasználj lifecycle szabályokat és rendszeres takarítást

A Billing menüpont alatt könnyen beállítható:

  • költségkeret
  • értesítés
  • projektenkénti költségkontroll

A felhő mindig egy másfajta szemléletet kíván. Ez csak az elején nehéz, utána belerázódsz.

Összegzés

A GCP Free Tier nem arra való, hogy production rendszert építs rá.

Arra viszont nagyon is jó, hogy megtanuld a Google Cloud gondolkodásmódját:
serverless működés, adatközpontú tervezés, menedzselt szolgáltatások és az AI szolgáltatások integrálása.

Fel tudsz vele építeni valós, bemutatható projekteket – akár adat-elemzési, akár AI asszisztens jellegű megoldásokat.

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Iratkozz fel az InfoPack hírlevélre
Kövess LinkedIn-en
Iratkozz fel a YouTube csatornámra
Keress meg TikTok-on is

Rendszeresen jelentkezem új, szakmai tartalmakkal, hogy ismerd a Cloud izgalmas világát.

aws-free-tier-hero

AWS Free Tier 2026-ban: valódi lehetőség vagy illúzió?

, , , , , ,

| Olvasási idő: 5 perc |

A felhő világában a költség egy kritikus szempont. Főleg akkor, amikor szeretnél belépni vagy elmélyedni ebben a világban. Ilyenkor hatalmas segítség, ha vannak olyan szolgáltatások, amelyeket olcsóbban vagy akár ingyenesen (free) vehetsz igénybe. Erről lesz most szó.

Legutóbb az Azure esetén néztük meg, milyen ingyenes lehetőségek állnak rendelkezésre. Most az AWS-en belül vizsgáljuk meg ugyanezt – konkrét számokkal, free quota táblázattal és őszinte értékeléssel.

Az Amazon Web Services Free Tier modellje átgondolt és strukturált, de könnyű elveszni benne. Ezért jó ismerni, hogy magabiztosan mozogjunk ezen a területen is.

Hogyan épül fel az AWS Free Tier?

Az AWS szintén három kategóriába sorolja az ingyenes lehetőségeket:

  1. 12 hónapig ingyenes szolgáltatások
  2. Mindig ingyenes (Always Free – időkorlát nélküli) szolgáltatások
  3. Induló kreditek új ügyfeleknek (Free Plan keretében)

Ez az utóbbi az, ami az utóbbi időszakban kiemelten fontos lett. Ráadásul ez egy új lehetőség, ami 2025. július 15 óta elérhető.

AWS Free Plan vs Paid Plan – mit jelent ez valójában?

Az AWS új ügyfelek számára egy Free Plan modellt kínál, amely:

  • legfeljebb 6 hónapig használható,
  • akár 200 USD kredithez biztosíthat hozzáférést,
  • korlátozott keretek között teszi lehetővé a szolgáltatások kipróbálását.

Ez a 200 USD kredit tipikusan:

  • egy rész regisztrációkor,
  • egy rész további használat után érhető el.

Fontos: a kredit nem korlátlan hozzáférést jelent. A kredit keret erejéig használhatod a szolgáltatásokat.

free credit

Mi történik a kredit elfogyása után?

Két lehetőség van:

  1. Nem váltasz fizetős változatra (Paid Plan), így a használat korlátozott marad.
  2. Átváltasz a fizetős változatra és elindul a normál a számlázási modell.

A Fizetős esetén:

  • teljes hozzáférést kapsz az AWS szolgáltatásokhoz,
  • a kredit feletti használat fizetős,
  • a workload szabadon skálázható.

Ez enterprise szempontból is kritikus pont. Hiszen ott is van létjogosultsága ezen ingyenes lehetőségeknek:

  • A Free Plan sandbox vagy játszótér.
  • A Paid Plan production vagy élő rendszer.

Ha komoly architektúrát akarsz építeni, előbb-utóbb át kell váltanod a fizetős változatra.

AWS Free Tier – részletes free quota táblázat

Az alábbiak a 2026 elején érvényes keretek. (a teljes, folyamatosan frissülő listát itt találod)

12 hónapig ingyenes szolgáltatások

SzolgáltatásFree quotaGyakorlati jelentőség
Amazon EC2750 óra/hó t2.micro vagy t3.micro1 db folyamatosan futó kis VM
Amazon EBS30 GB gp2/gp31 kisebb rendszer diszk
Amazon S35 GB Standard storageStatikus fájlok, demó
Amazon S320 000 GET + 2 000 PUT kérésKis forgalmú projekt
Amazon RDS750 óra db.t3.micro (vagy hasonló)1 teszt adatbázis
Amazon RDS20 GB storageKis demó DB
Amazon CloudFront1 TB adatforgalomStatikus oldal globális teszt
AWS Lambda1M request + 400 000 GB-sKis serverless API

Fontos: a 750 óra egy havi, összesített keret az adott instance típusra. Több VM is futhat, de az órák összeadódnak. Ha például két instance fut folyamatosan, a keret nagyjából a hónap felénél elfogy.

Always Free szolgáltatások

SzolgáltatásFree quotaMire alkalmas
AWS Lambda1M request/hóHosszú távú kis API
Amazon DynamoDB25 GB + limitált R/WKis NoSQL backend
Amazon SQS1M request/hóEvent-driven tanulás
Amazon SNS1M publish/hóEmail / notification teszt
AWS CloudWatch10 custom metric + 5 GB logAlap monitoring
AWS IAMIngyenesRole és policy design
Amazon VPCIngyenesHálózati alapok

Mire elég ez a valójában?

Gondoltam írok néhány példát, ami talán felkelti az érdeklődésed, hogy mire is lehet elég az ingyenes szolgáltatás.

1. Egyszerű webalkalmazás adatbázissal (EC2 + RDS)

Készíthetünk egy egyszerű webalkalmazást, ami adatot fogad (pl. űrlap), majd eltárolja SQL adatbázisban és bármikor vissza tudja listázni az adatokat. Ehhez tudjuk használni az alábbi ingyenes szolgáltatásokat:

  • EC2: webszerver és alkalmazás réteg
  • Amazon RDS: SQL adatbázis
  • VPC: hogy az egyes rétegek (tier) a megfelelő védelmet kapják, privát és publikus alhálózatok használatával

Ezzel a felépítéssel az alkalmazás és az adatbázis hálózati szinten is elkülöníthető.

2. Statikus weboldal ingyen (S3)

Készíthetünk egy egyszerű statikus weboldalt (HTML, CSS, JavaScript). Ehhez használhatjuk az alábbi ingyenes szolgáltatást:

  • Amazon S3: statikus fájlok tárolása és kiszolgálása

Az S3 bucket konfigurálható statikus website hosting módban, így webszerver üzemeltetése nélkül publikálható egy weboldal.

3. Kiszolgálómentes megoldás (Lambda)

Készíthetünk egy egyszerű API-t vagy adatfeldolgozó logikát, ahol nincs folyamatosan futó szerver, csak kód, ami kérésre lefut. Ehhez használhatjuk az alábbi ingyenes szolgáltatásokat:

  • AWS Lambda: futtatási környezet
  • Amazon API Gateway: HTTP végpont biztosítása
  • Amazon DynamoDB: adatok tárolása

Itt a kód csak akkor fut, amikor kérés érkezik, és a skálázás is automatikus.

4. DevOps gyakorlás Free Tier-ben

Modellezhetünk egy egyszerű CI/CD folyamatot is, ahol például a GitHub-on lévő kódod módosítása után automatikusan frissül az alkalmazás. Ehhez használhatjuk akár:

  • AWS CodePipeline: pipeline vezérlés
  • AWS CodeBuild: build folyamat (ha szükséges)
  • Amazon EC2 vagy Amazon S3: cél környezet

Ezzel kipróbálható az automatizált deploy, a jogosultságkezelés és a pipeline alaplogika Free Tier keretben.

Mire nem?

Nem alkalmas:

  • production SaaS skálázásra
  • több rendelkezési zónában (availability zone) működő magas rendelkezésre állású (HA) architektúrára
  • nagy adatforgalmú weboldalra
  • komoly gépi tanulás (ML) vagy mesterséges intelligencia (AI) alapú megoldások kivitelezésére

Ha például Amazon SageMaker training instance-et indítasz, az ingyenes keret gyorsan elfogy.

Hol tudom ellenőrizni az ingyenes (Free Tier) kereteket?

Az AWS Console-ban a felső menüből elérhető a Billing and Cost Management felület.

Itt a bal oldali menüben találod a Free Tier részt, ahol:

  • szolgáltatásonként látod a Free Tier felhasználást
  • százalékosan jelzi, mennyit használtál el a havi keretből
  • külön mutatja a 12 hónapos és az Always Free kereteket

Emellett érdemes megnézni:

  • Budgets: költségkeret beállítása
  • Cost Explorer: részletes költségelemzés

A legfontosabb

Az AWS Free Tier nem arra való, hogy ingyen fusson a céged.

Arra való, hogy:

  • tanulj,
  • prototípust építs,
  • megértsd a költségmodellt,
  • enterprise szemléletet sajátíts el.

Amit én javaslok:

  1. Költségkeret szint és riasztás beállítása az első napon (Budget)
  2. Erőforrás címkézés
  3. Rendszeres költségellenőrzés (Cost Explorer)

És ne felejts el:

Ha nem használod, kapcsold le!

Összefoglaló

Az AWS Free Tier valódi lehetőség arra, hogy kockázat nélkül kipróbálj komplett architektúrákat.

Nem korlátlan.
Nem production környezetre való.
De elegendő ahhoz, hogy:

  • egyszerű webalkalmazást építs adatbázissal
  • statikus weboldalt publikálj
  • kipróbálj egy kiszolgálómentes megoldást
  • automatizált deploy folyamatot gyakorolj

A kulcs nem az, hogy mit indítasz el, hanem az, hogy figyeled-e a kereteket. A Billing and Cost Management felületen a Free Tier rész pontosan megmutatja, hol tartasz.

Ha tudatosan használod, a Free Tier nem csak ingyenes infrastruktúra, hanem egy kontrollált tanulási környezet.

Ha most ismerkedsz az AWS-sel, érdemes itt kezdeni. És közben megszokni azt a gondolkodást, ami később production környezetben is elvárás lesz. Ez segít megkönnyíteni, melyik felhőszolgáltatót válaszd:

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Iratkozz fel az InfoPack hírlevélre
Kövess LinkedIn-en
Iratkozz fel a YouTube csatornámra
Keress meg TikTok-on is

Rendszeresen jelentkezem új, szakmai tartalmakkal, hogy ismerd a Cloud izgalmas világát.

azure_free_tier_cloud_vs_money

Azure Free Tier: Mire jók valójában az ingyenes eszközök?

, , , , ,

| Olvasási idő: 6 perc |

Rendszeresen találkozom a kérdéssel: „érdemes-e Azure-t tanulni?”. A válaszom mindig ugyanaz, és ezt mér korábban itt a blogon is kifejtettem, 2026-ban nem hogy érdemes, de az AI fejlődéséi iránya miatt talán még fontosabb, mint valaha. Azután, ahogy beszélgetünk hamar ugyanoda lyukadunk ki: mennyi pénzbe kerül-e az első lépés?

A legtöbben attól félnek, hogy a cloud azonnal százezres számlát generál. És igen, láttam már olyat, hogy valaki elfelejtett leállítani néhány VM-et, vagy egy prototípusoknak szánt Kubernetes cluster-t felskálázva hagy (Én), és meglepődött a hó végén.

Az is tény, hogy ha valaki komolyan szeretne elmélyedni ebben a világban, annak be kell fektetnie a tudásba és a jövőbe. Semmi sincs ingyen.

Ez a cikk azonban nem arról szól, hogy elvegyem mindenki kedvét a tanulástól, fejlődéstől és az új lehetőségek megismerésétől. Sőt, pontosan az a célom, hogy aki hezitál, vajon bele merjen-e vágni a felhő tanulásba, annak azt mondjam: Igen! Az Azure Free Tier a tökéletes belépési pont mert: lehet ezt tudatosan, biztonságosan és költségkontroll alatt csinálni.

Ez is segíthet, hogy el tudd dönteni, hogy miért lehet jó választás az Azure 2026-ban.

Most megmutatom, mire elég valójában az Azure ingyenes csomag – és azt is, mire nem.

Mit jelent az Azure Free Tier?

Az Azure három fő ingyenes kategóriát kínál:

  1. 12 hónapig ingyenes szolgáltatások
  2. Mindig ingyenes szolgáltatások (Always Free)
  3. 200 USD induló kredit új regisztrációkor

Ez nem csupán marketingtrükk, ezek valódi, használható lehetőségek.

Fontos: az ingyenesség erőforrás- és mennyiségi korlátokhoz kötött.

Virtuális gépek – Tanulásra elég?

Az Azure biztosít bizonyos méretű Linux vagy Windows VM-et 12 hónapig ingyenesen (korlátozott havi óraszámmal).

Mire elég ez a gyakorlatban?

  • Linux alapok tanulása
  • NGINX vagy Apache webserver kipróbálása
  • Docker telepítés
  • Egyszerű API deploy
  • CI/CD pipeline tesztelése

Mire nem?

  • Production workload
  • Magas rendelkezésre állás
  • Komoly terhelés

A Free VM tipikusan B-sorozatú, burstable instance. Ez azt jelenti, hogy rövid ideig jól teljesít, de nem folyamatos terhelésre tervezték.

Amit sokan elrontanak: Nem állítják le éjszakára. A Free tier óraszámhoz kötött.

Ez azt is jelenti, hogy a havi 750 óra nem egyetlen gépre vonatkozik, hanem az adott gépméretből az adott hónapra. Tehát indíthatok 3 db gépet is az ingyenes mérettel, de ez esetben egy gépre havi 250 óra jut majd. Ebből is látszik, hogy van ebben rugalmasság, ami emeli a használhatóságot.

Azure App Service – Egyszerű webapp hosting

Az Azure App Service rendelkezik Ingyenes (F1) csomaggal. Ez általában napi 60 perc használatot tesz lehetővé. Nem az indítástól számítják ezt az időt, hanem összegzik azon másodperceket, amikor a szolgáltatást a felhasználóink igénybe vették. Ez így máris jobban hangzik.

Mire alkalmas?

  • Portfólió weboldal
  • Prototípus alkalmazások
  • Node.js vagy .NET demo alkalmazás
  • REST API tesztkörnyezet
  • Karrierváltóknak GitHub → DevOps gyakorlás
  • Ritkán használt alkalmazások

Mire nem?

  • Enterprise szintű skálázás
  • SLA (rendelkezésreállási) garancia
  • Éles rendszer szintű stabilitás
  • Izolált környezetek létrehozása

Ez inkább egy játszótér, ahol kipróbálhatunk és megtanulhatunk dolgokat. Erre a célra viszont tökéletes.

Azure Functions – Serverless tanulás

Az Azure Functions consumption plan (Rugalmas fogyasztási csomag) modellben havi szinten bizonyos számú futtatás ingyenes.

Ez már komolyabb dolog.

Mire elég?

  • Webhook feldolgozás
  • Egyszerű háttérfolyamat
  • Időzített feladat (cron jellegű)
  • API backend MVP

Serverless architektúrát lehet vele tanulni valós módon.

Itt már látszik az enterprise gondolkodás alapja: Event-driven design, skálázás igény szerint.

Azure Cosmos DB Free Tier

Az Azure Cosmos DB rendelkezik Free Tier opcióval, amely bizonyos throughput (RU/s) és tárhely limit mellett ingyenes.

Mire jó?

  • Dokumentum alapú adatmodell tanulása
  • JSON alapú NoSQL gondolkodás
  • API backend adatbázisa
  • Proof of Concept (PoC)

Mire nem?

  • Nagy forgalmú rendszer
  • Komplex multi-region architektúra

Tanulásra, fejlesztésre teljesen reális.

Azure Storage – A csendes hős

Blob storage, Queue, File – ezekből mindig van egy kisebb ingyenes keret.

Mire elég?

Sokan nem is sejtik, hogy egy teljesen működő statikus weboldalt ki tud szolgálni Storage + CDN kombináció.

Azure SQL Database – Korlátozott, de hasznos

Az ingyenes keretben elérhető bizonyos DTU-alapú adatbázis.

Ez nem production, de:

  • SQL tanulás
  • ORM kipróbálás
  • Backend fejlesztés

Teljesen elegendő.

Azure Active Directory (Microsoft Entra ID)

Az identitás- és hozzáférés-kezelés (IAM) az egyik legfontosabb enterprise téma. Eben az Entra ID adja az alapot, ami nagyon sokáig elegendő ingyenesen is. Tehát az alap funkcionalitás mindig elérhető.

Mire jó?

  • App registration / Service principal (programozott hozzáféréshez)
  • RBAC teljeskörű használata
  • OAuth2 / OpenID kapcsolódás
  • SSO
  • Multi-tenant alkalmazás támogatás
  • B2B external user meghívás (külső felhasználók meghívása az erőforrások kezelésére)

Ami nincs benne

Karrierváltóknak, vagy akik a hagyományos Active Directory-ban jártasak, ez aranyat ér.

Ízelítő – Azure Free Tier lista (12 hónapig ingyenes és mindig ingyenes)

KategóriaSzolgáltatásIngyenesség típusaFő limit / kvóta
ComputeLinux Virtual Machine (B1s/B2)12 hónap750 óra/hó
ComputeWindows Virtual Machine12 hónap750 óra/hó
StorageBlob Storage (LRS)12 hónap5 GB
StorageAzure Files12 hónap100 GB
StorageArchive Storage12 hónap10 GB
StorageManaged Disks12 hónap2 × 64 GB
ContainerAzure Container Registry12 hónap100 GB tár
DatabaseCosmos DB12 hónap400 RU/s + 25 GB
DatabaseAzure Database for MySQL12 hónap750 óra + 32 GB
DatabaseAzure Database for PostgreSQL12 hónap750 óra + 32 GB
DatabaseSQL Managed Instance12 hónap720 vCore-óra
IntegrationService Bus (Standard)12 hónap750 óra + műveleti limit
NetworkLoad Balancer12 hónap750 óra
NetworkVPN Gateway12 hónap750 óra
NetworkOutbound Data Transfer12 hónap15 GB
SecurityKey Vault12 hónap10 000 művelet
ServerlessAzure FunctionsMindig1 millió futtatás
App HostingApp Service (F1)Mindig10 app
WebStatic Web AppsMindig100 GB bandwidth
ContainersAzure Kubernetes Service (control plane)MindigControl plane ingyen
ContainersContainer AppsMindigHavi kvótás compute
DevOpsAzure DevOpsMindig5 user
IdentityMicrosoft Entra IDMindig50 000 objektum
IdentityAzure AD B2CMindig50 000 MAU
AIAzure AI SearchMindig50 MB index
AIAzure TranslatorMindig2 millió karakter
AILanguage ServiceAlways Free5 000 rekord
AISpeech ServiceAlways FreeLimitált perc
IntegrationAPI ManagementAlways Free1 millió hívás
IntegrationEvent GridAlways Free100 000 művelet
IntegrationLogic AppsAlways Free4 000 beépített művelet
IoTIoT Hub FreeAlways Free8 000 üzenet/nap
MonitoringAzure MonitorAlways FreeLimitált adat
AdminCost ManagementAlways FreeIngyenes
AdminCloud ShellAlways Free5 GB tár
AutomationAzure AutomationAlways Free500 perc

Teljes, naprakész lista itt található.

Mit lehet ebből valójában felépíteni?

Egy reális MVP architektúra Free tierből:

  • Frontend: Azure Storage statikus weboldal
  • Backend: Azure Functions
  • Adatbázis: Cosmos DB Free tier
  • Authentikáció: Entra ID
  • Hosting: App Service Free

Ez már egy valódi, működő webalkalmazás.

Nem egy végtelenségig skálázható, robosztus rendszer, de szakmailag releváns.

Mire figyelj költség szempontból?

  1. Mindig állíts be költség keretet (nem véd meg a magas számláktól, de riaszt, amikor elérted a beállított szintet)
  2. Teszt és “éles” környezetet külön kezeld
  3. Ne futtass fölöslegesen VM-et
  4. Monitorozd a használatot

Fontos: A Free tier nem azt jelenti, hogy nem lehet számla, vagy minden ingyenes. Csak azt, hogy egy szint alatt nem kell fizetned.

Karrier szempontból mit jelent ez?

Sokan azt gondolják, hogy cloud tanuláshoz egy cég kell, ahol ki tudod próbálni az egyes megoldásokat valós élethelyzetben.

Ez nem teljesen igaz. Gyakorolhatsz való életből származó példákon (webalkalmazás, alkalmazás réteggel és adatbázissal) keresztül is.

Így egy tudatosan felépített Free tier architektúrával:

Ha jól átgondoltan teszed mindet, akkor ez már interjúképes tudás is lehet.

Őszinte korlátok

Nem lesz:

  • Magas rendelkezésre állás (High availability)
  • SLA
  • Több régióra kiterjedő redundancia (Multi-region redundancy)
  • Vállalati szintű biztonsági megfelelőség (Enterprise security compliance)

Kezdésnek azonban nem is ez a cél, hanem az alapok stabil megértése és megértése.

Úgy gondolom, hogy aki tudatosan használja az Azure Free Tier lehetőségeit, az nemcsak tanul, hanem megérti a költséghatékony működésalapjait is. És ez az, ami igazán számít.

Ez segít megkönnyíteni, melyik felhőszolgáltatót válaszd:

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Iratkozz fel az InfoPack hírlevélre
Kövess LinkedIn-en
Iratkozz fel a YouTube csatornámra
Keress meg TikTok-on is

Rendszeresen jelentkezem új, szakmai tartalmakkal, hogy ismerd a Cloud izgalmas világát.

azure_openai_enterprise

Azure és OpenAI: fordulat az enterprise AI piacán?

, , , , , , , ,

| Olvasási idő: 5 perc |

Az előző cikkben megnéztük, hogy a Microsoft hogyan mozdul el a saját AI–modellek irányába, és miért csökkenti hosszú távon a függőségét az OpenAI-tól.

Most viszont beszélek a legfontosabb kérdésről: Mit jelent ez nekünk, akik Azure-t és OpenAI-modellt használunk?

Néhány fontos és mindenkiben felmerülő kérdést igyekszem megválaszolni.

Stabil marad az Azure OpenAI?

A rövid válasz: igen.

Az Microsoft és az OpenAI között több évre szóló megállapodás van érvényben. Az Azure OpenAI Service jelenleg működik, frissül, támogatott.

Ha ma:

  • chatbot-ot futtatsz Azure-on
  • RAG rendszert építesz
  • belső tudásbázist generatív AI-val egészítesz ki

akkor nincs ok azonnali aggodalomra.

Ez nem egy hirtelen váltás, sőt az is lehet, hogy hosszú távon sem fog ez Téged érinteni.

Mit csináljunk máshogy az AI-al?

Amit én sok cégnél látok: az LLM-et fix, központi komponensként kezelik. Konkrét modell névre és típusra építik a szolgáltatásokat.

Nagyon ritka, hogy valaki megfelelően, konfigurációs állományban definiálva használja a modelleket. És néhány esetben láttam már olyat is, hogy egy modellre specifikusan van írva a kód. Nincs fallback, nincs B terv.

Ez rövid távon működik, vagy prototípusok esetén kiválóan működik, de hosszú távon nagyon kockázatos.

Ha a Microsoft saját foundation modelleket (alapmodell) vezet be Azure-on belül, akkor valószínűleg még a jelenleginél is több modell közül választhatunk majd. Ez jó hír, hiszen még több lehetőségünk van megtalálni a megoldásunkhoz tökéletesen passzoló modellt.

Ez azonban csak akkor működőképes, ha az architektúránk erre fel van készítve. Ha tanácstalan vagy, hogyan tudod ezt megtenni, az alábbiak segíthetnek:

  • Service layer: Az LLM-hívás legyen egy központi backend szolgáltatásból megvalósítva, és ne a UI réteg (frontend) vagy minden mikroszolgáltatás saját, egyedi integrációja. Így ha később modellt kell cserélni, azt nem az egész kódbázisban kell átírni, hanem csak a backend-hez kell hozzányúlni.
  • Konfigurálható modellválasztás: A használt AI-modell ne legyen fixen beégetve a kódba, hanem konfigurációból lehessen meghatározni, hogy éppen melyik modellt és annak melyik verzióját használja a rendszer. Ez lehetővé teszi, hogy teszteléskor egy olcsóbb (akár helyi) modellt használjunk, éles környezetben pedig egy erősebbet, vagy hogy gyorsan váltsunk, ha változik az ár vagy a teljesítmény.
  • Monitoring token- és költségszinten: Az AI-hívások költsége token alapú, ezért nagy forgalomnál gyorsan elszállhat, ha nincs rálátásunk a használatra. A felhőszolgáltató ad alap költségfigyelést, de enterprise környezetben alkalmazás szinten is érdemes mérni, mely funkció mennyi AI-erőforrást fogyaszt. A token az AI világában ugyanaz, mint korábban a CPU-idő volt: ha nem mérjük, nem tudjuk kontrollálni.
  • Fallback modell logika: Érdemes úgy megtervezni a rendszert, hogy ha az elsődlegesen használt modell nem elérhető, túl lassú vagy túl drága, akkor a rendszer automatikusan át tudjon váltani egy alternatív modellre. Ez növeli az üzletmenet-folytonosságot és csökkenti a szolgáltatáskimaradás kockázatát.

Ezek nem felesleges lépések, hanem a hosszútávú stabilitást biztosító praktikák.

Ugyanúgy, ahogy nem kötjük egyetlen availability zone-hoz a rendszert, ne kössük egyetlen modellhez sem.

AI vendor lock-in kérdés

Az Azure használata önmagában nem feltétlenül probléma. Az viszont igen, ha az AI logika teljesen egy adott modell viselkedésére optimalizált, az már kockázat.

A piac abba az irányba megy, hogy a nagy cloud szolgáltatók (kivéve Azure) kínál saját modelleket. A Google (Gemini, Imagen, stb) és az AWS (Amazon Titan) is kínálnak saját modelleket.

Ha te Azure-on maradsz, az teljesen jogos döntés, de az AI-réteg legyen cserélhető.

Egy jól átgondolt architektúrában az alábbiakat követjük:

  • Platformfüggetlen: A rendszer ne egy konkrét cloud szolgáltató vagy modell sajátosságaira épüljön, hanem általános LLM-képességre.
  • API-absztrakció: Az LLM-hívásokat egy központi backend API kezelje, ne a frontend vagy több különálló komponens közvetlenül a modellt.
  • Tudatos modellválasztás: A modell kiválasztása use case, teljesítmény és költség alapján történjen, ne alapértelmezett döntésként.

Copilot jövője

A Microsoft 365 Copilot és a GitHub Copilot jelenleg jelentős részben OpenAI modellekre épülnek, de tudunk már egyéb modelleket is használni, például a Sonnet-et vagy a Opus-t.

Ha a Microsoft saját modelleket integrál, az nem feltétlenül jelent minőségromlást. Én úgy gondolom, inkább előrelépést hozhat, mert nem egy általános modellt kapunk majd, hanem specializált megoldásokat.

A Microsoft célja inkább a:

  • költségcsökkentés
  • adatkontroll
  • stratégiai függetlenség

Felhasználói oldalról nagyobb változás csak akkor várható, ha a modellváltás érezhetően befolyásolja a minőséget.

AI költségtudatosság

Ez az a pont, amit nem lehet megkerülni. Az AI nem olcsó és bármit is hoz a jövő a költség az egyik legfontosabb tényező marad.

Az AI-szolgáltatások token alapú számlázással működnek, vagyis minden elküldött és generált szöveg után fizetünk, és mivel a modellek komoly számítási kapacitást igényelnek, nagy forgalomnál a költség nagyon gyorsan meg tud nőni.

Ha a Microsoft saját modellekkel optimalizálni tudja a költségstruktúrát Azure-on belül, az enterprise ügyfeleknek előny lehet.

Ma még nem tudjuk, hogy az új modellstratégia pontosan milyen árszinten jelenik meg, ezért különösen fontos a használat folyamatos monitorozása és a költséglimitek beállítása. Érdemes a teszt- és éles környezetet szigorúan elkülöníteni, valamint kontroll alatt tartani a fejlesztői környezeteket is, hogy ne maradjanak feleslegesen futó, költséget termelő AI-folyamatok.

Igen, ez AI-nál is ugyanaz a jelenség, mint VM-eknél: ha nem figyelsz, elszáll a költség.

Karrier szempontból mit tanulj?

Ha Azure + OpenAI irányba haladsz, ne csak prompt engineeringet tanulj.

Tanuld meg az alapokat és az általános AI világ rejtelmeit:

  • hogyan működik egy RAG architektúra
  • miként mérünk modell teljesítményt
  • milyen módon optimalizálunk költséget
  • miért tervezzünk multi-model környezetet
  • stb.

A piac nem egy modell köré szerveződik. Hanem AI megoldások és technikák köré.

A lényeg

Nem kell kétségbe esni, a két cég nem szakít és nem vállnak azonnal ketté útjaik. Inkább járjunk nyitott szemmel és készüljünk fel a változásra.

  • Az Azure OpenAI ma stabil
  • A stratégia változik
  • A piac érik és fejlődik
  • Az architektúrának rugalmasnak kell lennie

Ha AI-rendszert építesz Azure-on, most van itt az ideje annak, hogy enterprise szinten gondolkodj: költség, biztonság, rugalmasság.

Érdekelnek a hasonló Cloud és AI tartalmak?

gcp-2026-cikk

Felhőválasztás 2026 – GCP az AI-first felhő. Kinek éri meg?

, , , , , , , , ,

| Olvasási idő: < 1 perc |

Korábban már beszéltem az Azure-ről és az AWS-ről, mint lehetséges felhőplatformról 2026-ban. Ebben a videóban a Google Cloud Platformot (GCP) mutatom be, ami egy AI-first szemléletű felhő.

Az AI-first stratégia lényege, hogy a Google a mesterséges intelligenciát tette minden terméke és szolgáltatása alapvető mozgatórugójává, így az már nem csak egy extra funkció, hanem az elsődleges fejlesztési szempont. Ez a szemléletmód a felhasználóhoz alkalmazkodó, segítőkész technológiát és saját, specifikus hardveres infrastruktúrát (például TPU-kat) állít a cég teljes működésének középpontjába.

A Google Cloud egyik legnagyobb erőssége, hogy itt az AI nem kiegészítő, hanem alapértelmezett része a platformnak. A videóban szó lesz a Gemini modellcsaládról, a Vertex AI-ról, az adatplatformok szerepéről, és arról is, hogy kinek lehet jó választás a GCP.

Azt is elmondom, mikor nem ideális a Google Cloud, például klasszikus enterprise lift-and-shift megközelítés esetén.

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Load More

Verified by MonsterInsights