Cloud Mentor - A gyakorlati felhőtudás forrása

2026.05.21.

Golden image refresh: egységes OS-verzió egyszerűbben

VMSS-ek karbantartása korábban kézzel, lassan - ma Golden Image refresh-el, Terraform-al, verziókezelve. Ha VMSS-t üzemeltetsz, ez megkönnyíti a mindennapjaid

2026.05.14.

Tanúsítvány: AWS AIF-C01 – újabb kaland az AI világában

Három AI vizsga után az AWS AIF-C01 segített igazán rendszerezni a tudást. Nézd meg, miért volt hasznos, friss és inspiráló…

2026.05.05.

GitHub Copilot új árazás: fizetsz, amennyit használsz

A GitHub Copilot 2026 júniusától usage-based modellre vált. Ha AI-eszközökkel dolgozol, ez a változás téged is érint – és érdemes…

2026.04.30.

Google Cloud Agents CLI: egy eszköz az egész életciklushoz

A Google Cloud Agents CLI azt oldja meg, ahol a legtöbb fejlesztői csapat megakad: a prototípustól az éles deployment-ig. Próbáld…

2026.04.23.

Vertex AI új néven: itt a Gemini Enterprise Agent Platform

A Google Cloud 2026-ban átnevezte a Vertex AI-t és több adatplatform termékét. Nézzük meg, mi változott, mi marad, és mit…

2026.04.14.

Tanúsítvány: Azure AI-900 vizsga, ami nem csak kezdésnek jó

AI vizsgában gondolkodsz? Megmutatom, mit adott nekem az Azure AI-900, és miért lehet ez neked is egy erős első lépés…

2026.04.07.

GitHub Copilot: használják-e az adataid tanításra vagy nem?

Ha használsz Copilotot, mostantól eldöntheted, hogy felhasználhatják-e az adataid tanításra. Te mit gondolsz? Olvasd el, és írd meg nekem is.

2026.03.30.

Új S3 namespace modell: végre nem kell a nevekkel küzdeni

Eleged van abból, hogy minden S3 bucket név foglalt? Az AWS új namespace modellje végre megoldja ezt, és tisztább, kiszámíthatóbb…

1 2 3 4 ›»

Kategóriák

Felhő / Cloud

Felhő ABC

Mesterséges Intelligencia / AI

Videók

Határidők / Események

2026.06.01.

Azure Frissítés

Virtual Desktop: Secure Boot tanúsítványfrissítés

Fontos biztonsági határidő közeledik az AVD környezetek üzemeltetői számára. A Secure Boot 2011-es tanúsítványai hamarosan lejárnak, ami közvetlenül érinti a Trusted Launch funkcióval rendelkező virtuális gépeket.

🗓️ Határidő

2026. június: Eddig kell elvégezni a frissítést a Secure Boot 2023-as tanúsítványokra.

🛠️ Kit érint ez a változás?

Azokat az Azure Virtual Desktop session hostokat, amelyeknél engedélyezve van a Trusted Launch és a Secure Boot.
Azokat a szervezeteket, amelyek egyedi "golden image"-ekből építkeznek.

Kit NEM érint?

Akik nem használnak Secure Boot-ot, vagy kikapcsolták a Trusted Launch funkciót (bár biztonsági szempontból ez nem javasolt).

✅ Tennivalók

Audit: Mérd fel, hány session host fut az érintett 2011-es tanúsítvánnyal.
Frissítés: Telepítsd a Secure Boot 2023-as tanúsítványokat a Microsoft útmutatása alapján.
Image management: Ha saját image-eket használsz, frissítsd az alap sablonokat, hogy az új telepítések már a 2023-as tanúsítvánnyal induljanak el.

A frissítés elmaradása esetén a rendszerek védtelenek maradhatnak a boot-szintű fenyegetésekkel szemben, vagy kompatibilitási hibák léphetnek fel az indításkor.

Hasznos link

Kritikus: Ez egy fontos változás, a szolgáltatás/funkció ezen a napon megszűnik vagy megváltozik. A zavartalan működéshez beavatkozás szükséges.

2026.06.16.

GCP Beállítás Értesítés

Google Cloud Billing: Változik a CUD-ok kezelése

A Google módosítja a kötelezettségvállalási kedvezmények (Commitment Use Discount - CUD) alapértelmezett beállításait. A cél a kihasználatlan kedvezmények minimalizálása és a megtakarítás maximalizálása.

🗓️ Dátum: 2026. június 16.

🛠️ Mi változik?

Eddig a projektalapú (resource-based) CUD-ok alapértelmezés szerint csak az adott projektben voltak felhasználhatók. Júniustól a megosztás (sharing) lesz az alapértelmezett beállítás:

Új fiókoknál: Automatikusan bekapcsolt megosztás.
Meglévő fiókoknál (aktív CUD nélkül): Szintén aktiválódik a megosztás.
Meglévő fiókoknál (aktív CUD-dal): A jelenlegi beállításaid nem változnak, marad minden a régiben.

💰 Mi az előnye?

A megosztással a kedvezmény nem "ragad be" egy projektbe. Ha az egyik projektben csökken az erőforrásigény, a kifizetett kedvezményt a számlázási fiókhoz tartozó bármely más projekt igénybe veheti.

✅ Teendők

Pénzügyi izoláció: Ha projektalapú elszámolást (chargeback) alkalmazol, és nem szeretnéd, hogy a kedvezmények "vándoroljanak" a projektek között, a Billing konzolon manuálisan ki kell kapcsolnod a megosztást (Self-serve toggle).
Kezelhetőség: Ha eddig manuálisan sakkoztál a kedvezményekkel, most érdemes felülvizsgálni, hogy az automatikus megosztás egyszerűsítené-e az életedet.

