Menu

storage

s3_namespace_image

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

, , , , ,

| Olvasási idő: 3 perc |

Az S3 20 éve szolgál már minket, mint az egyik legjobb felhő alapú tároló a piacon. Ez alatt a 20 év alatt talán a legidegesítőbb mindig a bucket-ek nevének kiválasztása volt. A kezdetektől – hiszen már az AWS is 20 éves – globálisan egyedi nevet kellett megadnunk, amikor egy S3 bucket-et létrehoztunk.

Aki dolgozott már AWS-sel, biztos belefutott ebba a klasszikus hibába: kiválasztasz egy tökéletes bucket nevet… majd jön a hiba, hogy már foglalt.

És ilyenkor jön a kreatív káosz:
alkalmazas-adatok-prod-123

Nem túl elegáns. És ami fontosabb: enterprise környezetben ez nem csak esztétikai probléma, hanem governance és skálázási kérdés is.

Az Amazon most ezen változtatott egy fontos lépéssel: megjelent az account regional namespace az S3 general purpose bucket-ekhez.

Ez elsőre apróságnak tűnik, de valójában egy elég komoly architekturális változás. És mindemellett nagy könnyebbség nekünk.

Mi volt eddig a probléma az S3 bucket nevekkel?

Az S3 eddig globális namespace-et használt.

Ez azt jelenti:

  • minden bucket név globálisan egyedi kellett legyen
  • nem csak a te accountodban
  • hanem az egész AWS-ben

Ez több problémát okozott:

  • nehéz volt értelmes és több fiókon átívelő naming convention-t tartani
  • „multi-account” esetén hamar káosz lett
  • CI/CD pipeline-oknál collision veszély
  • onboarding során gyakori hibák

Sok-sok ilyet látok és láttam már: a bucket nevek elkezdtek „véletlenszerű szöveg + suffix” irányba elmenni.

Mi az az account regional namespace?

Az új modell lényege:

  • a bucket nevek nem globálisan, hanem
  • account + régió szinten lesznek egyediek

Tehát ugyanaz a bucket név:

  • használható több accountban
  • és akár több régióban is

Ez nagyon fontos különbség.

Mit jelent ez a gyakorlatban?

Vegyünk egy egyszerű példát.

Korábban:

  • cloudmentor → ha valaki már használta a világon, bukó

Most:

  • cloudmentor használható:
    • a te AWS accountodban
    • egy adott régióban

Ez közelebb hozza az S3 működését más AWS szolgáltatásokhoz, ahol az erőforrások általában account szinten izoláltak.

Összehasonlítás: régi vs új modell

Régi (globális namespace)

  • Bucket név: globálisan egyedi
  • Naming: alkalmazas-eles-v2 (suffixek, random stringek)
  • Multi-account: nehézkes
  • Automatizálás: collision kockázat
  • Governance: nehezebb standardizálni

Új (account regional namespace)

  • Bucket név: account + régió szinten egyedi
  • Naming: tiszta, olvasható
  • Multi-account: egyszerűbb
  • Automatizálás: kiszámíthatóbb
  • Governance: könnyebb enforce-olni

Mi a legnagyobb előnye?

Ha egy dolgot kellene kiemelnem: visszahozza az érthető, konzisztens elnevezési szabályokat.

És ez nem csak esztétika. Ez hatással van:

  • DevOps workflow-kra
  • IaC (Terraform, OpenTofu) használatra
  • onboarding sebességre
  • hibák számának csökkentésére

Egyébként is a naming convention az egyik leggyorsabban „szétcsúszó” dolog, minden környezetben. Ez a változás ezt stabilizálja.

Mire kell még figyelni?

Ez nem azt jelenti, hogy minden probléma megoldódott.

Néhány fontos korlát:

  • legacy bucket-ek továbbra is léteznek
  • nem mindenki fog azonnal átállni
  • naming collision fiókon belül továbbra is lehet
  • cross-account access esetén még mindig kell tervezés

És ami kritikus: governance továbbra is a te felelősséged.

Ez egy eszköz, ami segít egyszerűsíteni, de nem egy teljes megoldás.

Mikor lesz ez igazán fontos?

Ez főleg akkor jön ki:

  • multi-account architektúrában
  • IaC alapú előforrás kezelésnél
  • platform csapatoknál
  • nagyobb szervezeteknél

Egy kis projektnél lehet, hogy nem érzed meg. Enterprise szinten ez nagyon sok problémát szüntet meg.

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

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

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

