1. Hogyan fognak küldeni levelet a 3rd party üzleti alkalmazások?
2. Hogyan fogok tudni scan-to-mail-t használni?
3. Kamera/riasztó/szünetmentes hogyan fog küldeni levelet Exchange online-on keresztül?
4. Nem tudok mindenhol OAuth-ot használni, mégis tudok majd levelet küldeni a felhőből?
5. stb.

SMTP levélküldés az Exchange Online-ból

A Microsoft már többször nekiszaladt, hogy megszünteti az ún. Basic Auth-ot az SMTP mailküldés esetében – ezt egyelőre halasztották – most 2027 közepe a végleges dátum. Ettől függetlenül nem mindig tudjuk használni ezt a megoldást, mert:

• A tenant sztintű „Security Defaults” megakadályozza
• Nincs Entra P1 licencünk, így a Security Defaults helyett nem tudunk használni Conditional Access-t, hogy kivételre tehessük a küldőt

Természetesen OAuth segítségével továbbra is használhatjuk az smtp.office365.com címet és küldhetünk is levelet, „csak” a Basic auth nem fog működni.

Jellemzően se az MFP-k se egyéb régi cuccok nem fognak tudni küldeni levelet OAuth-al.

Levélküldési lehetőségek az M365-ben és azon túl

A következő lehetőségeket természetesen kombinálhatjuk is:

Mikor melyik megoldást érdemes használni?

1. Client SMTP submission – ha fontos, hogy külön postafiókban a „Sent Items”-ben akarjuk tárolni a kimenő leveleket. (pl.: további feldolgozás miatt, vagy egyéb levél beolvasás miatt). Hátránya, hogy OAuth kell neki és egy darab Exchange Online licence is.
2. SMTP Relay – Nyomtatókhoz, kamerához, 3rd party alkalmazásokhoz kiváló, figyelni rá, hogy az SMTP server az M365-ös MX rekordod lesz! (pl.: contoso-com.mail.protection.outlook.com). Hátránya, hogy kell neki egy FIX IP cím a telephelyen és az SPF rekordba is vegyük fel ezt az IP-t! (Exchange admin centerben készíteni kell egy vagy több konnektort!)
3. Direct Send – Microsoft terve, hogy ez defaultban ki lesz kapcsolva, csak bentre küld, de magasabbak a limitációi mint a Client SMTP submission-nak!
4. High Volume E-mail – belső nagytömegű e-mailküldés, akár 50 postafiók is létrehozható, nincs licence költsége!
5. Azure Communication Services – külön költsége van, Azureban számolódik el. Jellemzően nagytömegű külső levélküldésre használjuk (Webshop, E-számla stb.)

A SMTP levélküldés a Microsoft felhőből bejegyzés először HRP Services-én jelent meg.

Mi az a BLOB?

Binary Large Object storage – az egyik legrégebbi Azure szolgáltatás, segítségével strukturálatlan adattömeget (fájlok, videók, képek, logok, mentések stb.) tárolhatunk hatékonyan a felhőben. 3 típusa van:

• Block
• Page
• Append

Ebben a bejegyzésben nem részletezem a különbségeket a 3 típus között, legyen most annyi elég, hogy IT üzemeltetési szempontból nekünk a Block Blob a lényeges.

Mi az a Storage Tiering?

Azt jelenti, hogy a felhőben tárolt Block Blobjaimat mindig az aktuális igényeknek megfelelően tárolhatom:

• Elérés sebessége és módja
• Árazás

Típusai:

• Hot
• Cool
• Cold
• Archive
• Smart (erről lesz szó, hamarosan!)

A storage tiering úgy működik, hogy ha nincs szükségem valamilyen adatra sokáig (pl.: logok, régi filmek) akkor „hátra” sorolom másik rétegbe (tier-be). Így olcsóbb lesz a tárolásom, de lassabb vagy éppen költséges az elérésem. Archive rétegbe például akkor érdemes adatokat átmozgatni, ha minimum 180-360 napig biztosan nem fogunk hozzá férni.

Mi az a Storage Lifecycle Manager?