Alapvetően ez egy pozitív változás, de a komplexebb költséghely-kezelésnél érdemes körültekintően eljárni.

Hasznos link

Opcionális: Ez egy opcionális változás vagy kényelmi funkció, nem kötelező alkalmazni.

2026.08.31.

GCP Kivezetés

Google Cloud KMS kvótarendszer migrációja II.

🗓️ Fontos dátumok

2026. február 16. – február 27.: A migrációs folyamat aktív szakasza.
2026. augusztus 31.: A régi metrikák végleges kivezetése. Eddig az időpontig kell frissíteni minden egyedi monitorozást!

🛠️ Mi változik?

Regionális kvótaérvényesítés: A forgalom mostantól ott számít bele a kvótába, ahol a feladat fut (még multi-region forgalom esetén is).
Új metrika elnevezések: Pontosabb kategóriák érkeznek a védelem típusa szerint (software_usage, hsm_usage, etc.) és műveleti típusok alapján (read_usage, write_usage).
"Soft Enforcement": Az új metrikák többségénél a kvóta túllépése esetén is kiszolgálja a rendszer a kéréseket, amennyiben van szabad kapacitás.

✅ Teendők

Monitorozás: Ha saját dashboardokat vagy riasztásokat használtok, augusztus 31-ig írjátok át őket az új metrikákra az adatok folytonossága érdekében.
Kvóta túllépések (Overrides): A meglévő override-okat a Google automatikusan migrálja, ezzel nincs teendőtök.
Számlázás: A változás nem érinti a költségeket, a KMS számlázása továbbra is használat alapú marad.

Hasznos link

Kritikus: Ez egy fontos változás, a szolgáltatás/funkció ezen a napon megszűnik vagy megváltozik. A zavartalan működéshez beavatkozás szükséges.

2026.09.30.

GCP Biztonság Új

IAM szerepkör-változások a Google Cloudban

A Google Cloud több szolgáltatás esetén módosítja az előredefiniált IAM szerepkörök jogosultságait.
A cél az egységesebb role-definíció és az új, valamint meglévő funkciók lefedése.

➡️ Role-definíciók egységesítése:
• {Service} Admin – teljes hozzáférés az adott szolgáltatás minden műveletéhez
• {Service} Editor – erőforrások létrehozása, módosítása, törlése és használata (security policy-k nélkül)
• {Service} Viewer – read-only hozzáférés az erőforrásokhoz és konfigurációjukhoz.

⚠️ Hatás a meglévő projektekre
• A változás nem érinti a jelenlegi működést
• Az érintett felhasználók és service account-ok 2026. szeptember 30-tól automatikusan megkapják az új jogosultságokat.

⚠️ Ajánlott ellenőrzési pont
• Érdemes átnézni, hogy az új permission-ök illeszkednek-e a jelenlegi IAM és security modellhez
• Ha szükséges, a hozzáférés finomítható custom IAM role-lal vagy IAM Deny policy-vel

Ez egy role-definíciókat érintő változás, amelyet mindenkinek érdemes tudnia.

Hasznos link

Opcionális: Ez egy opcionális változás vagy kényelmi funkció, nem kötelező alkalmazni.

2027.02.27.

Azure Biztonság Migráció

Azure Key Vault: RBAC lesz az alapértelmezett

A Microsoft bejelentette az Azure Key Vault API-k eddigi egyik legjelentősebb változását. Ha az infrastruktúrádat kódból építed (IaC), erre nagyon oda kell figyelned!

🗓️ Kulcsfontosságú dátumok

2026. február: Megjelenik a 2026-02-01 API verzió, ahol már az Azure RBAC lesz az alapértelmezett modell az új vault-oknál.
2027. február 27.: Minden korábbi API verzió kivezetésre kerül (Retirement).

🛠️ Mi változik?

Eddig az új Key Vault-ok alapértelmezés szerint "Access Policy" (örökölt hozzáférési szabályok) módban jöttek létre. Az új API verzióval ez megfordul:

RBAC az új alapértelmezett: Minden újonnan létrehozott vault Azure RBAC-re lesz állítva, hacsak nem jelzed explicit módon az ellenkezőjét.
IaC hibaforrás: Ha a Terraform vagy Bicep scriptjeid nem tartalmazzák az explicit konfigurációt, az új vault-ok RBAC módban jönnek létre, a korábbi Access Policy-k pedig nem fognak működni.

✅ Mit kell tenned?

Megerősítem a Microsoft javaslatát: Migrálj Azure RBAC-re! Ez sokkal granuláltabb, biztonságosabb és a modern Azure standard-oknak megfelelő megoldás.

Teendők:

Ellenőrizd a meglévő Key Vault-jaidat, és készíts tervet az RBAC-re való áttérésre.
Frissítsd a CLI, PowerShell, ARM, Bicep és Terraform sablonjaidat.
Ha ragaszkodsz a régi Access Policy modellhez, az új API verzióra való váltáskor explicit módon be kell állítanodezt a sablonjaidban, különben az automatizációid elhasalnak.

Ha nem módosítod az automatizációs scriptjeidet, az új vault-ok 403-as hibával elutasíthatják a kéréseket.

Ne várd meg 2027-et, az új API-val járó változások már jövő februártól élesednek az új erőforrásoknál!

Hasznos link

Ajánlott: Ez egy javasolt módosítás, vagy egy új funkció. A szolgáltatás működését közvetlenül nem befolyásolja.