s3_20_cover

Amazon S3: 20 év adattárolás élén. És utána mi következik?

, , , , ,

| Olvasási idő: 4 perc |

Aki régóta dolgozik AWS-el, mint én is, annak az Amazon S3 szinte természetes része lett a mindennapoknak. Olyan, mint a levegő: nem gondolunk rá külön, de mindenhol ott van.

Amikor az Amazon S3 2006-ban megjelent (és vele az S3 is elsőként), még nem beszéltünk microservices-ről, Kubernetes-ről vagy AI modellekről napi szinten. Az adat viszont már a kezdetektől létezett. Csak nem volt ilyen egyszerű kezelni.

Ma pedig ott tartunk, hogy az S3 nem csak egy storage megoldás, hanem egy alapréteg. Egy csendes infrastruktúra elem, ami nélkül a modern cloud gyakorlatilag nem működik.

És most, hogy az AWS a 20. születésnapját ünnepli, érdemes egy pillanatra megállni, és megnézni: mit adott nekünk, és merre tartunk tovább.

Miért volt ennyire meghatározó az S3?

Erre könnyű a válasz: mert egyszerű volt.

Az S3 egy object storage szolgáltatás. Ez azt jelenti, hogy fájlokat (object-eket) tárolunk benne, kulcs-alapú eléréssel, nem klasszikus fájlrendszerként.

A valódi ereje nem ebben van, hanem abban, hogy:

  • gyakorlatilag korlátlanul skálázódik
  • nem kell szervereket kezelni
  • API-n keresztül bárhonnan elérhető
  • és nagyon magas tartósságot biztosít (durability)

Ez a kombináció 2006-ban forradalmi volt. És szerintem még ma is az.

Mire használják valójában az S3-at?

Sokan azt gondolják, hogy az S3 „csak egy fájltároló”.

A valóságban viszont rengeteg különböző use case épül rá. Nézzünk meg néhányat, amikkel én is rendszeresen találkozom.

1. Backup és archiválás

Ez a klasszikus.

  • adatbázis mentések
  • logok tárolása
  • hosszú távú archiválás (pl. törvényi megfelelőség miatt)

Az S3 lifecycle policy segítségével az adatokat automatikusan lehet költséghatékonyabb ú.n. storage class-ba mozgatni (pl. Glacier, Deep Archive).

Sok cég esetében azonban néha hiba csúszik a gépezetbe: feltöltik az adatokat az S3-ba, de lifecycle szabály nincs létrehozva, majd csodálkoznak, hogy a költségek elszállnak.

2. Statikus weboldalak kiszolgálása

S3 + CDN (CloudFront) = egyszerű és olcsó web hosting.

Tipikus példa:

  • landing page
  • dokumentációs oldal
  • egyszerű frontend app (React, Vue)

Nem kell VM, nem kell Kubernetes. Ez az a „simplicity”, amit sokan túl korán elfelejtenek. Pedig itt szinte ingyen van.

3. Data lake alap

Ez már egy komolyabb use case.

Az S3 gyakran a data lake alapja:

  • raw adatok tárolása
  • strukturált és strukturálatlan adatok együtt
  • későbbi feldolgozás (pl. Athena, Glue)

Itt már megjelenik az adatstratégia, amely egy új színtere egy cég életének. És itt szokott elcsúszni a legtöbb projekt: nincs naming convention, nincs partitioning, így később nehéz kezelni.

4. AI és machine learning

Az elmúlt évek egyik legnagyobb változása. Az S3 ma már az AI pipeline-ok egyik alapja:

  • training datasetek tárolása
  • model artifactek mentése
  • inference input/output tárolás

AWS oldalon például a SageMaker is erősen épít rá, de ugyanez igaz más platformokra is. Nehéz olyan megoldást találni, ahol az S3-at nem használjuk. Igazi alappillér.

5. CI/CD és DevOps

Ezt kevesebben említik, pedig napi szinten használjuk.

  • build artifactek tárolása
  • Terraform state backend (S3 + locking)
  • telepítési csomagok

Egy egyszerű példa: Egy pipeline build-el egy alkalmazást, majd feltölti S3-ba, és onnan olvassa fel a kódot az AWS Lambda.

Egyszerű, stabil, jól működik.

6. Log és observability adatgyűjtés

