Azure

2026 01 15

AI + Cloud 2026: amikor a platform életre kel és gondolkodik

AWS, Azure, Cloud, GCP, Mesterséges Intelligencia ai, aws, azure, cloud, cloudservices, gcp, llm

| Olvasási idő: 6 perc |

Az előző cikk végén ott hagytuk abba, hogy 2026-ban a cloud már nem cél, hanem eszköz. Egy gondolkodásmód, amire a legtöbb digitális rendszer épül. A következő lépés viszont már nem pusztán erről szól. Az igazi változás ott kezdődik, amikor az AI nem csak használja ezt az alapot, hanem formálni is kezdi a felhőt.

Ez a cikk erről a személetváltásról szól. Nem arról, hogy melyik modell jobb, és nem is technikai útmutató. Sokkal inkább arról, milyen szerepe lett és lesz az AI-nak a cloud működésében, és milyen következményei vannak ennek technológiai, gazdasági és döntési szinten.

Az AI szerepe a Cloud-ban megváltozott

Az AI ma már nem külön projektként jelenik meg a felhőben. Nem egy újabb doboz a sok közül, hanem platformszintű képesség. A cloud szolgáltatók nem egyszerűen futtatási környezetet adnak hozzá, hanem olyan rétegeket építenek köré, amelyek az AI-t beemelik a mindennapi működésbe. Mindehol ott a Co-Pilot jellegű működés, amely arra hivatott, hogy segítse a mindennapjainkat. Bár néha kifejezetten idegesítő.

Ez jól látszik abban, ahogyan a hyperscalerek pozicionálják az AI-t. Nem egyetlen „AI termékről” beszélnek, hanem olyan szolgáltatásokról, amelyek architektúra-tervezést, skálázást, költségoptimalizálást vagy incidensek értelmezését is támogatják. Fontos: Az AI nem helyettesít, hanem döntési teret alakít át.

Azure, AWS és GCP – „minden út Budára vezet”

A Microsoft Azure esetében az AI erősen az LLM-vonal köré szerveződik. Az Azure OpenAI Service és az erre épülő enterprise megoldások azt mutatják, hogy az AI szorosan integrálódik az üzleti folyamatokba. Nem önmagában érdekes, hanem azért, mert ott jelenik meg, ahol a felhasználók dolgoznak. Persze ez csak egy nagyon apró része annak az AI funkcionalitásnak és trendnek, amit ma ismerünk.

Az AWS más irányból érkezett. Régóta erős a machine learning területén, és ezt a tapasztalatot vitte tovább platformlogikába. A Bedrock a generatív AI-t teszi elérhetővé felügyelt módon, míg a SageMaker AI a klasszikus ML-életciklust fedi le. Az üzenet itt nem a modell, hanem az eszköztár és az irányíthatóság.

A Google Cloud Platform pedig azért érdekes, mert az AI nem új irány nála. A Google belső rendszerei évek óta AI-ra épülnek, és ez a szemlélet jelent meg a Vertex AI köré szervezett cloud kínálatban. Itt az adat és az AI szoros összekapcsolása kerül fókuszba.

A közös pont mindhárom esetben az, hogy az AI nem kiegészítő, hanem a platform működésének része lett.

Miért lett a cloud az AI természetes közege?

Sokan még mindig hardveroldalról közelítik meg az AI-t: milyen GPU kell hozzá, mennyi memória, elég-e egy erős otthoni gép. Ez a gondolkodás érthető, de egyre kevésbé írja le a valóságot.

A cloud egyik legnagyobb előnye az AI esetében nem pusztán a teljesítmény, hanem a skálázhatóság és az időbeliség. Olyan erőforrások érhetők el rövid időre is – több terabájt memória, több nagy teljesítményű GPU egy környezetben –, amelyek otthoni vagy kisebb on-prem környezetben nem reálisak.

A valódi szemléletváltás azonban ott történik, hogy az AI jellemzően felügyelt (managed) szolgáltatásként jelenik meg. Nem kell CPU-, RAM- vagy GPU-konfigurációval foglalkozni, nem kell drivereket, frameworköket karbantartani. Ezeket a problémákat a platform kezeli.

Személyes megjegyzésként idekívánkozik, hogy 2026-ban én is szert tettem egy aránylag erős helyi gépre, kifejezetten AI-val való kísérletezésre és fejlesztésre. Egy Ryzen 7 7800X3D, 64 GB RAM és egy RTX 3090 24GB körüli konfiguráció már alkalmas arra, hogy kis- és közepes modellekkel dolgozzak, tanuljak, prototípusokat építsek.

De ez a tapasztalat inkább megerősítette bennem: amit helyben lehet, az tanulás és kísérletezés. Amint skálázni, párhuzamosítani vagy üzemszerűen használni szeretnék, a cloud egyszerűen más ligában játszik.

És itt előtérbe kerül az árazás és az árazási modellek megértése a felhőben. Otthon az a kérdés, hogy elég-e a gép. A felhőben az, hogy mennyibe kerül, ha így használom. Ez az egyik oka annak, hogy az AI a cloud-ban nem hobbi-megoldásként, hanem üzemszerűen terjedt el.

Az AI hatása a hardverpiacra

Az AI és a cloud együtt nem csak szoftveres változást hozott. A hardverpiacon is érezhető a hatása. Az adatközponti AI igény nem csak GPU-kat szív fel, hanem memóriát is – különösen nagy sávszélességű és szerveroldali megoldásokat.

A piaci elemzések és üzleti hírek egyre gyakrabban kötik össze a memóriaárak alakulását az AI-adatközpontok növekvő igényével. A hangsúly eltolódott: a gyártók és beszállítók számára a hyperscalerek váltak a legfontosabb ügyfelekké.

A változás egyik leglátványosabb következménye az árakon látszik. Egyes GPU- és memóriaszegmensekben 2024–2025 során 1,5–3× közötti áremelkedés volt tapasztalható, különösen ott, ahol az adatközponti AI-igény közvetlenül megjelent. Ez nem egységes a teljes piacon, de jól mutatja az irányt: amikor a hyperscalerek és nagyvállalatok tömegesen vásárolnak, a fogyasztói és kisebb üzleti piac háttérbe szorul.

Ezt a folyamatot jól szemlélteti az NVIDIA bevételeit bemutató ábra. A sávok azt mutatják, hogyan vált a Data Center (DC) üzletág – vagyis a Cloud-os, AI-fókuszú infrastruktúra – a domináns bevételi forrássá, miközben a Gaming és az egyéb szegmensek aránya háttérbe szorult. A grafikon nem csak növekedést, hanem súlypont-eltolódást jelez: az AI ma már elsősorban adatközpontokban él.

Adatbiztonság és a félreértések

Az AI + Cloud kapcsán az egyik legtöbb bizonytalanságot az adatkezelés okozza. Sok félelem nem konkrét tapasztalatból, hanem feltételezésekből fakad. Gyakori gondolat, hogy a Cloud-os AI „biztos betanítja az adatokat”.

A valóság ennél árnyaltabb. A nagy cloud szolgáltatók dokumentációja különbséget tesz az alapértelmezett működés és az explicit engedélyezett tréning között. Enterprise környezetben az ügyféladatok jellemzően elkülönítve maradnak, és nem kerülnek más ügyfelekhez vagy alapmodell-tréningbe engedély nélkül.

Ugyanakkor fontos kimondani: a cloud nem varázslat. Az adatbiztonság nem automatikus. A shared responsibility modell itt is érvényes. A platform adja az alapokat, de a jogosultságkezelés, a hozzáférések és az adathasználat kontrollja továbbra is az ügyfél döntése.

A félelmek egy része abból fakad, hogy sokan a mai napig nem értik pontosan, hogyan működik egy AI. A modell, a tréning, az inference és az adatkezelés gyakran egyetlen „fekete dobozzá” mosódik össze a fejekben. Ha nem világos, mi történik egy kérdés elküldésekor, hol fut a feldolgozás, és mi marad meg belőle, akkor természetes reakció a bizalmatlanság. Ez a bizonytalanság nem rosszindulatból fakad, hanem információhiányból.

Ezért a zavar valószínűleg 2026-ban sem fog teljesen eltűnni. Nem azért, mert a szolgáltatók ne lennének egyre transzparensebbek, hanem mert az AI használata gyorsabban terjed, mint ahogy a szervezetek megtanulják helyesen értelmezni a működését.

Mit várhatunk 2026-ban az AI + Cloud területén?

Az AI és a Cloud együtt nem új trend, hanem új működési környezet. Kevesebb manuális döntés látszik, de több döntés történik a háttérben. Kevesebb technikai akadály, de nagyobb felelősség.

Azok járnak jól ebben a világban, akik nem csodát várnak az AI-tól, hanem értik, mire használják, és hajlandók felelősséget vállalni a döntéseikért.

2026-ban az AI nem egy kísérleti technológia lesz, hanem egy stratégiai alapvetés, amely a cloud működésének mindennapi részévé válik. A nagy technológiai szolgáltatók és elemzők szerint több irányban is érdemes felkészülni:

• Az AI szerepe tovább mélyül: A korábbi „AI mint eszköz” fázist teljesen felváltja az „AI mint partner” logika – az AI nem csak kérdésekre válaszol, hanem támogatja a döntéseket, együttműködik munkafolyamatokban és gyorsítja a kutatást. Ez nem csak technikai előny, hanem szervezeti és működési átalakulás is.

• Agentic AI és intelligens automatizálás erősödik: A vállalati környezetben 2026-ra szélesebb körben terjednek az olyan AI-agentek, amelyek nem csak input-output feladatokat végeznek, hanem autonómabban lépnek kölcsönhatásba rendszerekkel és döntési folyamatokkal.

• Adat és AI governance fókuszba kerül: A fogyasztók és szervezetek egyre nagyobb figyelmet fordítanak arra, hogyan használja az AI az adatokat, hogyan magyarázható és kontrollálható a működése. Ez nem csupán technikai kérdés, hanem a bizalom és jogi megfelelés alapja.

• Biztonság és infrastruktúra kiemelt téma: A növekvő AI-használat új támadási felületeket és identitás-vezérelt kihívásokat hoz, ezért a kiberbiztonság nem csak háttérfeladat, hanem stratégiai prioritás lesz az AI + Cloud környezetben.