Olyan Azure szolgáltatás („felhős job”) melynek segítségével az automatikus adatmozgatást elvégezhetem valamilyen szabályok szerint, pl.:

ha az adott BLOB-on nem volt se írási olvasási művelet 30 napig, akkor mozgasd át Cool-ba, majd 60 nap után Cold-ba, majd 180 nap után Archive-ba stb.

Figyeljünk rá, hogy az adatmozgatásnak is van díja, hiszen folyamatosan írjuk/olvassuk az adott fájlt, vagyis blob-ot!

Ezen kívül, ha egy rétegbe túl korán mozgatunk át adatokat (pl.: HOT-ból Cool-ba 15 nap után) akkor korai törlési díjat is felszámolnak!

Hogyan működik a Storage Smart Tiering?

Ezzel az új rétegezési megoldással nem kell manuálisan létrehozzunk Storage Lifecycle manager szabályokat, nincs adatmozgatási díj, nincs korai törlési díj, nem kell mindenféle táblázatot böngésznünk!

Nagyon egyszerű a működési modell:

• minden 30 napnál régebbi adat mozog automatikusan Cool rétegbe
• minden 90 napnál régebbi adat mozog automatikusan Cold rétegbe
• minden adat „visszaugrik” HOT rétegbe a hozzáféréskor
• nincs korai törlési díj
• van egy minimális „Monitoring fee” minden olyan BLOB-ra, mely nagyobb mint 128 KiB (minden 10 000 objektumonként 0,04 EUR/hó)

Nézzük az árakat!

A következő feladatot kaptuk az egyik partnertől/ügyféltől:

Van egy Veeam backup szerver, a heti mentés nagysága 15TB, ezt kellene kitolni Azure-ba hetente és megőrizni az adatokat 180 napig! Azt, hogy mennyi BLOB-ot hoz majd létre a szoftver nem tudjuk.

Első kalkuláció Lifecycle Manager használatával

HOT mentés 30 napig: 15 TB – kb 300 EUR/hó és az írási olvasási tranzakciók számát nem ismerjük!

Cool mentés 60 napig: 30 TB – kb 341 EUR/hó

Cold mentés 90 napig: 45 TB – kb 195 EUR/hó

összesen: 90 TB kb. 900 EUR/hó és nem tudjuk, hogy mennyi lesz az írási olvasási tranzakciók száma és költsége sem az első mentéskor, sem később a tiering során! Ez az ismeretlen szám nagyon magas is lehet és nagyon nehéz becsülni! (a költség nem azonnal jelentkezik, hanem fokozatosan növekszik 180 napig, míg be nem áll a végleges állapot)

Smart Tier kalkuláció

Lesz egy ismeretlenem az egyenletben szintén: blobok száma a mentés után. (első alkalommal kiderül, érdemes egy POC keretében kipróbálni!)

Tárolási díj ugyanúgy 90 TB kb. 900 EUR, viszont nem lesz tranzakciós díjam és korai törlési díjam sem + nincs munka a Lifecycle manager beállítással és annak módosításával: minden automatikusan fog történni! (szintén fokozatosan fog nőni a számla, nem azonnali költség!)

A költségek korai megfigyelése sok segítséget adhat a további beállítások helyes kiválasztásában!

Beállítása

Minden zóna redundáns storage account-on bekapcsolható, vagy új storage fiók létrehozásakor is kiválasztható:

1. ábra Storage Smart Tier forrás: https://techcommunity.microsoft.com/blog/azurestorageblog/unlocking-storage-optimizations-smart-tiering-for-blobs-and-adls-in-azure-storag/4469811

Mikor használjunk Smart Tiering-et?

Amikor nem tudjuk pontosan, hogy az Azureba mentett vagy archivált adatokra pontosan mikor van szükségünk, nem határolhatók el az egyes rétegek egzakt módon.

Amikor ad hoc gyorsan és olcsón kell hozzáférni 30, 60, 90 napos adatokhoz.

Mikor ne használjuk? – Amikor valamit archiválni szeretnénk és teljesen biztosak vagyunk benne, hogy több mint 180 napig az adathoz biztosan nem kell hozzáférnünk! ebben az esetben ott van az Archive Tier – szuper olcsón!