Sok rendszer logjai végül S3-ban landolnak:

  • Terheléselosztó és alkalmazás naplófájlok
  • CloudTrail események
  • Hálózati információs naplófájlok

Innen tovább lehet őket feldolgozni (pl. Athena vagy más tool-ok).

Mi változott 20 év alatt?

Őszintén? Az alap koncepció szinte semmit és nekem pont ez tetszik.

Ami változott:

  • több storage class (költségoptimalizálás)
  • jobb biztonsági kontrollok (IAM, encryption, bucket policy)
  • esemény alapú működés (S3 event → Lambda)
  • integráció más szolgáltatásokkal

Az alap modell ugyanaz maradt. Ez ritka az IT-ban és a jelenlegi világunkban.

És mi jöhet ezután?

Itt érdemes kicsit megállni. Igyekszem biztos dolgokat írni és nem csupán találgatni.

1. S3 mint adatplatform alap

Egyre több rendszer épít közvetlenül S3-ra, nem csak tárolásként, hanem:

  • query layer-rel
  • metadata kezeléssel
  • verziózással

Ez már nem a klasszikus storage használat.

2. AI-first adatkezelés

Az AI miatt az adatok szerepe megváltozott:

  • nem csak tároljuk, hanem használjuk is folyamatosan
  • nem csak a struktúrált adat értékes, hanem minden adat számít

Az S3 ebben központi szereplő maradhat.

3. Egyszerűség visszatérése

Ebben a túlbonyolított világban, szükség van az egyszerű és megbízható dolgokra és ilyenkor sokan visszatérnek az alapokhoz:

  • S3
  • egyszerű pipeline
  • kevesebb komponens

Ez nem visszalépés, hanem érettség.

Buktatók S3 használat közben

Ez fontos, mert könnyű belefutni:

  • nincs lifecycle policy: drága lesz
  • nem megfelelő access control: biztonsági kockázat
  • hiányzó elnevezési stratégia: káosz
  • minden adat egy bucket-ben: kezelhetetlen

Ezek nem technikai problémák, hanem tervezési hibák, amelyek átgondoltsággal könnyen orvosolhatók.

A következő 20 év előtt

Az S3 nem látványos. Nincs UI varázslat, nincs „wow” élmény, de ott van minden mögött.

Az elmúlt 20 évben az egyik legstabilabb alapköve lett a cloud világnak és nem csak az AWS-ben lakó szolgáltatásoknak.

És ha valamit érdemes megérteni mélyen – akár kezdőként is –, akkor ez az. Mert nem csak egy szolgáltatást tanulsz meg. Hanem azt, hogyan gondolkodik a modern infrastruktúra az adatokról.

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

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

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

azure-tarfiok-tls

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

, , , , , ,

| 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:

  1. Lépj be az Azure Portalba.
  2. Keresd meg a módosítani kívánt Tárfiókot.
  3. A bal oldali menüben válaszd a Beállítások > Konfiguráció (Settings > Configuration) menüpontot.
  4. A Minimális TLS-verzió (Minimum TLS version) beállításnál válaszd ki a TLS 1.2 opciót.
  5. 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.

Statikus weboldal (1080 x 1080 képpont)

Statikus weboldal AWS-en egyszerűen – videó

, , , , , , , , , , , , , , , ,

| Olvasási idő: 3 perc |

Az egyszerű, gyors és költséghatékony weboldalhosztolás egyik legjobb módja, ha statikus weboldalunkat az AWS-re helyezzük. Ebben a bejegyzésben videóban lépésre bemutatom, hogyan lehet egy statikus weboldalt S3-ban tárolni, a publikus elérést beállítani. Ideális megoldás portfóliók, dokumentációk vagy egyszerű céges oldalak számára.

Ráadásul a weboldal fejlesztésében ChatGPT is a segítségünkre lesz.

Hogyan készítsd el a weboldaladat (index.html és error.html fájlokkal) ChatGPT segítségével

Hozz létre egy felhasználói fiókot ChatGPT-ben, majd nyiss egy új beszélgetést és add meg neki a következő prompt-ot. (Kedved szerint módosítsd a számodra fontos adatokat. Pl.: Milyen legyen a kinézet és a stílus, mi legyen a domain név, mi legyen a cég neve és profilja)

Szia,

Segíts nekem. Te egy webfejlesztő vagy.

AWS S3 static website-ot szeretnék létrehozni. Ehhez kérlek készíts egy index.html fájlt és egy error.html fájlt. Emellett hozd létre a szükséges bucket policy-t is. A bucket neve a domain neve legyen.