Ezek az irányok nem csupán az én gondolataim, hanem a legfrissebb szakmai előrejelzésekkel egybevágó vélemény is.

Az AI nem külön dolog többé, hanem a Cloud működésének szerves, strukturális része lesz.

2026-ban már nem az a kérdés, használod-e az AI-t a Cloudban, hanem az, hogy jól használod-e. Ha ebben szeretnél biztosabb lenni, iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeimet.

2026 01 12

Cloud 2026: hol járunk most, és merre tart a felhő

AWS, Azure, Cloud, GCP, Mesterséges Intelligencia ai, aws, azure, cloud, cloudservices, gcp

| Olvasási idő: 5 perc |

Amikor több mint egy évtizeddel ezelőtt először dolgoztam felhővel, még egészen más kérdések foglalkoztatták a cégeket. Mekkora szervert vegyünk? Elég lesz-e két év múlva is? Mikor kell új vasat rendelni, és mennyi idő alatt ér ide? A döntések hónapokra, vagy évekre előre szóltak, és minden hibának ára volt.

Ma, 2026 elején, egészen másról beszélünk. A kérdés már nem az, hogy „használjunk-e felhőt”, hanem az, hogy hogyan használjuk jól.

Ez a cikk nem arról szól, hogyan kell kattintgatni a konzolon, inkább egy helyzetkép: hol tart most a cloud, mit tanultunk az elmúlt években, és mire érdemes készülni rövid távon.

Mi a cloud computing ma, röviden és érthetően

A cloud computing nem egy konkrét technológia, hanem egy működési modell. A lényege egyszerű: erőforrásokat használsz akkor, amikor kell, és csak addig fizetsz értük, amíg valóban szükséged van rájuk. Nem te vásárolsz szervert, nem te cseréled a meghibásodott alkatrészt, és nem neked kell minden részletet kézben tartani.

Fontos kimondani azt is, ami sokszor kimarad: a cloud nem ingyenes, és nem varázslat. Nem lesz tőle automatikusan gyorsabb vagy jobb egy alkalmazás. Viszont ad egy rugalmasságot, amit korábban csak nagyvállalatok tudtak megfizetni.

Egy egyszerű példa: egy webalkalmazás elindítása saját szerverrel ma is működik. Viszont ha hirtelen tízszer annyi felhasználó kezdi el használni, a cloud adja azt a mozgásteret, amivel ezt különösebb kapkodás és túlterhelés miatti leállás nélkül le lehet kezelni.

Mi változott az elmúlt években, és miért fontos ez 2026-ban

Néhány évvel ezelőtt sok helyen uralkodó gondolat volt, hogy „mindent vigyünk fel a felhőbe”. Ez azonban hibás gondolat, úgy ahogy a Scrum sem való minden projekthez. Emiatt ez a hozzáállás ma már egyértelműen kiforrottabb lett. A cégek megtanulták, hogy a cloud nem automatikusan olcsóbb, és a rosszul megtervezett rendszerek itt is gyorsan drágává és átláthatatlanná válhatnak.

2026-ra a cloud érett technológiává vált. Nem a kísérletezésről szól, hanem a tudatos döntésekről. Egyre több szervezet ismeri fel, hogy kevesebb szolgáltatás, egyszerűbb architektúra és átgondolt működés sokszor többet ér, mint a legújabb megoldások halmozása. Annak ellenére, hogy a felhőszolgáltatók sokszor mást sugallnak.

A cloud nem lett rosszabb. Mi lettünk tapasztaltabbak. És elkezdtük hatékonyabban használni.

Mire használják a cégek a felhőt 2026-ban valójában

A legtöbb vállalat ma nem csupán „innovációs lehetőségként” tekint a felhőre. Sokkal inkább stabil alapként. Tipikus felhasználási területek:

üzleti webalkalmazások futtatása
belső rendszerek és API-k
adatfeldolgozás és jelentéskészítés
fejlesztői és tesztkörnyezetek gyors létrehozása

Ezekben a felhasználási esetekben a cloud legnagyobb értéke a gyors indulás és a skálázhatóság. Nem kell mindent előre megtervezni évekre. Lehet kipróbálni, tapasztalni, majd dönteni.

Itt jelenik meg egyre természetesebben az AI is. Nem külön projektként, hanem funkcióként. Keresésben, ügyfélszolgálati automatizmusokban, vagy éppen adatok értelmezésében. A cloud biztosítja azt az alapot, amely nélkül ezek a megoldások nem lennének gazdaságosan működtethetők.

Hogyan indul ma egy kis cég?

Vegyünk egy mai, valós helyzetet. Egy kisebb cég szeretne egy webes alkalmazást indítani, aminek eleinte csak néhány száz felhasználója van, de nem tudják, fél év múlva mi lesz belőle.

2026-ban ilyenkor már ritkán merül fel az, hogy saját szervert vegyenek. Ehelyett:

elindítanak egy felhőben futó alkalmazást,
használnak egy felügyelt adatbázist,
és tárolják az adatokat egy felhőalapú storage-ban.

Ha az alkalmazás sikeres lesz, a rendszer skálázható. Ha nem válik be, egyszerűen leállítható, nagy veszteség nélkül.

Ez a cloud egyik legnagyobb ereje: nem kell előre mindent tudni, mégis van mozgástér. Ez üzleti oldalról legalább akkora előny, mint technikai szempontból.

Hol találkozol a felhővel a gyakorlatban?

Sokan úgy gondolnak a felhőre, mint valami elvont, „nagyvállalati” dologra, pedig a legtöbben már most is naponta használják – csak nem így hívják. Ha azt mondom: Instagram, TikTok, Gmail, OneDrive és Netflix, akkor azoknak a szolgáltatásoknak a nevét sorolom, ahol naponta találkozol Te is a felhővel.

Amikor egy webalkalmazás gyorsan betölt, amikor egy online rendszer gond nélkül kiszolgál sok felhasználót egyszerre, vagy amikor egy szolgáltatás mögött nincs látható leállás, ott nagyon gyakran „cloud fut a háttérben”.

A felhő a nagy szolgáltatóknál nagyon hasonló alapokra épül.

Például:

Microsoft Azure esetén tipikusan virtuális gépek, menedzselt adatbázisok és tárolószolgáltatások adják az alapot.
Amazon Web Services ugyanezt az elvet követi, csak más elnevezésekkel, megközelítéssel és hangsúlyokkal.
Google Cloud Platform pedig különösen erős adatfeldolgozási és analitikai irányban.

A lényeg nem az, hogy melyik platformon vagy, hanem az, hogy nem nulláról építkezel, hanem kész, kipróbált építőelemekből dolgozol.

Mit jelent a cloud a felhasználók számára

A legtöbb végfelhasználó nem gondolkodik cloudban. Nem is kell. Ők gyors, megbízható szolgáltatásokat várnak el, lehetőség szerint zéró leállással és elfogadható válaszidőkkel. Ha egy alkalmazás lassú vagy elérhetetlen, nem az érdekli őket, hogy hol fut, hanem az, hogy miért nem működik.

2026-ra a cloud ebből a szempontból láthatatlanná vált. Ott van minden mögött, de csak akkor kerül szóba, ha valami nem úgy működik, ahogy kellene. Ez önmagában jelzi az érettségét. Pontosan olyan alapszolgáltatásként tekintünk rá, mint a vezetékes vízre vagy az áramra.

Mit jelent a cloud a karrierváltóknak és pályakezdőknek

Sokan kérdezik tőlem, hogy érdemes-e ma még cloud irányba indulni. A válaszom röviden: igen, de másképp, mint pár éve. Nem az számít, hogy hány szolgáltatás nevét ismered, hanem az, hogy érted-e az alapokat.

2026-ban a cloud jó belépési pont az IT világába azoknak is, akik nem szeretnének mélyen programozni. A rendszerszemlélet, az alap biztonsági gondolkodás és az üzleti igények megértése sokkal fontosabb lett, mint a konkrét implementációs részletek.

Az AI ebben a tanulási folyamatban segíthet, magyarázhat és irányt mutathat, de nem veszi le a döntés terhét a válladról.

A cloud szakember nem attól lesz jó, hogy mindent automatizál vagy mindent tud, hanem attól, hogy felelősséget vállal a döntéseiért és tanul a hibáiból.

Az AI szerepe röviden

Talán észrevetted az AI itt nem főszereplő még, de nem lehet megkerülni. 2026-ban egyértelműen látszik, hogy az AI felerősíti a cloud jelentőségét. Skálázás, költségoptimalizálás, automatizált elemzés mind olyan területek, ahol a kettő együtt ad valódi értéket.

Ugyanakkor fontos határt húzni. A cloud itt még az alap, az infrastruktúra és a platform. Az igazi változás ott kezdődik, amikor az AI már nem csak használja a felhőt, hanem formálja is. Erről szól majd a következő cikkem.

Korlátok, amik 2026-ban is megmaradnak

A cloud nem old meg rossz döntéseket. Nem helyettesíti a gondolkodást, és nem javítja ki a szervezeti problémákat. Rosszul használva továbbra is drága, és könnyen átláthatatlanná válik.

Ez AI-val együtt sincs másképp. Ha nincs világos cél, nincs felelősség és nincs kontroll, akkor a legmodernebb technológia is csak gyorsabban visz rossz irányba.

Útravaló

2026-ban a cloud nem trend, hanem alap. Nem cél, hanem eszköz. Azok a csapatok és szakemberek járnak jól, akik nem csodát várnak tőle, hanem tudatosan használják. A következő lépés viszont már nem csak erről szól. Az AI és a cloud együtt új kérdéseket vet fel, és új válaszokat kényszerít ki.

Erről fog szólni a folytatás…

Ha érdekel, merre halad ez az irány, és hogyan érdemes rá felkészülni, akkor iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeim.

2025 12 15

VM naplózás lelke: Log Analytics és Data Collection Rules

Azure, Cloud azure, cloud, cloudservices, iaas, logs

| Olvasási idő: 10 perc |

A felhős monitoring az egyik legösszetettebb terület az Azure-ben. Rengeteg szolgáltatás, beállítás, rövidítés és „best practice” kering körülötte, miközben a legtöbb ember csak azt szeretné tudni: látom-e, mi történik a virtuális gépemen; és ha több virtuális gépem van, tudom-e azok naplóbejegyzéseit egy helyen kezelni.