A Storage Smart Tiering avagy hogyan tárolhatok több petabájtnyi adatot költséghatékonyan a felhőben? bejegyzés először HRP Services-én jelent meg.

A NAT Gateway egy hálózati címfordítási (NAT) szolgáltatás, ami a belső IP címeket fordítja egy publikus IP-re, lehetővé téve pl. az internet elérését. A NAT szolgáltatáson keresztül NEM érhetők el a belső hálózati erőforrások az internet felől (csak a kimenő csomagokra érkező válaszok engedélyezettek).

Két típusa:

• Standard
• StandardV2

Természetesen a V2-es megoldás az újabb és természetesen „többet tud” mint az előző verzió:

• Zónaredundáns (már nem kell külön meghatározni zónánként)
• IPV6-támogatás
• Nagyobb sávszélesség (100Gb/s a korábbi 50Gb/s helyett)
• Forgalom naplózása

Miért van most aktualitása a NAT GW-nek?

A Microsoft 2026. március 31-től megváltoztatja az alapértelmezett hálózati üzemeltetési módot és nem engedélyezi az implicit Internet hozzáférést (a korábbi erőforrások működnek tovább).

Vagyis a fenti dátumtól, ha létrehozunk egy új hálózatot, akkor az sokkal „szigorúbb lesz” és a benne lévő VM-ek nem kapnak default NATolást az internet felé.

A jövőben az alábbi módokon biztosíthatunk „internetet” az Azure VM-nek:

1. ábra: forrás: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access?tabs=portal

Hogyan működik a NAT GW?

A NAT GW szolgáltatás létrehozásakor meg kell adnunk, hogy mely hálózatban és azon belül mely alhálózatokban (subnetekben) végezzen címfordítást, természetesen több subnet is megadható, de több VNET nem! (VNET peering megengedett)

2. ábra: NAT GW v2 Zóna támogatással

Használatához válasszuk az Azure portálon a NAT Gateways menüpontot (felső menübe beírni)

3. ábra: NAT GW Standard V2

Ki kell választani, hogy milyen publikus IP címet használjon az átjáró, ez megtörténhet a NAT GW létrehozásakor, vagy korábban is elkészíthetjük a Publikus IP-t külön is!  IPV6 támogatás beállításához Standard V2 Public IP kell!

Standard V2 Public IP

Az új NAT GW megoldáshoz új IP cím típust is bevezettek, de erről túl sok dokumentációt nem lehet találni jelenleg, ami fontos információ, hogy az új NAT GW-hez ezt az új Public IP típust KELL használni.

4. ábra: V2-es Public IP létrehozása

Árak

Ami jó hír, hogy mind a NAT GW-ből, mind az IP-ből nyugodtan választhatjuk az új V2-es verziót, mert az ára ugyan az, mint az előző verziónak! NAT GW esetében az ár két tényezőből rakódik össze:

1. GW ára óránként/havonta
2. Adatforgalmi díj – GW-n átmenő adatforgalom GB-ban

5. ábra: Azure NAT GW és adatforgalom költségek West Europe-ban

6. ábra: Publikus IP árazása West Europe-ban

Előnye

A NAT GW használata sokkal biztonságosabb, mint ha minden VM dedikált Publikus IP-t kapna! A felügylete is jóval egyszerűbb és nincs az a veszély, hogy a VM-ek (vagy egyéb szolgáltatások) közvetlenül Internet felől is megszólíthatóak. (nem kell vesződni az NSG-vel vagy az Azure FW-vel sem!)

Jelen esetben pedig az ügyfél külön kérése volt, hogy akkor mostantól mind az AVD VM-ek, mind az adatbázis szerver azonos IP-ről látszódjon az Internet felé. Bővebb információ és összehasonlítás a NAT GW-ről: https://learn.microsoft.com/en-us/azure/nat-gateway/nat-sku#sku-comparison

A NAT Gateway v2 és a Standard v2 Publikus IP használata bejegyzés először HRP Services-én jelent meg.