A felhő technológia alapjai és jelentősége
Határidők / Események
Mit jelent ez a gyakorlatban?
Ha az alkalmazásod vagy integrációd TLS 1.0 / 1.1-et használ, kapcsolódási hibák léphetnek fel 2026.02.03. után. Az érintett Storage account-oknál minél hamarabb át kell állni TLS 1.2-re.
Érdemes ellenőrizni a kliensalkalmazásokat, SDK-kat, régi runtime-okat (pl. legacy Java, .NET, régi appliance-ek, stb.).
Mit tegyél most?
1. Nézd meg, mely Storage account-ok érintettek (Azure Retirement Workbook: https://aka.ms/ServicesRetirementWorkbook).
2. Ellenőrizd, hogy a kliensalkalmazások milyen TLS verziót használnak.
3. Állítsd be a minimum TLS verziót 1.2-re az érintett Storage account-oknál.
4. Teszteld az alkalmazásokat a módosítás után.
Ez CloudTrail eseménynevek és event source-ok változásával jár, ami érintheti a számlázáshoz kapcsolódó auditokat, riasztásokat és automatizmusokat.
Mi változik?
• billingconsole.amazonaws.com ➡️ billing.amazonaws.com
• Több eseménynél event name módosul (pl. RedeemPromoCode ➡️ RedeemCredits)
Érintett események például:
• GetCredits
• RedeemCredits
• GetBillingNotifications
Mit tegyél?
Ha bármilyen megoldásod (SIEM, alert, compliance check, Lambda, stb.) CloudTrail billing eseményekre épül, frissítsd az “event name + event source” párosokat 2026.02.16 előtt, hogy elkerüld az események kimaradását a naplózásból.
Ez egy “láthatatlan” változás, ami nem okoz közvetlen hibát – de adatot veszíthetsz, ha nem figyelsz rá.
-
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!
-
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.
-
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.
A Google Cloud elindította az új, natív OpenTelemetry (OTel) ingestion API-t, amely közös nevezőre hozza a logok, trace-ek és metrikák fogadását.
🗓️ Mi történik és mikor?-
2026. március 4.: Az új
telemetry.googleapis.comvégpont automatikusan aktiválódik minden olyan projektben, ahol a Cloud Logging, Trace vagy Monitoring API-k használatban vannak. -
Az új projekteknél az alapértelmezett aktiválás részeként ez az API is a függőségek közé kerül.
A cél egy zökkenőmentes átmenet biztosítása az OpenTelemetry Protocol (OTLP) irányába. Az új, egységesített végpont:
-
Native OTel támogatás: Hatékonyabb log, span és metrika beküldés.
-
Egyszerűbb infrastruktúra: Kevesebb különálló API-t kell kezelni a gyűjtőeszközök (collectorok) konfigurációja során.
-
Transzparencia: A meglévő szolgáltatásaidban nem lesz fennakadás, a Google automatikusan kezeli az aktiválást a háttérben.
-
Nincs közvetlen teendőd: A migráció automatikus, a meglévő ingestion folyamatok zavartalanul futnak tovább.
-
Audit: Ha szigorú biztonsági szabályokat (Org Policies) alkalmazol az engedélyezett API-kra vonatkozóan, érdemes felvenni a listára a
telemetry.googleapis.comvégpontot, hogy elkerüld az aktiválási hibákat.
Ez a lépés is mutatja, hogy az OpenTelemetry végérvényesen az iparági sztenderddé vált a Cloud Observability területén.
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. március 29-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.
-
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!
-
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.
-
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.