Nemrég az egyik mentoráltammal belekóstoltunk ebbe a világba. Ő kifejezetten rákapott a monitoring ízére, ami jó jel, viszont közben számomra is világossá vált, hogy nem a tankönyv szerinti megoldás a legjobb megközelítés ahhoz, hogy valóban megértsük ennek a világnak a működését.

Miért mondom ezt? Mert sokan úgy gondolják – és én is így mutattam be korábban –, hogy akkor kell beállítani a naplófájlok gyűjtését, amikor a virtuális gépet létrehozzuk. Hiszen amikor összetett rendszerekkel dolgozunk, általában egy előre beállított, finomhangolt monitoring rendszerbe illesztjük be az új gépeket.

Ezzel azonban pont azt a logikus, jól követhető utat kerülöm el, amelyen keresztül az érdeklődők a legkönnyebben elérik a céljukat: hogy gyorsan átlássák ezt a komplex világot.

Mit javaslok tehát? Kövessük a józan észt, és gondoljuk végig, mi egy alkalmazás vagy rendszer természetes evolúciója. Hogyan történik ez a valóságban, amikor kicsiben kezdünk?

Először létrehozok egy vagy több virtuális gépet, alapbeállításokkal, majd telepítem rájuk az alkalmazásaimat. Jön még egy gép, aztán még egy. Egy idő után azt veszem észre, hogy egy nagy, összetett rendszerem van, viszont vak vagyok: nem látom, mi történik a virtuális gépeimen, és nem látom a gépek által létrehozott naplóbejegyzéseket sem.

Ekkor jön a következő lépés: beállítom az Azure Monitor megoldását, hogy legyen szemem és fülem. És innentől már értelmezhető adatokat kapok arról, mi történik a rendszeremben.

Ugye milyen egyszerű így?

Ebben a cikkben erről – pontosabban ennek egy pici, de nagyon fontos szeletéről – fogok egy alap konfigurációt bemutatni. A fókusz a naplóbejegyzések központi kezelése lesz az Azure Monitoron belül.

Ennek két legfontosabb komponense:

a Log Analytics Workspace
és a Data Collection Rules (DCR)

Ezek adják az egész VM-alapú naplózás és megfigyelés gerincét.

Később górcső alá vesszük az Azure Monitor további elemeit is, hogy jobban belelássatok ebbe a nagyon komplex, mégis rendkívül izgalmas világba.

Nem elméleti áttekintést szeretnék adni, és nem is egy „mindent bele” vállalati monitoring architektúrát bemutatni. A célom sokkal egyszerűbb és gyakorlatiasabb:

megérteni, mi a szerepe a Log Analytics Workspace-nek,
tisztázni, mire valók a Data Collection Rules,
és végigmenni egy egyszerű beállításon Linux és Windows Server virtuális gépek esetén is.

Alapfogalmak és szerepek

Log Analytics Workspace (LAW) a központi adattároló, ahová minden log és metrika beérkezik. Gyakorlatilag egy speciális adatbázis, amely KQL (Kusto Query Language) lekérdezéseket támogat. Egy workspace több száz VM-et is kiszolgálhat, de szervezeti vagy biztonsági okokból létrehozhatsz többet is.

Data Collection Rule (DCR) határozza meg, hogy mit gyűjtsünk, honnan és hová küldjük. Ez a „szabálykönyv”, ami összeköti a forrásokat (VM-ek) a célponttal (LAW). A DCR-ek rugalmasak: különböző szabályokat alkalmazhatsz különböző VM-csoportokra.

Azure Monitor Agent (AMA) a VM-eken futó agent, ami a DCR alapján gyűjti és továbbítja az adatokat. Ez váltotta le a régi Log Analytics Agent-et (MMA) és a Diagnostics Extension-t.

A terv

Az alábbi lépéseket fogjuk követni tehát:

Virtuális gépek (Linux, Windows) létrehozása (nagyon felületesen, mert tényleg alapbeállításokkal hozzuk létre)
Log Analytics Workspace létrehozás
Data Collection Rule létrehozás és beállítás
Azure Monitor Agent ellenőrzése a Virtuális gépeken
Naplóbejegyzések lekérdezése központilag

Öt egyszerű lépés, ami segít megérteni hogyan működik ez a szörnyeteg.

1. lépés: Virtuális gépek létrehozása

Amikor elindul a vállalkozásunk, először egy vagy tövv gépet hozunk létre. Tegyük ezt most is.

Minden lépést a Portálon fogunk elvégezni, az egyszerűség kedvéért.

Linux vm

Hozzunk létre egy erőforráscsoportot, ebbe fogunk most dolgozni
A Marketplace-n keresd meg: „Ubuntu 24.04 LTS – all plans including Ubuntu Pro”
Ebből hozz létre egy „Ubuntu Server 24.04 LTS”
Gép neve legyen „linux-monitor”
Méret legyen egy kicsi, pl.: Standard_B1s
Hitelesítés típusa legyen Nyilvános SSH-kulcs
Lemez esetén elegendő egy Standard SSD
Hálózatnál létrehozhatunk egy monitor-vnet nevű hálózatot
A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre az első virtuális gépünket

Windows vm

A Marketplace-n keresd meg: „Windows Server”
Ebből hozz létre egy „Windows Server 2022 Datacenter”
Gép neve legyen „windows-monitor”
Méret legyen egy kicsi, pl.: Standard_B2s
Rendszergazdai fióknál állítsunk be egy felhasználónevet és a hozzátartozó jelszót
Lemez esetén elegendő egy Standard SSD
Hálózatnál válasszuk a linux-nál létrehozott monitor-vnet nevű hálózatot
A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre a második virtuális gépünket

2. lépés: Log Analytics Workspace létrehozása

Eljutottunk tehát oda, hogy megvannak a gépeink, de nem tudjuk mi is van velük, vagy mi történik az alkalmazásokkal. Kell nekünk egy központi tároló, ahová a gépeken keletkező naplóbejegyzések és/vagy metrikák beérkeznek. Most ezt hozzuk létre.

Felül a keresőben keresd meg: „Log Analytics-munkaterületek„, majd kattintsunk rá.
Kattints: „+ Létrehozás” gombra
Töltsd ki:
- Előfizetés: válaszd ki
- Erőforráscsoport: válaszd a korábban létrehozttat
- Név: egyedi név (pl.: law-mentor)
- Régió: válaszd azt amit az erőforráscsoportnál és a VM-eknél is használtál
- Kattints: „Áttekintés és létrehozás”, majd hozd létre. 1-2 perc és létrejön.

Most már van egy adatbázisunk, ahová gyűjthetjük az adatokat.

3. lépés: Data Collection Rule létrehozás és beállítás

Egyre közelebb vagyunk a célunkhoz. Most hozzuk létre azt a szabályt, hogy a létező VM-ekről milyen adatokat szeretnénk látni a központi adatbázisban (Log Analytics Workspace)

Alap adatok

Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Beállítások > Adatgyűjtési szabályok elemet és kattintsunk rá
Kattints: „+ Létrehozás” gombra
Add meg a szabály alap adatait:
- Szabály neve: pl: dcr-vm-logs-all
- Előfizetés és erőforráscsoport: ugyanaz, mint a LAW
- Platform típusa: válaszd „All” (Ha Windows és Linux is kell. Mi most ezt szeretnénk)
- Adatgyűjtési végpont: Nekünk ez most nem szükséges, mert Azure-on belüli gépekhez hozzuk létre
Kattints: „Következő: Erőforrások >” gombra
Erőforrások fül: Itt adod hozzá a VM-eket, amikről gyűjteni szeretnél. Kattints „+ Erőforrások hozzáadása” gombra és válaszd ki a VM-eket amelyeket korábban létrehoztál. (Az AMA agent automatikusan települ, ha még nincs fent.)
Kattints: „Következő: Gyűjtés és küldés >” gombra
Gyűjtés és küldés fül: Itt definiálod az adatforrásokat (mit olvasson be a VM-ekről)

Windows adatforrás

Kattints „+ Adatforrás felvétele”
Adatforrás típusánál válaszd a „Windowsos eseménynaplók” elemet. Ezzel lehetőséged van beolvasni azokat az eseménynapló-bejegyzéseket, amelyekre szükséged van. Ezeket nagyon részletesen testre lehet szabni.
Mi most itt csak az Alapszintű elemeket fogjuk gyűjteni. Jelöld ki mindet.
Ebben az ablakban kattints „Következő: Cél >” gombra.
Ellenőrizd, hogy a megfelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
Ezzel a Windows naplóbejegyzések betöltése készen áll

Linux adatforrás

Kattints „+ Adatforrás felvétele”
Adatforrás típusánál válaszd a „Linux Syslog” elemet. Ezzel lehetőséged van beolvasni azokat az eseménynapló-bejegyzéseket, amelyekre szükséged van. Ezeket nagyon részletesen testre lehet szabni.
Ezután be kel állítanunk, hogy mi a minimális naplózási szint, amit szeretnénk beállítani. Alapvetően senkinek nem javaslom, hogy beállítsa az LOG_INFO szintet, de a példánk miatt, most ezt tesszük.
Majd, szintén a példa kedvéért, kiválasztjuk az összes szolgáltatást.
Ebben az ablakban kattints „Következő: Cél >” gombra.
Ellenőrizd, hogy a megelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
Ezzel a Linux naplóbejegyzések betöltése is készen áll.

Szabály véglegesítése

Megvan a két adatforrásunk. A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre a szabályt.

Most várnunk kell 5-10 percet, amíg elindul az adatok betöltése. Amíg ez megtörténik, ellenőrizzük le mindegyik VM-ünk esetén, hogy a monitor ügynők települt-e.

Megjegyzés: A teljesítmény metrikák beállítása is hasonlóan történik, ott az adatforrás típusa lesz más.

4. lépés: Azure Monitor Agent ellenőrzése a Virtuális gépeken

Ezt mindkét típusú (Linux, Windows) virtuális gépnél ugyanott tudjuk megtenni.

Keressük meg az erőforráscsoportban a virtuális gép erőforrást (linux-monitor vagy windows-monitor) és kattintsunk rá
A bal oldali panelon keressük meg a Beállítások > Alkalmazások és bővítmények elemet és kattintsunk rá
Itt kell látnunk az AMA elemet
- Windows esetén: AzureMonitorWindowsAgent
- Linux esetén: AzureMonitorLinuxAgent