Az index.htm egy komplex, modern, letisztult, színes (fekete, ezüst, mélyzöld), egylapos weboldal legyen ami egy magyar startup cég weboldala lesz. 

Cég neve: LignumArt
Iparág: Faipar, luxus bútorok egyedi megrendelésre
Domain név: lignumart.mentorcloud.hu

Előre is köszönöm.

Ez alapján legenerálásra kerül 3 fájl tartalma (index.html, error.html, bucket-policy.json) A számítógépeken hozd létre ezeket a fájlokat és másold bele a megfelelő tartalmakat.

S3 bucket konfiguráció és bucket policy beállítása

  1. Jelentkezz be az AWS fiókodba.
  2. Keresőben keresd meg az S3-at
  3. Hozz létre egy bucketet az S3 felületén a Create bucket gombra kattintva
  4. A bucket adatai:
    • Név: a te domain-ed neve. Mi esetünkben lignumart.mentorcloud.hu
    • Block all public access részből vedd ki az összes jelölőt
    • Nyugtázd, hogy elfogadod a nyilvános fájlokkal kapcsolatos kockázatokat
  5. Kattints a lapalján a Create bucket gombra
  6. Megnyitjuk a bucket-et
  7. Properties fülre megyünk és legörgetünk a lap aljára
  8. Static website hosting részt szerkesszük és engedélyezzük
  9. Adjuk meg a megfelelő helyen az index.html és error.html fájlok nevét
  10. Mentsük el a változásokat
  11. Permission fülre menjünk át
  12. Keressük meg a Bucket policy részt
  13. Edit gomb megnyomásával szerkeszthetjük is
  14. Az itt szereplő mezőbe másoljuk be a bucket-policy.json fájl tartalmát, majd mentsük el
  15. Görgessünk a lap aljára és mentsük el a változásokat

Fájlok feltöltése S3 bucket-be

  1. Menjünk a Objects fülre
  2. Upload gombra kattintva kezdjük el a fá ljok feltöltését (Add files)
  3. Amikor a fájlok feltöltésre kerültek navigáljunk át a Properties fülre és görgessünk a lap aljára
  4. És ott találjuk a weboldalunk linkjét. (formátum: http://<bucket neve>.s3-website.<aws régió neve>.amazonaws.com)
  5. Ha ezt megnyitjuk, akkor láthatjuk a weboldalunkat
  6. Ezzel gyakorlatilag készen vagyunk 🙂

Saját domain használata a weboldalhoz

Itt a Route 53 szolgáltatást fogjuk használni egyéni domain rendeléssel. A példánkban feltételezzük, hogy AWS.ben már beállítottuk a domain zónánkat (Route 53 hosted zone).

Az alábbi lépéseket kell követned:

  1. Jelentkezz be az AWS fiókodba.
  2. Keresőben keresd meg az Route 53-at
  3. Lépjünk be a domain zónába, ami a domain nevünkhöz tartozik
  4. Create record gombra kattintva elkezem a dns bejezés létrehozását
  5. Átváltunk a varázsló nézetre, a Switch to wizard linkre kattintva
  6. Válasszuk a Simple routing lehetőséget, majd Next gomb
  7. Define simple record gombra kattintva folytatjuk a beálltást
  8. Itt az alábbiakat állítjuk be
    • Record name: az általunk választott aldomain neve (mi esetünkben: lignumart), ha a fő domain nevünket akarjuk itt beállítani, akkor ezt hagyjuk üresen
    • Record type: A
    • Value/Route traffic to: Amazon S3 website endpoint
    • Régió: az a régió ahová a bucket-ünket létrehoztuk
    • Végpont neve: a legördülő menüben megjelenik a mi S3 bucket-ünk
  9. Define simple record gombra kattintva elmentjük a változásokat
  10. A teljes véglegesítéshez kattintsunk a Create record gombra
  11. Ezzel létrejött a domainhez tartozó DNS bejegyzés, és használatba is vehetjük azt.
  12. Nyissuk meg böngészőnkben a megfelelő linket: http://<én domain nevem amit használtam> (mi példánkban: http://lignumart.mentorcloud.hu)

Ezzel elérhetővé vált mindenki számára a weboldalunk, az általunk beállított saját domain nevén.

Próbáld ki te is, és meglátod milyen egyszerű. 🙂

Verified by MonsterInsights