Nemrégiben ismét egy újabb, rosszul megírt projektet indítottam el szórakozásból, mert hiszek abban, hogy a saját problémáimat mások problémáivá kell tennem. Ez közben eszembe jutott valami, ami már régóta motoszkált bennem: az AWS-sel való munka meglehetősen fájdalmas.
Miért tűnhet ez furcsának?
Ez elsőre talán nevetségesnek hangzik, hiszen a legtöbb jól bejáratott cégnél az AWS használata nem különösebben megterhelő: kódot tolunk egy tárolóba, elindul a CI/CD folyamat (amelynek gyakran Jenkins a motorja – egy érdekes figura, akivel ugyan sok helyen dolgoztam együtt, de személyesen sosem találkoztam), és valahogy a kód végül éles környezetbe kerül.
Azonban pont ez a fejlesztői eszközök hiánya az igazi probléma: ha nem fektetünk bele rengeteg munkát a környezet kialakításába, akkor az AWS használata rendkívül körülményes és frusztráló tud lenni.
Az AWS használatának buktatói lépésről lépésre
Képzeljük el, hogy teljesen nulláról szeretnénk egy egyszerű webalkalmazást telepíteni az AWS-re. Az első lépések így néznek ki:
- Fiók létrehozása: Először regisztrálnunk kell egy AWS fiókot.
- AWS SSO alkalmazás beállítása: Ez mostanra átneveződött “IAM Identity Center”-re, amihez elengedhetetlen egy AWS szervezet létrehozása is.
- Engedélyek kezelése: Egy „permission set” (ami egyébként nem túl világos fogalom) hozzárendelése egy IAM szerepkörhöz.
- Bejelentkezés az SSO panelbe: Ez egy nehezen megjegyezhető URL-en érhető el, ezért én például készítettem egy automatikus átirányítót, hogy könnyebben elérjem (például „shitposting.badUX.cloud” címről).
- Szerepkör kiválasztása: A hosszú listából ki kell választani a megfelelő szerepkört.
- Kapcsolódás a fejlesztői környezethez: Ehhez vagy az AWS SSO parancssori eszközt használjuk, vagy inkább a nyílt forráskódú granted.dev projektet, amely sokkal kényelmesebbé teszi ezt a folyamatot.
Ezek után következik a kulcskezelés vagy az OIDC kapcsolat beállítása GitHub-bal (vagy GitLab-bal – bár ezt inkább hagyjuk), majd a GitHub Actions vagy az AWS CodeBuild segítségével történik a telepítés. Ekkor még azt is ki kell találni, hogy melyik AWS szolgáltatásra telepítsük az alkalmazást: AWS Amplify-ra? Amazon CodeCatalyst-re? (Utóbbi nemrégiben megszűnt.)
A legnagyobb kihívás: IAM konfiguráció
A hozzáférések beállítása az egyik legfrusztrálóbb része az egész folyamatnak. Az IAM dokumentáció olyan érzést kelt, mintha egy magányos szerzetes írta volna, miközben lassan összenyomta volna egy boroshordó. Itt próbáljuk megadni az erőforrásoknak csak annyi jogosultságot, amennyi feltétlenül szükséges – ami persze sosem működik elsőre.
Többszöri próbálkozás után vagy túlságosan széles jogosultságokat adunk, vagy feladjuk és mindent engedélyezünk „TODO” megjegyzéssel ellátva. Ez a „TODO” aztán gyakran örökre ott marad – amíg végül el nem vesznek a kód utolsó példányai is valamilyen képzeletbeli nagy holografikus könyvtártűzben 2351-ben.
Google Cloud Platform: Egy másik megközelítés
Ezzel szemben a Google Cloud Platform (GCP) sokkal egyszerűbben kezeli ezt a helyzetet. Alapértelmezés szerint minden projekt képes kommunikálni egymással ugyanazon projekten belül. Biztonsági szakértők persze tiltakozhatnak ez ellen mondván, hogy ez nem vállalati szintű megoldás – igazuk is van –, ezért fejlettebb szervezetek kikapcsolhatják ezt és explicit engedélyeket állíthatnak be. Azonban sok fejlesztő értékeli azt, hogy nem kell minden alkalommal bonyolult biztonsági akadályokat leküzdeniük ahhoz, hogy működő rendszert építsenek.
A további konfigurációs rémálmok
Egy egyszerű webalkalmazás telepítésekor még számos szolgáltatást kell kezelni: S3 tárolók címkézése, CloudFront CDN beállítása, Route 53 DNS konfigurációja, EC2/Fargate/Lambda + API Gateway integrációja, adatbázisok (RDS vagy DynamoDB) kezelése és persze számlázási riasztások beállítása. Ezek mind különböző konzolrészeken találhatók és nem működnek zökkenőmentesen együtt alapból.
Végül pedig feltöltjük a kódot és rájövünk: összességében több látogatója van egy kis fóka videónak, mint az általunk épített weboldalnak – mert sajnos senkit sem érdekel már igazán, amit készítünk.
Egyszerűség kontra komplexitás: Vercel és társai
Ezzel szemben nézzük meg például a Vercel platformot! Egy egyszerű webalkalmazás telepítése itt kevesebb időt vesz igénybe, mint amennyi idő alatt én meggyőztem a szerkesztőmet ennek a cikknek a publikálásáról. Ugyanez igaz Netlify-ra, Render-re és számos más modern fejlesztőközpontú felhőszolgáltatásra is – amelyek garantáltan megjelennek majd önreklám kommentek formájában pár percen belül ennek a cikknek a megjelenése után.
A választás lehetősége
Az egyszerű telepítés nem technikai akadálya az AWS-nek; hiszen maga a Vercel is az AWS infrastruktúrájára épül. A különbség kizárólag abban rejlik, hogy mennyire akarják magas szinten biztosítani a jó felhasználói élményt.
Egy generációs váltás küszöbén
Sokan közülünk (X generációsok és millenniumiak) már megszokták az AWS és GCP sajátosságait – ezekkel nőttünk fel technológiailag. Az Azure inkább az idősebb generációk platformja. Az újabb generációk viszont olyan platformokat használnak majd, amelyek nem tesztelik folyamatosan ügyességüket és türelmüket.
Mesterséges intelligencia és jövőbeli fejlesztők
Nemrég egy AI robot segítségével készítettem demót egy közelgő re:Invent előadáshoz. Érdekes módon ez az AI aktívan próbált lebeszélni az AWS használatáról annak komplexitása miatt. Bár végül meggyőztem őt arról, hogy maradjunk annál, mégis ez mutatja: ezek az intelligens rendszerek fogják tanítani a következő fejlesztőgenerációt.
A jövő fejlesztői nem lesznek hajlandók átérezni azt a türelmetlenséget és masochizmust, amit ma az AWS-hez való alkalmazkodás jelent. Ők olyan platformokon fognak dolgozni majd, amelyek nem követelik meg tőlük szenvedéssel bizonyítani rátermettségüket.
Következtetés
Az Amazon Web Services két évtized alatt felépítette világ legfejlettebb felhőplatformját. Azonban könnyen lehet, hogy a következő két évtizedben csak azok számára marad releváns, akik már mélyen beágyazódtak ebbe az ökoszisztémába – míg mások újabb és egyszerűbb megoldások felé fordulnak majd.
Forrás: https://www.theregister.com/2025/11/04/aws_genz_misery_nope/