Ha ez hiányzik, akkor nem fogjuk tudni gyűjteni a naplóbejegyzéseket és metrikákat.

5. lépés: Naplóbejegyzések lekérdezése központilag

Most pedig elérkezett a pillanat amire vártunk: központilag le tudjuk kérdezni a begyűjtött adatokat. Azokat tudjuk elemezni, vagy további feldolgozást végezhetünk rajuk. Nincs határ.

Elemzések áttekintése

Amint az adatok begyűjtése elindul, a LAW munkába lendül és rengeteg hasznos információt biztosít számunkra. Ebből jelenleg csak az alap elemzési diagrammot szeretném megmutatni.

Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
Felül válaszd ki a megfelelő Workspace-t
Majd kattints a nevére
Megnyílik az elemzési áttekintő ablak

Naplóbejegyzése a portálon

Most pedig megmutatom az ajtót a naplóbejegyzések keresésének végtelen univerzumába.

Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
Felül válaszd ki a megfelelő Workspace-t
Majd kattints a nevére
Megnyílik az elemzési áttekintő ablak
A bal oldali panelon keressük meg a Figyelés > Munküzetek elemet és kattintsunk rá.
Itt találsz előre elkészített elemet.
Mi most újat hozunk létre, mert az a legegyszerűbb. Kattints: „+ Új”
A megjelenő lapon a Log Analytics-munkaterület Naplók (Analytics) Lekérdezés rész a KQL query editor. Ide írhatod meg az egyedi lekérdezésedet, amit utána el is menthetsz.
Illeszd me az alábbit, majd kattints a Lekérdezés futtatása gombra

// Windows Információs bejegyzések az elmúlt 1 órából
Event
| where TimeGenerated > ago(1h)
| where EventLevelName in ("Information")
| project TimeGenerated, Computer, EventLog, EventLevelName, RenderedDescription
| order by TimeGenerated desc

Ezt is próbáld ki:

// Linux auth események (bejelentkezések)
Syslog
| where TimeGenerated > ago(3h)
| where Facility == "auth" or Facility == "authpriv"
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc

És egyéb példák:

// Összes Windows Event az elmúlt 24 órából
Event
| where TimeGenerated > ago(24h)
| summarize count() by EventLog, EventLevelName
| order by count_ desc

// Windows hibák és figyelmeztetések
Event
| where TimeGenerated > ago(1h)
| where EventLevelName in ("Error", "Warning")
| project TimeGenerated, Computer, EventLog, EventLevelName, RenderedDescription
| order by TimeGenerated desc

// Linux syslog események
Syslog
| where TimeGenerated > ago(24h)
| summarize count() by Facility, SeverityLevel
| order by count_ desc

// Linux auth események (bejelentkezések)
Syslog
| where TimeGenerated > ago(24h)
| where Facility == "auth" or Facility == "authpriv"
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc


// Adott VM összes logja
Event
| where Computer == "linux-monitor"
| where TimeGenerated > ago(1h)
| order by TimeGenerated desc

Tippek

Ezzel végeztünk is. Ugye, hogy milyen sima volt?

Fontos: A KQL lekérdezéseket érdemes tanulmányozni, hogy elérd a kívánt eredményt.

Problémák elkerülése:

Amikor eldöntjük, mit gyűjtünk, rengeteg lehetőség van. Én azt javaslom, hogy tudatosan tervezzük meg mire is van igazán szükségünk, mert könnyű elkövetni az alábbi hibákat:

túl sok adat gyűjtése feleslegesen,
nem egyértelmű, hogy egy VM miért nem küld naplót,
Linux és Windows eltérő logikájának keverése (ezért sem optimális a jelenlegi beállításunk),
vagy egyszerűen az, hogy nem világos, mi történik a háttérben.

Költségoptimalizálás tippek:

Ne gyűjts mindent „Information” szinten, csak Warning és felette
Állíts be data retention limitet (30 nap alap, növelhető)
Használj data collection rule transformations-t a felesleges adatok szűrésére

Összefoglalás

Együtt beállítottunk egy teljes körű log gyűjtési megoldást Azure Monitor segítségével. Létrehoztunk egy Log Analytics Workspace-t, ami központi tárolóként szolgál minden begyűjtött adatnak.

Konfiguráltunk egy Data Collection Rule-t, amely Windows Event Logs és Linux Syslog forrásokból gyűjti az eseményeket, és hozzárendeltük a monitorozni kívánt VM-ekhez.

Az Azure Monitor Agent automatikusan települt a gépekre, így azok azonnal elkezdték küldeni az adatokat. A begyűjtött logokat a Log Analytics Workspace Naplók menüpontjában KQL lekérdezésekkel tudjuk elemezni és keresni.

Ha most ismerkedsz az Azure Monitoring-al, vagy eddig csak „kattontgattad”, mert muszáj volt, akkor ez a cikk neked szólt.

Rövid gyakorlás után biztos vagyok benne, hogy hamar összeáll a kép.

2025 12 01

A Microsoft AI platform evolúciója: OpenAI és Foundry

agents, Azure, Cloud, llm, mcp, Mesterséges Intelligencia, ml, rag ai, azure, cloud, cloudservices, iaas, llm

| Olvasási idő: 4 perc |

Nem rég fejeztem be egy videós képzési anyagot a Mentor Klub részére, ahol a résztvevők megismerhették az Azure-on belül elérhető OpenAI megoldásokat. Ennek részeként bemutattam az Azure OpenAI Studio felületét is, ami valójában az Azure AI Foundry egyik funkcionális eleme. Mindkettőt elég gyakran használom, különböző projektekben és különböző célokra. Hogy éppen melyik a jobb egy adott feladathoz, azt többnyire az aktuális projekt igényei döntik el.

A Microsoft azonban az elmúlt hónapokban egy olyan változtatást indított el, amely alapjaiban alakítja át azt, ahogyan eddig AI-megoldásokat építettünk Azure-ban. A Foundry platform fokozatosan átveszi az Azure OpenAI Studio szerepét, kiszélesítve annak lehetőségeit és egységesítve az AI-fejlesztés teljes ökoszisztémáját.

Mi volt az Azure OpenAI Studio szerepe

A Microsoft az Azure OpenAI Studio felületet arra hozta létre, hogy egyszerű legyen kipróbálni és tesztelni az Azure által kínált OpenAI modelleket. A felület segítségével lehetett:

modelleket kipróbálni egy játszótérben
finomhangolt modelleket kezelni
API-végpontokat és kulcsokat elérni
kötegelt feldolgozást és tárolt befejezéseket használni
értékeléseket futtatni
és még sok hasznos AI programozást segítő funkciót.

Az Azure OpenAI Studio azonban alapvetően egy modelltípusra, az Azure által értékesített OpenAI modellekre épült. Ez a projektjeim során is érezhető volt: ha más modellgyártó megoldását szerettem volna használni, akkor azt külön kellett integrálni vagy külső szolgáltatásból kellett elérni.

Ez az a pont, ahol a Foundry teljesen más szemléletet hoz.

Mit kínál a Microsoft Foundry?

A Microsoft Foundry egy egységes AI-platform, amely több modellszolgáltatót, több szolgáltatást és teljes életciklus-kezelést egy felületre hoz. A Microsoft Learn dokumentum így fogalmaz: a Foundry egy nagyvállalati szintű platform, amely ügynököket, modelleket és fejlesztői eszközöket egy helyen kezel, kiegészítve beépített felügyeleti, monitorozási és értékelési képességekkel .

A legfontosabb különbségek a következők.

Széles modellkínálat

Az Azure OpenAI-val szemben a Foundry nem korlátozódik egyetlen gyártóra. Elérhetők többek között:

Azure OpenAI modellek
DeepSeek
Meta
Mistral
xAI
Black Forest Labs
Stability, Cohere és más közösségi modellek

És ez még csak a jéghegy csúcsa.

Ügynökszolgáltatás és többügynökös alkalmazások (AgenticAI)

A Foundry API kifejezetten ügynökalapú fejlesztéshez készült, ahol több modell és komponens együttműködésére van szükség.

Egységes API különböző modellekhez

A Foundry egységes API-t biztosít, így a fejlesztőnek nem kell minden gyártó logikáját külön megtanulnia.

Vállalati funkciók beépítve

A Foundry felületén eleve jelen vannak:

nyomkövetés
monitorozás
értékelések
integrált RBAC és szabályzatok
hálózati és biztonsági beállítások

Gyakorlatilag, minden ami a nagyvállalati és biztonságos működéshez elengedhetetlen.

Projektalapú működés

A Foundry projektek olyan elkülönített munkaterületek, amelyekhez külön hozzáférés, külön adatkészletek és külön tároló tartozik. Így egy projektben lehet modelleket, ügynököket, fájlokat és indexeket is kezelni anélkül, hogy más projektekhez keverednének.

Hogyan kapcsolódik össze a két világ

A Microsoft nem megszünteti az Azure OpenAI-t, hanem lehetővé teszi, hogy az adott erőforrás Foundry-erőforrássá alakuljon. A frissítési folyamat lényege:

a meglévő végpontok és kulcsok megmaradnak
a finomhangolt modellek és állapotok megmaradnak
a Foundry funkciói azonnal elérhetővé válnak
a fejlesztő továbbra is használhatja az Azure OpenAI API-t

Mindezt lépésről lépésre írja le a frissítési útmutató.

Egy példán keresztül…

Amikor még csak Azure OpenAI-val dolgoztam, előfordult, hogy egy ügyfél Meta vagy Mistral modellt szeretett volna kipróbálni összehasonlításként. Ezt külön rendszerben kellett megoldani.
A Foundry megjelenésével ugyanabban a projektben elérhetővé vált:

GPT-típusú modell
Mistral
Meta
DeepSeek
és még sok más

Egy projekten belül egyszerre lehet kísérletezni, mérni és értékelni különböző modellek viselkedését.

Mit jelent ez a felhőben dolgozó szakembereknek

A Foundry nem egyszerűen egy új kezelőfelület. A gyakorlati előnyei:

Egységes platform, kevesebb különálló eszköz
Könnyebb modellválasztás és modellváltás
Átláthatóbb üzemeltetés, biztonság és hálózatkezelés
Bővíthető modellkínálat
Konszolidált fejlesztői élmény és API

A dokumentáció többször hangsúlyozza, hogy a Foundry nemcsak kísérletezésre, hanem üzleti szintű, gyártásra kész alkalmazásokra is alkalmas. Ez a mindennapi munkában is érezhető.

Miért előnyös ez a vállalatoknak

A vállalatok számára a Foundry több szempontból stratégiai előrelépés:

Egységes biztonsági és megfelelőségi keretrendszer
Több modellgyártó támogatása egy platformon
Könnyebb üzemeltetési kontroll
Gyorsabb AI-bevezetési ciklus
Rugalmasabb fejlesztési irányok

A Foundry megjelenésével a cégek már nem csak egyetlen modellre vagy ökoszisztémára építenek, hanem több szolgáltató képességét is bevonhatják anélkül, hogy töredezett lenne a rendszer.

Tulajdonság	Azure OpenAI	Foundry
Közvetlenül az Azure által értékesített modellek	Csak Azure OpenAI	Azure OpenAI, Black Forest Labs, DeepSeek, Meta, xAI, Mistral, Microsoft
Partner és Közösség modellek a Marketplace-en keresztül – Stability, Cohere stb.		✅
Azure OpenAI API (köteg, tárolt befejezések, finomhangolás, értékelés stb.)	✅	✅
Ügynökszolgáltatás		✅
Azure Foundry API		✅
AI-szolgáltatások (beszéd, látás, nyelv, tartalomértés)		✅

Összegzés

Az Azure OpenAI Studio jó kiindulási pont volt az Azure AI-képességeinek megismerésére és modellek kipróbálására.

A Microsoft Foundry azonban túlnő ezen a szerepen:
egységes platformot biztosít a teljes AI-fejlesztési életciklushoz, több modellgyártóval és kiterjesztett vállalati funkciókkal.

A Microsoft nem leváltja az Azure OpenAI-t, hanem beépíti egy nagyobb, átfogóbb rendszerbe. Ez a lépés hosszú távon kiszámíthatóbb, hatékonyabb és sokkal rugalmasabb AI-fejlesztést tesz lehetővé.

2025 11 17

Az URL-ek működése és szerepe a modern felhővilágban

AWS, Azure, Cloud, Docker, Hírek, Kubernetes cloud, cloudservices, https, iaas, kubernetes, link, url

| Olvasási idő: 4 perc |

Több tucat cikket olvashattatok tőlem a felhőszolgáltatások alapfogalmairól, és arról is, hogyan kommunikálnak egymással a különböző rendszerek. Ebben a cikkben egy olyan területet hozok közelebb, amely látszólag egyszerűnek tűnik, mégis meglepően sok félreértés forrása.

Egy saját történettel kezdem: amikor először készítettem több rétegű felhős alkalmazást, órákon át kerestem, miért nem érhető el a szolgáltatásom. A hiba mindössze annyi volt, hogy egy helytelenül megadott URL miatt teljesen más címre irányítottam a kéréseket. Ez volt az első alkalom, amikor igazán megértettem, mennyire fontos a pontos URL-használat.

A felhőben dolgozó szakemberek nap mint nap találkoznak API-végpontokkal, szolgáltatási URL-ekkel, konténerek belső hivatkozásaival és különböző load balancer címsémákkal. Ezek mind egy közös alapelvre épülnek: az URL szerkezetére. Ahhoz, hogy valaki magabiztosan mozogjon bármelyik felhős platformon, elengedhetetlen, hogy pontosan értse, mit is jelent egy URL, és hogyan működik.

Mi az az URL és miért létezik?

Az URL (Uniform Resource Locator) egy szabványos formátum, amely meghatározza, hogy az interneten vagy egy privát hálózaton belül hol található egy erőforrás, és milyen protokollon keresztül lehet elérni. A weboldalak címe, egy API végpontja, egy belső szolgáltatás címe: mind URL.

Példa:
https://api.evolvia.hu/gyakorlat/42

Ez nem egy véletlenszerű karakterhalmaz, hanem precízen meghatározott elemekből áll.

Egy URL szerkezete

Egy tipikus URL több kötelező és opcionális részből épül fel:

https://cloudmentor.hu:443/eleresi/ut/?lekerdezes=ertek#szekcio
└───┬──┘└─────┬──────┘└─┬─┘└────┬────┘└───────┬───────┘└──┬───┘
Protokoll Domain Port Útvonal Query Fragment

Az egyes részek szerepe:

Protokoll
Meghatározza, milyen szabályrendszerrel történik a kommunikáció.
Leggyakoribb: http, https

Domain vagy IP-cím
A cím, amelyhez a kérés érkezik.
Példák:
example.com
192.168.1.10
localhost – saját gépre mutat

Port
A szerveren futó adott szolgáltatás eléréséhez szükséges.
HTTP: 80
HTTPS: 443
API-k esetén gyakran egyedi, például: http://localhost:8080

Útvonal (Path)
Az erőforrás helye a szerveren belül.
Példa: /api/v1/orders

Query paraméterek
Opcionális adatok a kéréshez kapcsolódóan.
Példa: ?sort=asc&page=2

Fragment
Oldalon belüli hivatkozás, például egy szakaszra ugráshoz.

Gyakori URL-típusok és példák

1. Helyi fejlesztés: localhost
http://localhost:3000/api/test
Ez a saját gépre mutat, amit fejlesztők naponta használnak alkalmazások és API-k tesztelésére.

2. IP-cím alapú elérés
http://10.0.0.5:8080/health
Jellemző konténerek, virtuális gépek vagy belső hálózati szolgáltatások esetén.

3. Felhős API-végpontok
https://myapp.azurewebsites.net/api/login
https://abc123.execute-api.eu-west-1.amazonaws.com/prod/items
Ezek minden felhőszolgáltató esetén hasonló logikát követnek.

4. Belső szolgáltatás hivatkozása Kubernetesben
http://redis-master.default.svc.cluster.local:6379
Ez jól mutatja, hogy az URL nem csak internetes cím lehet, hanem klaszteren belüli erőforrás is.

Miért fontos ez a felhőben dolgozó szakemberek számára?

Egy felhőmérnök, DevOps vagy SRE munkája szinte minden nap érinti az URL-eket. API-k hívása, szolgáltatások összekapcsolása, webhookok beállítása, konténerek közötti kommunikáció, gateway routerek konfigurálása: mind olyan feladat, ahol egy hibás karakter is működésképtelenné tehet rendszereket.

Pontosan értve az URL szerkezetét:

gyorsabban lehet hibát keresni
megbízhatóbban lehet szolgáltatásokat összekötni
tisztábban értelmezhetők logok és monitoring adatok
könnyebbé válik a skálázható rendszertervezés

A felhőben minden kommunikáció URL-ekre épül. Aki érti az alapokat, stabil alapot kap a magasabb szintű architektúrákhoz.

Leggyakoribb hibák kezdők körében

Rosszul megadott protokoll: http helyett https
Port kihagyása olyan szolgáltatásnál, ahol nem alapértelmezett (alapértelmezett portok például: 80 – HTTP, 443 – HTTPS)
Query paraméterek helytelen formázása
Localhost és külső elérési címek összekeverése
Privát IP és publikus IP nem megfelelő használata

Ezek mind egyszerű hibák, mégis órákat vehetnek el a hibakeresésből.

HTTP és HTTPS közötti különbség

A webes kommunikáció két leggyakrabban használt protokollja a HTTP és a HTTPS. Bár a két rövidítés csak egyetlen betűben tér el, a mögöttük lévő technológiai különbség alapvetően meghatározza a biztonságot, a hitelesítést és az adatok védelmét. Felhőben dolgozó szakembereknek ez kiemelten fontos, hiszen az alkalmazások, API-k és háttérszolgáltatások nagy része érzékeny adatokat kezel.

HTTP – titkosítás nélküli kommunikáció

A HTTP (Hypertext Transfer Protocol) az alapvető webes protokoll, amely szabályozza, hogyan kommunikál a kliens és a szerver. A HTTP-ben az adatok titkosítatlan formában utaznak, vagyis bárki, aki valamilyen módon hozzáfér a hálózati forgalomhoz, elméletben képes lehet kiolvasni a küldött vagy fogadott tartalmakat. Ez ma már csak fejlesztési, belső hálózati vagy nagyon specifikus esetekben elfogadható.

HTTPS – titkosított és hitelesített kapcsolat

A HTTPS (HTTP Secure) ugyanezt a kommunikációs modellt használja, de kiegészül TLS-alapú titkosítással. A TLS (Transport Layer Security) gondoskodik arról, hogy a kliens és a szerver között áthaladó adatok ne legyenek olvashatók harmadik fél számára. Emellett a szerver hitelesítése is megtörténik tanúsítványok segítségével.

Ez azt jelenti, hogy:

a forgalom titkosított
a kliens meggyőződik arról, hogy valóban a megfelelő szerverhez csatlakozik
az adatok nem módosíthatók észrevétlenül útközben

Miért számít ez a felhőben?

A modern felhőalapú rendszerekben elképzelhetetlen HTTPS nélkül dolgozni. API-k, belső menedzsment felületek, mikroszolgáltatások közötti kommunikáció: mind olyan elemek, ahol a biztonság és az integritás prioritás.

A HTTPS használata azért kritikus:

védi a hitelesítési adatokat
megakadályozza az adatok lehallgatását
biztosítja, hogy a kliens valós szolgáltatással kommunikál
megfelel biztonsági előírásoknak és iparági szabványoknak

Gyakorlati különbségek a fejlesztő szemszögéből

A HTTPS URL-ek https:// előtaggal kezdődnek, a HTTP pedig http:// formát használ
A HTTPS alapértelmezett portja 443, míg a HTTP-é 80
HTTPS esetén szükség van tanúsítványra, amely lehet publikusan hitelesített vagy saját aláírású

Összefoglalás

Az URL nem pusztán egy webcím. Ez a modern internet egyik legfontosabb építőköve. A felhőben dolgozó szakemberek számára pedig különösen lényeges alapelem, hiszen minden szolgáltatás, API, konténer és infrastruktúra modul ezen keresztül kommunikál. Aki tisztában van az URL felépítésével és működésével, sokkal tudatosabban és gyorsabban fogja megérteni a felhős rendszerek belső működését.

2025 10 30

Frissítés szükséges: csak TLS 1.2 az Azure Tárfióknál

Azure, Cloud, Hírek azure, cloud, cloudservices, security, storage

| Olvasási idő: 2 perc |

Aki régen dolgozik Azure-ban, mint én is, rendszeresen kap értesítő e-maileket, amelyekben biztonsági okokból kérik a felhasználót az infrastruktúra módosítására. Most is jött egy ilyen, október elején: a Microsoft arra figyelmeztet, hogy az Azure Tárfiókoknál 2026. február 3. után már csak a TLS 1.2 vagy újabb verzió lesz támogatott.

Ez az értesítés elsősorban azokat érinti, akiknek a Tárfiókjai még TLS 1.0 vagy 1.1 protokollt is elfogadnak. Ezek a régebbi titkosítási eljárások ma már elavultnak számítanak, és nem támogatják a modern kriptográfiai algoritmusokat, ezért a Microsoft fokozatosan megszünteti a használatukat.

Mi az a TLS és miért fontos?

A TLS (Transport Layer Security) egy biztonsági protokoll, amely az internetes adatátvitel védelmét szolgálja. A korábbi verziók (1.0 és 1.1) több mint 20 évesek, és ma már nem felelnek meg a biztonsági követelményeknek. A TLS 1.2 gyorsabb és biztonságosabb kommunikációt biztosít, amely jobban védi az adatokat a lehallgatás és a manipuláció ellen.

Mi a teendő?

Ha az Azure Tárfiókod TLS 1.0 vagy 1.1 protokollt is enged, akkor 2026. február 3-ig frissítened kell a beállításokat, különben az alkalmazásaid nem fognak tudni biztonságosan csatlakozni a szolgáltatáshoz.

A Microsoft ajánlása egyértelmű:

Állítsd be a Minimális TLS-verziót 1.2-re (vagy újabbra).
Ellenőrizd, hogy az alkalmazásaid és SDK-jaid is támogatják a TLS 1.2-t.

Hogyan lehet beállítani a TLS 1.2-t az Azure portálon?

A beállítás módosítása néhány kattintás az Azure portálon:

Lépj be az Azure Portalba.
Keresd meg a módosítani kívánt Tárfiókot.
A bal oldali menüben válaszd a Beállítások > Konfiguráció (Settings > Configuration) menüpontot.
A Minimális TLS-verzió (Minimum TLS version) beállításnál válaszd ki a TLS 1.2 opciót.
Mentsd el a módosítást (Mentés / Save).

Ha több Tárfiókod van, érdemes Azure Policy-t is használni, hogy központilag kikényszerítsd a TLS 1.2 beállítást minden fiókra.

Meddig van időm ezt elvégezni?

A határidő 2026. február 3., eddig kell minden Tárfiókon elvégezni a frissítést. Ezt követően a TLS 1.0 és 1.1 kapcsolatokat az Azure Tárfiók már nem fogadja el.

Aki addig nem módosítja a beállításokat, annak az alkalmazásai hibát fognak adni, amikor megpróbálnak kapcsolódni a Tárfiókhoz.

Összefoglalás

A változás célja, hogy az Azure-felhasználók biztonságosabb és korszerűbb titkosítási eljárásokat használjanak. A frissítés mindössze néhány percet vesz igénybe, de elengedhetetlen a jövőbeni hibamentes működéshez.

2025 10 16

RBAC az Azure-ban: biztonság, jogosultság és hatékonyság

Azure, Cloud access, azure, cloud, cloudservices, iaas, permission, rbac

| Olvasási idő: 4 perc |

A felhőalapú technológiák rohamos terjedésével egyre nagyobb hangsúlyt kap az erőforrásokhoz való hozzáférés kezelése. Az elmúlt hónapokban már több cikkben is körbejártuk, hogyan épülnek fel a modern felhőarchitektúrák, és milyen eszközökkel tarthatók átláthatóan karban. Most azonban elérkeztünk egy olyan témához, ami nélkül minden korábbi tudás bizonytalan lábakon állna: a hozzáférés-kezeléshez. Ennek egyik legfontosabb pillére az RBAC, vagyis a Role-Based Access Control – magyarul szerepkör-alapú hozzáférés-vezérlés.

Képzeljünk el egy nagyvállalatot, ahol több száz vagy több ezer ember dolgozik különböző projekteken. Nem mindenki férhet hozzá mindenhez – a fejlesztők nem módosíthatják a pénzügyi adatokat, az adminisztrátor viszont nem feltétlenül lát bele az alkalmazás kódjába. Az RBAC éppen ezt a problémát oldja meg: egyértelműen meghatározza, ki mit tehet és mit nem.

Mi az RBAC lényege?

Az RBAC alapelve, hogy a hozzáférési jogokat nem közvetlenül a felhasználókhoz, hanem szerepkörökhöz rendeljük. Ezek a szerepkörök előre definiált engedélyeket tartalmaznak, amelyek meghatározzák, milyen műveletek hajthatók végre adott erőforrásokon.
A felhasználók ezután egy vagy több szerepkört kaphatnak – így az engedélyezés egyszerre lesz átlátható, rugalmas és könnyen kezelhető.

A koncepció három alapeleme:

Felhasználók (Users) – azok a személyek vagy szolgáltatások, akik hozzáférnek az erőforrásokhoz.
Szerepkörök (Roles) – engedélyek gyűjteménye, például „Reader”, „Contributor” vagy „Owner”.
Hozzárendelések (Role Assignments) – ezek kapcsolják össze a felhasználót, a szerepkört és az adott erőforrást.

Hogyan működik az RBAC az Azure-ban?

Az Azure RBAC az Azure Resource Manager (ARM) modellre épül, és segítségével szabályozható, hogy ki milyen műveleteket végezhet el Azure-erőforrásokon – például virtuális gépeken, tárfiókokon, adatbázisokon vagy hálózati elemekben.

Az Azure-ban minden erőforrás hierarchikus struktúrában helyezkedik el:

Management Group (Felügyeleti csoport) – a legfelső szint, amely több előfizetést is összefoghat.
Subscription (Előfizetés) – az erőforrások logikai egysége, ahol a számlázás és az erőforrás-kvóták kezelése történik.
Resource Group (Erőforráscsoport) – az erőforrások rendezésére szolgáló konténer, például egy adott projekt vagy alkalmazás elemei számára.
Resource (Erőforrás) – az egyes Azure-szolgáltatások, például virtuális gépek, tárfiókok, adatbázisok vagy hálózati elemek.

Egy szerepkör-hozzárendelés bármelyik szinten megadható, és öröklődik a hierarchia alatti szintekre.
Ha például valaki Reader jogot kap egy teljes előfizetés szinten, akkor automatikusan olvashatja az összes erőforráscsoport és erőforrás tartalmát abban az előfizetésben.

RBAC a gyakorlatban (példa)

Képzeljük el, hogy egy fejlesztőcsapat három szereplőből áll:

Attila, a vezető fejlesztő
Péter, az infrastruktúra adminisztrátor
Zoli, a tesztelő

Az IT biztonsági elv szerint mindenkinek csak a munkájához szükséges jogokat adjuk meg.

Attila (Contributor) – létrehozhat, módosíthat és törölhet erőforrásokat a fejlesztői Resource Group-ban, de nem kezelheti a hozzáféréseket.
Péter (Owner) – teljes körű hozzáféréssel rendelkezik, így módosíthatja a szerepköröket és erőforrásokat is.
Zoli (Reader) – csak megtekintheti a fejlesztési környezetben található erőforrásokat, de nem módosíthat semmit.

Ez a megközelítés egyszerre biztonságos és hatékony, hiszen mindenki csak azt látja és azt kezeli, ami a feladata ellátásához szükséges.

RBAC szerepkörök az Azure-ban

Az Azure több mint 120 beépített szerepkört kínál, de a leggyakoribbak közé tartozik:

Owner – teljes hozzáférés mindenhez, beleértve a hozzáférés-kezelést is.
Contributor – minden erőforrást módosíthat, de nem kezelheti a jogosultságokat.
Reader – csak olvasási hozzáféréssel rendelkezik.
User Access Administrator – mások jogosultságait kezelheti, de magukat az erőforrásokat nem módosíthatja.

Ezen felül lehetőség van egyedi szerepkörök létrehozására is, ha a beépített szerepkörök nem fedik le pontosan a szervezet igényeit.
Egyedi szerepkörök JSON formátumban definiálhatók, és pontosan meghatározható bennük, milyen műveletek engedélyezettek vagy tiltottak.

Az RBAC előnyei

Biztonság – Csökkenti a túlzott jogosultságok kockázatát, így kevesebb az emberi hiba vagy jogosulatlan hozzáférés.
Átláthatóság – Könnyen ellenőrizhető, ki milyen jogokkal rendelkezik.
Skálázhatóság – Nagyvállalati környezetben is egyszerűen kezelhető a jogosultságok bővülése.
Automatizálhatóság – A szerepkörök hozzárendelhetők automatizált szkriptekkel vagy Terraform kódokkal is.

Az RBAC korlátai

Bár az RBAC rendkívül hasznos, nem minden esetben elégséges.

Nem tudja kezelni az adatszintű hozzáféréseket (például egy SQL tábla soraira vonatkozó jogosultságokat).
A komplex szervezeti hierarchiákban a szerepkörök öröklődése nehezen átláthatóvá válhat.
Túl sok egyedi szerepkör esetén nő az adminisztrációs teher és a hibalehetőség.

Ezek miatt sok vállalat az RBAC-et kombinálja más megoldásokkal, például Azure AD (EntraID) Conditional Access vagy Privileged Identity Management (PIM) funkciókkal, amelyek ideiglenes vagy feltételes jogosultságkezelést biztosítanak.

Miért hasznos a cégek és felhasználók számára?

A cégek számára az RBAC legnagyobb előnye a kontroll és a biztonság egyensúlya.
Ahelyett, hogy mindenki korlátlanul hozzáférne mindenhez, az RBAC lehetővé teszi, hogy a hozzáférés csak a szükséges mértékben legyen biztosítva.

A felhasználók számára ez azt jelenti, hogy egyértelműen látják, mire jogosultak, és nem kell aggódniuk a véletlen hibák miatt.
Egy fejlesztő például nyugodtan dolgozhat a saját projektjén anélkül, hogy kockáztatná más rendszerek működését.
A rendszergazdák pedig gyorsabban és pontosabban tudják kiosztani az engedélyeket, akár automatizált folyamatokon keresztül is.

Összegzés

A Role-Based Access Control az egyik legfontosabb biztonsági és hatékonysági alapelv a felhőben. Az Azure RBAC egy kifinomult, de logikusan felépített rendszer, amely segít abban, hogy a szervezetek biztonságosan, mégis rugalmasan kezeljék a hozzáféréseket.

Az alapelve egyszerű: mindenkinek csak annyi jogot adjunk, amennyire valóban szüksége van.

Ez a szemlélet nemcsak az Azure-ban, hanem bármely modern informatikai környezetben elengedhetetlen, ahol a bizalom és az ellenőrzés kéz a kézben jár.

2025 10 06

Vége a Bitnami ingyenes képeknek: mit tehetünk most

AWS, Azure, Cloud, Docker, Hírek, Kubernetes aws, azure, cloud, cloudservices, docker, iaas, k8s, kubernetes

| Olvasási idő: 5 perc |

Az elmúlt időszak eseményei olyanok, mint egy mese, ami váratlanul rémálommá vált. Képzeld el, hogy van egy kis kikötő, ahol a hajók évek óta ugyanazt a megbízható szállítótól kapják az alkatrészeket, ráadásul ingyen. A kapitányok megszokták, hogy mindig időben érkezik az utánpótlás, és minden zökkenőmentesen működik. Egy nap azonban a kikötőt átveszi egy új tulajdonos, aki közli: a régi, készleten lévő alkatrészek ugyan még elérhetők, de újak már nem lesznek, legalábbis nem ingyen.

A kapitányok előtt három út marad: átállnak az új, drágább rendszerre, saját megoldást keresnek, vagy alternatív kikötőt választanak.

Technológiailag ez a helyzet tükrözi, amit néhány napja a Bitnami Docker image-k kapcsán bejelentettek. Sok fejlesztői közösség számára hirtelen egy új realitással kell szembenézni – és most megnézzük együtt, mit is jelent ez a változás, és milyen lehetőségeink vannak.

Mi az a Bitnami?

A Bitnami egy régóta ismert projekt, amely célul tűzte ki, hogy nyílt forrású szoftvereket (pl. adatbázisokat, webkiszolgálókat, cache-rendszereket) „do‐it‐yourself” egyszerűségű csomagként kínáljon: konténerképek, Helm chartok, könnyű telepíthetőség. Évtizedeken át sok Kubernetes-projekt, fejlesztő és üzemeltető használta ki előre konfigurált Bitnami image-eket és chartokat, mivel ezek stabilan, dokumentáltan és viszonylag kevés törés mellett működtek.

A Bitnami projekt most a Broadcom portfóliójába tartozik (Broadcom a VMware-t vásárolta fel), és ennek kapcsán stratégiai átalakítást hajt végre a konténerkép-disztribúciójában.

Miért fontos ez a változás?

A Bitnami eddig szerepelt sok Kubernetes infrastruktúra alapvető építőköveként: telepíthető komponensek, megbízható konténerképek, és helm chartok, amelyek akadálymentesítették az alkalmazások bevezetését. Amikor ez a támogatás visszavonul, többféle technikai és gyakorlati kockázat jelenik meg:

A docker.io/bitnami publikus regisztrációs hely (ahonnan sok image eddig szabadon letölthető volt) a változások hatására mérséklődik, és sok verziós címke eltűnik.
Az eddigi képek átkerültek egy Bitnami Legacy (bitnamilegacy) regiszterbe, ahol nem kapnak több kiadást, frissítést, biztonsági javítást.
Egy új, Bitnami Secure Images (bitnamisecure) hivatalosan nem „közösségi” szolgáltatás, hanem vállalati előfizetéshez kötött, fizetős kínálat.
A publikus Helm chartok (az OCI manifestjeik) frissítése is szünetel: a forráskód továbbra is elérhető marad GitHub-on, de az automatikus képek, verziófrissítések nem mindig jönnek majd.
A végleges “központi” publikus Bitnami regiszter törlése 2025. szeptember 29-én volt.
A Bitnami Secure Images vállalati előfizetésként érhető el, ára a források szerint több ezer dollár havonta, jellemzően 6 000 USD/hó körüli szinten indul.

Mindez azt jelenti, hogy ha nem léptünk időben, a Kubernetes klaszterekben, CI/CD folyamatokban, frissítési és automatikus skálázási műveletek során hirtelen hibaüzenetekkel (például ImagePullBackOff, ErrImagePull) találkozhatunk, amikor a rendszer nem tudja letölteni a szükséges képeket.

Mit okozhat a Kubernetes alapú rendszerekben?

Ha nem készültünk fel:

Új podok nem indulnak el – amikor a fürt új csomópontot indít vagy új replika szükséges, a rendszer letöltené a Bitnami image-t, de ha az már nem elérhető, hibát kapunk: ErrImagePull vagy ImagePullBackOff.
Frissítés vagy skálázás meghiúsul – ha egy alkalmazást új verzióra frissítenénk, de a chartban vagy a konfigurációban Bitnami image hivatkozás van, akkor az update művelet elbukhat.
Biztonsági elmaradások halmozódnak – a bitnamilegacy képek fagyottak: nem kapnak további biztonsági frissítést, így elavult, sérülékeny komponensek maradhatnak használatban.
Rejtett függőségek okozta meglepetések – nemcsak közvetlen alkalmazásaink használhatják Bitnami képeket, hanem alcsomagok, segédkonténerek, init container-ek is, amelyek rejtetten hivatkozhatnak a bitnami regiszterre.
CI/CD pipeline-ok hibái – ha build vagy teszt folyamat során Bitnami képet húzunk be (pl. adatbázis konténer, migrációs konténer), akkor az egész pipeline leállhat.

Összességében tehát egy jól működő rendszerben sok esetben „hallgatólagos” függőségek fognak megbukni, és váratlan leállások vagy hibák léphetnek fel.

Milyen lehetőségeink vannak a problémák megoldására?

Ahogy a halász a történetben új kikötőt vagy hajót választhat, nekünk is több stratégiánk van:

1. Átirányítás a Bitnami Legacy Registry (bitnamilegacy)

Ez a legegyszerűbb ideiglenes megoldás: módosítjuk a konfigurációkat (helm values, deployment spec) úgy, hogy a repository: bitnamilegacy/… formát használjuk, és tartsuk meg a jelenlegi címkéket, amíg át tudunk térni.

Előny: viszonylag kevés munkával elérhető átmeneti működés. Hátrány: ezek az image-ek nem kapnak új frissítéseket vagy biztonsági javításokat — idővel elavultak lesznek.

Ha ezt választjuk, erősen ajánlott saját privát regiszterbe tükrözni (mirror), hogy legalább ne függjünk harmadik féltől.

2. Használjuk a Bitnami Secure Images (BSI) szolgáltatást

A Bitnami bejelentette, hogy új, „secure”, hardened képek és Helm chartok szolgáltatása indul, amely verziókezelést, SBOM-ot, CVE-transzparenciát, és egyéb vállalati tulajdonságokat ad.
Ez a megoldás azonban jellemzően fizetős, és inkább vállalati környezetekben lesz értelmes választás.
Ha előfizetünk, akkor a képek és chartok publikusan már nem a bitnami regiszteren lesznek, hanem automatikus privát vagy dedikált OCI regisztereken.
A Bitnami beígérte, hogy a Secure Images kínálat kisebb, de biztonságosabb verziókat fog tartalmazni (distroless képek, kisebb támadási felület).

3. Teljes elszakadás a Bitnami képektől – alternatívák és saját build

Ez a leginkább javasolt hosszú távon: magunknak választunk más képeket (például hivatalos Docker képeket, más közösségi projektek képeit), vagy akár a Bitnami számára elérhető open source konténerforrásokból saját képeket építünk és menedzselünk.

A Bitnami-forráskódok (Dockerfile-ok, Helm chartok) továbbra is elérhetők GitHubon Apache 2 licenccel — tehát jogilag megengedett saját építésre.
Kiválaszthatunk megbízható, aktív közösségű alternatívákat (pl. hivatalos image-ek, distro-specifikus build-ek).
Szükség lehet az értékek és beállítások átalakítására, mert nem minden image viselkedik ugyanúgy, mint a korábbi Bitnami verziók.
Célszerű bevezetni folyamatos integrációs (CI) pipeline-ban a képek tesztelését, vulnerability scan-t, hogy újabb függőségi hibák ne csússzanak be.
Lépésként részleges migráció is szóba jöhet: először a kritikus komponenseket „lecsupaszított”, alternatív képekkel cserélni, majd haladni tovább.

4. Audit és függőségek feltérképezése

Mielőtt döntenénk, célszerű átfogó auditot végezni:

Kikeresni az összes konténerkép-hivatkozást (pl. grep bitnami a manifestekben).
Megszámolni azokat a fürtön belüli podokat, amelyek Bitnami képet használnak (pl. kubectl get pods -A -o json | jq … | grep bitnami)
Felmérni, mely komponensek kritikusak, melyek kevésbé veszélyeztetettek, hogy prioritásokat állíthassunk.
Tesztelni a migrált konfigurációkat staging környezetben, hogy ne érjen minket meglepetés élesben.

5. Fokozatos átállás, párhuzamos környezetek

Nem feltétlenül kell mindent egyszerre lecserélni. Lehet fokozatosan:

Kritikus komponensek migrálása
Tesztkörnyezetek kipróbálása
Monitorozás, visszajelzések gyűjtése
Végleges átállás

Ez csökkentheti a kockázatot, és lehetőséget ad arra, hogy közbe avatkozzunk, ha valami nem működik.

Összegzés

Ez jelentős változás a konténeres és Kubernetes-alapú rendszerek világában. Ha nem készültünk fel, akkor ImagePull hibák, skálázási problémák és biztonsági elmaradások várnak ránk.

A legbiztosabb megoldás hosszú távon az, ha függetlenedünk a Bitnami-tól: alternatív képeket használunk, saját építésű konténereket alkalmazunk, és megfelelő folyamatokat építünk be (audit, tesztelés, scanning). Addig is átmeneti megoldásként a Bitnami Legacy regiszter használata segíthet.

2025 09 29

Azure CDN: gyors, biztonságos és globális média kezelés

abc, Azure, c, Cloud abc, azure, cdn, cloud, cloudservices, iaas

| Olvasási idő: 3 perc |

Korábban részletesen bemutattam a CDN alapfogalmait, ahol szó volt arról, hogy miként lehet a tartalmakat közelebb vinni a felhasználókhoz, csökkentve a késleltetést és tehermentesítve az eredeti szervereket. Utána írtam az AWS CDN megoldásáról is az AWS CloudFront szolgáltatásról.

Most egy lépéssel tovább megyünk, és megmutatom az Azure CDN-t, amely a Microsoft felhőszolgáltatásának egyik legfontosabb eleme. Gondoljunk bele: mi történik, ha egy nagy nemzetközi esemény közvetítése, egy webáruház kampányidőszaka vagy egy globális alkalmazás frissítése egyszerre több millió felhasználóhoz jut el? Ilyenkor mutatkozik meg igazán, mennyit ér egy jól felépített CDN.

Mi az Azure CDN?

Az Azure Content Delivery Network (CDN) lényege, hogy a tartalmakat – legyen szó weboldalról, képekről, videókról vagy alkalmazásfájlokról – világszerte elérhető peremhálózati (edge) szervereken tárolja. Ezek a szerverek közelebb vannak a végfelhasználókhoz, így az adatok gyorsabban töltődnek be, csökken a hálózati késleltetés, és a felhasználói élmény jelentősen javul.
Jelenleg kétféle háttérhálózaton érhető el:

Azure CDN from Microsoft, amely a Microsoft saját globális hálózatát használja.
Azure CDN from Edgio, amely korábban Verizon/Edgecast néven működött, de átnevezés után is elérhető opció maradt.

A korábbi Azure CDN from Akamai szolgáltatás 2023. októberében kivezetésre került, így ma már nem érhető el új előfizetők számára.

Erősségek

Globális jelenlét: a Microsoft saját hálózata és az Edgio közösen biztosítanak világszintű edge pontokat.
Integráció: szorosan kapcsolódik az Azure Storage-hoz, Web Apps-hoz és Media Services-hez.
Biztonság: HTTPS támogatás, token alapú hitelesítés és modern titkosítási szabványok.
Rugalmasság: fejlett szabálykezelés a gyorsítótárazás finomhangolásához.
Analitika: részletes statisztikák a forgalomról és a teljesítményről.

Lehetőségek és korlátok

Az Azure CDN nem old meg minden teljesítményproblémát. Ha a tartalomforrás lassú vagy hibásan konfigurált, a CDN nem tudja ellensúlyozni. Emellett költséggel is jár: a globális adatforgalom és a speciális funkciók használata külön díjazás alá eshet. Fontos a gondos tervezés, hogy a szolgáltatás valóban értéket adjon.

Felhasználási esetek

Weboldalak: WordPress alapú oldalak esetén a képek és videók gyorsan betöltődnek bárhonnan a világon.
E-kereskedelem: nemzetközi webshopok stabil vásárlói élményt tudnak biztosítani csúcsidőben, például Black Friday alatt.
Streaming: videószolgáltatók számára akadozásmentes lejátszást biztosít még extrém terhelés mellett is.

Azure CDN és AWS CloudFront. Mikor?

Mindkét szolgáltatás globális lefedettséget, integrációt és biztonságot kínál.

Azure CDN: előnyös azoknak, akik elsősorban Microsoft-ökoszisztémát használnak.
AWS CloudFront: jobban illeszkedik az Amazon szolgáltatásaihoz, például az S3-hoz és a Lambda@Edge-hez.

A választás gyakran attól függ, melyik felhőszolgáltatót használja az adott szervezet elsődlegesen.

Összegzés

Az Azure CDN ideális választás minden olyan vállalat számára, amely globális jelenlétet, gyorsabb betöltődést és jobb felhasználói élményt szeretne biztosítani. Ez közvetlen üzleti előnyt is jelent: nagyobb konverziós arányt, elégedettebb ügyfeleket és jobb piaci megítélést.

2025 09 18

Miért fontos a CDN a modern webes világban?

AWS, Azure, Cloud, GCP aws, azure, cloud, cloudservices, gcp, iaas

| Olvasási idő: 4 perc |

Korábban már írtam olyan felhőszolgáltatásokról, amelyek nem csupán hasznosak, hanem kifejezetten izgalmasak is. Például az AI-t használó SageMaker Canvas, amely segít egyszerűen elindulni a gépi tanulás világában. A felhő világában azonban nemcsak az intelligencia, hanem a sebesség és a megbízhatóság is kulcsfontosságú. Gondoljunk csak bele: ha egy weboldal lassan töltődik be, a felhasználók nagy része azonnal bezárja.

Képzelj el egy mesebeli könyvtárat, ahol a világ összes könyve elérhető. Amikor keresel valamit, nem kell a fővárosba utaznod, mert minden nagyobb városban van egy helyi fiók, amelyben a legnépszerűbb könyvek ott várnak rád. Így bárhol jársz a világban, mindig gyorsan megkapod, amit keresel. A digitális világban pontosan ezt a szerepet tölti be a CDN (Content Delivery Network).

Mi az a CDN?

A CDN egy globális szerverhálózat, amely a weboldalak és alkalmazások statikus tartalmát (képeket, videókat, JavaScript és CSS fájlokat) a felhasználóhoz földrajzilag közel tárolja.

Amikor egy látogató megnyit egy weboldalt, a tartalom nem feltétlenül az eredeti központi szerverről érkezik, hanem a hozzá legközelebb lévő „edge” szerverről. Ez a közeli kiszolgálás drámaian lecsökkenti a betöltési időt, és így javítja a felhasználói élményt.

Hogyan működik?

Cache-elés (gyorsítótár): A statikus tartalmak (pl. képek, videók) előre másolatként elérhetőek a CDN pontokon.
Edge szerverek: Ezek a földrajzilag szétszórt szerverek a világ számos pontján elhelyezkednek.
Intelligens forgalomirányítás: A felhasználó mindig a legközelebbi edge szervertől kapja meg a tartalmat.
Frissítés kezelése: Amikor a központi szerveren változik egy fájl, a CDN gondoskodik róla, hogy az új verzió a cache-elt példányokat is felülírja.

Milyen előnyöket nyújt a CDN?

Gyorsabb betöltési idő: A tartalom a felhasználóhoz közeli szerverről érkezik. Egy tokiói látogató nem Budapestről tölti le a képet, hanem Japánból.
Megbízhatóság és redundancia: Ha egy szerver kiesik, a hálózat más pontjai átveszik a terhelést.
Skálázhatóság: Nagy forgalomnövekedés esetén (pl. Black Friday, kampányidőszak) a CDN elosztja a terhelést.
Biztonság: Sok CDN véd DDoS támadások ellen és automatikus HTTPS támogatást kínál.

Példák a CDN használatára

WordPress weboldal
Képzelj el egy WordPress blogot, amely tele van képekkel és videókkal. A szerver Budapesten van, de az olvasóid Németországból, az USA-ból és Ázsiából is érkeznek. Ha minden tartalom csak Budapestről érkezne, a távoli látogatóknak lassan töltődne be. Ha viszont a képeket és videókat a CDN tárolja, akkor a felhasználók mindenhol ugyanolyan gyorsan kapják meg az oldal tartalmát – a legközelebbi edge szerverből. Ez jobb élményt ad, és az oldal Google-keresési rangsorolása is javulhat.
Globális SaaS szolgáltatás
Egy CRM rendszert több ezer cég használ világszerte. Az alkalmazás szerverei Frankfurtban vannak, de az ügyfelek Dél-Amerikában és Ázsiában is dolgoznak vele. CDN nélkül mindenki ugyanarra a központi szerverre kapcsolódna, ami lassulást és instabilitást okozhatna. A CDN azonban gondoskodik róla, hogy az alkalmazás statikus részei (UI, JavaScript, képek) a felhasználókhoz közeli edge szerverekről töltődjenek le. Az élmény olyan, mintha az alkalmazás helyben futna.
Médiaoldal vagy streaming szolgáltatás
Egy nagy hírportálnál vagy streaming cégnél kritikus, hogy a videók megszakítás nélkül fussanak, még akkor is, ha milliók nézik egyszerre. A CDN segít elkerülni a túlterhelést, és biztosítja, hogy a tartalom folyamatosan, késleltetés nélkül érkezzen a felhasználókhoz.

Hogyan kapcsolódik a felhőhöz?

A nagy felhőszolgáltatók kínálnak saját CDN megoldást:

Amazon CloudFront (AWS)
Azure Front Door
Google Cloud CDN

Ezek közvetlenül integrálhatók más szolgáltatásokkal (például tárhellyel, webalkalmazás-szerverekkel), így szinte automatikusan skálázható és globálisan gyors rendszer hozható létre.

Vannak korlátai is

Költség: Nagy adatforgalom esetén a CDN komoly költséget jelenthet.
Beállítási komplexitás: A kezdőknek a konfiguráció elsőre bonyolult lehet (cache szabályok, TTL értékek).
Nem minden tartalomhoz ideális: A CDN főként statikus fájloknál hatékony. Dinamikus tartalom, például adatbázis-lekérdezések nem gyorsíthatók vele közvetlenül.

Mikor érdemes CDN-t használni?

A weboldalad vagy alkalmazásod nemzetközi közönséget céloz.
Kritikus számodra a sebesség és felhasználói élmény.
Gyakoriak a nagy forgalmi hullámok.
Ha a biztonságot szeretnéd növelni.

Összefoglalás

A CDN a modern web egyik alapköve. Olyan, mintha a digitális világ könyvtárát földrajzi fiókokra osztanánk, így mindig gyorsan és biztonságosan elérhető lenne a tartalom. Nem minden projektnél szükséges, de ahol a sebesség, a stabilitás és a globális jelenlét fontos, ott a CDN szinte kötelező.

A Te weboldalad vagy alkalmazásod is profitálna a gyorsabb betöltésből és a stabilabb működésből – lehet, hogy épp most jött el az idő a CDN kipróbálására.

Boldog szülinapot nekem!